Message processing method, electronic device, and storage medium

Abstract

The present application relates to but not limited to the technical field of communications. Provided are a message processing method, a device, and a medium. The method comprises: encapsulating a bit indexed explicit replication (BIER) header to a multicast message, so as to obtain an encapsulated multicast packet, wherein the BIER header comprises a bitstring field, the bitstring field comprises a first mapping string, and the first mapping string is used for mapping an identifier of the multicast message; and then sending the encapsulated multicast message, such that after receiving the multicast message, a bit forwarding egress router (BFER) can determine a corresponding destination user node on the basis of the first mapping string, and then forwards the multicast message to the corresponding destination user node.

Description

Message processing method, electronic device and storage medium

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to the Chinese patent application filed with the China Patent Office on November 24, 2023, with application number 202311600278.8 and invention name “Message processing method, electronic device and storage medium”. The entire contents of the Chinese patent application are incorporated herein by reference. Technical Field

[0003] The embodiments of the present application relate to the field of communication technologies, and in particular to a message processing method, an electronic device, and a storage medium. Background Art

[0004] Bit Indexed Explicit Replication (BIER) is a new multicast data forwarding technology that represents nodes at the edge of the network with only one bit. When multicast traffic is transmitted in the intermediate network, a specific BIER header is additionally encapsulated. This header marks all the destination nodes of the multicast stream in the form of a bit string. The intermediate network forwarding node searches the BIER forwarding table based on the bit position for routing to ensure that the traffic can be sent to all destination nodes.

[0005] Because BIER technology does not have the problem of establishing a multicast tree, it does not need to perceive different multicast data flows and eliminates the delay in establishing a multicast tree. When a network failure occurs, there is no experimental overhead of rebuilding the multicast tree, and the convergence speed is much faster than the original multicast technology.

[0006] Current point-to-multipoint applications, including live streaming, online teaching, and remote conferencing, face the challenge of a massive number of users at the network edge. For example, live streaming can have millions of viewers online, while individual influencers can reach tens of millions. During the Spring Festival, hundreds of millions of users watch the Spring Festival Gala live, with a single video platform potentially reaching tens of millions of viewers. Deploying BIER technology to adapt to these scenarios is a major challenge facing the industry.

[0007] Summary of the Invention

[0008] In the first aspect, an embodiment of the present application provides a message processing method, the method comprising: explicitly copying a BIER header to a multicast message encapsulation bit index to obtain an encapsulated multicast message, wherein the BIER header comprises a bit string BitString field, the BitString field comprises a first mapping bit string, and the first mapping bit string is used to map an identifier of the multicast message; and sending the encapsulated multicast message.

[0009] In second aspect, an embodiment of the present application provides a message processing method, the method comprising: receiving a multicast message, wherein the multicast message includes a bit index explicit copy BIER header, the BIER header includes a bit string BitString field, and the BitString field includes a first mapping bit string; determining an identifier of the multicast message based on the first mapping bit string; determining a destination user node based on the identifier of the multicast message; and forwarding the multicast message to the destination user node.

[0010] In a third aspect, an embodiment of the present application provides an electronic device comprising: one or more processors; a memory on which one or more programs are stored, wherein when the one or more programs are executed by the one or more processors, the one or more processors implement the message processing method as described in the first aspect above; or, the message processing method as described in the second aspect above.

[0011] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the message processing method as described in the first aspect above; or, the message processing method as described in the second aspect above. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] The accompanying drawings are used to provide a further understanding of the technical solution of the present invention and constitute a part of the specification. Together with the embodiments of the present invention, they are used to explain the technical solution of the present invention and do not constitute a limitation to the technical solution of the present invention.

[0013] FIG1 is a schematic diagram of an implementation environment of a message processing method provided in an embodiment of the present application;

[0014] FIG2 is a schematic diagram of the encapsulation format of the BIER header provided by the related art;

[0015] FIG3 is a schematic diagram of another packaging format of a BIER header provided by the related art;

[0016] 4 is a schematic diagram of the correspondence between the address information of the multicast message and the identifier of the multicast message provided in an embodiment of the present application;

[0017] FIG5 is a schematic diagram of a format for notifying the length of a first mapping bit string provided by the related art;

[0018] FIG6 is a schematic diagram of a newly defined format for notifying the length of the first mapping bit string provided by the related art;

[0019] FIG7 is a schematic diagram of the BIER Info Sub-TLV format provided in an embodiment of the present application;

[0020] FIG8 is a schematic diagram of a newly added Sub-sub-TLV format provided in an embodiment of the present application;

[0021] FIG9 is a flow chart of a message processing method provided in an embodiment of the present application;

[0022] FIG10 is a flow chart of a message processing method provided in another embodiment of the present application;

[0023] FIG11 is a schematic diagram of the device structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

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

[0025] It should be understood that in the description of the embodiments of the present application, if there is a description of "first", "second", etc., it is only for the purpose of distinguishing technical features, and cannot be understood as indicating or implying relative importance or implicitly indicating the number of the indicated technical features or implicitly indicating the order of the indicated technical features. "At least one" means one or more, and "more" means two or more. "And / or" describes the association relationship of associated objects, indicating that three relationships may exist. For example, A and / or B can represent the existence of A alone, the existence of A and B at the same time, and the existence of B alone. Among them, A and B can be singular or plural. The character " / " generally indicates that the previous and next associated objects are in an "or" relationship. "At least one of the following" and similar expressions refer to any group of these items, including any group of single or plural items. For example, at least one of a, b and c can represent: a, b, c, a and b, a and c, b and c, or a, b and c, where a, b, c can be single or multiple.

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

[0027] To facilitate understanding of the solutions of the embodiments of the present application and to provide a clear and concise description of the following embodiments, a brief introduction to the relevant technologies is first given:

[0028] Please refer to Figure 1, which is a schematic diagram of an implementation environment of the message processing method provided in an embodiment of the present application. The implementation environment shown in Figure 1 is a network architecture, which includes a backbone network, a metropolitan area network, and an access network, wherein the backbone network includes one or more core router devices (Core Router, CR), the metropolitan area network includes one or more broadband remote access server devices (Broadband Remote Access Server, BRAS), and the access network includes one or more user terminal devices. The CR device can be connected to one or more content servers, each BRAS device can be connected to one or more CR devices, and each BRAS device can also be connected to one or more user terminal devices. In the network architecture shown in Figure 1, the backbone network includes a CR1 device, which is connected to the content server and can receive multicast data packets sent by the content server. The CR1 device is also connected to BRAS1, BRAS2, ..., BRASn in the metropolitan area network, and BRAS1, BRAS2, ..., BRASn are respectively connected to multiple user terminal devices. The multicast data message sent by the content server can be transmitted to the corresponding BRAS device via the CR1 device, and then forwarded by the corresponding BRAS device to the user terminal device that needs to receive the multicast data message.

