1. 首页首页
  2. 编程笔记编程笔记

在线有道翻译

编程笔记 • • 阅读 22

使用BGP的链路状态和流量工程(TE)信息的网路分布 摘要 在许多环境中，需要调用网络外部的组件来执行基于网络拓扑结构和网络内连接的当前状态的计算，包括流量工程(Traffic Engineering, TE)信息。这是通常由IGP路由协议在网络中分发的信息。 本文档描述了一种通过BGP路由协议从网络中收集链路状态和TE信息并与外部组件共享的机制。

使用BGP的链路状态和流量工程(TE)信息的网路分布

摘要

在许多环境中，需要调用网络外部的组件来执行基于网络拓扑结构和网络内连接的当前状态的计算，包括流量工程(Traffic Engineering, TE)信息。这是通常由IGP路由协议在网络中分发的信息。
本文档描述了一种通过BGP路由协议从网络中收集链路状态和TE信息并与外部组件共享的机制。
这是通过一种新的BGP网络层可达性信息(NLRI)编码格式实现的。该机制适用于物理和虚拟IGP链路。
所描述的机制受策略控制。该技术的应用包括应用层流量优化(ALTO)服务器和路径计算元素(PCEs)。
这是一个互联网标准跟踪文件。本文档是IETF (Internet ngineering Task Force)的产品。
它代表了IETF社区的共识。它已接受公众审查，并已获互联网工程指导小组(IESG)批准出版。有关互联网标准的更多信息，请参阅RFC 5741第2节。有关本文档的当前状态、勘误表以及如何提供反馈的信息可在http://www.rfc-editor.org/info/rfc7752获得。

在许多环境中，需要调用网络外部的组件来执行基于网络拓扑结构和网络内连接的当前状态的计算，
包括流量工程(Traffic Engineering, TE)信息。这是通常由IGP路由协议在网络中分发的信息。
本文档描述了一种通过BGP路由协议从网络中收集链路状态和TE信息并与外部组件共享的机制。
这是通过一种新的BGP网络层可达性信息(NLRI)编码格式实现的。该机制适用于物理和虚拟IGP链路。
所描述的机制受策略控制。
该技术的应用包括应用层流量优化(ALTO)服务器和路径计算元素(PCEs)。

  1. Introduction

链路状态数据库(Link-State Database, LSDB)或IGP的流量工程数据库(Traffic Engineering Database, TED)的内容
仅描述IGP区域内的链路和节点。一些应用程序，如端到端交通工程(TE)，将受益于一个区域或自治系统(as)之外的可见性，
以便做出更好的决策。

IETF定义了路径计算元素(PCE) [RFC4655]作为一种机制，用于实现跨越多个TED的可见性或需要cpu密集型或协调计算的端到端TE路径的计算。
IETF还将ALTO服务器(RFC5693)定义为生成抽象网络拓扑并将其提供给网络感知应用程序的实体。

PCE和ALTO服务器都需要收集有关网络拓扑和功能的信息，以便能够实现它们的功能。

本文描述了一种利用BGP路由协议[RFC4271]从网络中收集链路状态和TE信息并与外部组件共享的机制。
这是通过使用一种新的BGP网络层各可性信息(NLRI)编码格式实现的。该机制适用于物理链路和虚拟链路。所描述的机制受策略控制。

路由器维护一个或多个数据库，用于存储任何给定区域内的节点和链路的链路状态信息。存储在这些数据库中的链路属性包括:本地/远端IP地址、本地/远端接口标识符、链路度量和TE度量、链路带宽、保留带宽、按服务分类保留状态、抢占和共享风险链路组(SRLGs)。

路由器的BGP进程可以从这些lsdb中检索拓扑，并使用本文中指定的编码方式，直接或通过对等体BGP speaker(通常是专用的Route Reflector)将其分发给消费者。

链路状态和TE信息的收集和分布情况如下图所示。
±----------+
| Consumer |
±----------+
^
|
±----------+
| BGP | ±----------+
| Speaker | | Consumer |
±----------+ ±----------+
^ ^ ^ ^
| | | |
±--------------+ | ±------------------+ |
| | | |
±----------+ ±----------+ ±----------+
| BGP | | BGP | | BGP |
| Speaker | | Speaker | . . . | Speaker |
±----------+ ±----------+ ±----------+
^ ^ ^
| | |
IGP IGP IGP

       Figure 1: Collection of Link-State and TE Information

