CN112350936A - 一种内部网关协议泛洪优化方法及装置、存储介质 - Google Patents

Abstract

本申请公开了一种内部网关协议泛洪优化方法、装置及存储介质，该内部网关协议泛洪优化方法包括：第一节点向邻居节点泛洪携带链路状态数据和第一记录信息的第一报文，所述第一记录信息包括所述链路状态数据所经历的节点的指示信息。本实施例中，通过携带链路状态数据所经历的节点的指示信息，便于节点根据该信息减少冗余发送链路状态信息，从而加快收敛速度。

Description

一种内部网关协议泛洪优化方法及装置、存储介质

技术领域

本发明实施例涉及但不限于一种内部网关协议泛洪优化方法及装置、存储介质。

背景技术

近些年来，业界日益关注数据中心Spine-leaf、Clos、Fat-tree网络拓扑的动态路由问题。传统的IGP(Interior Gateway Protocol，内部网关协议)协议，如ISIS(Intermediate System to Intermediate System，中间系统至中间系统协议)或OSPF(Open Shortest Path First，开放最短路径优先)，在如此密集的网络拓扑中向所有链路冗余泛洪信息，将会导致控制平面负担很大，由此产生一系列的问题。主要问题是针对网络拓扑变化时的反应，链路状态路由协议依赖的是某个泛洪算法，在密集的拓扑中，这种泛洪算法是高度冗余的，拓扑中的每个节点将会从每条链路上多次收到同样的链路状态更新，虽然最终所有冗余的更新都会丢弃，但是它们已经到达控制平面并得到处理了，这些冗余消息可能会排在某个重要的链路状态更新之前，使得收敛变慢。另外，在网络设备的具体实现中，控制平面相关的入向报文队列大小都是有限的，如果较长一段时间内收到泛洪更新的速率超过了协议处理更新的速率，那么后续的更新将会被丢弃，被丢弃的更新中也许包含了很重要的更新，这样进一步延缓链路状态数据库的稳定，使得收敛变慢。

发明内容

本发明至少一实施例提供了一种内部网关协议泛洪优化方法及装置、存储介质，减少冗余泛洪，提高网络收敛速度。

本发明至少一实施例提供一种内部网关协议泛洪优化方法，包括：

第一节点向邻居节点泛洪携带链路状态数据和第一记录信息的第一报文，所述第一记录信息包括所述链路状态数据所经历的节点的指示信息。

本发明至少一实施例提供一种内部网关协议泛洪优化装置，包括存储器和处理器，所述存储器存储有程序，所述程序在被所述处理器读取执行时，实现任一实施例所述的内部网关协议泛洪优化方法。

本发明至少一实施例提供一种计算机可读存储介质，所述计算机可读存储介质存储有一个或者多个程序，所述一个或者多个程序可被一个或者多个处理器执行，以实现任一实施例所述的内部网关协议泛洪优化方法。

与相关技术相比，本发明一实施例提供一种内部网关协议泛洪优化方法，包括：第一节点向邻居节点泛洪携带链路状态数据和第一记录信息的第一报文，所述第一记录信息包括所述链路状态数据所经历的节点的指示信息。采用本发明实施例所述方法，通过携带链路状态数据所经历的节点的指示信息，便于节点根据该信息减少冗余发送链路状态信息，从而加快收敛速度，且实现极其简单，成本非常小，相比其它优化手段具有明显优势。

本发明的其它特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变得显而易见，或者通过实施本发明而了解。本发明的目的和其他优点可通过在说明书、权利要求书以及附图中所特别指出的结构来实现和获得。

附图说明

附图用来提供对本发明技术方案的进一步理解，并且构成说明书的一部分，与本申请的实施例一起用于解释本发明的技术方案，并不构成对本发明技术方案的限制。

图1是本发明一实施例提供的内部网关协议泛洪优化方法流程图；

图2是本发明具体实施例一、二的网络拓扑图；

图3是本发明具体实施例三的网络拓扑图；

图4是本发明具体实施例四的网络拓扑图；

图5是本发明一实施例提供的内部网关协议泛洪优化装置框图；

图6是本发明一实施例提供的计算机可读存储介质框图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚明白，下文中将结合附图对本发明的实施例进行详细说明。需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互任意组合。

在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行。并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

RFC8279定义了BIER(Bit Indexed Explicit Replication，位索引显式复制)架构，是组播数据报文转发的一种新的架构，为组播数据报文在组播域中提供最优路径转发。不需要使用协议建立组播分发树，也不需要中间节点维护任何流状态。当组播报文从域外到达BFIR(Bit-Forwarding Ingress Router，位转发入口路由器)时，BFIR先确定报文将在哪个BIER SD(sub-domain，子域)内发送并发往哪些BFER(Bit-Forwarding EgressRouter，位转发出口路由器)。RFC8296定义了BIER报文的封装格式，BFIR在报文头中插入“BIER header(BIER头)”，其中包含一个BitString(比特串)，BitString的每一位表示相应BFER的BFR-id(Bit-Forwarding Router-id，位转发路由器标识)。一个报文能转发至的BFER的个数，取决于BSL(BitString Length，BitString的长度)。有可能，sub-domain中包含的BFER个数会超过BSL，为了支持这种情况，在BIER header中再引入SI(SetIdentifier，集合标识)。SI与BitString一起确定报文要转发至哪些BFER。若SI为n，BitString中的第K位为1(记最低位为第1位)，则报文将会发给BFR-id为n*BSL+K的BFER。