[0029] It should be noted that there may be an intermediate connection device (not shown in the figure) between the CR device and the BRAS device, and there may be multiple levels of switch devices (not shown in the figure) between the BRAS device and the user terminal device.

[0030] It should be noted that the user terminal device may be user equipment (UE), where UE includes a handheld device, a vehicle-mounted device, a wearable device, or a computing device with wireless communication capabilities. For example, the UE may be a mobile phone, a tablet computer, or a computer with wireless transceiver capabilities. The terminal device may also be a virtual reality (VR) terminal device, an augmented reality (AR) terminal device, a wireless terminal in industrial control, a wireless terminal in unmanned driving, a wireless terminal in telemedicine, a wireless terminal in a smart grid, a wireless terminal in a smart city, a wireless terminal in a smart home, and the like.

[0031] Bit Indexed Explicit Replication (BIER) is a new multicast data forwarding technology that represents nodes at the edge of the network with only one bit. When multicast traffic is transmitted in the intermediate network, it will be additionally encapsulated with a specific BIER header. This message header marks all the destination nodes of the multicast stream in the form of a BitString. The intermediate network forwarding node searches the BIER forwarding table based on the bit position for routing to ensure that the traffic can be sent to all destination nodes.

[0032] Please refer to Figure 2, which is a schematic diagram of the encapsulation format of the BIER header provided by the relevant technology. As shown in Figure 2, the BIER header includes a BIFT-id field, a TC field, an S field, a TTL field, a Nibble field, a Ver field, a BSL field, an Entropy field, an OAM field, an Rsv field, a DSCP field, a Proto field, a BFIR-id field, and a BitString field. The TC field can be used to identify and distinguish different categories of multicast data packets so that specific processing can be performed based on the category of the multicast data packets, indicating the multicast data packet category of the packet. The S field is used to indicate the existence and validity of the Entropy field. The TTL field is used to identify the maximum number of hops that a packet can be forwarded in the network. The BSL field is used to indicate the length of the BitString field, that is, the number of bits in the path identifier. The Entropy field is used to add some randomness to multipath selection to ensure that the data packets are evenly distributed across multiple paths during transmission, improving load balancing. The OAM field is used to indicate whether the packet is used for OAM purposes. The setting of the OAM bit can trigger network devices to perform special operations for network management and maintenance. The DSCP field is used to specify the Differentiated Services Code Point of the packet, which helps to distinguish and prioritize the quality of service (QoS) of the packet. The BFIR-id field is used to identify the starting router of the packet, that is, the router performing the BIER operation, and is used to indicate the initial entry point of the packet. Each bit in the BitString field represents a specific multicast forwarding path, and the combination of multiple bits represents a group of paths, each corresponding to an interface in the network.

[0033] Taking the implementation environment shown in FIG1 as an example, the CR1 device serves as a bit forwarding ingress router (BFIR), and the BRAS1 device, BRAS2 device, ..., BRASn device serve as bit forwarding egress routers (BFER).

[0034] Because BIER technology does not have the problem of establishing a multicast tree, it does not need to perceive different multicast data flows and eliminates the delay in establishing a multicast tree. Therefore, when a network failure occurs, there is no experimental overhead of rebuilding the multicast tree, and the convergence speed is much faster than the original multicast technology.

[0035] Current point-to-multipoint application scenarios, including live streaming, online teaching, and remote conferencing, face the challenge of a massive number of users at the network edge. For example, a live stream can have millions of online viewers, with individual influencers potentially reaching tens of millions. During the Spring Festival, hundreds of millions of users watch the Spring Festival Gala live, with a single video platform potentially attracting tens of millions of viewers. Deploying BIER technology to adapt to these scenarios is a major challenge facing the industry.

[0036] In related technologies, each BRAS device manages more than 32,000 users. A BRAS device with better performance can manage more than 64,000 users. There are also multiple levels of switch devices between the BRAS device and the user terminal devices, which are not drawn here for simplicity.

[0037] For example, in the case of live streaming, the content server typically sends traffic to a CR device in the backbone network. Based on the user distribution, the backbone device then pushes the traffic to devices in the metropolitan area network (MAN). Once the traffic reaches the BRAS at the edge of the MAN, the BRAS pushes it to the users watching the live stream. In real-world scenarios, the backbone network may have multiple devices. While live streaming traffic may be sent to only one backbone CR device, it is actually forwarded to other CR devices in the backbone network. This means that, depending on the distribution of live streaming users, several CR devices, corresponding BRAS devices in the MAN, and millions or even tens of millions of user terminals may form a point-to-multipoint application scenario.

[0038] For BIER technology, the destination edge node will be represented in the BitString field of the BIER header in the form of a bit. The BitString field has a length limit. The maximum length of the BitString specified in the current standard is 4096 bits, but the current device capabilities generally process a BitString length of 256 bits, which means that there can be 256 destination nodes that can be identified in a BIER header.

[0039] When current operators intend to apply BIER technology to this scenario, they face the problem of a huge number of users. When a user terminal is used as the destination node BFER, a BIER message can only identify 256 users. In a live broadcast scenario, assuming that one million users are watching the same live program, at least 3906 BIER messages need to be encapsulated by BFIR to be sent to so many users. Such a large number of BIER messages takes up a lot of bandwidth and greatly increases the processing burden of the equipment. This does not reflect the advantages of BIER technology at all, and its efficiency is even worse than that of traditional PIM (Protocol Independent Multicast) technology.

[0040] In addition, if the user terminal is used as the destination node, the user's terminal devices, such as computers, smart TVs, mobile phones, etc., need to be upgraded to support BIER message parsing. Upgrading and transforming such a large number of terminal devices is also a huge challenge.

[0041] Based on this, the embodiments of the present application provide a message processing method, an electronic device and a storage medium, which aim to improve the encapsulation processing logic of the BIER header in ultra-large-scale user scenarios to expand the number of users that can be accommodated.

