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

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

Info

Publication number
WO2021022945A1
WO2021022945A1 PCT/CN2020/099018 CN2020099018W WO2021022945A1 WO 2021022945 A1 WO2021022945 A1 WO 2021022945A1 CN 2020099018 W CN2020099018 W CN 2020099018W WO 2021022945 A1 WO2021022945 A1 WO 2021022945A1
Authority
WO
WIPO (PCT)
Prior art keywords
node
link state
state data
nodes
flooding
Prior art date
Application number
PCT/CN2020/099018
Other languages
English (en)
French (fr)
Inventor
彭少富
王会来
孙晋松
陈华南
朱永庆
Original Assignee
南京中兴软件有限责任公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 南京中兴软件有限责任公司 filed Critical 南京中兴软件有限责任公司
Priority to CA3147310A priority Critical patent/CA3147310A1/en
Priority to EP20849979.8A priority patent/EP4012988A4/en
Priority to US17/633,620 priority patent/US20220321461A1/en
Publication of WO2021022945A1 publication Critical patent/WO2021022945A1/zh

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/32—Flooding
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/12—Discovery or management of network topologies
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/02—Topology update or discovery
    • H04L45/03—Topology update or discovery by updating link state protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/16—Multipoint routing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H04L49/15—Interconnection of switching modules
    • H04L49/1515—Non-blocking multistage, e.g. Clos
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0894—Policy-based network configuration management