RFC8279还描述了BIER架构的分层模型：处于底层的路由层，一般通过IGP建立单播路由转发信息，当然少数情况下也可能通过BGP(Border Gateway Protocol，边界网关协议)或静态路由等其它方式来建立单播路由转发信息；处于中间层的BIER层，包含了用于在BIER domain(BIER域)中传输组播数据报文的协议和流程；处于上层的业务组播流层，包含了组播业务协议集，BFIR为组播数据报文确定BFER集合的功能，以及BFER从BIER域内收到BIER封装的报文时如何进一步转发报文的功能。从上述分层模型可知，BIER报文的转发一般情况下会依赖底层的IGP单播路由转发。

本申请至少一实施例中，提供一种在密集网络拓扑中引入BIER技术以达到解决和优化IGP协议的链路状态数据冗余泛洪问题的机制。

本申请至少一实施例中，在密集网络拓扑中引入BIER技术，并提供一套基于BIER的链路状态数据泛洪机制，以减少IGP协议的链路状态数据的冗余泛洪，提升网络收敛速度。

本发明一实施例提供一种内部网关协议泛洪优化方法，如图1所示，包括：

步骤101，第一节点向邻居节点泛洪携带链路状态数据和第一记录信息的第一报文，所述第一记录信息包括所述链路状态数据所经历的节点的指示信息。

采用本发明实施例所述方法，通过携带链路状态数据所经历的节点的指示信息，便于节点根据该信息减少冗余发送链路状态信息，从而加快收敛速度，且实现极其简单，成本非常小，相比其它优化手段具有明显优势。

在一实施例中，所述节点的指示信息比如为节点标识。节点标识可以是多种标识，比如为BFR-id，节点的物理标识等等。

其中，第一节点进行链路状态数据泛洪可以是由本地产生的链路状态数据引起，也可能是接收到其他节点的链路状态数据引起。

在一实施例中，如果链路状态数据是第一节点本地产生的，链路状态数据所经历的节点可以包括第一节点和第一节点的所有邻居节点；

如果链路状态数据是第一节点从其他节点接收到的，接收该链路状态数据时还接收到第二记录信息，则链路状态数据所经历的节点除了包括第一节点、第一节点的所有邻居节点外，还包括接收到的第二记录信息中指示的节点。需要说明的是，第一节点、第一节点的所有邻居节点和第二记录信息中指示的节点可能出现重叠，携带时，相同的节点只保留一个即可。

在一实施例中，所述第一节点向邻居节点泛洪携带链路状态数据和第一记录信息的第一报文包括：

所述第一节点本地产生所述链路状态数据时，所述第一节点向邻居节点泛洪所述第一报文；其中，所述第一记录信息包括所述第一节点的标识及所述第一节点的所有邻居节点的标识。即该链路状态数据由第一节点产生并进行泛洪。

在一实施例中，所述第一节点向邻居节点泛洪携带链路状态数据和第一记录信息的第一报文包括：

所述第一节点接收到来自第二节点的携带第二记录信息及所述链路状态数据的第二报文，且本地不存在所述链路状态数据或者所述链路状态数据新于本地的链路状态数据时，所述第一节点向除所述第二节点以及所述第二记录信息指示的节点外的邻居节点泛洪所述第一报文，所述第一记录信息中包括所述第一节点的标识、所述第一节点的所有邻居节点的标识以及所述第二记录信息。本实施例提供的方案，根据携带的节点向链路状态信息未经历的节点发送链路状态信息，从而大大减少所发送的报文数量，提高收敛速度。

在一实施例中，可以设置一是否支持泛洪优化的能力开关，网络中的各节点可以使能或不使能该能力开关，当使能时，支持发送和接收携带链路状态数据和记录信息的报文，当不使能时，基于相关技术实现链路状态数据泛洪，另外，节点不存在该能力开关时，与不使能该能力开关的节点的处理相同。具体的，当第一节点的该开关使能时，第一节点发送携带链路状态数据和第一记录信息的第一报文给使能该开关的邻居节点，对于其他未使能该开关邻居节点，则按照相关技术中的方案进行链路状态数据泛洪。需要说明的是，第一节点在发送给使能能力开关的邻居节点的报文中携带的第一记录信息中，包括未使能或不支持泛洪优化能力的邻居节点的指示信息。另外，在其他实施例中，也可以不设置该能力开关，默认所有节点支持接收和发送所述携带链路状态数据和第一记录信息的报文，或者，强制配置使能所有节点的该能力开关。

在一实施例中，第一节点向邻居节点泛洪携带链路状态数据和第一记录信息的第一报文包括：

当所述第一节点支持预设泛洪优化能力时，所述第一节点向支持所述预设泛洪优化能力的邻居节点泛洪携带链路状态数据和第一记录信息的第一报文。