[0042] Please refer to Figure 9, which is a flowchart of a message processing method provided by an embodiment of the present application. The execution subject of the message processing method can be a CR device in the implementation environment shown in Figure 1, wherein the CR device serves as a bit forwarding entry router (BFIR) device. As shown in Figure 9, the message processing method may include but is not limited to the following steps S110-S120. Each step is described in sequence below:

[0043] Step S110, explicitly copy the BIER header to the multicast message encapsulation bit index to obtain the encapsulated multicast message, wherein the BIER header includes a bit string BitString field, the BitString field includes a first mapping bit string, and the first mapping bit string is used to map the identifier of the multicast message.

[0044] It is understandable that the identifier of the multicast message can be determined through the first mapping bit string, the corresponding destination address information can be determined according to the identifier of the multicast message, and then the destination user node can be determined according to the destination address information.

[0045] Exemplarily, in the BitString field in the BIER header, the mapping reserved bits of the first mapping bit string are divided out, each bit corresponds to the identifier of a multicast message, and the mapping reserved bit corresponding to the destination address information in the BitString field is set to 1.

[0046] It should be noted that the BitString field also includes a second mapping bit string, and the second mapping bit string is used to map the routing information of the multicast message.

[0047] Illustratively, the routing information of the multicast message may be a destination bandwidth access server BRAS node corresponding to the multicast message or a transmission link corresponding to the multicast message.

[0048] It should be noted that the routing information of the multicast message can be determined through the second mapping bit string, and the corresponding BRAS device can be determined according to the routing information of the multicast message.

[0049] It should be noted that the number of BRAS devices is far smaller than that of user terminal devices, so there is no need to occupy a large number of bits in the BitString for representation. Using the mapped reserved bits in the BitString to represent specific multicast messages can speed up the processing speed of the BRAS device.

[0050] It should be noted that, as shown in Figure 2, Figure 2 is a schematic diagram of the encapsulation format of the BIER header provided by the relevant technology. For example, when the length of the BitString is 256 bits, the first 64 bits are used to represent the mapping reserved bits of the multicast message, that is, the first mapping bit string. As shown in Figure 3, the last 192 bits of the BitString field are used to represent the BFER device, that is, the last 192 bits are the second mapping bit string.

[0051] For example, assuming that there are one million user terminal devices that need to receive the multicast message, these one million user terminal devices are distributed on 50 BFER devices, that is, distributed on 50 BRAS devices, then the routing information of the multicast message is filled in the last 192 bits of the BitString, that is, the second mapping bit string, wherein the routing information of the multicast message includes the destination broadband access server BRAS node corresponding to the multicast message; or, the transmission link corresponding to the multicast message.

[0052] It should be noted that the BIER header also includes a third mapping bit string, wherein the third mapping bit string is used to map the identifier of the multicast message together with the first mapping bit string.

[0053] It is understandable that the third mapping bit string is located in the Entropy field of the BIER header.

[0054] It should be noted that the identifier of the multicast message is mapped through the first mapping bit string and the third mapping bit string.

[0055] For example, in the BitString field in the BIER header, the mapping reserved bits of the first mapping bit string are divided out, and each bit of the first mapping bit string corresponds to the identifier of a multicast message. The bits outside the mapping reserved bits in the BitString field are used to represent the second mapping bit string; in the large-scale user scenario, the number of destination address information far exceeds the number of mapping reserved bits. At this time, it can be represented in combination with the Entropy field in the BIER header, that is, the third mapping bit string. Therefore, the embodiment of the present application can jointly map the identifier of the multicast message through the first mapping bit string and the third mapping bit string, and the corresponding destination address information can be determined based on the identifier of the multicast message, thereby realizing that the BIER header can be applicable to the scenario of ultra-large-scale users, expanding the number of users that can be accommodated.

[0056] It can be understood that, assuming that there are 2000 multicast messages, the first 64 bits of the BitString field are used as the first mapping bit string of the multicast message, and combined with the Entropy field to represent it, that is, the identifier of the multicast message is mapped by combining the first mapping bit string and the third mapping bit string. Assuming that the identifier of the multicast message is 50, then the value of the Entropy field of the third mapping bit string is set to 0, and the 50th bit from the left of the first mapping bit string is set to 1; assuming that the identifier of the multicast message is 200, then the value of the Entropy field of the third mapping bit string is set to 3, and the 8th bit from the left of the first mapping bit string is set to 1; assuming that the identifier of the multicast message is 300, then the value of the Entropy field of the third mapping bit string is set to 4, and the 44th bit from the left of the first mapping bit string is set to 1.

[0057] For example, as shown in Figure 2, Figure 2 is a schematic diagram of the encapsulation format of the BIER header provided by the relevant technology. For example, when the length of the BitString is 256 bits, the first 64 bits are used to represent the mapping reserved bits of the multicast message, that is, the first mapping bit string. As shown in Figure 3, the last 192 bits of the BitString field are used to represent the BFER device, that is, the last 192 bits are the second mapping bit string; wherein, the 64-bit mapping reserved bits of the multicast message can correspond to 64 multicast messages, and in the current large-scale application scenario, the number of multicast messages far exceeds 64. Therefore, it can be combined with the Entropy field in the BIER header to represent, that is, the identifier of the multicast message is mapped by combining the first mapping bit string and the third mapping bit string. Therefore, in the embodiment of the present application, the identifier of the multicast message is jointly determined by combining the first mapping bit string and the third mapping bit string, and the routing information of the multicast message is determined by the second mapping bit string, thereby making the BIER header suitable for scenarios of ultra-large-scale users and expanding the number of users that can be accommodated.

[0058] It should be noted that the length of the mapping reserved bits of the multicast message can be adjusted according to actual conditions, that is, the length of the first mapping bit string can be adjusted according to actual conditions. For example, the length of the mapping reserved bits of the multicast message can be adjusted to 128 bits. Then, when the length of the BitString is 256 bits, the remaining 128 bits are used to represent the BFER device, that is, the remaining 128 bits are the second mapping bit string.

[0059] In a possible embodiment of the present application, before step S110, the following steps S100a and S100b are further included:

[0060] Step S100a, obtaining address information corresponding to the multicast message;

[0061] Step S100b: searching for the identifier of the corresponding multicast message in a preset multicast flow mapping table according to the address information.

[0062] It should be noted that the address information corresponding to the multicast message includes at least destination address information.

[0063] For example, after obtaining the address information corresponding to the multicast message, the corresponding multicast message identifier is searched in the preset multicast stream mapping table according to the address information, and the multicast message identifier is encapsulated into the BIER header. The multicast message identifier is mapped together by combining the first mapping bit string and the third mapping bit string to determine the corresponding destination address information, thereby enabling the BIER header to be suitable for scenarios with ultra-large-scale users, thereby expanding the number of users that can be accommodated.

