A method and device for dynamically obtaining multicast group member information in a BIER network

Abstract

The present invention relates to the field of communication technology, and provides a method and device for dynamically obtaining multicast group member information in a BIER network. Wherein, when a bit forwarding egress router BFER node obtains a BIER Ping request message and confirms that the BIER Ping request message carries a requested multicast group flag, when generating a corresponding BIER Ping response message, the method includes: the BFER node carries the multicast table entry information of the multicast group it has joined in the BIER Ping response message; and sends the BIER Ping response message to the bit forwarding ingress router BFIR node. The present invention solves the problem that the multicast stream ingress node in the BIER network cannot dynamically obtain the multicast group member information, thereby improving the competitiveness of the equipment; the existing multicast protocol is not modified, and other protocols are not deployed, so the implementation is simple, easy to deploy, and convenient for promotion.

Description

Technical Field

[0001] The present invention relates to the field of communication technology, and in particular to a method and device for dynamically obtaining multicast group member information in a BIER network. Background Art

[0002] In the Bit Index Explicit Replication (BIER) domain, each edge node in the BIER subdomain needs to be configured with a BFR-ID (BFR's full name is: Bit-Forwarding Router) value, which is unique within the BIER subdomain.

[0003] The BFR-id information in the BIER subdomain, together with other information (such as the IP address of the node), is flooded through the Interior Gateway Protocol (IGP) protocol to establish BIER forwarding information at each node in the network. The BIER forwarding information instructs the node on how to copy and send the message according to the BitString in the message after receiving the BIER message with the BitString.

[0004] Each bit in the BitString represents a multicast message destination node. However, the length of BSL (full name: BitStringLength) is limited, so the number of nodes that can be represented by a BitString is limited. To solve this problem, BIER introduces the concept of Set. Set refers to a collection of BFRs, and the number of BFRs in a Set does not exceed the BSL length. When the destination node of a multicast message belongs to multiple Sets, BFIR copies the multicast message according to the number of Sets it belongs to, writes different Set IDs one by one into the BIFT-ID (full name of BIFT: Bit Index Forwarding Table) field of each BIERv6 message header, and then forwards each multicast message independently according to the BIER process.

[0005] After configuring a BSL for the BIER network, the device automatically maps the BFR-id value of each Bit-Forwarding Egress Router (BFER) to a bit in the BitString (hereinafter referred to as the Bit Position), and calculates the Set ID to which the device belongs. The Bit Position and Set ID calculation formula for each BFER is as follows:

[0006] Bit Position=(BFR-id–1)mod BSL+1;

[0007] Set ID=int[(BFR-id–1)÷BSL];

[0008] Among them, mod and int represent remainder and rounding down respectively.

[0009] The device uses the Set ID and BitString to uniquely identify a group of nodes within a sub-domain that receive a multicast message. If a group of nodes belongs to two or more sets, the message is replicated in the BFIR into multiple multicast messages based on the number of sets to which it belongs.

[0010] After completing the BIER network configuration, the device encapsulates the information required for BIER path calculation in the TLV defined in the IGP and floods it, thereby generating a BIER bit index forwarding table BIFT containing BitString information. The BIFT index consists of a 4-bit BSL + an 8-bit Sub-Domain + an 8-bit Set ID, which means that independent BIFT content is generated within the BFR according to the Sub-Domain, Set ID, and BSL.

[0011] BIFT is the key table entry for each BFR forwarding multicast message in the BIER Sub-Domain, and BIRT is the prerequisite for generating BIFT.

[0012] The detailed generation process of BIRT and BIFT is described as follows:

[0013] Each BFR in the BIER Sub-Domain notifies other BFR nodes of information such as the local BFR-prefix, Sub-Domain ID, BFR-id, BSL, and path calculation algorithm through the TLV defined in the IGP.

[0014] Each BFR node obtains the BFR neighbor (BFR-NBR, i.e. BFR-Neighbor) from the current node to each BFER through path calculation and generates BIRT content.

[0015] Each BFR node generates BIFT content based on the BIRT content. When generating, it performs an OR operation on all BFR-IDs in the BIRT that refer to the same BFR neighbor to obtain the F-BM (full name: Forwarding Bit Mask) column content.

[0016] In the BIER network, after each BFR receives a multicast message, it identifies the BitString in the message and then completes the message forwarding in combination with the corresponding BIFT content.

[0017] After receiving a multicast message, each BFR performs forwarding actions according to the following process:

[0018] Step 1: BFR receives a multicast message, identifies the destination address of the message as the local IP address, and determines to forward it according to the BIER process.

[0019] Step 2: BFR identifies the BIFT-ID field value and BitString value in the message, and then locates the corresponding local BIFT content according to the BIFT-ID field value.

[0020] Step 3: Read the first line of BIFT, perform an AND operation on the F-BM (Forwarding Bit Mask) in this line and the BitString of the message to be forwarded to obtain a new BitString.

[0021] Step 4: Based on the calculation results, select the following forwarding process:

[0022] Step 4.1: If the new BitString value is 0, that is, all Bit Positions are 0, it means that the BFR neighbor (BFR-NBR, that is, BFR-Neighbor) does not need to forward the message.

[0023] Step 4.2: If the new BitString value is not 0 and the BFR neighbor is not the current node, copy the message, write the new BitString into the BitString field of the copied message, write the BFR neighbor's BFR-Prefix into the destination address field of the copied message, and then forward the copied message to the BFR neighbor.

[0024] Step 4.3: If the new BitString value is not 0 and the BFR neighbor is the current node, a copy of the message is made to determine whether the Bit Position with a value of 1 in the new BitString is the current node. If so, the BIERv6 message header is stripped from the copied message and the message is forwarded out of the BIERv6 network. Otherwise, the copied message is discarded.

[0025] Repeat steps 3 and 4 to read all other rows of BIFT and complete the corresponding processing.

[0026] When a multicast message arrives at a BFIR from outside the BIER domain, the BFIR needs to determine the set of BFERs to which the message will be sent. To do this, the BFIR must construct a bit mask (BitString) to indicate which BFERs within the same BIER subdomain will receive the message. To determine the BitString, the BFIR needs to obtain information about the multicast group members. Currently, there are several approaches to this problem:

[0027] Method 1: Static configuration of multicast group member information at the ingress node, such as Figure 1 As shown; its disadvantage is that the configuration is large and it cannot reflect the changes of multicast members in real time;

[0028] Method 2: All incoming packets are forwarded to all egress routers, which then make forwarding decisions based on local information. The disadvantage is that unnecessary nodes will also receive traffic, resulting in bandwidth waste.

[0029] Method 3: Draft-ietf-bier-mld-07 extends MLDv2 and IGMPv3 to share multicast membership information from the egress router (acting as a listener) to the ingress router (acting as a querier). This method requires extending the IGMP and MLD protocols, making implementation complex and potentially causing compatibility issues during deployment.

[0030] In addition, the application number CN106330718A was also retrieved, and the invention name is Multicast Message Forwarding Method and Device. Its main content is: introducing the MS (Map Server) or the MS processor in the BIER network that applies the LISP protocol as the execution subject, interacting with the XTR (Egress / Ingress Tunnel Router, the export / entry tunnel router, the application number is called edge device) to complete the processing of the mapping relationship between the multicast group address and the bit index. The disadvantage is that a new execution subject MS is introduced, and the interaction between MS and XTR is complicated.

[0031] Furthermore, application number CN106603407A, entitled "Multicast Address Transmission Method and Apparatus," was retrieved. Its main content: A border bit forwarding router (BFR) extends Interior Gateway Protocol (IGP) (ISIS, OSPF) message advertisements to carry multicast group address information supported by the border BFR. The disadvantage of this method is that it modifies the existing Interior Gateway Protocol (IGP) (ISIS, OSPF); in addition, BFR nodes also perceive multicast group membership information.

[0032] In view of this, overcoming the defects of the prior art is an urgent problem to be solved in this technical field. Summary of the Invention

[0033] The technical problem to be solved by this invention is that when a multicast message arrives at a BFIR from outside the BIER domain, the BFIR needs to determine the set of BFERs to which the message will be sent. To do this, the BFIR must construct a bit mask (BitString) to indicate which BFER within the same BIER subdomain will receive the message. To determine the BitString, the BFIR needs to obtain the multicast group member information. Currently, there are several approaches to this problem:

[0034] Method 1: Statically configure multicast group member information on the ingress node. This method requires a lot of configuration and cannot reflect changes in multicast group members in real time.

[0035] Method 2: All incoming packets are forwarded to all egress routers, which then make forwarding decisions based on local information. The disadvantage is that unnecessary nodes will also receive traffic, resulting in bandwidth waste.

[0036] Method 3: Draft-ietf-bier-mld-07 extends MLDv2 and IGMPv3 to share multicast membership information from the egress router (acting as a listener) to the ingress router (acting as a querier). This method requires extending the IGMP and MLD protocols, making implementation complex and potentially causing compatibility issues during deployment.

[0037] The present invention adopts the following technical solutions:

[0038] In a first aspect, the present invention provides a method for dynamically obtaining multicast group member information in a BIER network, comprising:

[0039] The BFER node receives the BIER Ping request message and confirms that the BIERPing request message carries the requested multicast group flag. When generating the corresponding BIER Ping response message, the BFER node carries the multicast entry information of the multicast group it has joined in the BIER Ping response message;

[0040] The BIER Ping response message is sent to the bit forwarding ingress router BFIR node.

[0041] Preferably, the BIER Ping request message sent by the BFIR node also includes a multicast traffic end flag, specifically:

[0042] When the BFIR node detects the end of multicast traffic, it uses a BIER Ping request message carrying a multicast traffic end flag to notify all BIER domain edge nodes of the end of BIER traffic; wherein, the BIER domain edge node is composed of one or more BFER nodes;

[0043] After the BFER node receives the BIER Ping request message carrying the multicast traffic end flag, it deletes the corresponding BFIR address from the locally stored BFIR address list of the requested multicast group.

[0044] Preferably, before the bit forwarding egress router BFER node obtains the BIER Ping request message, the method further includes:

[0045] The BFIR node receives an IP multicast message. If the IP multicast message does not have a corresponding multicast table entry, it sends a BIER Ping request message to all BIER domain edge nodes; wherein the BIER Ping request message carries a request multicast group flag.

[0046] Preferably, the method further comprises:

[0047] After the BFER node receives the BIER Ping request message carrying the request multicast group flag, it saves the BFIR address that sent the BIER Ping request message locally.

[0048] Preferably, the method further comprises:

[0049] The BFIR node receives the BIERPing response message notified by the BFER, which carries the multicast table entry information of the multicast group that the BFER node has joined, and saves the correspondence between the multicast table entry information and the BFER node locally for subsequent multicast traffic forwarding.

[0050] Preferably, when the BFER node receives a message of joining or leaving a multicast group of the IGMP / MLD protocol, it sends a BIER Ping response message to all BFIR addresses of the requested multicast group stored locally to notify the multicast table entry information of the multicast group that this node has joined.

[0051] Preferably, the multicast entry information of the multicast group specifically includes multicast entries of any source multicast model and multicast entries of a specified source multicast model.

[0052] Preferably, the BFER node carries the multicast entry information of the multicast group it has joined in the BIER Ping response message, specifically including:

[0053] A multicast entry information byte is added to the Rep field in the Echo Reply message; and the corresponding additional multicast entry information byte setting is known in advance by each BFER node and BFIR node.

[0054] Preferably, the BIER Ping request message carries a request multicast group flag, specifically including:

[0055] A request multicast group flag byte bit is added to the Req field in the Echo Request message; the corresponding setting of the additional request multicast group flag byte bit is known in advance by each BFER node and BFIR node.

[0056] In a second aspect, the present invention further provides a device for dynamically obtaining multicast group member information in a BIER network, for implementing the method for dynamically obtaining multicast group member information in a BIER network described in the first aspect, the device comprising:

[0057] At least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the processor to execute the method for dynamically obtaining multicast group member information in the BIER network described in the first aspect.

[0058] In the third aspect, the present invention also provides a non-volatile computer storage medium, which stores computer-executable instructions, and the computer-executable instructions are executed by one or more processors to complete the method for dynamically obtaining multicast group member information in the BIER network described in the first aspect.

[0059] The present invention solves the problem that the multicast stream entry node in the BIER network cannot dynamically obtain multicast group member information, thereby improving the competitiveness of the equipment; it does not modify the existing multicast protocol, nor does it add and deploy other protocols. It is simple to implement, easy to deploy, and convenient for promotion. BRIEF DESCRIPTION OF THE DRAWINGS

[0060] To more clearly illustrate the technical solutions of the embodiments of the present invention, the following briefly introduces the drawings required for use in the embodiments of the present invention. Obviously, the drawings described below are only some embodiments of the present invention. Those skilled in the art can also derive other drawings based on these drawings without inventive effort.

[0061] Figure 1 This is a schematic diagram of the effect of statically configuring multicast group member information at an ingress node according to an embodiment of the present invention;

[0062] Figure 2 This is a flow chart of a method for dynamically obtaining multicast group member information in a BIER network provided by an embodiment of the present invention;

[0063] Figure 3 This is a flowchart of a method for dynamically obtaining multicast group member information in a BIER network provided by an embodiment of the present invention;

[0064] Figure 4This is a flowchart of a method for dynamically obtaining multicast group member information in a BIER network provided by an embodiment of the present invention;

[0065] Figure 5 This is a flowchart of a method for dynamically obtaining multicast group member information in a BIER network provided by an embodiment of the present invention;

[0066] Figure 6 This is a flowchart of a method for dynamically obtaining multicast group member information in a BIER network provided by an embodiment of the present invention;

[0067] Figure 7 This is a node interaction timing diagram provided by an embodiment of the present invention, in which a multicast stream triggers a BFIR to dynamically obtain multicast information of a multicast group to which the BFER node has joined;

[0068] Figure 8 This is a flowchart of a process when a BFIR node receives a multicast stream, provided by an embodiment of the present invention;

[0069] Figure 9 This is a node interaction timing diagram provided by an embodiment of the present invention, in which an IGMP / MLD protocol multicast group join / leave message triggers a BFER to proactively notify the node of the multicast information that the node has joined the multicast group;

[0070] Figure 10 This is a schematic diagram of a BIER header Ethernet format encapsulation structure provided by an embodiment of the present invention;

[0071] Figure 11 This is a processing flow chart provided by an embodiment of the present invention when a BFIR node receives a BIERPing response message carrying a (*, G) or (S, G) list;

[0072] Figure 12 This is a flowchart of a process when a BFIR node detects the end of multicast traffic, provided by an embodiment of the present invention;

[0073] Figure 13 This is a schematic diagram of a BIER header format structure provided by an embodiment of the present invention;

[0074] Figure 14 This is a schematic diagram of a BIER header Ethernet format encapsulation structure provided by an embodiment of the present invention;

[0075] Figure 15 This is a schematic diagram of a BIER header MPLS format encapsulation structure provided by an embodiment of the present invention;

[0076] Figure 16 The present invention provides a schematic diagram of the structure of a device for statically configuring multicast group member information at an ingress node. DETAILED DESCRIPTION

[0077] In order to make the purpose, technical solutions and advantages of the present invention more clearly understood, the present invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not intended to limit the present invention.

[0078] In the description of the present invention, the terms "inside", "outside", "longitudinal", "lateral", "upper", "lower", "top", "bottom", etc. indicate orientations or positional relationships based on the orientations or positional relationships shown in the accompanying drawings. They are only for the convenience of describing the present invention and do not require that the present invention must be constructed and operated in a specific orientation. Therefore, they should not be understood as limitations on the present invention.

[0079] The terms "first," "second," etc., used in this application are for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of the technical features being referred to. Thus, a feature identified with "first," "second," etc. may explicitly or implicitly include one or more of such features. Throughout this application, unless otherwise specified, "plurality" means two or more.

[0080] In this application, unless otherwise specified or limited, the term "connection" should be understood broadly. For example, "connection" can mean fixed connection, detachable connection, or integration; it can mean direct connection or indirect connection through an intermediate medium. In addition, the term "coupling" can refer to the manner in which electrical connection is achieved for signal transmission.

[0081] In addition, the technical features involved in the various embodiments of the present invention described below can be combined with each other as long as they do not conflict with each other.

[0082] Embodiment 1:

[0083] Embodiment 1 of the present invention provides a method for dynamically obtaining multicast group member information in a BIER network, such as Figure 2 As shown, the method includes:

[0084] In step 201, the bit forwarding egress router BFER node obtains the BIER Ping request message and confirms that the BIER Ping request message carries a request multicast group flag.

[0085] For example: a request multicast group flag byte bit is added to the Req field in the Echo Request message (which is the specific message presentation form of the BIER Ping request message in BIERv6); the corresponding setting of the added request multicast group flag byte bit is predicted in advance by each BFER node and BFIR node.

[0086] In step 202, when generating the corresponding BIER Ping response message, the BFER node carries the multicast table entry information of the multicast group it has joined in the BIER Ping response message.

[0087] For example: a multicast table entry information byte is added to the Rep field in the Echo Reply message (which is the specific message presentation form of the BIER Ping response message in BIERv6); the corresponding added multicast table entry information byte setting is predicted in advance by each BFER node and BFIR node.

[0088] The multicast entry information of the multicast group specifically includes multicast entries of any source multicast model and multicast entries of a specified source multicast model. The content of the multicast entry will be presented in detail in Example 2 and will not be elaborated here.

[0089] In step 203, the BIER Ping response message is sent to the bit forwarding ingress router BFIR node.

[0090] The embodiment of the present invention solves the problem that the multicast stream entry node in the BIER network cannot dynamically obtain multicast group member information, thereby improving the competitiveness of the equipment; it does not modify the existing multicast protocol, nor does it add and deploy other protocols. It is simple to implement, easy to deploy, and convenient for promotion.

[0091] As for this embodiment, since there is an action to start the collection and reporting of multicast table information, then as a more complete technical solution, the execution of the end action will be determined accordingly. Therefore, in combination with the embodiment of the present invention, there is also an extended solution, and the BIER Ping request message sent by the BFIR node also includes a multicast traffic end flag, such as Figure 3 As shown, the method further includes:

[0092] In step 204, when the BFIR node detects the end of multicast traffic, it uses a BIER Ping request message carrying a multicast traffic end flag to notify all BIER domain edge nodes of the end of BIER traffic.

[0093] Among them, the BIER domain edge node is composed of one or more BFER nodes.

[0094] In step 205, after receiving the BIER Ping request message carrying the multicast traffic end flag, the BFER node deletes the corresponding BFIR address from the locally stored BFIR address list of the requested multicast group.

[0095] On the other hand, as a prerequisite for triggering the execution of the action in step 201 of the embodiment of the present invention, the BFER node will first receive the BIER Ping request message. If it is a BIER Ping request message in the conventional prior art, its role is only a tool for detecting the connectivity of the BIER network. However, in the present invention, the content carried by it is creatively expanded, and the identification and processing of the extended content carried by the BFER node and the BFIR node are pre-communication, thereby realizing the technical solution content of embodiment 1 of the present invention. Therefore, in combination with the embodiment of the present invention, as a process before step 201, such as Figure 4 As shown, the method further includes:

[0096] In step 200, the BFIR node receives an IP multicast message. If the IP multicast message does not have a corresponding multicast table entry, a BIER Ping request message is sent to all BIER domain edge nodes.

[0097] Among them, the BIER Ping request message carries a request multicast group flag.

[0098] Correspondingly, the above step 200 can also be performed with Figure 3 Step 204 and step 205 are combined together to form a more complete solution. It should be noted here that in the implementation process of the embodiment of the present invention, the existence of step 200 is required to be higher than step 204 and step 205. The reason is that the present invention is implemented on the basis of the existing BIER Ping request message and BIERPing response message framework, and step 204 and step 205 are performed as a completing finishing action. In the specific implementation process, even if step 204 and step 205 do not exist, the corresponding BFER node can also delete the corresponding BFIR address after a certain time period. Therefore, steps 204-205 should not over-limit the scope of protection of the present invention.

[0099] Through steps 204-205 of the above-mentioned extended implementation method, it is not difficult to find that there is an operation that is executed by default during its implementation process, that is, after the BFER node receives the BIER Ping request message carrying the request multicast group flag, it locally saves the BFIR address that sent the BIER Ping request message. Furthermore, the BFIR node receives the BIER Ping response message notified by the BFER that carries the multicast table entry information of the multicast group that the BFER node has joined, and locally saves the correspondence between the multicast table entry information and the BFER node for subsequent multicast traffic forwarding.

[0100] In conjunction with the embodiment of the present invention, there is also a possible process scenario, such as Figure 5 As shown, it also includes:

[0101] In step 204', when the BFER node receives the IGMP / MLD protocol multicast group joining or leaving message, it sends a BIER Ping response message to all BFIR addresses of the requested multicast group stored locally to notify the multicast table entry information of the multicast group that this node has joined.

[0102] For details about the IGMP protocol and the MLD protocol, please refer to draft-ietf-bier-mld-07, which will not be described in detail here.

[0103] Example 2:

[0104] The embodiment of the present invention takes Example 1 as a theoretical basis, and combines the specific data content presentation form and relevant protocol terms to specifically present the method process in Example 1 in a feasible scenario.

[0105] The overall schematic diagram of the implementation of this method is as follows: Figure 6 As shown, specifically involving Figure 6 The BFIR node and BFER node in the BIER Ping response message need to be expanded, and a new TLV needs to be added to carry the multicast information list of the (*, G) or (S, G) multicast group that the BFER node has joined; the BIER Ping request message needs to be expanded, and a "request multicast group flag" and "multicast traffic end flag" need to be added.

[0106] The node interaction sequence diagram of the multicast flow triggering BFIR to dynamically obtain the multicast information of the multicast group that the BFER node has joined is as follows: Figure 7 Shown, including:

[0107] In 301, the BFIR node receives a multicast stream.

[0108] In 302, the BFIR node starts a multicast flow detection timer.

[0109] In 303, after confirming that the IP multicast message has no corresponding multicast entry, the BFIR node sends an Echo Request message to the BFER node; wherein the Echo Request message carries a multicast group request flag.

[0110] The specific process can be referred to Figure 8 In step 3021-step 3022, and in the specific implementation process, once the BFIR node confirms that it has a multicast table entry for a, that is, the judgment result in step 3022 is yes, it will directly jump to step 308 and send the multicast stream to the corresponding BFER.

[0111] In 304, the BFER node updates the BFIR address list for requesting multicast group information; and locally saves the BFIR address for sending the BIERPing request message.

[0112] In 305 , the BFER node returns an Echo Reply message to the BFIR node; the Echo Reply message carries a (*, G) or (S, G) list.

[0113] The (*, G) entry represents the Any-Source Multicast (ASM) model multicast entry, where * represents any source and G represents the multicast group. The (*, G) entry applies to all multicast packets with group address G. Regardless of the multicast source, all multicast packets destined for multicast group G must be forwarded through the outbound interface specified in the (*, G) entry.

[0114] (S, G) is a multicast entry for the Source-Specific Multicast (SSM) model, where S represents the multicast source and G represents the multicast group. Upon reaching a multicast device, a multicast packet with source address S and group address G is forwarded through the outbound interface specified in the (S, G) entry.

[0115] In 306, a mapping table ((*, G) or (S, G), BFER node set) is established based on the multicast group address list returned by each BFER, which corresponds to the correspondence between the locally stored multicast table information and the BFER nodes in embodiment 1.

[0116] In 307, the BitString of the BIER header is set according to the mapping relationship of ((*, G) or (S, G), BFER node set).

[0117] In 308, the multicast stream is sent to the corresponding BFER node and then forwarded to Figure 6 The recipient shown.

[0118] Among them, in the BitString of the BIER header, only the BFER node bit corresponding to the multicast group is set to 1.

[0119] Example 3:

[0120] The embodiment of the present invention takes Example 1 as a theoretical basis, and combines the specific data content presentation form and relevant protocol terms to specifically present the method process in Example 1 in a feasible scenario.

[0121] The overall schematic diagram of the implementation of this method is as follows: Figure 6 As shown, specifically involving Figure 6The BFIR node and BFER node in the BIER Ping response message need to be expanded, and a new TLV needs to be added to carry the multicast information list of the (*, G) or (S, G) multicast group that the BFER node has joined; the BIER Ping request message needs to be expanded, and a "request multicast group flag" and "multicast traffic end flag" need to be added.

[0122] The node interaction sequence diagram of the IGMP / MLD protocol multicast group join / leave message triggering BFER to actively notify the node that it has joined the multicast group, as shown in the following figure: Figure 9 shown.

[0123] In step 401, an IGMP / MLD protocol multicast group joins or leaves a BFER node.

[0124] like Figure 10 FIG. 4 shows the execution process after step 401 is completed within the BFER node, specifically including: in step 4011, whether there is a change in the joined multicast group; if there is no change, directly skipping the following step 403; otherwise, proceeding to step 4012 to encapsulate the Echo Reply message carrying all (*, G) or (S, G) list information, and finally connecting to step 402 of this embodiment.

[0125] In step 402, the BFER node proactively initiates an Echo Reply message, wherein the Echo Reply message carries the updated (*, G) or (S, G) list.

[0126] In step 403, the locally stored (*, G) or (S, G) and BFER node set mapping table is updated according to the multicast group address list returned by the BFER.

[0127] Example 4:

[0128] This embodiment is a processing flow when a BFIR node receives a BIER Ping response message carrying a (*, G) or (S, G) list, which can be used to support the implementation of step 306 in embodiment 2 and the implementation of step 403 in embodiment 3, such as Figure 11 As shown, the method includes:

[0129] In step 501, a BFIR node receives an Echo Reply message.

[0130] The steps here are connected between step 305 and step 306 in embodiment 2, that is, the BFIR node receives the Echo Reply message.

[0131] In step 502, the BFIR node parses the (*, G) or (S, G) list in the Echo Reply message.

[0132] As explained in Example 1, the present invention does not modify the existing protocol mechanism, but sets a common transmittable and resolvable data area for the interacting parties through TLV, namely the above-mentioned (*, G) or (S, G) list, which is also described as multicast table information in Example 1 and other related embodiments.

[0133] In step 503, the BFIR node updates the (*, G) or (S, G) and BFER node set mapping table and synchronizes it to the local storage database.

[0134] Example 5:

[0135] This embodiment corresponds to step 204-step 205 in embodiment 1, and is performed in the specific application scenario of the above embodiments 2-4. That is, the processing flow when the BFIR node detects the end of multicast traffic, such as Figure 12 As shown, the following steps are included:

[0136] In step 601, the timeout of the multicast timer is detected to determine whether there is a multicast stream; if so, the process proceeds to step 603; otherwise, the process proceeds to step 602.

[0137] In step 602, the BFIR node sends an Echo Request message, wherein all bits of the BitString in the Echo Request message are set to 1, carrying a multicast traffic end flag.

[0138] The meaning of setting all bits of the BitString in the Echo Request message to 1 is that it targets all BFER nodes.

[0139] In step 603, a multicast flow detection timer is started.

[0140] At this time, once the multicast stream timer times out, the process will go back to step 601 to complete the above-mentioned cycle.

[0141] Example 6:

[0142] In this embodiment, the corresponding BIER packet header format is presented from the basic side. No matter what encapsulation method is used for the BIER Ping message, the (*, G) or (S, G) multicast group information that the BFER node has joined can be passed to the BIER by extending the BIER Ping response message. Based on this BIER header, several examples of encapsulation are further given.

[0143] The basic fields of the BIER header are as follows: Figure 13 Shown, including:

[0144] BFIT-id is the BITF used for packet forwarding, the label value corresponding to MPLS encapsulation. When no MPLS encapsulation (Ethernet or IPv6) is used, (SD, SI BSL) is used for mapping or encoding.

[0145] TC is the traffic type, which is the same as the TC of MPLS encapsulation. Refer to RFC5462.

[0146] S is the bottom identifier of the label stack, which is the same as the S bit in MPLS encapsulation. Refer to RFC3032.

[0147] TTL is the same as TTL in MPLS encapsulation. Refer to RFC3032.

[0148] Nibble is a fixed value of 0101, which is used to distinguish BIER encapsulation from the ECMP function of MPLS.

[0149] Ver is the version number. The current value is 0, which indicates the experimental version.

[0150] BSL is the length of BitString (log2(k)-5), used for offline analysis.

[0151] Entropy supports ECMP. For the same Entropy+BitString, the same path is selected.

[0152] The default value of OAM is 0, and ping / trace can be used without affecting forwarding and QoS.

[0153] RSV is a reserved bit and is currently not used and defaults to 0.

[0154] DSCP is not used when MPLS encapsulation is used, but can be used when no MPLS encapsulation is used.

[0155] Proto indicates the type of the Payload message, which has been standardized by RFC.

[0156] BFIR-id indicates the BFR-ID value of the first BIER router in the BIER domain where the multicast enters.

[0157] BitStirng is the same as SD and SI, which represents a group of BFER routers.

[0158] like Figure 13 As shown, the improved "multicast group request flag" and "multicast traffic end flag" of the present invention have been introduced.

[0159] On this basis, if Figure 14The following is the BIER Ethernet encapsulation format; IANA defines the BIER Ethernet encapsulation type as 0XAB37, with the Ethernet header directly followed by the BIER message header. BIER's Ethernet encapsulation is very concise and efficient, as shown in the following figure. Figure 10 The Ethernet type 0xAB37 indicates that its payload is a BIER message, where the format of the BIER message header is Figure 13 The Protocol field in the BIER message header further identifies the contents of the upper-layer protocol. A value of 2 in the Protocol field in the BIER message indicates the upstream-assigned MPLS label, typically used to implement multicast VPN services. For detailed information on BIER Ethernet encapsulation, refer to RFC8296, "Encapsulation for Bit Index Explicit Replication (BIER) in MPLS and Non-MPLS Networks."

[0160] On this basis, if Figure 15 The figure shows the MPLS encapsulation format of BIER; BIER's MPLS encapsulation uses the IANA-defined MPLS type of 0x8847, where 0x8847 identifies the Ethernet message payload as an MPLS encapsulated message, and the BIER message type is determined by the label value range. The label management module allocates an independent label range to BIER encapsulation, just like the IPv4 / IPv6 protocol. MPLS encapsulation reuses the first 4 bytes of the BIER message header, where the BIFT-Id in the first 20 bits of the BIER message header is the BIER label value assigned by the label management module. The MPLS encapsulation order of BIER is Ethernet, BIER message header, and upper-layer protocol. There is no independent MPLS label. This needs to be noted. Figure 15 As shown in the figure. After the MPLS module parses the first 4 bytes of the BIER header (MPLS-BIER), it enters the processing flow of different protocols, including BIER, based on the label value, and determines the corresponding forwarding table based on the label value. For detailed information on BIER MPLS encapsulation, please refer to RFC8296 "Encapsulation for Bit Index Explicit Replication (BIER) in MPLS and Non-MPLS Networks."

[0161] Example 7:

[0162] like Figure 16 , is a schematic diagram of the architecture of a device for dynamically acquiring multicast group member information in a BIER network according to an embodiment of the present invention. The device for dynamically acquiring multicast group member information in a BIER network according to this embodiment includes one or more processors 21 and a memory 22. Figure 16 A processor 21 is taken as an example.

[0163] The processor 21 and the memory 22 may be connected via a bus or other means. Figure 16 The bus connection is taken as an example.

[0164] The memory 22, as a non-volatile computer-readable storage medium, can be used to store non-volatile software programs and non-volatile computer executable programs, such as the method for dynamically obtaining multicast group member information in the BIER network in Example 1. The processor 21 executes the method for dynamically obtaining multicast group member information in the BIER network by running the non-volatile software programs and instructions stored in the memory 22.

[0165] The memory 22 may include high-speed random access memory and non-volatile memory, such as at least one disk storage device, flash memory device, or other non-volatile solid-state memory device. In some embodiments, the memory 22 may optionally include a memory remotely located relative to the processor 21, and such remote memory may be connected to the processor 21 via a network. Examples of such networks include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0166] The program instructions / modules are stored in the memory 22, and when executed by the one or more processors 21, the method for dynamically obtaining multicast group member information in the BIER network in the above embodiment 1 is executed, for example, the method described above is executed. Figure 2-Figure 12 The steps shown.