在一实施例中，所述第一记录信息中还包括所述链路状态数据未经历的节点的指示信息，所述链路状态数据未经历的节点根据预设策略配置。预设策略可以根据需要配置，比如，根据网络结构进行配置。在一实施例中，当所述第一节点为分层网络架构中的节点时，所述链路状态数据未经历的节点包括与所述第一节点处于同一层的其他节点，所述分层网络架构包括多层节点，同一层内的节点彼此无连接或者仅有部分连接，节点与下一层的节点全连接。分层网络架构比如有Spine-leaf(叶脊)，CLOS，Fat-tree等网络架构。比如，当所述第一节点为Spine-leaf架构中的脊(spine)节点时，所述链路状态数据未经历的节点包括所述叶脊架构中除所述第一节点外的脊节点。又比如，所述第一节点为叶脊架构中的叶节点时，所述链路状态数据未经历的节点包括与所述第一节点处于同一层的其他叶节点。通过该方案，能进一步降低冗余，提高收敛速度。需要说明的是，第一节点发送给各邻居节点的报文中的第一记录信息可以相同也可以不同。比如，第一节点发送给其中一个邻居节点的报文中的第一记录信息包括第一节点和所有邻居节点的指示信息，第一节点发送给其他邻居节点的报文中的第一记录信息包括第一节点、所有邻居节点以及根据预设策略配置的且所述链路状态数据未经历的节点的指示信息。

在一实施例中，可以结合BIER实现上述技术方案。所述第一报文为BIER报文，所述第一记录信息使用所述BIER的报文头中的比特串携带。各节点使能BIER能力。

在一实施例中，所述BIER报文中的保留字段设置为第一预设值，指示所述BIER报文的报文头中的比特串携带所述第一记录信息。

在一实施例中，所述BIER报文中的Proto字段设置为第二预设值或第三预设值，指示所述BIER报文携带的载荷类型为链路状态数据。

在一实施例中，所述方法还包括：所述节点与其邻居节点之间周期性同步链路状态数据库。同步方法有多种，开启链路状态数据库同步功能，比如传统的链路状态数据库同步机制。传统上这种同步机制一般仅在广播链路上开启，在本申请一实施例中，则不管它与邻居之间是通过点到点链路还是广播链路相连，均需要开启以保证数据一致性。或者，约定只要节点支持泛洪优化能力，则不管它与邻居之间是通过点到点链路还是广播链路相连，均需要开启以保证数据一致性。

下面通过具体实施例进一步说明基于BIER实现泛洪优化的实现。

采用以下技术方案：

1)在IGP area/level内的每个节点上，均使能BIER能力且分别配置全网唯一的BFR-id。IGP area/level是指由一些节点和以及连接这些节点的链路所构成的区域，这些节点运行相同的IGP协议如ISIS或OSPF，并相互通告自身节点以及本地链路加入的area/level信息，构成一个三层路由网络拓扑，如ISIS level-2，ISIS level-1,OSPF area。在本文的后续说明中，有时也直接使用“网络”一词来替代“IGP area/level”以方便描述。

2)在相关技术中的BIER转发机制中引入一种“BIER记录”功能，该功能能够记录BIER封装的载荷经历了哪些节点，即BIER header中的BitString中记录了载荷所经历的所有节点信息。此处的载荷是指IGP链路状态数据，如ISIS的LSP(Link State PDU，链路状态协议数据单元)报文或OSPF的LSU(Link State Update，链路状态更新)报文。为满足上述功能要求，需针对RFC8296做少量扩展以满足本申请实施例要求，一种具体的扩展可以是如下：

新增R(Record)标志：当前BIER header中的Rsv字段未被使用，可以用其最低位作为R标志，用于指示BIER报文为携带记录信息的BIER报文还是传统BIER报文。比如，R标志设置为1时表示该BIER报文非传统的BIER报文，不进行传统的BIER报文转发处理，报文中携带记录信息，此时BIER header中的TTL(Time to Live，生存时间)要同时设置为1；R标志设置为0时表示该BIER报文是一个传统的普通BIER报文，其转发逻辑遵循现有RFC8296。需要说明的是，此处仅为示例，R标志也可以设置为其他值。另外，R标志也可以使用其他字段，或使用Rsv字段的其他位。

扩展Proto字段：当前BIER header中的Proto字段不支持将IGP协议报文作为载荷，IANA(Internet Assigned Numbers Authority，互联网数字分配机构)针对Proto字段已经分配了1～6，7～62留待分配。本申请实施例中，从7～62选择两个分别表示ISIS LSPpacket(包)和OSPF LSU packet，比如，在一实施例中，7表示ISIS LSP packet，8表示OSPFLSU packet。需要说明的是，在其他实施例中，也可以使用其他值进行指示，比如使用相同的值指示将IGP协议报文作为载荷，比如，使用7表示将IGP协议报文作为载荷，该IGP协议报文可能是ISIS LSP packet，也可能是OSPF LSU packet。