[0064] Exemplarily, after the CR1 device receives a multicast message from the content server, it obtains the address information (S, G) or (*, G) corresponding to the multicast message, where the address information at least includes the destination address information, and based on the address information, searches for the corresponding multicast message identifier in the preset multicast stream mapping table. As shown in Figure 4, after obtaining the identifier of the multicast message, the identifier of the multicast message is encapsulated in the BitString of the BIER header by combining the first mapping bit string and the third mapping bit string, and the routing information of the multicast message is filled in the second mapping bit string in the BitString.

[0065] It can be understood that the (*) in the above (*, G) refers to the wildcard source address, and the embodiment of the present application does not make specific restrictions. S is the source address and G is the destination address information.

[0066] Specifically, in a possible embodiment, the message processing method further includes step S130 or step S140:

[0067] Step S130: Receive a multicast flow mapping table issued by the controller, where the multicast flow mapping table includes an identifier and address information corresponding to the multicast message;

[0068] or,

[0069] Step S140: configure a corresponding identifier for the multicast message according to the address information corresponding to the multicast message, construct a multicast stream mapping table according to the address information and identifier corresponding to the multicast message, and send the multicast stream mapping table to the BRAS node in the BIER domain.

[0070] It should be noted that the multicast stream mapping table in the preset multicast stream mapping table that is searched for the corresponding multicast message identifier according to the address information can be the multicast stream mapping table issued by the controller, and the multicast stream mapping table includes the identifier and address information corresponding to the multicast message. It can be configured with a corresponding identifier for the multicast message according to the address information corresponding to the multicast message, and a multicast stream mapping table constructed according to the address information and identifier corresponding to the multicast message, and the constructed multicast stream mapping table is sent to the BRAS node in the BIER domain.

[0071] It is understandable that in order to ensure the consistency of multicast messages, the multicast stream mapping tables of the BFIR device and the BFER device are consistent. The multicast stream mapping table can be issued by the controller, or the BFIR device can configure the corresponding identifier for the multicast message according to the address information corresponding to the multicast message, and construct it according to the address information and identifier corresponding to the multicast message. The multicast stream mapping table can be sent to the BFER device, that is, the BRAS node in the BIER domain, through protocols such as BGP (Border Gateway Protocol), PIM (Protocol Independent Multicast), and MLD (Multicast Listener Discovery).

[0072] Exemplarily, the multicast stream mapping table sent by the receiving controller or the corresponding identifier of the multicast message is configured according to the address information corresponding to the multicast message, and the multicast stream mapping table is constructed according to the address information and identifier corresponding to the multicast message, and the multicast stream mapping table is sent to the BRAS node in the BIER domain; secondly, the address information corresponding to the multicast message is obtained; thirdly, the identifier of the corresponding multicast message is searched in the multicast stream mapping table according to the address information; finally, the BIER header is explicitly copied to the multicast message encapsulation bit index to obtain the encapsulated multicast message. Among them, the BIER header includes a bit string BitString field, and the BitString field includes a first mapping bit string, a second mapping bit string, and a third mapping bit string. The first mapping bit string and the third mapping bit string jointly map the identifier of the multicast message, and the second mapping bit string is used to map the routing information of the multicast message. Therefore, the embodiment of the present application improves the encapsulation processing logic of the BIER header to address the situation where the bits of the BIER header BitString cause a large amount of loss in ultra-large-scale user scenarios, which can greatly save bandwidth occupancy in the network, enable the BIER header to be suitable for ultra-large-scale user scenarios, and expand the number of users that can be accommodated.

[0073] Step S120: Send the encapsulated multicast message.

[0074] After completing the encapsulation of the BIER header, the BFIR device sends the multicast message to the next-hop BFER device, so that the BFER device forwards the multicast message according to the BitString carried in the BIER header.

[0075] It should be noted that the length of the first mapping bit string is determined according to the first mapping bit string length supported by the router nodes along the transmission path of the multicast message.

[0076] It should be noted that the length of the first mapping bit string supported by each of the routers is communicated with other router nodes in the domain through the routing protocol.

[0077] It should be noted that the routing protocol can be OSPF (Open Shortest Path First), IS-IS (Intermediate System to Intermediate System), BGP (Border Gateway Protocol), RIFT (Routing in Fat Trees) or BABEL, etc., which exchanges the first mapping bit string length supported by each with other router nodes in the domain through the routing protocol so that the BFIR device can select the optimal encapsulation form. Therefore, the number of users can be maximized to achieve traffic transmission.

[0078] Exemplarily, the specific method of notification can be carried out through the protocol extension of BGP, IS-IS, OSPF, PIFT or BABEL. Taking the BGP protocol as an example, RFC8556 defines the notification format of BIER PTA (PMSI (Provider-Multicast Service Interfaces) Tunnel Attribute), as shown in Figure 5. When notifying the length of the first mapping bit string, the notification can be made with reference to the newly defined format shown in Figure 6. In the flag, a new flag bit M is defined. When the flag bit is set to 1, it indicates the length notification of the first mapping bit string carried by this PTA; at the very end of the PTA, an M-flow-mapping field is added to indicate the length notification of the first mapping bit string. The field can be defined as the lowest bit indicating the length of the first mapping bit string that supports 64 bits, the second to last bit from the lowest bit indicating the length of the first mapping bit string that supports 128 bits, the third to last bit from the lowest bit indicating the length of the first mapping bit string that supports 192 bits, and so on.

[0079] It should be noted that after receiving the support status of the first mapping bit string length notified by other routing nodes in the network, the BFIR device node will choose the optimal method to process it. For example, all routing nodes in the network support the first mapping bit string length of 64 bits, and some routing nodes can also support the first mapping bit string length of 128 bits or 192 bits. In this case, the length of the 64-bit first mapping bit string supported by each routing node is selected to encapsulate the multicast message.

[0080] Specifically, in a possible embodiment, the message processing method further includes the following steps S150 and S160:

[0081] Step S150: Report the first mapping bit string length supported by the node to the controller;

[0082] Step S160, receive the first mapping bit string length supported by other router nodes in the domain issued by the controller; or, receive the first mapping bit string length information associated with the multicast message issued by the controller, the first mapping bit string length information is used to indicate the length of the first mapping bit string in the BIER header of the multicast message, and the first mapping bit string length information is determined by the controller based on the first mapping bit string length supported by the router nodes included in the transmission path of the multicast message.