BGP speaker可以对其发布的信息应用可配置的策略。因此，它可以从LSDB或TED中分发真实的物理拓扑。或者，它可以创建一个抽象的拓扑，其中虚拟的、
聚合的节点通过虚拟路径连接。例如，可以在一个存在点(Point of Presence, POP)中的多个路由器中创建聚合节点。抽象拓扑也可以是物理和虚拟节点
以及物理和虚拟链接的混合。此外，BGP speaker还可以应用策略来确定何时向消费者更新信息，从而减少从网络到消费者的信息流。

用于聚合或虚拟化拓扑的机制不在本文讨论范围之内。

1.1. 要求语言

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].

  1. 动机和适用性
    本节描述可以从其中导出需求的用例。

2.1. MPLS-TE with PCE

如[RFC4655]所述，PCE可用于计算一个“域”(如IGP区域)内的MPLS-TE路径，也可用于跨多个域(如多区域As或多个As)的MPLS-TE路径。
o 在单个区域内，PCE提供了增强的计算能力，这在单个路由器、复杂的策略控制和算法以及整个区域的计算协调上可能是不可用的。
o 如果一个路由器想要计算一个跨越IGP区域的MPLS-TE路径，那么它自己的TED就缺乏对整个拓扑的可见性。这意味着路由器无法确定端到端路径，
甚至无法为最优路径选择正确的出口路由器(区域边界路由器(ABR))。对于大型网络来说，这是一个问题，它们需要将核心网络划分为不同的区域，但仍然希望利用MPLS-TE。

以前的解决方案使用每域路径计算[RFC5152]。源路由器只能计算第一个区域的路径，因为路由器只对沿路径的第一个区域有完全的拓扑可见性，而对后续区域没有。每个域路径

compute使用一种叫做“loose-hop-expansion”的技术[RFC3209]，并使用igp计算的最短路径拓扑来选择出口ABR和其他ABR或AS边界路由器(asbr)。这可能会导致次优路径，使备用/备份路径计算困难，并可能导致在真正存在TE路径时找不到TE路径。

该PCE提供了一个计算服务器，该计算服务器可以对多个IGP区域或AS具有可见性，或者可以与其他PCE合作执行分布式路径计算。PCE显然需要为它服务的区域访问TED，但是[RFC4655]没有描述这是如何实现的。许多实现使PCE成为IGP中的被动参与者，以便它可以了解网络的最新状态，但当网络受到高度的变动或PCE负责多个区域时，这可能是次优的。

下图显示了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   |
            +----------+              +----------+

 Figure 2: 使用TED同步机制的外部PCE节点

本文档中的机制允许从网络内的IGP收集必要的TED信息，根据可配置的策略进行过滤，并根据需要分发到PCE。

2.2. ALTO Server Network API

ALTO服务器[RFC5693]是一个实体，它生成抽象的网络拓扑，并通过基于web服务的API将其提供给网络感知的应用程序。示例应用程序是点对点(P2P)客户端或跟踪器，
或内容分发网络(cdn)。抽象的网络拓扑以两种映射的形式出现:一个network Map指定分区标识符(Partition identifier, pid)的前缀分配，另一个Cost Map指定network Map中列出的pid之间的开销。详细信息请参见[RFC7285]。

ALTO抽象网络拓扑可以从底层网络的物理拓扑自动生成。生成通常基于操作员设置的策略和规则。需要配置前缀数据和TE数据:
生成ALTO Network Maps需要配置前缀数据，生成ALTO Cost Maps需要配置TE (topology)数据。
前缀数据在BGP中产生，TE数据在IGP中产生。本文中定义的机制提供了一个单一的接口，通过该接口，ALTO服务器可以从底层网络检索
所有必要的前缀和网络拓扑数据。需要注意的是，ALTO服务器可以使用其他机制来获取网络数据，例如与多个IGP和BGP speaker进行对等。

下图展示了ALTO服务器如何使用本文中描述的机制从底层网络获取网络拓扑信息。

 +--------+
 | Client |<--+
 +--------+   |
              |    ALTO    +--------+     BGP with    +---------+
 +--------+   |  Protocol  |  ALTO  | Link-State NLRI |   BGP   |
 | Client |<--+------------| Server |<----------------| Speaker |
 +--------+   |            |        |                 |         |
              |            +--------+                 +---------+
 +--------+   |
 | Client |<--+
 +--------+

     Figure 3: ALTO Server Using Network Topology Information

  1. BGP中携带链路状态信息