3)在IGP area/level内的每个节点上，在用于构建该IGP area/level的相应IGP实例下配置使能“通过BIER优化冗余泛洪”开关(即前述的泛洪优化开关的一种实现方式)，并在对外泛洪的节点能力信息中，包含本节点是否支持“通过BIER优化冗余泛洪”标志(简称B标志)，用于指示该节点是否支持通过BIER优化冗余泛洪。在一实施例中，可以扩展IS-IS Router Capability TLV-242(参考RFC7981，从IS-IS Router CAPABILITY TLV(路由能力类型长度值)中的Flags(标志)字段的Reserved(保留)部分中取一个比特用于上述B标志)和Router Information Opaque LSA(参考RFC7770，从OSPF Router InformationalCapabilities TLV(OSPF路由信息能力类型长度值)中的Informational Capabilities(信息能力)字段的Unassigned(未分配)部分取一个比特用于上述B标志)，新增上述B标志，比如，B标志设置为1表示能力通告方节点支持“通过BIER优化冗余泛洪”，这意味着该节点支持识别和处理前述“BIER记录”报文，以及识别BIER封装的载荷类型为前述ISIS LSP报文或OSPF LSU报文，B标志设置为0表示能力通告方节点不支持“通过BIER优化冗余泛洪”。需要说明的是，也可以将B标志设置为其他值来表示是否支持“通过BIER优化冗余泛洪”。需要说明的是，在其他实施例中，也可以不配置“通过BIER优化冗余泛洪”开关，默认所有节点支持“通过BIER优化冗余泛洪”能力。

4)基于上述基础，当网络中某个节点A需要向某个邻居节点N泛洪本地产生的链路状态数据时，如果节点A支持“通过BIER优化冗余泛洪”，并且它感知到邻居节点N也具备“通过BIER优化冗余泛洪”能力，则节点A可通过“BIER记录”报文向邻居泛洪链路状态数据，此时“BIER记录”报文中的BitString(为避免混淆，本文将发送的“BIER记录”报文中的BIERheader中的BitString记为send_bitstring)中包含有节点A自身及其所有邻居节点的BFR-id信息，所封装的载荷为上述链路状态数据(如ISIS LSP或OSPF LSU)。注意节点A与邻居节点N之间存在多条链路时，只需选择沿其中一条链路发送上述“BIER记录”报文，不允许冗余的沿每条链路都发送。

如果节点A不支持“通过BIER优化冗余泛洪”，或者感知到邻居节点N不具备“通过BIER优化冗余泛洪”能力，节点A将采取传统的IGP泛洪机制向节点N泛洪链路状态数据。

在实际网络部署中，如果管理员确信网络内所有节点都具备“通过BIER优化冗余泛洪”能力，那么为了加快收敛(如新建一张密集网络)，可在各节点上配置本地策略，强制使用“BIER记录”报文向邻居泛洪链路状态数据。

5)进一步的，网络中某个节点A可能会从其某个邻居节点N收到非本地产生的链路状态数据(或称远端链路状态数据)，这可能是通过传统的IGP泛洪机制收到的，也可能是通过“BIER记录”报文收到的(为避免混淆，本文将收到的“BIER记录”报文中的BIER header中的BitString记为recv_bitstring)。以下分情况描述：

a)通过“BIER记录”报文收到：节点A收到后，需检查本地维护的链路状态数据库中是否早已经存在同样的远端链路状态数据并比较新旧。如果本地不存在或者本地存在的是旧的，则节点A需要将收到的远端链路状态数据添加或更新至本地维护的链路状态数据库中，然后继续泛洪给除节点N以及recv_bitstring中包含的所有邻居节点之外的所有其它邻居节点；如果本地链路状态数据库中存在的是新的，则节点A只需将本地的新的链路状态数据泛洪给邻居节点N；如果收到的与本地维护的同样新，则不做处理。

b)通过传统的IGP泛洪机制收到：节点A收到后，需检查本地维护的链路状态数据库中是否早已经存在同样的远端链路状态数据并比较新旧。如果本地不存在或者本地存在的是旧的，则节点A需要将收到的远端链路状态数据添加或更新至本地维护的链路状态数据库中，然后继续泛洪给除节点N之外的所有其它邻居；如果本地链路状态数据库中存在的是新的，则节点A只需将本地的新的链路状态数据泛洪给邻居节点N；如果收到的与本地维护的同样新，则不做处理。

上述两种情况中，如果节点A需要向任何邻居泛洪远端链路状态数据，则与第4)步中处理一样，需要根据本节点以及邻居节点是否支持“通过BIER优化冗余泛洪”能力，决定采取传统IGP泛洪机制还是发送相应的“BIER记录”报文(注意配置本地策略可强制采用“BIER记录”报文)。如果是采取发送相应的“BIER记录”报文，则其send_bitstring中将包含节点A自身及其所有邻居的BFR-id信息，特别的，当这种行为是因为节点A从邻居节点N通过“BIER记录”报文收到的远端链路状态数据导致时，则BitString(即send_bitstring)中还包含有从邻居节点N收到的“BIER记录”报文其recv_bitstring中已包含的那些BFR-id信息。

6)进一步的，可配置本地策略，使得当通过“BIER记录”报文向邻居泛洪链路状态数据时，根据本地策略显式的向BIER header中的BitString中添加一些BFR-id信息，而这些BFR-id可能并不是实际的IGP邻居的。在一些具有明显特征的网络拓扑(如Spine-leaf)中，这种本地策略将能够很好的发挥作用减少冗余泛洪现象。需要说明的是，不限于Spine-leaf网络，在其他网络中，也可以使用该方案。比如，CLOS，Fat-tree网络等。