[0083] Exemplarily, first, the node reports the first mapping bit string length supported by the node to the controller; then, the node receives the first mapping bit string length supported by other router nodes in the domain from the controller; or receives the first mapping bit string length information associated with the multicast message from the controller, and indicates the length of the first mapping bit string in the BIER header of the multicast message based on the first mapping bit string length information. The first mapping bit string length information is determined by the controller based on the first mapping bit string length supported by the router nodes included in the transmission path of the multicast message. By informing the router nodes of the first mapping bit string length supported by the controller, the BFIR device selects the optimal encapsulation method, thereby maximizing the number of users accommodated and achieving multicast message transmission.

[0084] Please refer to Figure 10, which is a flowchart of a message processing method provided by another embodiment of the present application. The execution subject of this message processing method may be a BRAS device in the implementation environment shown in Figure 1, wherein the BRAS device serves as a bit forwarding egress router (BFER) device. As shown in Figure 10, this message processing method may include but is not limited to the following steps S210-S240. Each step is described in sequence below:

[0085] Step S210: receiving a multicast message, wherein the multicast message includes a bit index explicit copy BIER header, the BIER header includes a bit string BitString field, and the BitString field includes a first mapping bit string;

[0086] It should be noted that the BitString field also includes a second mapping bit string, wherein the second mapping bit string is used to map the routing information of the multicast message, and the routing information of the multicast message includes: the destination BRAS node corresponding to the multicast message; or the transmission link corresponding to the multicast message.

[0087] It should be noted that the number of BRAS devices is far smaller than that of user terminal devices, so there is no need to occupy a large number of bits in the BitString for representation. Using the mapped reserved bits in the BitString to represent specific multicast messages can speed up the processing speed of the BRAS device.

[0088] Step S220: determining an identifier of the multicast message according to the first mapping bit string;

[0089] It should be noted that the BIER header also includes a third mapping bit string, wherein the third mapping bit string is located in the Entropy field of the BIER header.

[0090] In a possible embodiment, determining the identifier of the multicast message according to the first mapping bit string includes: determining the identifier of the multicast message according to the third mapping bit string and the first mapping bit string.

[0091] For example, in a large-scale user scenario, the amount of destination address information far exceeds the number of mapped reserved bits. Therefore, in an embodiment of the present application, the identifier of the multicast message is jointly determined by combining the first mapping bit string and the third mapping bit string, and the routing information of the multicast message is determined by the second mapping bit string, thereby making the BIER header suitable for scenarios with ultra-large-scale users and expanding the number of users that can be accommodated.

[0092] For example, as shown in Figure 2, Figure 2 is a schematic diagram of the encapsulation format of the BIER header provided by the relevant technology. For example, when the length of the BitString is 256 bits, the first 64 bits are used to represent the mapping reserved bits of the multicast message, that is, the first mapping bit string. As shown in Figure 3, the last 192 bits of the BitString field are used to represent the BFER device, that is, the last 192 bits are the second mapping bit string; wherein, the 64-bit mapping reserved bits of the multicast message can correspond to 64 multicast messages, and in the current large-scale application scenario, the number of multicast messages far exceeds 64. Therefore, it can be combined with the Entropy field in the BIER header to represent, that is, the identifier of the multicast message is mapped by combining the first mapping bit string and the third mapping bit string. Therefore, in the embodiment of the present application, the identifier of the multicast message is jointly determined by combining the first mapping bit string and the third mapping bit string, and the routing information of the multicast message is determined by the second mapping bit string, thereby making the BIER header suitable for scenarios of ultra-large-scale users and expanding the number of users that can be accommodated.

[0093] Step S230, determining the destination user node according to the identifier of the multicast message;

[0094] Specifically, in a possible embodiment, step S230 includes step S231a and step S232a:

[0095] Step S231a, according to the identifier of the multicast message, searching for the destination address information corresponding to the identifier in the preset multicast flow mapping table;

[0096] Step S232a: Determine the destination user node according to the destination address information.

[0097] For example, first, the identifier of the multicast message is determined based on the first mapping bit string and the third mapping bit string; then, based on the identifier of the multicast message, the destination address information corresponding to the identifier is searched in the preset multicast stream mapping table; finally, the destination user node is determined based on the destination address information. Therefore, in the embodiment of the present application, the identifier of the multicast message is jointly determined by combining the first mapping bit string and the third mapping bit string, and the routing information of the multicast message is determined by the first mapping bit string, thereby making the BIER header applicable to scenarios with ultra-large-scale users and expanding the number of users that can be accommodated.

[0098] It is understandable that in order to ensure the consistency of multicast messages, the multicast flow mapping tables of the BFIR device and the BFER device are consistent. The multicast flow mapping table can be received from the controller or from the bit forwarding ingress router BFIR node.

[0099] In a possible embodiment, the message processing method further includes step S250 or step S260:

[0100] Step S250, exchanging the first mapping bit string lengths supported by each of the router nodes in the domain through the routing protocol;

[0101] or,

[0102] Step S260: Report the first mapping bit string length supported by the node to the controller.

[0103] It should be noted that the first mapping bit string lengths supported by each router node can be exchanged with other router nodes in the domain through a routing protocol.

[0104] It should be noted that the routing protocol can be OSPF (Open Shortest Path First), IS-IS (Intermediate System to Intermediate System), BGP (Border Gateway Protocol), RIFT (Routing in Fat Trees) or BABEL, etc., which exchanges the first mapping bit string length supported by each with other router nodes in the domain through the routing protocol so that the BFIR device can select the optimal encapsulation form. Therefore, the number of users can be maximized and the transmission of multicast messages can be realized.

[0105] It should be noted that the first mapping bit string length supported by the node can be reported to the controller, so that the BFIR device selects the optimal encapsulation format, thereby maximizing the number of users accommodated and realizing the transmission of multicast messages.

[0106] Step S240: forward the multicast message to the destination user node.

[0107] After determining the destination user node according to the identifier of the multicast message, the BFER device sends the multicast message to the next-hop user terminal device, so that the user terminal device receives the multicast message.

[0108] For example, after the multicast message is encapsulated in the BIER header, it is forwarded through each routing node in the network. When it reaches the BFER device, the BFER device will check the first mapping bit string and the third mapping bit string in the BitString field to obtain the identification of the multicast message, and search the corresponding multicast message address information in the preset multicast stream mapping table according to the identification of the multicast message to determine the destination user node. Then the BFER device removes the BIER header and directly copies the multicast message to each destination user node to complete the forwarding of the multicast message.