这个规范包含两部分:定义一个新的边界网关协议NLRI描述链接节点,和前缀组成显卡的链路状态信息,、
定义一个新的边界网关协议路径属性(BGP-LS属性),链接,节点,和前缀属性和属性,如链接和前缀度量或辅助路由器- id的节点,等等。

我们希望将这个属性对协议源的依赖保持到最小，并以igp中立的方式表示任何内容，这样想要了解链路状态拓扑的应用程序就不需要了解任何OSPF或is - is协议的细节。

3.1. TLV Format

新的链路状态NLRIs和属性中的信息以Type/Length/Value三联体形式编码。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)                     //
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       Figure 4: TLV Format

Length字段以字节为单位定义值部分的长度(因此，没有值部分的TLV的长度为0)。
TLV没有填充到4-八隅体对齐。必须保留和传播无法识别的类型。为了比较NLRIs和未知TLV，所有TLV必须按照TLV类型升序排列。
如果有更多的相同类型的tlv，那么无论字符串的长度如何，tlv必须是排序字符串，并首先比较最左边的字节。
3.2. 链路状态NLRI

MP_REACH_NLRI和MP_UNREACH_NLRI属性是BGP用来承载不透明信息的容器。每个link - state NLRI描述一个节点、
一条链路或一个前缀。

所有非vpn链路、节点和前缀信息均使用AFI 16388 / SAFI 71编码。VPN链路、节点和前缀信息使用AFI 16388 / SAFI 72编码。

为了使两个BGP speaker能够交换Link-State NLRI，它们必须使用BGP Capabilities Advertisement来确保它们都能够正确地处理这种NLRI。
按照[RFC4760]的规定，使用能力码1(多协议BGP)， AFI 16388 / SAFI 71用于BGP- ls, AFI 16388 / SAFI 72用于BGP- ls - vpn。

链路状态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)                 //
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Figure 5: Link-State AFI 16388 / SAFI 71 NLRI Format

  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

总NLRI长度字段包含NLRI其余部分的累计长度，单位为八位元，不包括NLRI类型字段或本身。对于VPN应用，它还包括Route Distinguisher的长度。

               +------+---------------------------+
               | Type | NLRI Type                 |
               +------+---------------------------+
               |  1   | Node NLRI                 |
               |  2   | Link NLRI                 |
               |  3   | IPv4 Topology Prefix NLRI |
               |  4   | IPv6 Topology Prefix NLRI |
               +------+---------------------------+

                        Table 1: NLRI Types

路由区分器的定义和讨论在[RFC4364]。

节点NLRI (NLRI Type = 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)            //
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 7: The Node NLRI Format

链路NLRI (NLRI Type = 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)                //
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 8: The Link NLRI Format

IPv4和IPv6前缀NLRIs (NLRI Type = 3和Type = 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)                //
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Figure 9: The IPv4/IPv6 Topology Prefix NLRI Format

Protocol-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                           |
        +-------------+----------------------------------+

                   Table 2: Protocol Identifiers

当BGP-LS获取本地信息时，应该使用“Direct”和“Static configuration”协议类型。
对于来自其他协议的所有信息，必须使用相应的协议id。如果BGP-LS可以直接访问接口信息，并且希望发布本地链路，
则应该使用协议id direct。对于虚拟链接的建模，如第4节中所描述的，应该使用协议id“静态配置”。

OSPF和IS-IS都可能在同一条链路上运行多个路由协议实例。参见[RFC6822]和[RFC6549]。这些实例定义了独立的“路由域”。64位Identifier字段用于
标识NLRI所属的路由域。NLRIs代表来自同一路由域的链路状态对象(节点、链路或前缀)必须具有相同的“标识符”值。具有不同“标识符”值的NLRIs必须被
认为来自不同的路由世界。

表3列出了在本文档中定义为众所周知的“Identifier”值。

         +------------+----------------------------------+
         | Identifier | Routing Universe                 |
         +------------+----------------------------------+
         |     0      | 缺省三层路由拓扑 |
         +------------+----------------------------------+

             Table 3: 众所周知的实例标识符

如果一个给定的协议不支持多个路由域，那么它应该根据表3设置Identifier字段。然而，实现可以使给定协议的“标识符”可配置。

每个节点描述符和链路描述符由一个或多个tlv组成，如下节所述。

3.2.1. Node Descriptors(节点描述符)