7)由于上述步骤中，各节点在决定是否向邻居泛洪链路状态数据时，会根据recv_bitstring来过滤一些邻居，在一些发生概率很小的极端事件中，那些被过滤掉的邻居之前可能恰好没有接收到相应的链路状态数据，并且也永远无机会再接收到。因此，引入一种纠错机制来防止这种情况，这可以通过在网络中各节点与邻居节点之间仍然使用传统的链路状态数据库同步机制来保证数据一致性，如通过OSPF DDP(Database DescriptionPacket，数据库描述报文)或ISIS CSNP(Complete Sequence Numbers PDU，完全序列号协议数据单元)包含整个链路状态数据库的摘要信息，传统上这种同步机制一般仅在广播链路上开启，在本申请一实施例中，约定只要节点支持“通过BIER优化冗余泛洪”能力，则不管它与邻居之间是通过点到点链路还是广播链路相连，均需要开启以保证数据一致性。对于广播链路，现有的OSPF或ISIS协议定义了一套选举DR(Designated Router，指定的路由器)或DIS(Designated Intermediate-System，指定的中间系统)的规则，并由DR或DIS负责发送其整个链路状态数据库的摘要信息(如OSPF DDP或ISIS CSNP)，其它节点收到后与本地维护的链路状态数据进行对比，识别出哪些链路状态数据DR或DIS有(或新)而本地无(或旧)，或DR或DIS无(或旧)而本地有(或新)，这些识别出来的链路状态数据将会被重新在广播链路上泛洪，与第4)步中处理一样，泛洪发送方节点需要根据本节点以及邻居节点是否支持“通过BIER优化冗余泛洪”能力，决定采取传统IGP泛洪机制还是发送相应的“BIER记录”报文(注意配置本地策略可强制采用“BIER记录”报文)，不再赘述；对于点到点链路，可完全参考广播链路上DR或DIS的选举规则，选举出优先级高的一端节点负责发送其整个链路状态数据库的摘要信息，其它处理同广播链路。

8)以上流程中，利用了BIER header的BitString来记录链路状态数据所经历过的节点的指示信息，为此需要在网络中部署BIER功能。实际上，基于类似的思想，直接利用传统的IGP协议报文的承载头(如Ethernet header(以太网头)，IP header(互联网协议头))做适当的扩展，引入类似BitString一样的字段来记录链路状态数据所经历过的节点的指示信息也是可行的，其处理思路同上。

采用本发明实施例所述方法，与相关技术相比，将显著减少网络中链路状态数据的冗余泛洪现象，并且实现极其简单，成本非常小，相比其它优化手段具有明显优势。

具体实施例一

如图2所示的网络是一种稀疏型网络，假设该网络中运行ISIS协议且使能BIER功能，网络中所有节点都处于ISIS level2中，均支持“通过BIER优化冗余泛洪”能力。网络中首先由节点1～7及相应的链路构成，待网络稳定后，向网络中新增节点X1以及连接网络的链路，接下来我们将观察此事件导致的链路状态数据在网络中的泛洪过程。假设各节点的BFR-id就是其节点编号，如节点1的BFR-id为1。具体如下：

步骤301，节点1与节点X1之间建立ISIS邻居关系后，节点1将产生一条本地的链路状态数据，即从节点1指向节点X1的一条单向链路，记为LSP(1->X1)，同理节点X1也将产生一条本地的链路状态数据，即从节点X1指向节点1的一条单向链路，记为LSP(X1->1)。

步骤302，节点1将本地产生的链路状态数据LSP(1->X1)泛洪给它的所有邻居，由于节点1知道网络中所有节点都具备“通过BIER优化冗余泛洪”能力，则可以通过“BIER记录”报文泛洪(或根据配置的本地策略强制使用“BIER记录”报文泛洪)，此时节点1分别向每个邻居(X1、2、3、4)泛洪的“BIER记录”报文中的BIER header中的BitString中都包含BFRid X1、1、2、3、4，BIER所封装的载荷记为上述链路状态数据LSP(1->X1)。

步骤303，节点2收到上述“BIER记录”报文，从中解析出链路状态数据LSP(1->X1)，添加至本地维护的链路状态数据库，然后继续向其它邻居泛洪。由于收到的上述“BIER记录”报文其recv-bitstring包含BFR id X1、1、2、3、4，即已经包含了邻居节点3的BFR-id，所以节点2只需向邻居节点5泛洪。节点2知道网络中所有节点都具备“通过BIER优化冗余泛洪”能力，则可以通过“BIER记录”报文泛洪(或根据配置的本地策略强制使用“BIER记录”报文泛洪)，此时节点2向邻居节点5泛洪的“BIER记录”报文其send-bitstring中将包含BFRid X1、1、2、3、4、5，BIER所封装的载荷记为上述链路状态数据LSP(1->X1)。

类似的，节点3从节点1收到“BIER记录”报文在本地处理后，也会分别向邻居节点5、6继续通过“BIER记录”报文泛洪，相应的send-bitstring中包含BFR id X1、1、2、3、4、5、6。