Definitions

  • the embodiments of the present disclosure relate to, but are not limited to, an internal gateway protocol flood optimization method, device, and storage medium.
  • IGP Interior Gateway Protocol
  • ISIS Intermediate System to Intermediate System, Intermediate System to Intermediate System Protocol
  • OSPF Open Shortest Path First, Open Shortest Path First
  • the link state routing protocol relies on a certain flooding algorithm. In a dense topology, this flooding algorithm is highly redundant, and each node in the topology will The same link status update is received multiple times from each link.
  • At least one embodiment of the present disclosure provides a method and device for optimizing flooding of an internal gateway protocol, and a storage medium to reduce redundant flooding and improve network convergence speed.
  • At least one embodiment of the present disclosure provides an internal gateway protocol flood optimization method, including:
  • the first node floods a first message carrying link state data and first record information to neighboring nodes, where the first record information includes indication information of the node through which the link state data has experienced.
  • At least one embodiment of the present disclosure provides an internal gateway protocol flooding optimization device, which includes a memory and a processor, the memory stores a program, and when the program is read and executed by the processor, implements the method described in any of the embodiments.
  • At least one embodiment of the present disclosure provides a computer-readable storage medium, the computer-readable storage medium stores one or more programs, and the one or more programs can be executed by one or more processors to implement any The flooding optimization method of the internal gateway protocol described in an embodiment.
  • an embodiment of the present disclosure provides an internal gateway protocol flooding optimization method, which includes: a first node floods a neighbor node with a first message carrying link state data and first record information, and The first record information includes indication information of nodes experienced by the link state data.
  • FIG. 1 is a flowchart of an internal gateway protocol flood optimization method provided by an embodiment of the present disclosure
  • Figure 2 is a network topology diagram of specific embodiments one and two of the present disclosure
  • Figure 3 is a network topology diagram of the third embodiment of the present disclosure.
  • Figure 4 is a network topology diagram of the fourth embodiment of the present disclosure.
  • FIG. 5 is a block diagram of an internal gateway protocol flooding optimization device provided by an embodiment of the present disclosure.
  • Fig. 6 is a block diagram of a computer-readable storage medium provided by an embodiment of the present disclosure.
  • RFC8279 defines the BIER (Bit Indexed Explicit Replication) architecture, which is a new architecture for multicast data packet forwarding, and provides the optimal path for multicast data packet forwarding in the multicast domain. There is no need to use a protocol to establish a multicast distribution tree, and no intermediate nodes to maintain any flow state.
  • BIER Bit Indexed Explicit Replication
  • BFIR Bit-Forwarding Ingress Router
  • BFER Bit forwarding egress router
  • RFC8296 defines the encapsulation format of BIER messages.
  • BIER header BIER header
  • BitString Bit string
  • BFR-id Bit- Forwarding Router-id, bit forwarding router identifier
  • SI Set Identifier
  • SI and BitString determine which BFER the message is forwarded to. If SI is n and the Kth bit in BitString is 1 (the lowest bit is the 1st bit), the message will be sent to the BFER whose BFR-id is n*BSL+K.
  • RFC8279 also describes the layered model of the BIER architecture: at the bottom routing layer, unicast routing and forwarding information is generally established through IGP. Of course, in a few cases, it may also be through BGP (Border Gateway Protocol) or other methods such as static routing.
  • BGP Border Gateway Protocol
  • the BIER layer in the middle layer contains the protocols and procedures used to transmit multicast data messages in the BIER domain (BIER domain);
  • the service multicast stream layer in the upper layer contains groups Broadcast service protocol set, BFIR determines the function of the BFER set for multicast data packets, and how BFER further forwards the message when it receives the BIER-encapsulated message from the BIER domain. It can be seen from the above layered model that the forwarding of BIER messages generally depends on the underlying IGP unicast routing and forwarding.
  • a mechanism is provided for introducing BIER technology into a dense network topology to solve and optimize the problem of redundant flooding of link state data of the IGP protocol.
  • the BIER technology is introduced into the dense network topology and a set of BIER-based link state data flooding mechanism is provided to reduce the redundant flooding of the link state data of the IGP protocol and improve network convergence speed.
  • An embodiment of the present disclosure provides an internal gateway protocol flood optimization method, as shown in FIG. 1, including:
  • Step 101 A first node floods a neighbor node with a first packet carrying link state data and first record information, where the first record information includes indication information of the node that the link state data has experienced.
  • the indication information of the node is, for example, a node identifier.
  • the node identifier can be a variety of identifiers, such as BFR-id, the physical identifier of the node, and so on.
  • the link state data flooding by the first node may be caused by locally generated link state data, or may be caused by receiving link state data from other nodes.
  • the nodes experienced by the link state data may include the first node and all neighbor nodes of the first node;
  • the link state data is received by the first node from other nodes, and the second record information is also received when the link state data is received, the nodes experienced by the link state data in addition to the first node and the first node In addition to all neighbor nodes, it also includes the node indicated in the received second record information. It should be noted that the first node, all neighbor nodes of the first node, and the node indicated in the second record information may overlap. When carrying, only one of the same node may be kept.
  • the flooding of the first message carrying link state data and first record information by the first node to neighbor nodes includes:
  • the first node When the first node locally generates the link state data, the first node floods the first message to neighbor nodes; wherein, the first record information includes the identification of the first node and the The identities of all neighbor nodes of the first node. That is, the link state data is generated by the first node and flooded.
  • the flooding of the first message carrying link state data and first record information by the first node to neighbor nodes includes:
  • the first node receives the second message carrying the second record information and the link state data from the second node, and the link state data does not exist locally or the link state data is new to the local
  • the first node floods the first packet to neighboring nodes other than the second node and the node indicated by the second record information, and the first record information includes The identifier of the first node, the identifiers of all neighbor nodes of the first node, and the second record information.
  • the solution provided in this embodiment sends link state information to nodes that have not experienced link state information based on the carried nodes, thereby greatly reducing the number of sent messages and improving convergence speed.
  • a capability switch that supports flooding optimization can be set.
  • Each node in the network can enable or disable the capability switch. When enabled, it supports sending and receiving link state data and records. When the information message is not enabled, the link state data flooding is realized based on related technologies.
  • the processing is the same as that of the node that does not enable the capability switch. Specifically, when the switch of the first node is enabled, the first node sends a first message carrying link state data and first record information to neighboring nodes that enable the switch, and for other neighbors that do not enable the switch The node performs link state data flooding according to the scheme in the related technology.
  • the first record information carried in the message sent by the first node to the neighbor node that enables the capability switch includes the indication information of the neighbor node that is not enabled or does not support the flood optimization capability.
  • the capability switch may not be set. By default, all nodes support receiving and sending the message carrying the link state data and the first record information, or the mandatory configuration enables the capability of all nodes switch.
  • the flooding of the first message carrying link state data and first record information by the first node to neighbor nodes includes:
  • the first node When the first node supports the preset flooding optimization capability, the first node floods the first message carrying link state data and first record information to neighbor nodes that support the preset flooding optimization capability .
  • the first record information further includes indication information of nodes that have not experienced the link state data, and the nodes that have not experienced the link state data are configured according to a preset policy.
  • the preset strategy can be configured as required, for example, according to the network structure.
  • the nodes that the link state data has not experienced include other nodes in the same layer as the first node, and the layer
  • the network architecture includes multiple layers of nodes. The nodes in the same layer are not connected to each other or only partially connected, and the nodes are fully connected to the nodes of the next layer.
  • Hierarchical network architectures include Spine-leaf (leaf spine), CLOS, Fat-tree and other network architectures.
  • nodes that have not undergone the link state data include spine nodes in the leaf-spine architecture other than the first node.
  • nodes that the link state data has not experienced include other leaf nodes at the same layer as the first node.
  • the first record information in the message sent by the first node to one of the neighbor nodes includes indication information of the first node and all neighbor nodes
  • the first record information in the message sent by the first node to other neighbor nodes includes Indication information of the first node, all neighboring nodes, and nodes that are configured according to a preset policy and that have not experienced the link state data.
  • the above technical solution can be implemented in combination with BIER.
  • the first message is a BIER message, and the first record information is carried using a bit string in a header of the BIER message.
  • Each node enables BIER capability.
  • the reserved field in the BIER message is set to a first preset value, indicating that the bit string in the header of the BIER message carries the first record information.
  • the Proto field in the BIER message is set to a second preset value or a third preset value, indicating that the load type carried in the BIER message is link state data.
  • the method further includes: periodically synchronizing a link state database between the node and its neighbor nodes.
  • link state database synchronization function such as the traditional link state database synchronization mechanism.
  • this synchronization mechanism is generally only enabled on the broadcast link.
  • this synchronization mechanism is generally only enabled on the broadcast link.
  • it regardless of whether it is connected to its neighbors through a point-to-point link or a broadcast link, it needs to be enabled to ensure data consistency. Sex. Or, it is agreed that as long as a node supports the flooding optimization capability, no matter whether it is connected to its neighbors through a point-to-point link or a broadcast link, it needs to be turned on to ensure data consistency.
  • IGP area/level refers to the area composed of some nodes and the links connecting these nodes. These nodes run the same IGP protocol such as ISIS or OSPF, and advertise the area/level information of their own nodes and local links. It forms a three-layer routing network topology, such as ISIS level-2, ISIS level-1, and OSPF area. In the subsequent description of this article, sometimes the word "network" is used directly instead of "IGP area/level" to facilitate description.
  • a "BIER record” function is introduced in the BIER forwarding mechanism in the related technology, which can record which nodes the BIER encapsulated load has gone through, that is, the BitString in the BIER header records all the node information the load has gone through.
  • the payload here refers to IGP link state data, such as ISIS LSP (Link State PDU, Link State Protocol Data Unit) messages or OSPF LSU (Link State Update, Link State Update) messages.
  • ISIS LSP Link State PDU, Link State Protocol Data Unit
  • OSPF LSU Link State Update, Link State Update
  • the Rsv field in the current BIER header is not used, and its lowest bit can be used as the R flag to indicate whether the BIER message is a BIER message carrying record information or a traditional BIER message. For example, when the R flag is set to 1, it means that the BIER message is not a traditional BIER message and does not perform traditional BIER message forwarding. The message carries record information. At this time, the TTL (Time to Live) in the BIER header Time) should be set to 1 at the same time; when the R flag is set to 0, it means that the BIER message is a traditional ordinary BIER message, and its forwarding logic follows the existing RFC8296. It should be noted that this is only an example, and the R flag can also be set to other values. In addition, the R flag can also use other fields or other bits of the Rsv field.
  • Extended Proto field The Proto field in the current BIER header does not support the use of IGP protocol packets as the payload.
  • IANA Internet Assigned Numbers Authority
  • two selected from 7 to 62 represent ISIS LSP packet and OSPF LSU packet, for example, in one embodiment, 7 represents ISIS LSP packet, and 8 represents OSPF LSU packet.
  • other values can also be used to indicate, for example, using the same value to indicate that the IGP protocol message is used as the payload. For example, using 7 indicates that the IGP protocol message is used as the payload.
  • the text may be ISIS LSP packet or OSPF LSU packet.
  • B flag BIER optimized redundancy flooding
  • IS-IS Router Capability TLV-242 can be extended (refer to RFC7981, take one from the Reserved part of the Flags field in IS-IS Router CAPABILITY TLV (Routing Capability Type Length Value) Bits are used for the above B flag) and Router Information Opaque LSA (refer to RFC7770, take one bit from the Informational Capabilities (unassigned) part of the OSPF Router Information Capabilities TLV (OSPF routing information capability type length value) Used for the above B flag), the above B flag is added.
  • the B flag is set to 1 to indicate that the capability notifier node supports “optimized redundancy flooding through BIER", which means that the node supports the identification and processing of the aforementioned "BIER records”
  • the packet and the payload type that identifies the BIER encapsulation is the aforementioned ISIS LSP packet or OSPF LSU packet, and the B flag is set to 0 to indicate that the capability notifier node does not support "optimizing redundant flooding through BIER".
  • the B flag can also be set to other values to indicate whether to support "optimizing redundant flooding through BIER”.
  • the switch of "optimizing redundancy flooding through BIER" may not be configured, and all nodes support the capability of "optimizing redundancy flooding through BIER" by default.
  • the BitString in the "BIER record” message (in order to avoid confusion In this article, the BitString in the BIER header in the sent "BIER record” message is marked as send_bitstring) contains the BFR-id information of node A itself and all its neighbor nodes, and the encapsulated payload is the above link state data (such as ISIS LSP or OSPF LSU). Note that when there are multiple links between node A and neighbor node N, you only need to choose to send the above-mentioned "BIER record” message along one of the links, and it is not allowed to send redundantly along each link.
  • node A If node A does not support “optimizing redundant flooding through BIER", or perceiving that neighbor node N does not have the capability of "optimizing redundant flooding through BIER", node A will use the traditional IGP flooding mechanism to flood the chain to node N Road status data.
  • a certain node A in the network may receive non-locally generated link state data (or remote link state data) from a neighbor node N, which may be through traditional IGP flooding
  • the mechanism received may also be received through a "BIER record” message (to avoid confusion, this article will record the BitString in the BIER header in the received "BIER record” message as recv_bitstring).
  • node A After node A receives it, it needs to check whether the same remote link state data already exists in the locally maintained link state database and compare the new and old ones. If the local does not exist or the local one is old, node A needs to add or update the received remote link state data to the locally maintained link state database, and then continue to flood it to nodes N and recv_bitstring All other neighbor nodes except all neighbor nodes included; if there is a new one in the local link state database, node A only needs to flood the new local link state data to neighbor node N; if it receives If it is as new as the locally maintained one, it will not be processed.
  • node A After node A receives it, it needs to check whether the same remote link state data already exists in the locally maintained link state database and compare the new and old ones. If the local does not exist or the local one is old, then node A needs to add or update the received remote link state data to the locally maintained link state database, and then continue to flood it to other than node N All other neighbors; if the local link state database is new, then node A only needs to flood the local new link state data to neighbor node N; if the received is as new as the one maintained locally, then No processing.
  • node A needs to flood the remote link state data to any neighbor, it is the same as the processing in step 4). It needs to be based on whether the node and neighbor nodes support "optimize redundant flooding through BIER” Ability to decide whether to adopt the traditional IGP flooding mechanism or send the corresponding "BIER record” message (note that the configuration of the local policy can force the use of "BIER record” message). If the corresponding "BIER record” message is sent, its send_bitstring will contain the BFR-id information of node A itself and all its neighbors.
  • BitString (ie send_bitstring) also contains the BFR-id information contained in the "BIER record” message received from the neighbor node N and its recv_bitstring .
  • a local policy can be configured so that when link state data is flooded to neighbors through a "BIER record" message, some BFR-id information is explicitly added to the BitString in the BIER header according to the local policy, and These BFR-ids may not be the actual IGP neighbors.
  • this local strategy will work well to reduce redundant flooding. It should be noted that it is not limited to the Spine-leaf network, and this solution can also be used in other networks. For example, CLOS, Fat-tree network, etc.
  • each node when it decides whether to flood the link state data to the neighbor, it will filter some neighbors according to recv_bitstring. In some extreme events with a small probability of occurrence, those neighbors that are filtered out may just happen to be before The corresponding link state data is not received, and there will never be a chance to receive it again. Therefore, an error correction mechanism is introduced to prevent this situation.
  • This can ensure data consistency by still using the traditional link state database synchronization mechanism between each node in the network and neighboring nodes, such as OSPF DDP (Database Description) Packet, Database Description Packet) or ISIS CSNP (Complete Sequence Numbers PDU, Complete Sequence Number Protocol Data Unit) contains summary information of the entire link state database.
  • OSPF DDP Database Description
  • Database Description Packet Database Description Packet
  • ISIS CSNP Complete Sequence Numbers PDU, Complete Sequence Number Protocol Data Unit
  • this synchronization mechanism is generally only enabled on the broadcast link.
  • the existing OSPF or ISIS protocol defines a set of rules for electing DR (Designated Router) or DIS (Designated Intermediate-System), and DR or DIS is responsible for sending it
  • DR Designated Router
  • DIS Designated Intermediate-System
  • the flooding sender node needs to decide whether to adopt the traditional IGP flooding mechanism or to send the corresponding "BIER record” message according to whether the node and neighbor nodes support the "optimized redundant flooding through BIER” capability (note that the local policy can be configured) Mandatory use of "BIER record” message), no more details; for point-to-point links, you can completely refer to the election rules of DR or DIS on the broadcast link, and elect a node with a higher priority to be responsible for sending its entire link state
  • the summary information of the database, other processing is the same as the broadcast link.
  • the BitString of the BIER header is used to record the indication information of the nodes that the link state data has experienced. For this reason, the BIER function needs to be deployed in the network.
  • directly use the traditional IGP protocol message bearer headers such as Ethernet header (Ethernet header), IP header (Internet protocol header)
  • IGP protocol message bearer headers such as Ethernet header (Ethernet header), IP header (Internet protocol header)
  • Ethernet header Ethernet header
  • IP header Internet protocol header
  • the network shown in Figure 2 is a sparse network. Assuming that the ISIS protocol is running in the network and the BIER function is enabled, all nodes in the network are in ISIS level 2, and they all support the ability to optimize redundant flooding through BIER.
  • the network first consists of nodes 1-7 and the corresponding links. After the network is stable, add node X1 and the link connecting the network to the network. Next, we will observe the link status data caused by this event in the network The flooding process. Assume that the BFR-id of each node is its node number, for example, the BFR-id of node 1 is 1. details as follows:
  • Step 301 After the ISIS neighbor relationship is established between node 1 and node X1, node 1 will generate a piece of local link state data, that is, a unidirectional link from node 1 to node X1, denoted as LSP(1->X1 ). Similarly, node X1 will also generate a piece of local link state data, that is, a unidirectional link from node X1 to node 1, denoted as LSP (X1->1).
  • node 1 floods the locally generated link state data LSP (1->X1) to all its neighbors. Since node 1 knows that all nodes in the network have the ability to optimize redundant flooding through BIER, then The "BIER record” message can be flooded (or forced to use the "BIER record” message flooding according to the configured local policy). At this time, node 1 floods each neighbor (X1, 2, 3, 4) The BitString in the BIER header in the "BIER record” message all contains the BFR id X1, 1, 2, 3, 4, and the payload encapsulated by the BIER is recorded as the aforementioned link state data LSP (1->X1).
  • node 2 receives the above-mentioned "BIER record” message, parses the link state data LSP (1->X1) from it, adds it to the locally maintained link state database, and then continues to flood other neighbors. Since the recv-bitstring of the received "BIER record” message contains BFR id X1, 1, 2, 3, 4, which already contains the BFR-id of neighbor node 3, node 2 only needs to report to neighbor node 5. flood.
  • Node 2 knows that all nodes in the network have the ability to "optimize redundant flooding through BIER", and can flood the "BIER record” message (or force the use of "BIER record” message flooding according to the configured local policy), At this time, the "BIER record” message flooded by node 2 to neighbor node 5 will contain BFR id X1, 1, 2, 3, 4, 5 in its send-bitstring, and the payload encapsulated by BIER is recorded as the above link state data LSP(1->X1).
  • node 3 After node 3 receives the "BIER record” message from node 1 and processes it locally, it will also continue to flood the neighbor nodes 5 and 6 through the "BIER record” message, and the corresponding send-bitstring contains BFR id X1, 1, 2, 3, 4, 5, 6.
  • node 4 After node 4 receives the "BIER record” message from node 1 and processes it locally, it will continue to flood the neighbor node 6 through the "BIER record” message, and the corresponding send-bitstring contains BFR id X1, 1 , 2, 3, 4, 6.
  • step 304 node 5 will receive corresponding link state data flooding from nodes 2 and 3 respectively. Assuming that slave node 2 receives the flooding first, since the corresponding recv-bitstring contains BFR id X1, 1, 2, 3 , 4, 5, so node 5 needs to continue to flood the neighbor node 7 through the "BIER record" message after local processing, and the corresponding send-bitstring contains BFR id X1, 1, 2, 3, 4, 5, 7. Next, the node 5 processes the flooding of the link state data received from the node 3. Since the same new link state data LSP (1->X1) already exists locally, no processing is performed.
  • node 6 will also receive the corresponding link state data flooding from nodes 3 and 4 respectively. After local processing, it will continue to flood the neighbor node 7 through the "BIER record" packet, and the corresponding send-bitstring It contains BFR id X1, 1, 2, 3, 4, 6, 7.
  • node 7 will receive the corresponding link state data flooding from nodes 5 and 6, assuming that slave node 5 receives the flooding first, because the corresponding recv-bitstring contains BFR id X1, 1, 2, 3 , 4, 5, 7, so node 7 needs to continue to flood the neighbor node 6 through the "BIER record" message after local processing, and the corresponding send-bitstring contains BFR id X1, 1, 2, 3, 4, 5, 6.
  • the node 7 processes the flooding of the link state data received from the node 6. Since the same new link state data LSP (1->X1) already exists locally, no processing is performed.
  • Step 306 similarly, node X1 also floods the link state data LSP (X1->1) to neighbor node 1 through the "BIER record" message.
  • the BitString in the BIER header contains BFR id X1, 1, and node 1 receives After the remote link state data is reached, the subsequent flooding process is the same as the above-mentioned flooding of the local link state data LSP (1->X1), and will not be repeated.
  • the solution provided by this embodiment has a certain optimization on the redundancy flooding of a sparse network, and reduces part of unnecessary redundancy flooding.
  • this example describes the problem of link state data inconsistency between neighbors in the network under extreme conditions and the corresponding correction mechanism.
  • Figure 2 it is assumed that when node 1 floods its locally generated link state data LSP (1->X1) to all its neighbors X1, 2, 3, 4 through the "BIER record” message, and If the link between neighboring nodes 2 suddenly fails and disconnects, the ISIS neighbor relationship between node 1 and node 2 will be deleted, and node 1 cannot flood the link state data LSP (1->X1) to node 2.
  • the above "BIER record” message will only be received by nodes X1, 3, and 4.
  • node 2 and node 3 can elect a high-priority one end node (such as node 2) to periodically send its CSNP to the other end node (such as node 3).
  • node 3 receives the CSNP sent by node 2, compares it with the link state database maintained locally, and finds that the locally existing link state data LSP (1->X1) is not available in node 2, so node 3 will Send the above-mentioned link state data LSP (1->X1) to node 2 through the "BIER record” message, and its send-bitstring contains BFR-id 1, 2, 3, 4, 5, 6, and node 2 will receive it , Add LSP (1->X1) to its locally maintained link state database, and will not continue to flood its neighbors 1, 5, because the received "BIER record” packet has already been in the recv-bitstring Contains BFR-id 1, 2, 3, 4, 5, 6.
  • This embodiment tests the optimization effect of the technical solution of the application in the typical Spine-leaf architecture of the data center network.
  • FIG. 3 it is a K(4,8) topology, including 4 Spine, 8 Leaf, and all Spine
  • the nodes are connected to all Leaf nodes.
  • the network first consists of nodes 21-29, nodes 210-212 and the corresponding links. After the network is stable, add node X2 and the link connecting the network to the network, and then observe the link status caused by this event The flooding process of data in the network.
  • the BFR-id of each node is its node number, for example, the BFR-id of node 21 is 21. details as follows:
  • Step 401 After the OSPF neighbor relationship is established between node 21 and node X2, node 21 will generate a piece of local link state data, that is, a unidirectional link from node 21 to node X2, denoted as LSA (21->X2 ). Similarly, node X2 will also generate a piece of local link state data, that is, a unidirectional link from node X2 to node 21, denoted as LSA (X2->21).
  • the node 21 floods the locally generated link state data LSA (21->X2) to all its neighbors. Since the node 21 knows that all nodes in the network have the capability of "optimizing redundant flooding through BIER", then You can use "BIER record” message flooding (or force the use of "BIER record” message flooding according to the configured local policy); in addition, configure a local policy on node 21, which allows all those who have the same Spine role as it The BFR-ids of other Spine nodes 22, 23, and 24 are added to the send-bitstring of the "BIER record” packet flooded by node 21, although no OSPF is established between other Spine nodes 22, 23, and 24 and node 21 Neighbor relationship.
  • This local strategy will control the "BIER record” message flooded to most of the leaf-side neighbor nodes (such as nodes 26 to 212). Other Spine nodes 22, 23, 24 will be added to the send-bitstring.
  • the send-bitstring of the "BIER record” message that floods only a few Leaf-side neighbor nodes (such as only a single node 25) does not add the BFR-id information of other Spine nodes 22, 23, 24. id information.
  • node 21 floods the "BIER record” message to each neighbor (X2, 25, 26, 27, 28, 29, 210, 211, 212), it floods the "BIER record” message to node 25
  • the send-bitstring contains the BFR id X2, 21, 25, 26, 27, 28, 29, 210, 211, 212
  • the "BIER record” packet flooded to nodes 26 to 212 contains the BFR id in the send-bitstring X2, 21, 22, 23, 24, 25, 26, 27, 28, 29, 210, 211, 212, the payload encapsulated by BIER is recorded as the above-mentioned link state data LSA (21->X2).
  • the node 25 receives the above-mentioned "BIER record” message, parses the link state data LSA (21->X2) from it, adds it to the locally maintained link state database, and then continues to flood other neighbors. Since the corresponding recv-bitstring contains BFR id X2, 21, 25, 26, 27, 28, 29, 210, 211, 212, the node 25 needs to flood the neighbor nodes 22, 23, 24. At this time, the "BIER record” message that node 25 floods to neighbor nodes 22, 23, 24 will contain BFR id X2, 21, 22, 23, 24, 25, 26, 27, 28, 29, in the send-bitstring. 210, 211, 212, the payload encapsulated by BIER is recorded as the above-mentioned link state data LSA (21->X2).
  • the node 26 also receives the corresponding "BIER record” message from the node 21, parses the link state data LSA (21->X2) from it, and adds it to the link state database maintained locally. Since the recv-bitstring of the received "BIER record” message already contains BFR id X2, 21, 22, 23, 24, 25, 26, 27, 28, 29, 210, 211, 212, it will not be sent to The neighbors 22, 23, and 24 flood the above-mentioned link state data LSA (21->X2). The processing of nodes 27, 28, 29, 210, 211, 212 and node 26 are similar.
  • Step 404 After the node 22 receives the flooding of the link state data LSA (21->X2) from the node 25, it parses the link state data LSA (21->X2) from it, and adds it to the locally maintained link state database . Since the recv-bitstring of the received "BIER record" message already contains BFR id X2, 21, 22, 23, 24, 25, 26, 27, 28, 29, 210, 211, 212, it will not be sent to The neighbor nodes 25-212 flood the above-mentioned link state data LSA (21->X2). The processing of nodes 23 and 24 is similar to that of node 22.
  • Step 405 similarly, the node X2 also floods the link state data LSA (X2->21) to the neighbor node 21 through the "BIER record" message, and the corresponding send-bitstring contains BFR id X2, 21, and the node 21 receives After the remote link state data is reached, the subsequent flooding process is the same as the above-mentioned flooding of the local link state data LSA (21->X2), and will not be repeated.
  • the solution provided in this embodiment can prevent neighbor nodes 26, 27, 28, 29, 210, 211, and 212 from reporting to Spine nodes 22, 23, 24.
  • Sending messages carrying link state data reduces redundancy flooding and improves convergence speed.
  • the solution of this embodiment significantly optimizes redundancy flooding of dense Spine-leaf networks, reducing most of the The necessary redundant flooding.
  • This embodiment tests the optimization effect of this application in a full-mesh network.
  • Fig. 4 it is a full-mesh topology including 8 nodes, and each node is directly connected to all other nodes.
  • the OSPF protocol is running on the network and the BIER function is enabled
  • all nodes in the network are in the same OSPF area, and all support the capability of "optimizing redundant flooding through BIER", and assuming that the BFR-id of each node is its node number For example, the BFR-id of node 31 is 31.
  • the network first consists of nodes 31-38 and corresponding links. After the network is stable, add node X3 and the link connecting the network to the network.
  • the flooding process of the link state data in the network caused by this event is related to The foregoing embodiments are completely similar, but in this example, we will observe a very extreme phenomenon, that is, the link state data only needs to be flooded once, and there is no continuous flooding by neighbors.
  • node 31 floods all its neighbor nodes X3, 32, 33, 34, 35, 36, 37, 38 with locally generated link state data LSA (31->X3) through a "BIER record” message
  • the corresponding send-bitstring will contain BFR id X3, 31, 32, 33, 34, 35, 36, 37, 38.
  • the state data LSA (31->X3) is added to the link state database maintained locally, and no longer continues to flood to their neighbors. The specific process will not be repeated.
  • an embodiment of the present disclosure provides an internal gateway protocol flooding optimization device 50, including a memory 510 and a processor 520.
  • the memory 510 stores a program, and the program is read by the processor 520.
  • the internal gateway protocol flooding optimization method described in any of the embodiments is implemented.
  • an embodiment of the present disclosure provides a computer-readable storage medium 60.
  • the computer-readable storage medium stores one or more programs 610, and the one or more programs can be used by one or more
  • the processor executes to implement the internal gateway protocol flooding optimization method described in any embodiment.
  • Such software may be distributed on a computer-readable medium
  • the computer-readable medium may include a computer storage medium (or non-transitory medium) and a communication medium (or transitory medium).
  • the term computer storage medium includes volatile and non-volatile memory implemented in any method or technology for storing information (such as computer-readable instructions, data structures, program modules, or other data).
  • Computer storage media include but are not limited to RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disk (DVD) or other optical disk storage, magnetic cassette, tape, magnetic disk storage or other magnetic storage device, or Any other medium used to store desired information and that can be accessed by a computer.
  • communication media usually contain computer-readable instructions, data structures, program modules, or other data in a modulated data signal such as carrier waves or other transmission mechanisms, and may include any information delivery media .
  • An embodiment of the present disclosure provides an internal gateway protocol flooding optimization method.
  • a first message carrying link state data and first record information is flooded to neighboring nodes through a first node, where the first record information includes the Indication information of the node that the link state data has experienced.
  • the method described in the embodiment of the present disclosure by carrying the indication information of the node experienced by the link state data, it is convenient for the node to reduce redundant transmission of link state information according to the information, thereby accelerating the convergence speed, and the implementation is extremely simple and the cost is very small Compared with other optimization methods, it has obvious advantages.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

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 Egress Router，位转发出口路由器)。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(Set Identifier，集合标识)。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 LSP packet(包)和OSPF LSU packet，比如，在一实施例中，7表示ISIS LSP packet，8表示OSPF LSU 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 Informational Capabilities 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记录”报文中的BIER header中的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 Description Packet，数据库描述报文)或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中都包含BFR id 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中将包含BFR id 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 id X1、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中包含BFR id 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任一所述的内部网关协议泛洪优化方法。
PCT/CN2020/099018 2019-08-08 2020-06-29 一种内部网关协议泛洪优化方法及装置、存储介质 WO2021022945A1 (zh)