[0167] It is worth noting that the information interaction, execution process, etc. between the modules and units within the above-mentioned devices and systems are based on the same concept as the processing method embodiment of the present invention. The specific content can be found in the description of the method embodiment of the present invention and will not be repeated here.

[0168] Those skilled in the art will understand that all or part of the steps in the various methods of the embodiments can be completed by instructing related hardware through a program, and the program can be stored in a computer-readable storage medium, which may include: read-only memory (ROM), random access memory (RAM), a disk or an optical disk, etc.

[0169] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions and improvements made within the spirit and principles of the present invention should be included in the scope of protection of the present invention.

Claims

1. A method for dynamically obtaining multicast group member information in a BIER network, characterized in that: include: The BFIR node receives an IP multicast message. If the IP multicast message does not have a corresponding multicast table entry, it sends a BIER Ping request message to all BIER domain edge nodes; wherein the BIER Ping request message carries a request multicast group flag; The BFER node receives the BIER Ping request message and confirms that the BIER Ping request message carries the requested multicast group flag. When generating the corresponding BIER Ping response message, the BFER node carries the multicast entry information of the multicast group it has joined in the BIERPing response message; The BIER Ping response message is sent to the bit forwarding ingress router BFIR node.

2. The method for dynamically obtaining multicast group member information in a BIER network according to claim 1, characterized in that: The BIER Ping request message sent by the BFIR node also includes a multicast traffic end flag, specifically including: When the BFIR node detects the end of multicast traffic, it uses a BIER Ping request message carrying a multicast traffic end flag to notify all BIER domain edge nodes of the end of BIER traffic; wherein, the BIER domain edge node is composed of one or more BFER nodes; After the BFER node receives the BIER Ping request message carrying the multicast traffic end flag, it deletes the corresponding BFIR address from the locally stored BFIR address list of the requested multicast group.