类似的，节点4从节点1收到“BIER记录”报文在本地处理后，也会向邻居节点6继续通过“BIER记录”报文泛洪，相应的send-bitstring中包含BFR id X1、1、2、3、4、6。

步骤304，节点5会分别从节点2、3收到相应的链路状态数据泛洪，假设从节点2先收到泛洪，由于相应的recv-bitstring中包含BFR id X1、1、2、3、4、5，所以节点5本地处理后需要向邻居节点7继续通过“BIER记录”报文泛洪，相应的send-bitstring中包含BFR idX1、1、2、3、4、5、7。接下来节点5处理从节点3收到的链路状态数据泛洪，由于本地已经存在同样新的链路状态数据LSP(1->X1)，则不做处理。

类似的，节点6也会分别从节点3、4收到相应的链路状态数据泛洪，本地处理后，也会继续向邻居节点7通过“BIER记录”报文泛洪，相应的send-bitstring中包含BFR id X1、1、2、3、4、6、7。

步骤305，节点7会分别从节点5、6收到相应的链路状态数据泛洪，假设从节点5先收到泛洪，由于相应的recv-bitstring中包含BFR id X1、1、2、3、4、5、7，所以节点7本地处理后需要向邻居节点6继续通过“BIER记录”报文泛洪，相应的send-bitstring中包含BFRid X1、1、2、3、4、5、6、7，邻居节点6收到后，由于本地已经存在同样新的链路状态数据LSP(1->X1)，则不做处理。接下来节点7处理从节点6收到的链路状态数据泛洪，由于本地已经存在同样新的链路状态数据LSP(1->X1)，则不做处理。

步骤306，类似的，节点X1也通过“BIER记录”报文向邻居节点1泛洪链路状态数据LSP(X1->1)，BIER header中的BitString中包含BFR id X1、1，节点1收到该远端链路状态数据后，接下来的泛洪过程与上述泛洪本地链路状体数据LSP(1->X1)是一样的，不再赘述。

从本实施例可知，本实施例提供的方案对稀疏网络的冗余泛洪有一定的优化，减少了部分不必要的冗余泛洪。

具体实施例二

本实例基于实施例一，描述在极端情况下网络中邻居之间可能发生链路状态数据不一致的问题以及相应的纠正机制。仍然如图2所示，假设节点1在将其本地产生的链路状态数据LSP(1->X1)向其所有邻居X1、2、3、4通过“BIER记录”报文泛洪时，与邻居节点2之间的链路突然发生故障断开，则节点1与节点2之间的ISIS邻居关系将删除，节点1无法将链路状态数据LSP(1->X1)向节点2泛洪。上述“BIER记录”报文只会被节点X1、3、4收到，在节点3上，由于收到的“BIER记录”报文其recv-bitstring中已经包含了BFR-id X1、1、2、3、4，所以节点3也不会将相应的链路状态数据LSP(1->X1)继续向节点2泛洪，导致节点2永远无法收到链路状态数据LSP(1->X1)。

为了解决此问题，节点2与节点3之间可选举出高优先级的一端节点(如节点2)周期性的向另一端节点(如节点3)发送其CSNP。此处，节点3收到节点2发送的CSNP后，与其本地维护的链路状态数据库进行对比，发现本地存在的链路状态数据LSP(1->X1)是节点2没有的，于是节点3将通过“BIER记录”报文向节点2发送上述链路状态数据LSP(1->X1)，其send-bitstring中包含BFR-id 1、2、3、4、5、6，节点2收到后，在其本地维护的链路状态数据库中添加LSP(1->X1)，并且不会再向其邻居1、5继续泛洪，因为收到的“BIER记录”报文其recv-bitstring中已经包含了BFR-id 1、2、3、4、5、6。

具体实施例三

本实施例检验本申请技术方案在数据中心网络典型的Spine-leaf架构中的优化效果，如图3所示，是一个K(4,8)拓扑，包含4个Spine，8个Leaf，所有Spine节点都与所有的Leaf节点相连。假设该网络中运行OSPF协议且使能BIER功能，网络中所有节点都处于同一OSPF area中，均支持支持“通过BIER优化冗余泛洪”能力。网络中首先由节点21～29，节点210～212及相应的链路构成，待网络稳定后，向网络中新增节点X2以及连接网络的链路，接下来将观察此事件导致的链路状态数据在网络中的泛洪过程。假设各节点的BFR-id就是其节点编号，如节点21的BFR-id为21。具体如下：

步骤401，节点21与节点X2之间建立OSPF邻居关系后，节点21将产生一条本地的链路状态数据，即从节点21指向节点X2的一条单向链路，记为LSA(21->X2)，同理节点X2也将产生一条本地的链路状态数据，即从节点X2指向节点21的一条单向链路，记为LSA(X2->21)。