Priority Applications (3)

Application Number Priority Date Filing Date Title
CA3147310A CA3147310A1 (en) 2019-08-08 2020-06-29 Interior gateway protocol flooding optimization method and device, and storage medium
EP20849979.8A EP4012988A4 (en) 2019-08-08 2020-06-29 INTERNAL GATEWAY PROTOCOL FLOOD ROUTING OPTIMIZATION METHOD AND DEVICE AND MEDIA
US17/633,620 US20220321461A1 (en) 2019-08-08 2020-06-29 Interior gateway protocol flooding optimization method and device, and storage medium

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201910730287.6A CN112350936B (zh) 2019-08-08 2019-08-08 一种内部网关协议泛洪优化方法及装置、存储介质
CN201910730287.6 2019-08-08

Publications (1)

Publication Number Publication Date
WO2021022945A1 true WO2021022945A1 (zh) 2021-02-11

Family

ID=74366771

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2020/099018 WO2021022945A1 (zh) 2019-08-08 2020-06-29 一种内部网关协议泛洪优化方法及装置、存储介质

Country Status (5)

Country Link
US (1) US20220321461A1 (zh)
EP (1) EP4012988A4 (zh)
CN (1) CN112350936B (zh)
CA (1) CA3147310A1 (zh)
WO (1) WO2021022945A1 (zh)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114884852B (zh) * 2022-05-07 2024-04-23 武汉思普崚技术有限公司 节点交互及协议识别方法、装置、设备及计算机介质
CN117425131B (zh) * 2023-12-19 2024-03-01 西安蜂语信息科技有限公司 语音数据传输方法、装置、电子设备和存储介质

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1859375A (zh) * 2005-11-12 2006-11-08 华为技术有限公司 一种避免冗余Flood的方法
CN101431448A (zh) * 2008-10-22 2009-05-13 华为技术有限公司 定位ip承载网故障的方法、设备和系统
CN103118362A (zh) * 2013-02-22 2013-05-22 中国人民解放军国防科学技术大学 基于多维尺度变换的虫洞拓扑识别方法
CN103532922A (zh) * 2012-09-29 2014-01-22 深圳市友讯达科技发展有限公司 一种软件版本升级方法、装置及系统
CN106572016A (zh) * 2015-10-09 2017-04-19 中兴通讯股份有限公司 路径计算方法及装置
US20180278521A1 (en) * 2017-03-22 2018-09-27 Cisco Technology, Inc. System and method for providing a bit indexed service chain

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10038623B2 (en) * 2016-10-24 2018-07-31 Microsoft Technology Licensing, Llc Reducing flooding of link state changes in networks
CN107835128A (zh) * 2017-09-29 2018-03-23 北京空间飞行器总体设计部 一种基于确定链路状态的空间网络增强ospf路由方法
KR102496586B1 (ko) * 2018-01-12 2023-02-07 후아웨이 테크놀러지 컴퍼니 리미티드 내부 게이트웨이 프로토콜 플러딩 최소화

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1859375A (zh) * 2005-11-12 2006-11-08 华为技术有限公司 一种避免冗余Flood的方法
CN101431448A (zh) * 2008-10-22 2009-05-13 华为技术有限公司 定位ip承载网故障的方法、设备和系统
CN103532922A (zh) * 2012-09-29 2014-01-22 深圳市友讯达科技发展有限公司 一种软件版本升级方法、装置及系统
CN103118362A (zh) * 2013-02-22 2013-05-22 中国人民解放军国防科学技术大学 基于多维尺度变换的虫洞拓扑识别方法
CN106572016A (zh) * 2015-10-09 2017-04-19 中兴通讯股份有限公司 路径计算方法及装置
US20180278521A1 (en) * 2017-03-22 2018-09-27 Cisco Technology, Inc. System and method for providing a bit indexed service chain

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
See also references of EP4012988A4 *
XUEZHI JIANG; MINGWEI XU; QI LI; LINGTAO PAN: "Improving IGP Convergence through Distributed OSPF in Scalable Router", 2009 11TH IEEE INTERNATIONAL CONFERENCE ON HIGH PERFORMANCE COMPUTING AND COMMUNICATIONS, 25 June 2009 (2009-06-25), pages 438 - 443, XP031491426, DOI: 10.1109/HPCC.2009.21 *