每个链路由一对Router-ID固定，由底层IGP使用，is-is使用48位ISO System-ID, OSPFv2和OSPFv3使用32位Router-ID。IGP可以使用一个或多个
附加的辅助路由器id，主要用于流量工程目的。例如，IS-IS可能有一个或多个IPv4和IPv6 TE router - id [RFC5305] [RFC6119]。这些辅助路由器
id必须包含在章节3.3.2中描述的link属性中。

Node Descriptor内部的Router-ID赋值是全局唯一的是可取的。然而，可能会有Router- id空间(例如ISO)，其中没有全局注册表存在，或者更糟，
Router- id已经按照RFC1918 [RFC1918]中描述的私有ip分配分配。BGP-LS通过自治系统号和BGP-LS标识符(请参见3.2.1.4)来消除路由器id的歧义，
请参见3.2.1.1。

3.2.1.1. Globally Unique Node/Link/Prefix Identifiers

需要解决的一个问题是全局识别IGP节点的能力(这里的“全局”指的是在由所有相互通信的BGP-LS发言者收集的BGP-LS数据库中)。这可以通过以下两个要求来表达:

(A)同一个节点一定不能用两个键表示(否则，一个节点看起来像两个节点)。
(B)两个不同的节点不能用相同的键表示(否则，两个节点看起来像一个节点)。

我们将“IGP域”定义为节点的集合(因此，通过扩展链接和前缀)，其中每个节点使用Area-ID、Router-ID、Protocol-ID、Multi-Topology ID和
Instance-ID的组合具有唯一的IGP表示。问题是BGP可能从多个独立的“IGP域”接收到节点/链路/前缀信息，我们需要对它们进行区分。

此外，我们不能假设每个AS总有一个或只有一个IGP域。在IGP转换期间，可能会出现两个多余的IGP。

在3.2.1.4节中，描述了一组子tlv，它允许为任何给定的节点/链路信息指定一个灵活的密钥，从而保证NLRI的全局唯一性。

3.2.1.2. Local Node Descriptors

本地节点描述符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)            //
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

           Figure 10: Local Node Descriptors TLV Format

3.2.1.3. Remote Node Descriptors

远程节点描述符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)            //
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

           Figure 11: Remote Node Descriptors TLV Format

3.2.1.4. Node Descriptor Sub-TLVs

节点描述子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 |
       +--------------------+-------------------+----------+

                 Table 4: Node Descriptor Sub-TLVs

节点描述符tlv中的子tlv值定义如下:

Autonomous System:Opaque值(32位AS号)

BGP-LS Identifier: 不透明值(32位ID)。与自治系统号(Autonomous System Number, ASN)结合使用，唯一标识BGP-LS域。ASN和BGP-LS ID
的组合必须是全局唯一的。一个IGP泛洪集(IGP node -set)内的所有BGP-LS speaker必须使用相同的ASN, BGP-LS ID元组。如果一个IGP域
由多个泛洪集组成，则该IGP域中的所有BGP-LS speaker都应该使用相同的ASN、BGP-LS ID元组。

Area-ID: 用于标识NLRI所属的32位区域。区域标识符允许区分同一路由器的不同NLRIs。

IGP Router-ID: 不透明值。这是强制性的TLV。
对于IS-IS非伪节点，它包含一个6字节的ISO Node-ID (ISO system-ID)。对于一个与局域网相对应的IS-IS伪节点，它包含指定中间系统(DI
S)的6字节ISO节点id，后面是1字节的非零PSN标识符(总共7字节)。对于OSPFv2或OSPFv3的非伪节点，它包含4字节的Router-ID。对于一个代
表局域网的OSPFv2伪节点，它包含DR的4字节的Router- id，后面是DR到局域网接口的4字节的IPv4地址(总共8字节)。类似地，对于OSPFv3伪
节点，它包含DR的4字节的Router-ID和DR的LAN接口的4字节的接口标识(共8字节)。TLV的大小与协议标识符结合，使解码器能够确定节点的类型。

在任何节点描述符中，每个子tlv类型最多只能有一个实例。节点描述符内的子tlv必须按子tlv类型升序排列。这样做是为了比较NLRIs，即使在实现遇
到未知的子tlv时也是如此。使用稳定排序，实现可以对NLRIs进行二进制比较，因此允许增量部署新的密钥子tlv。

3.2.1.5. Multi-Topology ID