3. The method for dynamically obtaining multicast group member information in a BIER network according to claim 1, characterized in that: The method also includes: After the BFER node receives the BIER Ping request message carrying the request multicast group flag, it saves the BFIR address that sent the BIERPing request message locally.

4. The method for dynamically obtaining multicast group member information in a BIER network according to claim 3, characterized in that: The method also includes: The BFIR node receives the BIER Ping response message notified by BFER, which carries the multicast table entry information of the multicast group that the BFER node has joined, and saves the correspondence between the multicast table entry information and the BFER node locally for subsequent multicast traffic forwarding.

5. The method for dynamically obtaining multicast group member information in a BIER network according to claim 3, characterized in that: Also includes: When a BFER node receives a multicast group join or leave message of the IGMP / MLD protocol, it sends a BIER Ping response message to all BFIR addresses of the requested multicast group stored locally to notify the multicast table information of the multicast group that this node has joined.

6. The method for dynamically obtaining multicast group member information in a BIER network according to any one of claims 1 to 5, characterized in that: The multicast entry information of the multicast group specifically includes multicast entries of any source multicast model and multicast entries of a specified source multicast model.

7. The method for dynamically obtaining multicast group member information in a BIER network according to any one of claims 1 to 5, characterized in that: The BFER node carries the multicast entry information of the multicast group it has joined in the BIER Ping response message, specifically including: Add a multicast entry information byte to the Rep field in the Echo Reply message.

8. The method for dynamically obtaining multicast group member information in a BIER network according to claim 7, characterized in that: The BIER Ping request message carries a request multicast group flag, specifically including: A multicast group flag byte is added to the Req field in the Echo Request message.

9. A device for dynamically obtaining multicast group member information in a BIER network, characterized in that: The device comprises: At least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the processor to execute the method for dynamically obtaining multicast group member information in a BIER network as described in any one of claims 1-8.

Images