Also Published As

Publication number Publication date
CN112350936A (zh) 2021-02-09
CA3147310A1 (en) 2021-02-11
CN112350936B (zh) 2023-04-18
EP4012988A4 (en) 2022-10-05
EP4012988A1 (en) 2022-06-15
US20220321461A1 (en) 2022-10-06

Similar Documents

Publication Publication Date Title
US10476793B2 (en) Multicast flow overlay using registration over a reliable transport
US9781032B1 (en) MPLS label usage in ethernet virtual private networks
US9019814B1 (en) Fast failover in multi-homed ethernet virtual private networks
CN105743689B (zh) 对多宿主以太网虚拟专网中的链路故障的快速收敛
US10097372B2 (en) Method for resource optimized network virtualization overlay transport in virtualized data center environments
US9197583B2 (en) Signaling of attachment circuit status and automatic discovery of inter-chassis communication peers
US9660898B2 (en) Enhanced protocol independent multicast source registration over a reliable transport
US9485198B1 (en) Methods and apparatus for multicast traffic failover in a network
WO2021031648A1 (zh) Evpn和vpls共存双活的方法、设备及系统
WO2021164402A1 (zh) 路由方法、路由装置及计算机可读存储介质
US9413605B2 (en) Path protection for ring-based multi-protocol label switched paths
WO2022057761A1 (zh) 流量转发控制方法及装置、流量转发方法及芯片、交换机、存储介质
US9729455B2 (en) Multi-protocol label switching rings
US11627066B2 (en) IGP topology information and use for BIER-TE
WO2021022945A1 (zh) 一种内部网关协议泛洪优化方法及装置、存储介质
US9692693B2 (en) Bandwidth control for ring-based multi-protocol label switched paths
US8085654B2 (en) Method for reducing fault detection time in a telecommunication network
WO2020244304A1 (zh) 路由信息发送的方法、路由选路的方法和装置
WO2023226633A1 (zh) 故障处理方法、相关设备和系统
CN113179212B (zh) 报文处理方法及装置
WO2024061184A1 (zh) 对应关系的获取方法、参数通告方法、装置、设备及介质
US20240056390A1 (en) Overlay route optimization across data centers
Del Piccolo et al. Synchronizing BRBs routing information to improve MLTP resiliency
Ellis et al. CCIE Routing and Switching V4. 0 Quick Reference

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 20849979

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 3147310

Country of ref document: CA

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2020849979

Country of ref document: EP

Effective date: 20220309