Multi-Topology ID (MT-ID) TLV为一个链路、节点或前缀携带一个或多个IS-IS或OSPF Multi-Topology ID。
IS-IS MT-ID的语义在RFC5120 [RFC5120]的7.2节中定义。OSPF MT-ID的语义在RFC4915 [RFC4915]章节3.7中定义。如果MT-ID TLV的值来源于OSPF，则前9位必须设置为0。位R是保留的，在产生时应该设置为0，在接收时忽略。
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  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure 12: Multi-Topology ID TLV Format

其中，Type为263,Length为2*n, n为TLV携带的mt - id个数。

MT-ID TLV可能存在于链路描述符、前缀描述符或节点NLRI的BGP-LS属性中。在链路或前缀描述符中，只允许一个包含该链路或前缀可达的拓扑的MT-ID的
MT-ID TLV。如果需要为给定的链路描述符或前缀描述符发布多个拓扑，则需要生成多个NLRI，其中每个NLRI包含一个唯一的MT-ID。在节点NLRI的BGP-
LS属性中，有一个允许的MT-ID TLV，其中包含该节点可达的所有拓扑的MT-ID数组。

3.2.2. Link Descriptors

链路描述符字段是一个TLV (Type/Length/Value)三元组的集合。每个TLV的格式见3.1节。链路描述符tlv在一对锚定路由器之间的多条并行链路中唯一
标识一条链路。由链路描述符tlv描述的链路实际上是“半链路”，逻辑链路的单向表示。为了完整地描述单个逻辑链路，两台发起路由器各自发布半链路，
即在给定的点对点链路上发布两个链路nlri。

大多数链路描述tlv中的Value字段的格式和语义与[RFC5305]、[RFC5307]和[RFC6119]定义的IS-IS扩展IS可达子tlv中的Value字段的格式和语义一致。
虽然链路描述符tlv的编码最初是为IS-IS定义的，但tlv既可以携带来自IS-IS的数据，也可以携带来自OSPF的数据。

The following TLVs are valid as Link Descriptors in the Link 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 | | |
±----------±--------------------±-------------±-----------------+

                   Table 5: Link Descriptor TLVs

本地节点产生的LSA/LSP中存在的链路信息决定了该链路的链路描述符中tlv的集合。
如果接口和邻居地址(IPv4或IPv6)存在，则IP地址TLV将包含在链路描述符中，而不包括链路本地/远端标识符TLV。链接本地/远程标识符可以包含在链接属性中。
如果接口和邻居地址不存在，且链路本地/远端标识符存在，则链路本地/远端标识符TLV将包含在链路描述符中。
如果该信息存在，则多拓扑标识符TLV将包含在链路描述符中。

3.2.3. Prefix Descriptors

前缀描述符字段是一个TLV (Type/Length/Value)三元组的集合。
前缀描述符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 | | |
±------------±--------------------±---------±-------------------+

                  Table 6: Prefix Descriptor TLVs

3.2.3.1. OSPF Route Type

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   |
 +-+-+-+-+-+-+-+-+

               Figure 13: OSPF Route Type TLV Format

其中TLV的Type和Length字段定义在表6中。

OSPF路由类型字段的值由OSPF协议定义，可以是以下几种类型之一:
o Intra-Area (0x1)
o Inter-Area (0x2)
o External 1 (0x3)
o External 2 (0x4)
o NSSA 1 (0x5)
o NSSA 2 (0x6)

3.2.3.2. IP Reachability Information

IP可达信息TLV是一种必选TLV，包含IGP拓扑中最初发布的一个IP地址前缀(IPv4或IPv6)。它的目的是通过将一个特定的BGP服务NLRI的BGP下一跳绑定到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)                         //
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         Figure 14: IP Reachability Information TLV Format

TLV的Type和Length字段定义如表6所示。下面两个字段决定了地址族的可达性信息。Prefix Length字段表示前缀的长度，以比特为单位。IP Prefix字
段包含前缀中最重要的字节，例如:1个字节表示前缀长度1到8,2个字节表示前缀长度9到16,3个字节表示前缀长度17到24,4个字节表示前缀长度25到32，
等等。
3.3. The BGP-LS Attribute

BGP- ls属性是一种可选的、非过渡的BGP属性，用于携带链路、节点、前缀等参数和属性。它被定义为一组类型/长度/值(TLV)三元组，将在下一节中描述。
这个属性应该只包含在链路状态NLRIs中。对于所有其他地址族，必须忽略此属性。

3.3.1. Node Attribute TLVs