[0109] For situations where forwarding along a specified path is required in the network, BIER-TE (Bit Index Explicit Replication-Traffic Engineering) technology is applied, and the BIER header encapsulation method defined in RFC9262 is used. In the BIER-TE scenario, the BitString field in the BIER header is used to indicate the transmission link BP (Bit-Position) passed through, that is, the routing information of the multicast message, and each bit corresponds to a link. In this case, part of the bits in the BitString field can also be used to represent the first mapping bit string of the multicast message, and the remaining bits in the BitString field can be used to represent the transmission link BP.

[0110] Example 1:

[0111] In combination with the implementation environment shown in Figure 1, the BRAS device establishes a corresponding relationship between multicast messages and user terminals in advance through the BGP (Border Gateway Protocol), or MLD (Multicast Listener Discovery), or PIM (Protocol Independent Multicast) messages sent by the user terminal. If there are 10,000 users who need to receive the multicast message on a BARS device in the metropolitan area network, then the BRAS device will establish an association table between the multicast message and these 10,000 users.

[0112] As shown in Figure 2, Figure 2 is a schematic diagram of the encapsulation format of the BIER header provided by the relevant technology. For example, when the length of the BitString is 256 bits, the first 64 bits are used to represent the mapping reserved bits of the multicast message, that is, the first mapping bit string. As shown in Figure 3, the last 192 bits of the BitString field are used to represent the BFER device, that is, the last 192 bits are the second mapping bit string; among them, the 64-bit mapping reserved bits of the multicast message can correspond to 64 multicast messages. In the current large-scale application scenarios, the number of multicast messages far exceeds 64. Therefore, it can be combined with the Entropy field in the BIER header to represent, that is, the identification of the multicast message is mapped by combining the first mapping bit string and the third mapping bit string.

[0113] It should be noted that the length of the mapping reserved bits of the multicast message can be adjusted according to actual conditions, that is, the length of the first mapping bit string can be adjusted according to actual conditions. For example, the length of the mapping reserved bits of the multicast message can be adjusted to 128 bits. Then, when the length of the BitString is 256 bits, the remaining 128 bits are used to represent the BFER device, that is, the remaining 128 bits are the second mapping bit string.

[0114] It can be understood that, assuming that there are 2000 multicast messages, the first 64 bits of the BitString field are used as the first mapping bit string of the multicast message, and combined with the Entropy field to represent it, that is, the identifier of the multicast message is mapped by combining the first mapping bit string and the third mapping bit string. Assuming that the identifier of the multicast message is 50, then the value of the Entropy field of the third mapping bit string is set to 0, and the 50th bit from the left of the first mapping bit string is set to 1; assuming that the identifier of the multicast message is 200, then the value of the Entropy field of the third mapping bit string is set to 3, and the 8th bit from the left of the first mapping bit string is set to 1; assuming that the identifier of the multicast message is 300, then the value of the Entropy field of the third mapping bit string is set to 4, and the 44th bit from the left of the first mapping bit string is set to 1.

[0115] It can be understood that, assuming that there are one million user terminal devices that need to receive the multicast message, these one million user terminal devices are distributed on 50 BFER devices, that is, distributed on 50 BRAS devices, then the routing information of the multicast message will be filled in the last 192 bits of the BitString, that is, the second mapping bit string, where the routing information of the multicast message includes the destination broadband access server BRAS node corresponding to the multicast message; or, the transmission link corresponding to the multicast message.

[0116] Therefore, after the CR1 device receives a multicast message from the content server, it obtains the address information (S, G) or (*, G) corresponding to the multicast message, where the address information at least includes the destination address information, and based on the address information, searches for the corresponding multicast message identifier in the preset multicast stream mapping table. As shown in Figure 4, after obtaining the identifier of the multicast message, the identifier of the multicast message is encapsulated in the BitString of the BIER header by combining the first mapping bit string and the third mapping bit string, and the routing information of the multicast message is filled in the second mapping bit string in the BitString.

[0117] It can be understood that the (*) in the above (*, G) refers to the wildcard source address, and the embodiment of the present application does not make specific restrictions. S is the source address and G is the destination address information.

[0118] It is understandable that in order to ensure the consistency of multicast messages, the multicast stream mapping tables of the BFIR device and the BFER device are consistent. The multicast stream mapping table can be issued by the controller, or the BFIR device can configure the corresponding identifier for the multicast message according to the address information corresponding to the multicast message, and construct it according to the address information and identifier corresponding to the multicast message. The multicast stream mapping table can be sent to the BFER device, that is, the BRAS node in the BIER domain, through protocols such as BGP (Border Gateway Protocol), PIM (Protocol Independent Multicast), and MLD (Multicast Listener Discovery).

[0119] After the multicast message is encapsulated in the BIER header, it is forwarded through each routing node in the network. When it reaches the BFER device, the BFER device will check the first mapping bit string and the third mapping bit string in the BitString field to obtain the identification of the multicast message, and search the corresponding multicast message address information in the preset multicast stream mapping table according to the identification of the multicast message to determine the destination user node. Then the BFER device removes the BIER header and directly copies the multicast message to each destination user node to complete the forwarding of the multicast message.

[0120] For situations where forwarding along a specified path is required in the network, BIER-TE (Bit Index Explicit Replication-Traffic Engineering) technology is applied, and the BIER header encapsulation method defined in RFC9262 is used. In the BIER-TE scenario, the BitString field in the BIER header is used to indicate the transmission link BP (Bit-Position) passed through, that is, the routing information of the multicast message, and each bit corresponds to a link. In this case, part of the bits in the BitString field can also be used to represent the first mapping bit string of the multicast message, and the remaining bits in the BitString field can be used to represent the transmission link BP.

[0121] It is understandable that BIER-TE technology is a new network technology based on SDN, which can achieve efficient traffic engineering without the need to use traditional labels and tunneling technologies. BIER-TE technology adds a BitString to the packet header to identify the forwarding path of the packet, thereby achieving precise control of the packet. Compared with traditional TE technology, BIER-TE technology has higher scalability and lower maintenance costs. The implementation of BIER-TE technology requires the use of a BIER-TE controller, which can obtain the topology information of BIER-TE devices and calculate the sum of the number of nodes and links. When the number of nodes or links in the network changes, the BIER-TE controller will automatically update the number of nodes and links to ensure the normal operation of the network.