步骤402，节点21将本地产生的链路状态数据LSA(21->X2)泛洪给它的所有邻居，由于节点21知道网络中所有节点都具备“通过BIER优化冗余泛洪”能力，则可以通过“BIER记录”报文泛洪(或根据配置的本地策略强制使用“BIER记录”报文泛洪)；另外，在节点21配置本地策略，该策略允许将与它同样作为Spine角色的所有其它Spine节点22、23、24的BFR-id添加至节点21对外泛洪的“BIER记录”报文的send-bitstring中，虽然其它Spine节点22、23、24与节点21之间并无建立OSPF邻居关系，这种本地策略将控制向绝大多数Leaf侧邻居节点(如节点26～212)泛洪的“BIER记录”报文其send-bitstring中将额外添加有其它Spine节点22、23、24的BFR-id信息，而仅向极少数Leaf侧邻居节点(如仅单个节点25)泛洪的“BIER记录”报文其send-bitstring中不添加有其它Spine节点22、23、24的BFR-id信息。

因此，节点21分别向每个邻居(X2、25、26、27、28、29、210、211、212)泛洪“BIER记录”报文时，向节点25泛洪的“BIER记录”报文其send-bitstring中包含BFR id X2、21、25、26、27、28、29、210、211、212，向节点26～212泛洪的“BIER记录”报文其send-bitstring中包含BFR id X2、21、22、23、24、25、26、27、28、29、210、211、212，BIER所封装的载荷记为上述链路状态数据LSA(21->X2)。

步骤403，节点25收到上述“BIER记录”报文，从中解析出链路状态数据LSA(21->X2)，添加至本地维护的链路状态数据库，然后继续向其它邻居泛洪。由于相应的recv-bitstring中包含BFR id X2、21、25、26、27、28、29、210、211、212，所以节点25需向邻居节点22、23、24泛洪。此时节点25向邻居节点22、23、24泛洪的“BIER记录”报文其send-bitstring中将包含BFR id X2、21、22、23、24、25、26、27、28、29、210、211、212，BIER所封装的载荷记为上述链路状态数据LSA(21->X2)。

类似的，节点26也从节点21收到相应的“BIER记录”报文，从中解析出链路状态数据LSA(21->X2)，添加至本地维护的链路状态数据库。由于收到的“BIER记录”报文其recv-bitstring中已经包含BFR id X2、21、22、23、24、25、26、27、28、29、210、211、212，因此不会再向邻居22、23、24泛洪上述链路状态数据LSA(21->X2)。节点27、28、29、210、211、212与节点26的处理是类似的。

步骤404，节点22从节点25收到链路状态数据LSA(21->X2)的泛洪后，从中解析出链路状态数据LSA(21->X2)，添加至本地维护的链路状态数据库。由于收到的“BIER记录”报文其recv-bitstring中已经包含BFR id X2、21、22、23、24、25、26、27、28、29、210、211、212，因此不会再向邻居节点25～212泛洪上述链路状态数据LSA(21->X2)。节点23、24的处理与节点22是类似的。

步骤405，类似的，节点X2也通过“BIER记录”报文向邻居节点21泛洪链路状态数据LSA(X2->21)，相应的send-bitstring中包含BFR id X2、21，节点21收到该远端链路状态数据后，接下来的泛洪过程与上述泛洪本地链路状体数据LSA(21->X2)是一样的，不再赘述。

本实施例提供的方案，相比不在记录信息中添加Spine节点22、23、24的实现方式，可以避免邻居节点26、27、28、29、210、211、212向Spine节点22,23,24发送携带链路状态数据的报文，减少了冗余泛洪，提高了收敛速度，本实施例方案对Spine-leaf类型的密集网络的冗余泛洪有显著的优化，减少了绝大部分不必要的冗余泛洪。

具体实施例四

本实施例检验本申请在一个完全full-mesh的网络中的优化效果，如图4所示，是一个包含有8个节点的full-mesh拓扑，每个节点都与其它所有节点直连。假设该网络中运行OSPF协议且使能BIER功能，网络中所有节点都处于同一OSPF area中，均支持支持“通过BIER优化冗余泛洪”能力，并假设各节点的BFR-id就是其节点编号，如节点31的BFR-id为31。网络中首先由节点31～38及相应的链路构成，待网络稳定后，向网络中新增节点X3以及连接网络的链路，此事件导致的链路状态数据在网络中的泛洪过程与前述实施例完全类似，只不过在此例中，我们将观察到一个非常极端的现象，那就是链路状态数据只需泛洪一次即可，不存在被邻居继续泛洪的现象。比如节点31通过“BIER记录”报文将本地产生的链路状态数据LSA(31->X3)向它的所有邻居节点X3、32、33、34、35、36、37、38泛洪时，相应的send-bitstring中将包含BFR id X3、31、32、33、34、35、36、37、38，每个邻居节点收到上述“BIER记录”报文后，都仅仅从中解析出链路状态数据LSA(31->X3)，添加至本地维护的链路状态数据库，不再继续向各自的邻居泛洪。具体流程不再赘述。

从本实施例可知，本实施例提供的方案，对完全full-mesh的密集网络的冗余泛洪的优化效果最好，完全减少了任何不必要的冗余泛洪。

如图5所示，本发明一实施例提供一种内部网关协议泛洪优化装置50，包括存储器510和处理器520，所述存储器510存储有程序，所述程序在被所述处理器520读取执行时，实现任一实施例所述的内部网关协议泛洪优化方法。