节点属性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 | | |
±------------±---------------------±---------±------------------+

                   Table 7: Node Attribute TLVs

3.3.1.1. Node Flag Bits TLV

Node Flag Bits 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|
 +-+-+-+-+-+-+-+-+-+

               Figure 15: Node Flag Bits TLV Format

bits 的定义如下:

    +-----------------+-------------------------+------------+
    |       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

3.3.1.2. IS-IS Area Identifier TLV

一个IS-IS节点可以是一个或多个IS-IS区域的一部分。每个区域地址都包含在is-is区域标识符TLV中。如果存在多个区域地址，则使用多个tlv对其进
行编码。IS-IS区域标识TLV只有在链路状态节点NLRI中发布时才会出现在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)                  //
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Figure 16: IS-IS Area Identifier TLV Format

3.3.1.3. Node Name TLV

"Node Name"为可选参数。它的结构和编码借用了[RFC5301]。Value字段标识路由器节点的符号名。这个符号名可以是路由器的Fully Qualified
Domain name (FQDN)，也可以是FQDN的一个子集(例如，一个主机名)，也可以是任何操作符想要用于路由器的字符串。强烈建议使用FQDN或其子集。
Node Name TLV的最大长度为255字节。

Value字段使用7位ASCII编码。如果用于配置或显示该字段的用户界面允许Unicode字符，则该用户界面负责应用[RFC5890]中描述的ToASCII和/或
ToUnicode算法，以实现传输或显示的正确格式。

尽管[RFC5301]描述了is - is特定的扩展，Node Name 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)                    //
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 17: Node Name Format

3.3.1.4. Local IPv4/IPv6 Router-ID TLVs

Local IPv4/IPv6 Router-ID tlv用于描述IGP可能使用的辅助Router-ID，例如用于TE和迁移目的，例如在不同协议之间关联一个Node-ID。
如果一个特定类型的辅助Router-ID多于一个，那么每个辅助Router-ID都被编码到自己的TLV中。

3.3.1.5. Opaque Node Attribute TLV

Opaque Node Attribute TLV是一个透明的包膜，它携带路由器发布的可选Node Attribute TLV。发起路由器应使用这个电磁阀的特定于协议的编
码信息宣传NLRI头Protocol-ID字段或新协议扩展协议NLRI头Protocol-ID领域的广告没有协议无关的边界网关协议链路状态NLRI表示。Opaque
Node Attribute TLV的主要用途是在定义一个新的IGP link-state属性和发布协议无关的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)             //
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure 18: Opaque Node Attribute Format

3.3.2. Link Attribute TLVs

链路属性tlv是指通过链路NLRI编码到BGP-LS属性中的tlv。每个“链接属性”都是一个类型/长度/值(TLV)三元组，格式如3.1节定义。某些链路属性
tlv中的Value字段的格式和语义与[RFC5305]和[RFC5307]定义的IS-IS扩展IS可达子tlv中的Value字段的格式和语义对应。其他链路属性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 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

3.3.2.1. IPv4/IPv6 Router-ID TLVs

本地/远端IPv4/IPv6 Router-ID tlv用于描述IGP可能使用的辅助Router-ID，例如用于TE目的。所有本地和远端节点的辅助router - id必须包含在
每个link NLRI的link属性中。如果指定类型的辅助Router-ID多于一个，则使用多个tlv对其进行编码。

3.3.2.2. MPLS Protocol Mask TLV

MPLS Protocol Mask TLV携带一个位掩码，用来描述使能了哪些MPLS信令协议。该TLV的长度为1。该值是一个由8个标志位组成的位数组，每个位代表一
种MPLS协议能力。

生成MPLS协议掩码TLV仅对具有本地链路洞察力的发起者有效，也仅对其有效，如表2中协议id“Static configuration”或“Direct”。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 |
 +-+-+-+-+-+-+-+-+

                 Figure 19: MPLS Protocol Mask 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 | |
±-----------±-----------------------------------------±----------+

              Table 10: MPLS Protocol Mask TLV Codes

3.3.2.3. TE Default Metric TLV

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                     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure 20: TE Default Metric TLV Format

3.3.2.4. IGP Metric TLV

IGP Metric 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)      //
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Figure 21: IGP Metric TLV Format

3.3.2.5. Shared Risk Link Group TLV