[0122] It is understood that RFC9262 defines a common Ethernet label type for MPLS (Multiprotocol Label Switching) and other data link layer encapsulations. These label types are used to establish a mapping between the Data Link Layer (DL) and MPLS to support multiprotocol label switching.

[0123] Therefore, compared with the related art in which the BFIR device needs to send 3906 multicast messages for these one million users, the embodiment of the present application only needs to send one multicast message, thereby greatly saving the bandwidth occupancy in the network. In addition, the BFER device can find the required destination user node according to the multicast stream mapping table and quickly copy and send the multicast message, thereby simplifying the processing flow of the BFER device and improving the processing speed.

[0124] Example 2:

[0125] Combined with the implementation environment shown in Figure 1, there may be inconsistencies in the processing of the first mapping bit string of the multicast message by the routing nodes in the network. For example, some routing nodes support a length of 64 bits for the first mapping bit string of the multicast message, while some routing nodes support a length of 64 bits or 128 bits for the first mapping bit string. Since the other bits in the BitString field except the first mapping bit string are used to implement BIER or BIER-TE forwarding, inconsistent processing may cause errors in the forwarding of the multicast message. Therefore, the routing nodes in the network, including CR devices, BRAS devices and other routing node devices in the middle, can announce the support status of the length of their first mapping bit string.

[0126] The specific method of notification can be carried out through the protocol extension of BGP, IS-IS, OSPF, PIFT or BABEL. Taking the BGP protocol as an example, RFC8556 defines the notification format of BIER PTA (PMSI (Provider-Multicast Service Interfaces) Tunnel Attribute), as shown in Figure 5. When notifying the length of the first mapping bit string, the notification can be made with reference to the newly defined format shown in Figure 6. In the flag, a new flag bit M is defined. When the flag bit is set to 1, it indicates the length notification of the first mapping bit string carried by this PTA; at the very end of the PTA, an M-flow-mapping field is added to indicate the length notification of the first mapping bit string. The field can be defined as the lowest bit indicating the length of the first mapping bit string that supports 64 bits, the second to last bit from the lowest bit indicating the length of the first mapping bit string that supports 128 bits, the third to last bit from the lowest bit indicating the length of the first mapping bit string that supports 192 bits, and so on.

[0127] Similarly, for the IS-IS protocol, a notification of the length of the first mapping bit string can be added to the BIER Info Sub-TLV defined in RFC8401, as shown in Figure 7. The format of the newly added Sub-sub-TLV is shown in Figure 8, where the type field is set to the identifier of the multicast message in the first mapping bit string, and the Length is set to the length of the M-flow-mapping field. The content of the M-flow-mapping field is the same as that defined in the BGP protocol, and is used to indicate the length notification of the first mapping bit string of the multicast message.

[0128] It is understandable that the definitions of protocols such as OSPF, RIFT, and BABEL are similar to the above-mentioned IS-IS protocol.

[0129] When each routing node announces, if the length of the first mapping bit string only supports 64 bits, the announcement is made, and only the lowest bit is set to 1; if the length of the first mapping bit string supports both 64 bits and 128 bits, the announcement is made, and the lowest 2 bits are set to 1; if the length of the first mapping bit string supports 64 bits, 128 bits, and 192 bits, the announcement is made, and the lowest 3 bits are all set to 1.

[0130] After receiving the support status of the first mapping bit string length notified by other routing nodes in the network, the BFIR device node will select the optimal method for processing. For example, all routing nodes in the network support the first mapping bit string length of 64 bits, and some routing nodes can also support the first mapping bit string length of 128 bits or 192 bits. In this case, the length of the 64-bit first mapping bit string supported by each routing node is selected to encapsulate the multicast message.

[0131] Therefore, the new encapsulation and processing mechanism of the BIER header defined in the embodiment of the present application, as well as the corresponding control plane notification mechanism, can greatly save the bandwidth occupancy in the network, and can find the required destination user node on the BFER device according to the multicast stream mapping table for rapid copying and sending, thereby simplifying the BFER processing flow and improving the processing speed.

[0132] The embodiment of the present application further provides an electronic device, as shown in FIG11 , wherein the electronic device 1400 includes:

[0133] one or more processors 1410;

[0134] The memory 1420 stores one or more programs. When the one or more programs are executed by the one or more processors 1410, the one or more processors 1410 implement the following:

[0135] Such as the message processing method applied to CR equipment; or

[0136] For example, the message processing method applied to BRAS equipment.

[0137] The memory 1420 is a non-transient network system that can be used to store non-transient software programs and non-transient computer executable programs. In addition, the memory 1420 may include a high-speed random access memory and may also include a non-transient memory, such as at least one disk storage device, a flash memory device, or other non-transient solid-state storage device. In some embodiments, the memory 1420 may optionally include a memory 1420 remotely located relative to the processor 1410, and these remote memories 1420 may be connected to the processor 1410 via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0138] The memory 1420 can be implemented in the form of a read-only memory (ROM), a static storage device, a dynamic storage device, or a random access memory (RAM). The memory 1420 can store an operating system and other application programs. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the relevant program code is stored in the memory 1420 and is called by the processor 1410 to execute the methods of the embodiments of this application.

[0139] The processor 1410 can be implemented using a general-purpose CPU (Central Processing Unit), a microprocessor, an application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of the present application.

[0140] In some embodiments, the electronic device further comprises:

[0141] Input / output interface, used to realize information input and output;

[0142] Communication interface, used to realize communication interaction between this device and other devices, which can be achieved through wired means (such as USB, network cable, etc.) or wireless means (such as mobile network, Wi-Fi, Bluetooth, etc.);

[0143] A bus that transmits information between various components of the device (e.g., the processor 1410, memory 1420, input / output interfaces, and communication interfaces);

[0144] The processor 1410 , the memory 1420 , the input / output interface, and the communication interface can be communicatively connected to each other within the device via a bus.

[0145] An embodiment of the present application further provides a computer-readable storage medium storing computer-executable instructions for executing:

[0146] Such as the message processing method applied to CR equipment; or

[0147] For example, the message processing method applied to BRAS equipment.

[0148] An embodiment of the present application further provides a computer program product, including a computer program or computer instructions, wherein the computer program or computer instructions are stored in a computer-readable storage medium. A processor of a computer device reads the computer program or computer instructions from the computer-readable storage medium, and the processor executes the computer program or computer instructions, so that the computer device performs the following operations:

[0149] Such as the message processing method applied to CR equipment; or