如图6所示，本发明一实施例提供一种计算机可读存储介质60，所述计算机可读存储介质存储有一个或者多个程序610，所述一个或者多个程序可被一个或者多个处理器执行，以实现任一实施例所述的内部网关协议泛洪优化方法。

本领域普通技术人员可以理解，上文中所公开方法中的全部或某些步骤、系统、装置中的功能模块/单元可以被实施为软件、固件、硬件及其适当的组合。在硬件实施方式中，在以上描述中提及的功能模块/单元之间的划分不一定对应于物理组件的划分；例如，一个物理组件可以具有多个功能，或者一个功能或步骤可以由若干物理组件合作执行。某些组件或所有组件可以被实施为由处理器，如数字信号处理器或微处理器执行的软件，或者被实施为硬件，或者被实施为集成电路，如专用集成电路。这样的软件可以分布在计算机可读介质上，计算机可读介质可以包括计算机存储介质(或非暂时性介质)和通信介质(或暂时性介质)。如本领域普通技术人员公知的，术语计算机存储介质包括在用于存储信息(诸如计算机可读指令、数据结构、程序模块或其他数据)的任何方法或技术中实施的易失性和非易失性、可移除和不可移除介质。计算机存储介质包括但不限于RAM、ROM、EEPROM、闪存或其他存储器技术、CD-ROM、数字多功能盘(DVD)或其他光盘存储、磁盒、磁带、磁盘存储或其他磁存储装置、或者可以用于存储期望的信息并且可以被计算机访问的任何其他的介质。此外，本领域普通技术人员公知的是，通信介质通常包含计算机可读指令、数据结构、程序模块或者诸如载波或其他传输机制之类的调制数据信号中的其他数据，并且可包括任何信息递送介质。

Claims (12)

1.一种内部网关协议泛洪优化方法，包括：

第一节点向邻居节点泛洪携带链路状态数据和第一记录信息的第一报文，所述第一记录信息包括所述链路状态数据所经历的节点的指示信息。

2.根据权利要求1所述的内部网关协议泛洪优化方法，其特征在于，所述第一节点向邻居节点泛洪携带链路状态数据和第一记录信息的报文包括：

所述第一节点本地产生所述链路状态数据时，所述第一节点向邻居节点泛洪所述第一报文；其中，所述第一记录信息包括所述第一节点的标识及所述第一节点的所有邻居节点的标识。

3.根据权利要求1所述的内部网关协议泛洪优化方法，其特征在于，所述第一节点向邻居节点泛洪携带链路状态数据和记录信息的报文包括：

所述第一节点接收到来自第二节点的携带第二记录信息及所述链路状态数据的第二报文，且本地不存在所述链路状态数据或者所述链路状态数据新于本地的链路状态数据时，所述第一节点向除所述第二节点以及所述第二记录信息指示的节点外的邻居节点泛洪所述第一报文，所述第一记录信息中包括所述第一节点的标识、所述第一节点的所有邻居节点的标识以及所述第二记录信息。

4.根据权利要求1所述的内部网关协议泛洪优化方法，其特征在于，所述第一记录信息中还包括所述链路状态数据未经历的节点的指示信息，其中，所述链路状态数据未经历的节点根据预设策略配置。

5.根据权利要求4所述的内部网关协议泛洪优化方法，其特征在于，当所述第一节点为分层网络架构中的节点时，所述链路状态数据未经历的节点包括与所述第一节点处于同一层的其他节点，所述分层网络架构包括多层节点，同一层内的节点彼此无连接或者仅有部分连接，节点与下一层的节点全连接。

6.根据权利要求1所述的内部网关协议泛洪优化方法，其特征在于，第一节点向邻居节点泛洪携带链路状态数据和第一记录信息的第一报文包括：

当所述第一节点支持预设泛洪优化能力时，所述第一节点向支持所述预设泛洪优化能力的邻居节点泛洪所述第一报文。

7.根据权利要求1所述的内部网关协议泛洪优化方法，其特征在于，所述第一报文为位索引显式复制报文，所述第一记录信息使用所述位索引显式复制报文的报文头中的比特串携带。

8.根据权利要求7所述的内部网关协议泛洪优化方法，其特征在于，所述位索引显式复制报文中的保留字段设置为第一预设值，指示所述位索引显式复制报文的报文头中的比特串携带所述第一记录信息。

9.根据权利要求7所述的内部网关协议泛洪优化方法，其特征在于，所述位索引显式复制报文中的Proto字段设置为第二预设值或第三预设值，指示所述位索引显式复制报文携带的载荷类型为链路状态数据。

10.根据权利要求1至9任一所述的内部网关协议泛洪优化方法，其特征在于，所述方法还包括：所述节点与其邻居节点周期性同步链路状态数据库。

11.一种内部网关协议泛洪优化装置，其特征在于，包括存储器和处理器，所述存储器存储有程序，所述程序在被所述处理器读取执行时，实现如权利要求1至10任一所述的内部网关协议泛洪优化方法。

12.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有一个或者多个程序，所述一个或者多个程序可被一个或者多个处理器执行，以实现如权利要求1至10任一所述的内部网关协议泛洪优化方法。

Images