共享风险链路组(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                 |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

           Figure 22: Shared Risk Link Group TLV Format

SRLG TLV for OSPF-TE定义在RFC4203中。在is - is中，SRLG信息包含在两个不同的TLV中:[RFC5307]定义的IPv4 (SRLG) TLV (Type 138)和
[RFC6119]定义的IPv6 SRLG TLV (Type 139)。在链路状态NLRI中，IPv4和IPv6 SRLG信息都在一个TLV中携带。

3.3.2.6. Opaque Link Attribute 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.

  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

3.3.2.7. Link Name 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
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.

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.

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)                    //
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 24: Link Name TLV Format

3.3.3. Prefix Attribute TLVs

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:

±--------------±---------------------±---------±----------------+
| TLV Code | Description | Length | Reference |
| Point | | | |
±--------------±---------------------±---------±----------------+
| 1152 | IGP Flags | 1 | Section 3.3.3.1 |
| 1153 | IGP Route Tag | 4n | [RFC5130] |
| 1154 | IGP Extended Route | 8n | [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

3.3.3.1. IGP Flags 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:

  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

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.  |           |
       +----------+---------------------------+-----------+

                Table 12: IGP Flag Bits Definitions

3.3.3.2. IGP Route Tag TLV

The IGP Route Tag TLV carries original IGP Tags (IS-IS [RFC5130] or
OSPF) of the prefix and is encoded as follows:

  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

Length is a multiple of 4.

The Value field contains one or more Route Tags as learned in the IGP
topology.

3.3.3.3. Extended IGP Route Tag TLV

The Extended IGP Route Tag TLV carries IS-IS Extended Route Tags of
the prefix [RFC5130] and is encoded as follows:

  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

Length is a multiple of 8.

The Extended Route Tag field contains one or more Extended Route Tags
as learned in the IGP topology.

3.3.3.4. Prefix Metric TLV

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.

  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

Length is 4.

3.3.3.5. OSPF Forwarding Address TLV

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.

  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

Length is 4 for an IPv4 forwarding address, and 16 for an IPv6
forwarding address.

3.3.3.6. Opaque Prefix Attribute TLV

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.

The format of the TLV is as follows:

  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

Type is as specified in Table 11. Length is variable.

3.4. BGP Next-Hop Information

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

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.

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.

3.5. Inter-AS Links

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

3.6. Router-ID Anchoring Example: ISO Pseudonode

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.

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.

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

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.

 +-----------------+    +-----------------+    +-----------------+
 |      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

3.7. Router-ID Anchoring Example: OSPF Pseudonode

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.

The Link NLRI of (Node1, Pseudonode1) is encoded as follows:

o Local Node Descriptor

     TLV #515: IGP Router-ID: 11.11.11.11

     TLV #514: OSPF Area-ID: ID:0.0.0.0

o Remote Node Descriptor

     TLV #515: IGP Router-ID: 11.11.11.11:10.1.1.1

     TLV #514: OSPF Area-ID: ID:0.0.0.0

The Link NLRI of (Pseudonode1, Node2) is encoded as follows:

o Local Node Descriptor

     TLV #515: IGP Router-ID: 11.11.11.11:10.1.1.1

     TLV #514: OSPF Area-ID: ID:0.0.0.0

o Remote Node Descriptor

     TLV #515: IGP Router-ID: 33.33.33.34

     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     |
 +-----------------+    +-----------------+    +-----------------+

                    Figure 32: OSPF Pseudonodes

3.8. Router-ID Anchoring Example: OSPFv2 to IS-IS Migration

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.

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.

  1. Link to Path Aggregation

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
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.

4.1. Example: No Link Aggregation

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.

      AS1   :   AS2
            :
       R1-------R3
        |   :   | \
        |   :   |  R5
        |   :   | /
       R2-------R4
            :
            :

     Figure 33: No Link Aggregation

4.2. Example: ASBR to ASBR Path Aggregation

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.

      AS1   :   AS2
            :
       R1-------R3
        |   :   |
        |   :   |
        |   :   |
       R2-------R4
            :
            :

     Figure 34: ASBR Link Aggregation

4.3. Example: Multi-AS Path Aggregation

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.

      AS1   :   AS2   :   AS3
            :         :
       R1-------R3-----
        |   :         : \
        |   :         :   vR0
        |   :         : /
       R2-------R4-----
            :         :
            :         :

     Figure 35: Multi-AS Aggregation

  1. IANA Considerations

IANA has assigned address family number 16388 (BGP-LS) in the
“Address Family Numbers” registry with this document as a reference.

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 has assigned value 29 (BGP-LS Attribute) in the “BGP Path
Attributes” sub-registry under the “Border Gateway Protocol (BGP)
Parameters” registry.

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:

o “BGP-LS NLRI-Types” registry

  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]).