[0150] For example, the message processing method applied to BRAS equipment.

[0151] The system architecture and application scenarios described in the embodiments of the present application are intended to more clearly illustrate the technical solutions of the embodiments of the present application, and do not constitute a limitation on the technical solutions provided in the embodiments of the present application. Those skilled in the art will appreciate that with the evolution of the system architecture and the emergence of new application scenarios, the technical solutions provided in the embodiments of the present application are equally applicable to similar technical problems.

[0152] Those skilled in the art will appreciate that all or part of the processes in the above-mentioned embodiments can be implemented by instructing the relevant hardware through a computer program. The computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to memory, storage, database or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM) or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link (Synchlink) DRAM (SLDRAM), memory bus (Rambus) direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM).

[0153] Those skilled in the art will appreciate that all or some of the steps and systems in the method disclosed above can be implemented as software, firmware, hardware, and appropriate combinations thereof. Some physical components or all physical components can be implemented as software executed by a processor, such as a central processing unit, a digital signal processor, or a microprocessor, or implemented as hardware, or implemented as an integrated circuit, such as an application-specific integrated circuit. Such software can be distributed on a computer-readable medium, and the computer-readable medium can include computer storage media (or non-transitory media) and communication media (or temporary media). As known to those skilled in the art, the term computer storage media is included in any method or technology for storing information (such as computer-readable instructions, data structures, program modules, or other data) and is volatile and non-volatile, removable, and non-removable. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory, or other memory technology, CD-ROM, digital versatile disks (DVD), or other optical disk storage, magnetic cassettes, magnetic tapes, disk storage, or other magnetic storage devices, or any other medium that can be used to store desired information and can be accessed by a computer. Furthermore, as is well known to those skilled in the art, communication media typically embodies computer-readable instructions, data structures, program modules, or other data in a modulated data signal such as a carrier wave or other transport mechanism, and may include any information delivery media.

[0154] The above description of some embodiments of the present application with reference to the accompanying drawings does not limit the scope of the present invention. Any modifications, equivalent substitutions, and improvements made by those skilled in the art without departing from the scope and essence of the present invention shall be within the scope of the present application.

Claims

1. A message processing method, the method comprising: Explicitly copy the BIER header to the multicast message encapsulation bit index to obtain the encapsulated multicast message, wherein the BIER header includes a bit string BitString field, the BitString field includes a first mapping bit string, and the first mapping bit string is used to map the identifier of the multicast message; Send the encapsulated multicast message.

2. The method according to claim 1, wherein: The BitString field also includes a second mapping bit string, where the second mapping bit string is used to map routing information of the multicast message, where the routing information of the multicast message includes: The destination broadband access server BRAS node corresponding to the multicast message; or, The transmission link corresponding to the multicast message.

3. The method according to claim 1, wherein: The BIER header also includes a third mapping bit string, which is used to map the identifier of the multicast message together with the first mapping bit string.

4. The method according to claim 3, wherein: The third mapping bit string is located in the Entropy field of the BIER header.

5. The method according to claim 1, wherein: Before encapsulating the bit index explicit copy BIER header in the multicast message, the method further includes: Acquire address information corresponding to the multicast message, wherein the address information at least includes destination address information; According to the address information, the identifier of the corresponding multicast message is searched in a preset multicast flow mapping table.

6. The method according to claim 5, wherein: The method further comprises: The multicast stream mapping table sent by the receiving controller includes an identifier and address information corresponding to the multicast message; or, Configure a corresponding identifier for the multicast message according to the address information corresponding to the multicast message, build a multicast stream mapping table according to the address information and identifier corresponding to the multicast message, and send the multicast stream mapping table to the BRAS node in the BIER domain.

7. The method according to claim 1, wherein: The length of the first mapping bit string is determined according to the first mapping bit string length supported by the router nodes through which the transmission path of the multicast message passes.

8. The method according to claim 7, wherein: The method further comprises: The first mapping bit string length supported by each of the nodes is exchanged with other router nodes in the domain through the routing protocol.

9. The method according to claim 7, wherein: The method further comprises: Report the first mapping bit string length supported by this node to the controller; Receive the first mapping bit string length supported by other router nodes in the domain issued by the controller; or, receive the first mapping bit string length information associated with the multicast message issued by the controller, the first mapping bit string length information is used to indicate the length of the first mapping bit string in the BIER header of the multicast message, and the first mapping bit string length information is determined by the controller according to the first mapping bit string length supported by the router nodes included in the transmission path of the multicast message.

10. A message processing method, the method comprising: Receive a multicast message, wherein the multicast message includes a bit index explicit copy BIER header, the BIER header includes a bit string BitString field, and the BitString field includes a first mapping bit string; Determining an identifier of the multicast message according to the first mapping bit string; Determining a destination user node according to an identifier of the multicast message; The multicast message is forwarded to the destination user node.

11. The method according to claim 10, wherein: The BitString field also includes a second mapping bit string, where the second mapping bit string is used to map routing information of the multicast message, where the routing information of the multicast message includes: The destination BRAS node corresponding to the multicast message; or, The transmission link corresponding to the multicast message.

12. The method according to claim 10, wherein: The BIER header also includes a third mapping bit string, and the identification of the multicast message is determined according to the first mapping bit string, including: The identifier of the multicast message is determined according to the third mapping bit string and the first mapping bit string.

13. The method according to claim 12, wherein: The third mapping bit string is located in the Entropy field of the BIER header.

14. The method according to claim 10, wherein: The determining the destination user node according to the identifier of the multicast message includes: According to the identifier of the multicast message, searching for destination address information corresponding to the identifier in a preset multicast stream mapping table; The destination user node is determined according to the destination address information.

15. The method according to claim 14, wherein: The multicast flow mapping table is received from a controller or a bit forwarding ingress router BFIR node.

16. The method according to claim 10, wherein: The method further comprises: Interacting with other router nodes in the domain through the routing protocol on the length of the first mapping bit string supported by each node; or, Report the first mapping bit string length supported by this node to the controller.

17. An electronic device comprising: one or more processors; A memory having one or more programs stored thereon, when the one or more programs are executed by the one or more processors, the one or more processors implement: The message processing method according to any one of claims 1 to 9; or, A message processing method as described in any one of claims 10-16.

18. A computer-readable storage medium having a computer program stored thereon, wherein when the program is executed by a processor, the program implements: The message processing method according to any one of claims 1 to 9; or, A message processing method as described in any one of claims 10-16.

Images