o “BGP-LS Protocol-IDs” registry

  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]).

o “BGP-LS Well-Known Instance-IDs” registry

  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.

o “BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and
Attribute TLVs” registry

  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]).

5.1. Guidance for Designated Experts

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.

  1. Manageability Considerations

This section is structured as recommended in [RFC5706].

6.1. Operational Considerations

6.1.1. Operations

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.

6.1.2. Installation and Initial Setup

Configuration parameters defined in Section 6.2.3 SHOULD be
initialized to the following default values:

o The Link-State NLRI capability is turned off for all neighbors.

o The maximum rate at which Link-State NLRIs will be advertised/
withdrawn from neighbors is set to 200 updates per second.

6.1.3. Migration Path

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.

6.1.4. Requirements on Other Protocols and Functional Components

The protocol extension defined in this document does not put new
requirements on other protocols or functional components.

6.1.5. Impact on Network Operation

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.

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.

6.1.6. Verifying Correct Operation

Existing BGP procedures apply. In addition, an implementation SHOULD
allow an operator to:

o List neighbors with whom the speaker is exchanging Link-State
NLRIs.

6.2. Management Considerations

6.2.1. Management Information

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.

6.2.2. Fault Management

If an implementation of BGP-LS detects a malformed attribute, then it
MUST use the ‘Attribute Discard’ action as per [RFC7606], Section 2.

An implementation of BGP-LS MUST perform the following syntactic
checks for determining if a message is malformed.

o Does the sum of all TLVs found in the BGP-LS attribute correspond
to the BGP-LS path attribute length?

o Does the sum of all TLVs found in the BGP MP_REACH_NLRI attribute
correspond to the BGP MP_REACH_NLRI length?

o Does the sum of all TLVs found in the BGP MP_UNREACH_NLRI
attribute correspond to the BGP MP_UNREACH_NLRI length?

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 Does any fixed-length TLV correspond to the TLV Length field in
this document?

6.2.3. Configuration Management

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.

An implementation SHOULD allow the operator to specify the maximum
rate at which Link-State NLRIs will be advertised/withdrawn from
neighbors.

An implementation SHOULD allow the operator to specify the maximum
number of Link-State NLRIs stored in a router’s Routing Information
Base (RIB).

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.

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.

6.2.4. Accounting Management

Not Applicable.

6.2.5. Performance Management

An implementation SHOULD provide the following statistics:

o Total number of Link-State NLRI updates sent/received

o Number of Link-State NLRI updates sent/received, per neighbor

o Number of errored received Link-State NLRI updates, per neighbor

o Total number of locally originated Link-State NLRIs

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.

6.2.6. 安全管理

操作符应该定义一个导入策略来限制入站更新，如下所示:
o删除来自消费者对等体的所有更新。
实现必须具有限制入站更新的方法。

  1. TLV/Sub-TLV Code Points Summary

    本部分包含了本文档中定义的所有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 | | |

| 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

  1. Security Considerations

本文定义的过程和协议扩展不影响BGP安全模型。参见[RFC4271]的安全注意事项一节对BGP安全的讨论。BGP的安全问题参见[RFC4272]和[RFC6952]。

在与本文档相关联的BGP对等体中，BGP speaker绝对不能接受消费者对等体的更新。也就是说，一个参与的BGP speaker应该意识到它的链路状态关系的性质，并且应该保护自己不受对等体发送的代表错误信息反馈循环或错误输入的更新的影响。这种保护可以通过在BGP speaker上手动配置消费者对等体来实现。

运营商应该采用一种机制来保护BGP speaker免受来自消费者的DDoS攻击。使用者可能应用的主要攻击是试图连续或同时启动多个会话。可以通过施加速率限制来实施保护。

此外，可以认为本文档中描述的链路状态和TE信息的导出对网络的关键任务或商业敏感信息的机密性构成风险。BGP对等体不是自动的，需要配置;因此，网络运营商有责任确保只有可信的消费者被配置为接收此类信息。

知秋君
知秋君

知秋君

版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请关注公众号“全栈程序员社区”联系小编举报，一经查实，本站将立刻删除。
上一篇 2024-08-01 19:36
下一篇 2024-08-01 19:02

相关推荐