Message processing method, electronic equipment and storage medium

Abstract

Provided are a message processing method, device and medium, which relate to but are not limited to the technical field of communications, the method comprising: explicitly copying a BI ER header to a multicast message encapsulation bit index, the BI ER header comprising a bit string BitString field, the BitString field comprising a first mapping bit string, mapping an identifier of a multicast message through the first mapping bit string, according to the method and the device, the first mapping bit string is mapped to the multicast message to obtain the packaged multicast message, and then the packaged multicast message is sent, so that after the BFER receives the multicast message, the BFER can determine the corresponding target user node according to the first mapping bit string, and then the multicast message is forwarded to the corresponding target user node. According to the embodiment of the invention, the packaging processing logic of the BI ER head is improved for the condition that a large number of messages are needed to bear multicast data in a super-large-scale user scene in the past, the number of multicast data messages can be greatly saved, the occupied network bandwidth is reduced, and the BI ER head can be suitable for the super-large-scale user scene.

Description

Technical Field

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

[0002] Bit Indexed Explicit Replication (BIER) is a new multicast data forwarding technology. In this technology, nodes at the network edge are represented by only one bit. When multicast traffic is transmitted in the intermediate network, a specific BIER header will be additionally encapsulated. This packet header marks all destination nodes of the multicast stream in the form of a bit string (BitString). Intermediate network forwarding nodes perform routing by looking up the BIER forwarding table according to the bit, ensuring that traffic can be sent to all destination nodes.

[0003] Since the BIER technology does not have the problem of establishing a multicast tree, it does not need to sense different multicast data flows, and eliminates the delay in establishing the multicast tree. When a network failure occurs, there is no experimental overhead for reconstructing the multicast tree, and the convergence speed is far faster than the original multicast technology.

[0004] Current point-to-multipoint application scenarios, including network live broadcasts, online teaching, remote conferences, etc., face the problem of a large number of receiving-end users at the network edge. Taking network live broadcasts as an example, the number of online viewers of a network live broadcast may reach millions, and individual internet celebrities may reach tens of millions. During the Spring Festival, hundreds of millions of users are watching the Spring Festival Gala live broadcast, and the number of viewers of the Spring Festival Gala live broadcast on a single video platform may reach tens of millions. How to deploy the BIER technology to adapt to such scenarios is the main problem faced by the industry currently. Summary of the Invention

[0005] The embodiments of the present application provide a method for processing packets, an electronic device, and a storage medium, aiming to improve the encapsulation processing logic of the BIER header in a large-scale user scenario to broaden the number of users that can be accommodated.

[0006] In a first aspect, the embodiments of the present application provide a method for processing packets, the method comprising:

[0007] Encapsulating a Bit Indexed Explicit Replication (BIER) header into a multicast packet to obtain an encapsulated multicast packet, wherein the BIER header includes a BitString field, and the BitString field includes a first mapped bit string for mapping an identifier of the multicast packet;

[0008] Sending the encapsulated multicast packet.

[0009] Second aspect, an embodiment of the present application provides a message processing method, the method comprising:

[0010] Receiving a multicast message, wherein the multicast message includes a Bit Index Explicit Replication (BIER) header, the BIER header includes a Bit String field, and the Bit String field includes a first mapping bit string;

[0011] Determining an identifier of the multicast message according to the first mapping bit string;

[0012] Determining a destination user node according to the identifier of the multicast message;

[0013] Forwarding the multicast message to the destination user node.

[0014] Third aspect, an embodiment of the present application provides an electronic device, comprising:

[0015] One or more processors;

[0016] A memory storing one or more programs, which when executed by the one or more processors, cause the one or more processors to implement the message processing method described in the first aspect above; or, the message processing method described in the second aspect above.

[0017] Fourth aspect, an embodiment of the present application provides a computer-readable storage medium, having stored thereon a computer program, which when executed by a processor, implements the message processing method described in the first aspect above; or, the message processing method described in the second aspect above.

[0018] For the message processing method, electronic device, and storage medium provided by the embodiments of the present application, first, a Bit Index Explicit Replication (BIER) header is encapsulated in the multicast message, where the BIER header includes a Bit String field, and the Bit String field includes a first mapping bit string. The identifier of the multicast message is mapped through the first mapping bit string to obtain the encapsulated multicast message, and then the encapsulated multicast message is sent. In this way, when the Bit Forwarding Egress Router (BFER) receives the multicast message, it can determine the corresponding destination user node according to the first mapping bit string, and then forward the multicast message to the corresponding destination user node. For the situation in the past where a large number of messages were required to carry multicast data in a very large-scale user scenario, the embodiments of the present application improve the encapsulation processing logic of the BIER header, which can greatly save the number of multicast data messages, reduce the occupied network bandwidth, enable the BIER header to be applicable to the very large-scale user scenario, and expand the number of users that the BIER header can accommodate. Description of the Drawings

[0019] The accompanying drawings are used to provide a further understanding of the technical solutions 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 solutions of the present invention, and do not constitute a limitation to the technical solutions of the present invention.

[0020] Figure 1 It is a schematic diagram of an implementation environment of a packet processing method provided by an embodiment of the present application;

[0021] Figure 2 It is a schematic diagram of the encapsulation format of a BIER header provided by the related art;

[0022] Figure 3 It is another schematic diagram of the encapsulation format of a BIER header provided by the related art;

[0023] Figure 4 It is a schematic diagram of the correspondence between the address information of a multicast packet and the identifier of the multicast packet provided by an embodiment of the present application;

[0024] Figure 5 It is a schematic diagram of the format for notifying the length of the first mapping bit string provided by the related art;

[0025] Figure 6 It is a schematic diagram of the new defined format for notifying the length of the first mapping bit string provided by the related art;

[0026] Figure 7 It is a schematic diagram of the BIER Info Sub-TLV format provided by an embodiment of the present application;

[0027] Figure 8 It is a schematic diagram of the newly added Sub-sub-TLV format provided by an embodiment of the present application;

[0028] Figure 9 It is a schematic diagram of the process of a packet processing method provided by an embodiment of the present application;

[0029] Figure 10 It is a schematic diagram of the process of a packet processing method provided by another embodiment of the present application;

[0030] Figure 11 It is a schematic diagram of the device structure of an electronic device provided by an embodiment of the present application. Detailed implementation manners

[0031] In order to make the objectives, technical solutions and advantages of the present invention clearer and more understandable, 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 used to limit the present invention.

[0032] 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 quantity of the indicated technical features or implicitly indicating the sequence of the indicated technical features. "At least one" means one or more, and "a plurality" 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 may represent the situation where A exists alone, A and B exist simultaneously, and B exists alone. Where A and B may be singular or plural. The character " / " generally represents an "or" relationship between the associated objects before and after. "At least one of the following" and its similar expressions refer to any group of these items, including any group of single items or plural items. For example, at least one of a, b, and c may represent: a, b, c, a and b, a and c, b and c, or a and b and c, where a, b, and c may be single or multiple.

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

[0034] To facilitate the understanding of the solutions of the embodiments of the present application and to make the descriptions of the following embodiments clear and concise, a brief introduction to the related technologies is first given:

[0035] Please refer to Figure 1 , Figure 1 which is a schematic diagram of an implementation environment of the message processing method provided by the embodiments of the present application. Figure 1 The shown implementation environment is a network architecture, which includes a backbone network, a metropolitan area network, and an access network. Among them, 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. As Figure 1In the network architecture shown, the backbone network includes a CR1 device. The CR1 device is connected to a content server. The CR1 device 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. BRAS1, BRAS2, ……, BRASn are respectively connected to multiple user terminal devices. The multicast data packets 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 devices that need to receive the multicast data packets.

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

[0037] It should be noted that the user terminal device can be a user equipment (UE for short). Among them, the UE includes a handheld device, a vehicle-mounted device, a wearable device or a computing device with wireless communication functions. Exemplarily, the UE can be a mobile phone, a tablet computer or a computer with wireless transceiver functions. The terminal device can also be a virtual reality (VR) terminal device, an augmented reality (AR) terminal device, a wireless terminal in industrial control, a wireless terminal in driverless, a wireless terminal in remote medical treatment, a wireless terminal in smart grid, a wireless terminal in smart city, a wireless terminal in smart home, and so on.

[0038] Bit Indexed Explicit Replication (BIER) is a new multicast data forwarding technology. This technology represents all nodes at the network edge with only one bit. When multicast traffic is transmitted in the intermediate network, a specific BIER header will be additionally encapsulated. This packet header marks all destination nodes of the multicast flow in the form of a BitString (bit string). The intermediate network forwarding nodes perform routing according to the bit by looking up the BIER forwarding table to ensure that the traffic can be sent to all destination nodes.

[0039] Please refer to Figure 2 , Figure 2 which is a schematic diagram of the encapsulation format of the BIER header provided by the related technology. As Figure 2As shown, 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. Among them, the TC field can be used to identify and distinguish different types of multicast data packets, so as to perform specific processing according to the category of the multicast data packets, and is used to indicate the multicast data packet category of the data 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 the data 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 of the path identifier; the Entropy field is used to add some randomness in multi-path selection to ensure that the data packets are evenly distributed to multiple paths during the transmission process, improving the load balancing; the OAM field is used to indicate whether the data packet is for OAM purposes, and the setting of the OAM bit can trigger the network device to perform some special operations for network management and maintenance; the DSCP field is used to specify the differentiated service code point of the data packet, which helps to distinguish and prioritize the data packets in terms of quality of service (QoS); the BFIR-id field is used to identify the starting router of the data packet, that is, the router that performs the BIER operation, and is used to indicate the initial entry point of the data packet; each bit in the BitString field represents a specific multicast forwarding path, and the combination of multiple bits represents a group of paths, and each path corresponds to an interface in the network.

[0040] Taking Figure 1 the shown implementation environment as an example, the CR1 device serves as the bit forwarding ingress router (BFIR), and the BRAS1 device, BRAS2 device, ……, BRASn device serve as the bit forwarding egress routers (BFER).

[0041] Since the BIER technology does not have the problem of multicast tree establishment, does not need to sense different multicast data flows, and eliminates the delay of multicast tree establishment, when the network fails, there is no experimental overhead for reconstructing the multicast tree, and the convergence speed is far faster than the original multicast technology.

[0042] The current point-to-multipoint application scenarios, including network live broadcast, online teaching, remote conferencing, etc., face the problem of a large number of users at the receiving end at the network edge. For example, in the case of network live broadcast, the number of online viewers of a network live broadcast may reach millions, and individual internet celebrities may reach tens of millions. During the Spring Festival, hundreds of millions of users are watching the Spring Festival Gala live broadcast, and the number of viewers of the Spring Festival Gala live broadcast on a single video platform may reach tens of millions. How to deploy the BIER technology to adapt to such scenarios is the main problem faced by the industry currently.

[0043] In the related art, each BRAS device manages more than 32,000 users, and 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 device, which are not drawn here for simplicity.

[0044] Taking the scenario of network live broadcast as an example, the content server for live broadcast usually sends traffic to the CR device of the backbone network. The devices of the backbone network will push the traffic to the devices of the metropolitan area network according to the distribution of users. After the traffic reaches the BRAS at the edge of the metropolitan area network, the BRAS will then push it to the users watching the live broadcast. In the actual scenario, there may be multiple devices in the backbone network. Although the live broadcast traffic may only be sent to one CR device of the backbone network, it will actually be forwarded to other CR devices in the backbone network. That is to say, according to the distribution of live broadcast users, several CR devices, the corresponding BRAS devices of the metropolitan area network, and millions or even tens of millions of user terminals form a point-to-multipoint application scenario.

[0045] For the BIER technology, the destination edge node is represented in the BitString field of the BIER header in the form of a single bit. The BitString field has a length limit. Currently, the maximum length of the BitString specified within the standard range is 4096 bits, but with the current device capabilities, the generally processed BitString length is 256 bits. That is to say, 256 destination nodes can be identified in a BIER header.

[0046] When the current operator intends to apply the BIER technology to this scenario, it faces the problem of a huge number of users. When using a user terminal as the destination node BFER, a BIER packet can only identify 256 users. In the network live broadcast scenario, assuming that one million users are watching the same live broadcast program, at least 3906 BIER packets need to be encapsulated by BFIR to send to so many users. Such a large number of BIER packets not only occupy a large amount of bandwidth themselves but also greatly increase the processing burden of the device. This completely fails to reflect the advantages of the BIER technology, and the efficiency is even lower than that of the traditional PIM (Protocol Independent Multicast) technology.

[0047] 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., all need to be upgraded to support BIER packet parsing, which is also a huge challenge for the upgrade and transformation of such a large number of terminal devices.

[0048] Based on this, the embodiments of the present application provide a packet processing method, an electronic device, and a storage medium, aiming to improve the encapsulation processing logic of the BIER header in an ultra-large-scale user scenario to broaden the number of users that can be accommodated.

[0049] Please refer to Figure 9 , Figure 9 which is a schematic flowchart of a packet processing method provided by the embodiments of the present application. The execution subject of this packet processing method can be Figure 1 the CR device in the shown implementation environment, where the CR device serves as a Bit Forwarding Ingress Router (BFIR) device. As Figure 9 shown, this packet processing method may include but is not limited to the following steps S110 - S120, and each step will be introduced in turn below:

[0050] Step S110: Encapsulate a bit index explicit replication (BIER) header for the multicast packet to obtain the encapsulated multicast packet. The BIER header includes a bit string (BitString) field, and the BitString field includes a first mapping bit string, and the first mapping bit string is used to map the identifier of the multicast packet.

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

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

[0053] 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 packet.

[0054] Exemplarily, the routing information of the multicast packet can be the destination bandwidth access server (BRAS) node corresponding to the multicast packet or the transmission link corresponding to the multicast packet.

[0055] It should be noted that the routing information of the multicast packet 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 packet.

[0056] It should be noted that the number of BRAS devices is much smaller than that of user terminal devices, so it is not necessary to occupy a large number of bits in the BitString to represent them. Using the mapping reserved bits in the BitString to represent specific multicast packets can accelerate the processing speed of the BRAS device.

[0057] It should be noted that, as Figure 2 shown, Figure 2 Figure Figure 2 is a schematic diagram of the encapsulation format of the BIER header provided by the related art. For example, when the length of the BitString is 256 bits, the first 64 bits of it are used to represent the mapping reserved bits of the multicast packet, that is, the first mapping bit string. As Figure 3 shown, 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.

[0058] Exemplarily, assuming that one million user terminal devices need to receive this multicast packet, and these one million user terminal devices are distributed on 50 BFER devices, that is, on 50 BRAS devices, then the routing information of the multicast packet is correspondingly filled into the last 192 bits of the BitString, that is, the second mapping bit string. Among them, the routing information of the multicast packet includes the destination broadband access server BRAS node corresponding to the multicast packet; or, the transmission link corresponding to the multicast packet.

[0059] It should be noted that the BIER header also includes a third mapping bit string, where the third mapping bit string is used to jointly map the identifier of the multicast packet with the first mapping bit string.

[0060] It can be understood that the third mapping bit string is located in the Entropy field of the BIER header.

[0061] It should be noted that the identifier of the multicast packet is jointly mapped by the first mapping bit string and the third mapping bit string.

[0062] Exemplarily, in the BitString field of the BIER header, the mapping reserved bits of the first mapping bit string are divided, and each bit of the first mapping bit string corresponds to an identifier of a multicast packet. The bits outside the mapping reserved bits in the BitString field are used to represent the second mapping bit string; in a 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 by combining the Entropy field in the BIER header, that is, the third mapping bit string. Therefore, the embodiments of the present application can jointly map the identifier of the multicast packet by the first mapping bit string and the third mapping bit string. Based on the identifier of the multicast packet, the corresponding destination address information can be determined, thereby enabling the BIER header to be applicable to the scenario of ultra-large-scale users and expanding the number of accommodable users.

[0063] It can be understood that when there are 2,000 multicast packets, the first 64 bits of the BitString field are used as the first mapping bit string of the multicast packets, and combined with the Entropy field to represent. That is, the identifier of the multicast packet is mapped by the combination of the first mapping bit string and the third mapping bit string. Suppose the identifier of the multicast packet is 50, then the value of the Entropy field of the third mapping bit string is set to 0 at this time, and the 50th bit from the left of the first mapping bit string is set to 1; suppose the identifier of the multicast packet is 200, then the value of the Entropy field of the third mapping bit string is set to 3 at this time, and the 8th bit from the left of the first mapping bit string is set to 1; suppose the identifier of the multicast packet is 300, then the value of the Entropy field of the third mapping bit string is set to 4 at this time, and the 44th bit from the left of the first mapping bit string is set to 1.

[0064] Exemplarily, as Figure 2 shown, Figure 2 is a schematic diagram of the encapsulation format of the BIER header provided by the related art. For example, when the length of the BitString is 256 bits, the first 64 bits of it are used to represent the mapping reserved bits of the multicast packet, that is, the first mapping bit string, as Figure 3 shown, the following 192 bits of the BitString field are used to represent the BFER device, that is, the following 192 bits are the second mapping bit string; among them, the 64-bit mapping reserved bits of the multicast packet can correspond to 64 multicast packets, and in the current large-scale application scenarios, the number of multicast packets 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 packet is mapped by the combination of the first mapping bit string and the third mapping bit string. Therefore, in the embodiment of the present application, the identifier of the multicast packet is jointly determined by the combination of the first mapping bit string and the third mapping bit string, and the routing information of the multicast packet is determined by the second mapping bit string, so that the BIER header can be applicable to the scenario of ultra-large-scale users and expand the number of users that can be accommodated.

[0065] It should be noted that the length of the mapping reserved bits of the multicast packet can be adjusted according to the actual situation, that is, the length of the first mapping bit string can be adjusted according to the actual situation. For example, the length of the mapping reserved bits of the multicast packet can be adjusted to 128 bits. Then, relative to the case where the length of the BitString is 256 bits, the following 128 bits are used to represent the BFER device, that is, the following 128 bits are the second mapping bit string.

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

[0067] Step S100a, obtaining the address information corresponding to the multicast packet;

[0068] Step S100b: Search for the identifier of the corresponding multicast packet in the pre-set multicast flow mapping table according to the address information.

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

[0070] Exemplarily, after obtaining the address information corresponding to the multicast packet, search for the identifier of the corresponding multicast packet in the pre-set multicast flow mapping table according to the address information, and encapsulate the identifier of the multicast packet into the BIER header, and map the identifier of the multicast packet jointly by combining the first mapping bit string and the third mapping bit string, so as to determine the corresponding destination address information, and further enable the BIER header to be applicable to the scenario of ultra-large-scale users, expanding the number of users that can be accommodated.

[0071] Exemplarily, after the CR1 device receives a multicast packet from the content server, obtain the address information (S, G) or (*, G) corresponding to the multicast packet, where the address information includes at least the destination address information, and search for the identifier of the corresponding multicast packet in the pre-set multicast flow mapping table according to the address information, as Figure 4 shown, after obtaining the identifier of the multicast packet, encapsulate the identifier of the multicast packet in the BitString of the BIER header by combining the first mapping bit string and the third mapping bit string, and fill the routing information of the multicast packet into the second mapping bit string in the BitString.

[0072] It can be understood that the (*) in the above (*, G) refers to source address wildcards, and the embodiments of the present application do not make specific limitations. S is the source address, and G is the destination address information.

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

[0074] Step S130: Receive the multicast flow mapping table sent by the controller. The multicast flow mapping table includes the identifier corresponding to the multicast packet and the address information;

[0075] Or,

[0076] Step S140: Configure a corresponding identifier for the multicast packet according to the address information corresponding to the multicast packet, construct a multicast flow mapping table according to the address information and the identifier corresponding to the multicast packet, and send the multicast flow mapping table to the BRAS node in the BIER domain.

[0077] It should be noted that the multicast flow mapping table for looking up the identifier of the corresponding multicast packet according to the address information in the preset multicast flow mapping table can be the multicast flow mapping table sent by the controller. The multicast flow mapping table includes the identifier corresponding to the multicast packet and the address information, and can be a multicast flow mapping table configured with the corresponding identifier for the multicast packet according to the address information corresponding to the multicast packet, and constructed based on the address information and identifier corresponding to the multicast packet, and the constructed multicast flow mapping table is sent to the BRAS node in the BIER domain.

[0078] It can be understood that to ensure the consistency of multicast packets, the multicast flow mapping tables of the BFIR device and the BFER device are the same. The multicast flow mapping table can be sent by the controller, or can be constructed by the BFIR device by configuring the corresponding identifier for the multicast packet according to the address information corresponding to the multicast packet, and based on the address information and identifier corresponding to the multicast packet. And the multicast flow 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).

[0079] Exemplarily, receive the multicast flow mapping table sent by the controller or configure the corresponding identifier for the multicast packet according to the address information corresponding to the multicast packet, and construct the multicast flow mapping table based on the address information and identifier corresponding to the multicast packet, and send the multicast flow mapping table to the BRAS node in the BIER domain; secondly, obtain the address information corresponding to the multicast packet; thirdly, look up the identifier of the corresponding multicast packet in the multicast flow mapping table according to the address information; finally, explicitly copy the BIER header to the encapsulation bit index of the multicast packet to obtain the encapsulated multicast packet. Among them, the BIER header includes a BitString field of a bit string. 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 packet, and the second mapping bit string is used to map the routing information of the multicast packet. Therefore, in the embodiment of the present application, in view of the situation that a large amount of loss is caused by the bits of the BIER header BitString in the ultra-large-scale user scenario, the encapsulation processing logic of the BIER header is improved, which can greatly save the bandwidth occupancy in the network, enable the BIER header to be applicable to the ultra-large-scale user scenario, and expand the number of users that can be accommodated.

[0080] Step S120, send the encapsulated multicast packet.

[0081] After completing the encapsulation of the BIER header, the BFIR device sends the multicast packet to the next-hop BFER device, enabling the BFER device to forward the multicast packet according to the BitString carried in the BIER header.

[0082] It should be noted that the length of the first mapping bitstring mentioned above is determined according to the length of the first mapping bitstring supported by the router nodes passed through by the transmission path of the multicast packet.

[0083] It should be noted that the length of the first mapping bitstring supported by each is exchanged with other router nodes within the domain through a routing protocol.

[0084] It should be noted that the routing protocol can be protocols such as OSPF (Open Shortest Path First), IS-IS (Intermediate System to Intermediate System), BGP (Border Gateway Protocol), RIFT (Routing in Fat Trees), or BABEL. By using the routing protocol to exchange the length of the first mapping bitstring supported by each with other router nodes within the domain, the BFI R device can select the optimal encapsulation form, thereby maximizing the number of users accommodated and realizing the transmission of traffic.

[0085] Exemplarily, the specific way of advertisement can be carried out through protocol extensions of BGP, IS-IS, OSPF, PIFT, or BABEL. Taking the BGP protocol as an example, RFC8556 defines the advertisement format of BIER PTA (PMSI (Provider-Multicast Service Interfaces) Tunnel Attribute), as Figure 5 shown. When advertising the length of the first mapping bitstring, it can be advertised according to the newly defined format as Figure 6 shown. In the flag, a new flag bit M is defined. When this flag bit is set to 1, it indicates the advertisement of the length of the first mapping bitstring carried by this PTA. At the end of the PTA, an M-flow-mapping field is added to indicate the advertisement of the length of the first mapping bitstring. This field can be defined such that the least significant bit represents the length of the first mapping bitstring supporting 64 bits, the second least significant bit from the least significant bit represents the length of the first mapping bitstring supporting 128 bits, the third least significant bit from the least significant bit represents the length of the first mapping bitstring supporting 192 bits, and so on.

[0086] It should be noted that after the BFIR device node receives the support status of the first mapping bit string length announced by other routing nodes in the network, it will select the optimal method for processing. For example, if all routing nodes in the network support a 64-bit first mapping bit string length, and some routing nodes can also support a 128-bit or 192-bit first mapping bit string length, then the 64-bit first mapping bit string length supported by each routing node is selected for encapsulating multicast packets.

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

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

[0089] Step S160: Receive the length of the first mapping bit string supported by other router nodes within the domain issued by the controller; or, receive the first mapping bit string length information associated with the multicast packet, where 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 packet, and the first mapping bit string length information is determined by the controller according to the length of the first mapping bit string supported by the router nodes included in the transmission path of the multicast packet.

[0090] Exemplarily, first, report to the controller the length of the first mapping bit string supported by this node; then, receive the length of the first mapping bit string supported by other router nodes within the domain issued by the controller; or receive the first mapping bit string length information associated with the multicast packet, and according to the first mapping bit string length information, indicate the length of the first mapping bit string in the BIER header of the multicast packet, where the first mapping bit string length information is determined by the controller according to the length of the first mapping bit string supported by the router nodes included in the transmission path of the multicast packet. By the controller announcing the lengths of the first mapping bit strings supported by each router node, so that the BFIR device can select the optimal encapsulation form, thus, the number of users can be maximally accommodated to achieve the transmission of multicast packets.

[0091] Please refer to Figure 10 , Figure 10 which is a schematic flowchart of a packet processing method provided by another embodiment of the present application. The execution subject of this packet processing method can be Figure 1 the BRAS device in the shown implementation environment, where the BRAS device serves as a bit forwarding egress router (BFER) device. As Figure 10 shown, this packet processing method may include but is not limited to the following steps S210 - S240, and each step will be introduced in turn below:

[0092] Step S210: Receive a multicast packet. The multicast packet includes a Bit Index Explicit Replication (BIER) header, and the BIER header includes a BitString field, and the BitString field includes a first mapping bit string.

[0093] It should be noted that the BitString field further includes a second mapping bit string, where the second mapping bit string is used to map the routing information of the multicast packet. The routing information of the multicast packet includes: the destination BRAS node corresponding to the multicast packet; or, the transmission link corresponding to the multicast packet.

[0094] It should be noted that the number of BRAS devices is much smaller than that of user terminal devices. Therefore, it is not necessary to occupy a large number of bits in the BitString to represent them. Using the mapping reserved bits in the BitString to represent specific multicast packets can speed up the processing speed of BRAS devices.

[0095] Step S220: Determine the identifier of the multicast packet according to the first mapping bit string.

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

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

[0098] Exemplarily, in a large-scale user scenario, the number of destination address information far exceeds the number of mapping reserved bits. Therefore, in the embodiments of the present application, by combining the first mapping bit string and the third mapping bit string, the identifier of the multicast packet is jointly determined, and the routing information of the multicast packet is determined by the second mapping bit string, so that the BIER header can be applicable to the scenario of ultra-large-scale users, expanding the number of users that can be accommodated.

[0099] Exemplarily, as Figure 2 shown, Figure 2 is a schematic diagram of the encapsulation format of the BIER header provided by the related art. For example, when the length of the BitString is 256 bits, the first 64 bits of it are used to represent the mapping reserved bits of the multicast packet, that is, the first mapping bit string, as Figure 3As shown, 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 mapping reserved bits of the 64-bit multicast packet can correspond to 64 multicast packets. However, in the current large-scale application scenarios, the number of multicast packets 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 packet is mapped in the way of 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 packet is jointly determined by combining the first mapping bit string and the third mapping bit string, and the routing information of the multicast packet is determined by the second mapping bit string, so that the BIER header can be applicable to the scenario of ultra-large-scale users, expanding the number of users that can be accommodated.

[0100] Step S230, determine the destination user node according to the identifier of the multicast packet;

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

[0102] Step S231a, according to the identifier of the multicast packet, look up the destination address information corresponding to the identifier in the preset multicast flow mapping table;

[0103] Step S232a, determine the destination user node according to the destination address information.

[0104] Exemplarily, first, determine the identifier of the multicast packet according to the first mapping bit string and the third mapping bit string; then, according to the identifier of the multicast packet, look up the destination address information corresponding to the identifier in the preset multicast flow mapping table; finally, determine the destination user node according to the destination address information. Therefore, in the embodiment of the present application, the identifier of the multicast packet is jointly determined by combining the first mapping bit string and the third mapping bit string, and the routing information of the multicast packet is determined by the first mapping bit string, so that the BIER header can be applicable to the scenario of ultra-large-scale users, expanding the number of users that can be accommodated.

[0105] It can be understood that, in order to ensure the consistency of the multicast packet, the multicast flow mapping tables of the BFIR device and the BFER device are the same, and the multicast flow mapping table can be obtained from the controller or from the bit forwarding ingress router BFIR node.

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

[0107] Step S250, interact with other router nodes in the domain through the routing protocol to exchange the lengths of the first mapping bit strings supported by each other;

[0108] Or,

[0109] Step S260, report to the controller the length of the first mapping bit string supported by this node.

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

[0111] 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. By using the routing protocol to exchange the lengths of the first mapping bit strings supported by each other with other router nodes in the domain, the BFIR device can select the optimal encapsulation form, so as to maximize the number of users accommodated and achieve the transmission of multicast packets.

[0112] It should be noted that the length of the first mapping bit string supported by this node can be reported to the controller, so that the BFIR device can select the optimal encapsulation form, so as to maximize the number of users accommodated and achieve the transmission of multicast packets.

[0113] Step S240, forward the multicast packet to the destination user node.

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

[0115] Exemplarily, after the multicast packet is encapsulated in the BIER header, it is forwarded through each routing node in the network. When it arrives at the BFER device, the BFER device checks the first mapping bit string and the third mapping bit string in the BitString field to obtain the identifier of the multicast packet, and looks up the address information of the corresponding multicast packet in the preset multicast flow mapping table according to the identifier of the multicast packet to determine the destination user node. Then, after removing the BIER header, the BFER device directly copies the multicast packet to each destination user node to complete the forwarding of the multicast packet.

[0116] For the case where forwarding according to a specified path is required in a network, the 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 represent the transmission link BP (Bit-Position) passed through, that is, to represent the routing information of the multicast packet, and each bit corresponds to one 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 packet, and the remaining bits in the BitString field are used to represent the transmission link BP.

[0117] Example 1:

[0118] Combined with Figure 1 the implementation environment shown, the BRAS device pre-establishes the correspondence between the multicast packet and the user terminal through BGP (Border Gateway Protocol), or MLD (Multicast Listener Discovery), or PIM (Protocol Independent Multicast) messages sent by the user terminal. If there are ten thousand users who need to receive a multicast packet on a certain BARS device in the metropolitan area network, then the BRAS device will establish an association table between the multicast packet and these ten thousand users.

[0119] As Figure 2 shown, Figure 2 is a schematic diagram of the encapsulation format of the BIER header provided by the related technology. For example, when the length of the BitString is 256 bits, its first 64 bits are used to represent the mapping reserved bits of the multicast packet, that is, the first mapping bit string. As Figure 3 shown, the following 192 bits of the BitString field are used to represent the BFER device, that is, the following 192 bits are the second mapping bit string; among them, the 64-bit mapping reserved bits of the multicast packet can correspond to 64 multicast packets. However, in the current large-scale application scenarios, the number of multicast packets 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 packet is mapped in the way of combining the first mapping bit string and the third mapping bit string.

[0120] It should be noted that the length of the mapping reserved bit of the multicast packet can be adjusted according to the actual situation, that is, the length of the first mapping bit string can be adjusted according to the actual situation. For example, the length of the mapping reserved bit of the multicast packet 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 latter 128 bits are the second mapping bit string.

[0121] It can be understood that, assuming there are 2,000 multicast packets, the first 64 bits of the BitString field are used as the first mapping bit string of the multicast packet and combined with the Entropy field to represent it. That is, the identifier of the multicast packet is mapped in the way of combining the first mapping bit string and the third mapping bit string. Assuming the identifier of the multicast packet 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 the identifier of the multicast packet 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 the identifier of the multicast packet 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.

[0122] It can be understood that, assuming that one million user terminal devices need to receive this multicast packet, these one million user terminal devices are distributed on 50 BFER devices, that is, on 50 BRAS devices. Then, the routing information of the multicast packet is correspondingly filled into the latter 192 bits of the BitString, that is, the second mapping bit string. Among them, the routing information of the multicast packet includes the destination broadband access server BRAS node corresponding to the multicast packet; or the transmission link corresponding to the multicast packet.

[0123] Therefore, after the CR1 device receives the multicast packet from the content server, it obtains the corresponding address information (S, G) or (*, G) of the multicast packet, where the address information includes at least the destination address information, and according to the address information, it looks up the identifier of the corresponding multicast packet in the preset multicast flow mapping table, as Figure 4 shown. After obtaining the identifier of the multicast packet, the identifier of the multicast packet is encapsulated in the BitString of the BIER header in the way of combining the first mapping bit string and the third mapping bit string, and the routing information of the multicast packet is filled into the second mapping bit string in the BitString.

[0124] It can be understood that, regarding the (*) in the above (*, G), it refers to the source address wildcards, which are not specifically limited in the embodiments of the present application. S is the source address, and G is the destination address information.

[0125] It is understandable that, in order to ensure the consistency of multicast packets, the multicast flow mapping tables of the BFIR device and the BFER device are the same. The multicast flow mapping table can be sent by the controller, or can be configured by the BFIR device with corresponding identifiers for the multicast packets according to the address information corresponding to the multicast packets, and constructed based on the address information and identifiers corresponding to the multicast packets. And the multicast flow 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).

[0126] After the multicast packet 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 identifier of the multicast packet, and find the corresponding address information of the multicast packet in the preset multicast flow mapping table according to the identifier of the multicast packet, so as to determine the destination user node. Then, after the BFER device removes the BIER header, it directly copies the multicast packet to each destination user node to complete the forwarding of the multicast packet.

[0127] For the case where it is necessary to forward according to a specified path in the network, the BIER-TE (Bit Index ExplicitReplication-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 represent the transmission link BP (Bit-Position) passed through, that is, to represent the routing information of the multicast packet, and each bit corresponds to one 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 packet, and the remaining bits in the BitString field are used to represent the transmission link BP.

[0128] It is understandable that the BIER-TE technology is a new SDN-based network technology that can achieve efficient traffic engineering without using traditional label and tunneling technologies. The 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 technologies, the BIER-TE technology has higher scalability and lower maintenance costs. The implementation of the 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 the number of 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.

[0129] It is understandable 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.

[0130] Therefore, compared with the related technologies where 3906 multicast packets need to be sent for these one million user BFIR devices, only 1 multicast packet needs to be sent in the embodiments of the present application, thus greatly saving the broadband occupancy in the network. And on the BFER device, the destination user nodes needed can be found according to the multicast flow mapping table to quickly replicate and send multicast packets, thereby simplifying the processing flow of the BFER device and improving the processing speed.

[0131] Example 2:

[0132] Combined with Figure 1 In the shown implementation environment, there may be inconsistent situations in the processing of the first mapping bitstring of multicast packets by routing nodes in the network. For example, some routing nodes support a 64-bit length of the first mapping bitstring of multicast packets, and some routing nodes support a 64-bit or 128-bit length of the first mapping bitstring. Since the other bits in the BitString field are used to implement BIER or BIER-TE forwarding, inconsistent processing may cause errors in the forwarding of multicast packets. Therefore, in the routing nodes in the network, that is, including CR devices, BRAS devices, and other intermediate routing node devices, the support situation of the length of their first mapping bitstring can be announced.

[0133] The specific way of advertisement can be carried out through protocol extensions of BGP, IS-IS, OSPF, PIFT or BABEL. Taking the BGP protocol as an example, RFC8556 defines the advertisement format of BIER PTA (PMSI (Provider-Multicast Service Interfaces) Tunnel Attribute). For example, Figure 5 as shown, when advertising the length of the first mapping bit string, it can be advertised with reference to the newly defined format as shown in Figure 6 In the flag, a new flag bit M is defined. When this flag bit is set to 1, it indicates the advertisement of the length of the first mapping bit string carried by this PTA; at the end of the PTA, an M-flow-mapping field is added to indicate the advertisement of the length of the first mapping bit string. This field can be defined such that the least significant bit represents the length of the first mapping bit string supporting 64 bits, the second least significant bit from the least significant bit represents the length of the first mapping bit string supporting 128 bits, the third least significant bit from the least significant bit represents the length of the first mapping bit string supporting 192 bits, and so on.

[0134] Similarly, for the IS-IS protocol, in the BIER Info Sub-TLV already defined in RFC8401, as shown in Figure 7 new advertisement of the length of the first mapping bit string can be added. The format of the newly added Sub-sub-TLV is as shown in Figure 8 The type field is set to represent the identifier of the multicast packet in the first mapping bit string, the Length is set to the length of the M-flow-mapping field, and the content of the M-flow-mapping field is the same as the definition in the BGP protocol, used to indicate the advertisement of the length of the first mapping bit string of the multicast packet.

[0135] It can be understood that for protocols such as OSPF, RIFT, BABEL, etc., they are similar to the definitions in the IS-IS protocol introduced above.

[0136] When advertising at each routing node, when the length of the first mapping bit string only supports 64 bits for advertisement, only the least significant bit is set to 1; when the length of the first mapping bit string supports both 64 bits and 128 bits for advertisement, the lowest 2 bits are set to 1; when the length of the first mapping bit string supports 64 bits, 128 bits and 192 bits for advertisement, the lowest 3 bits are all set to 1.

[0137] After receiving the support status of the length of the first mapping bit string announced by other routing nodes in the network, the BFIR device node will select the optimal way to process it. For example, if all routing nodes in the network support a 64-bit first mapping bit string length, and some routing nodes can also support 128-bit or 192-bit first mapping bit string lengths, then the 64-bit first mapping bit string length supported by each routing node is selected for encapsulating multicast packets.

[0138] Therefore, through the new encapsulation and processing mechanism of the BIER header defined in the embodiments of the present application, and the corresponding control plane announcement mechanism, the broadband occupancy in the network can be greatly saved, and on the BFER device, the destination user node needed can be found according to the multicast flow mapping table for fast replication and sending, which simplifies the processing flow of the BFER and improves the processing speed.

[0139] The embodiments of the present application also provide an electronic device, such as Figure 11 shown, the electronic device 1400 includes:

[0140] One or more processors 1410;

[0141] A memory 1420, on which one or more programs are stored. When the one or more programs are executed by the one or more processors 1410, the one or more processors 1410 are caused to implement:

[0142] Such as the packet processing method applied to the CR device; or,

[0143] Such as the packet processing method applied to the BRAS device.

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

[0145] 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), etc. The memory 1420 can store an operating system and other application programs. When implementing the technical solutions provided in the embodiments of this specification through software or firmware, the relevant program codes are stored in the memory 1420 and are called by the processor 1410 to execute the methods of the embodiments of this application.

[0146] The processor 1410 can be implemented in ways such as 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 this application.

[0147] In some embodiments, the electronic device further includes:

[0148] An input / output interface for implementing information input and output;

[0149] A communication interface for implementing communication interaction between this device and other devices. Communication can be achieved through wired means (such as USB, network cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.);

[0150] A bus for transmitting information between various components of the device (such as the processor 1410, the memory 1420, the input / output interface, and the communication interface);

[0151] Among them, the processor 1410, the memory 1420, the input / output interface, and the communication interface can achieve communication connections with each other inside the device through the bus.

[0152] An embodiment of this application further provides a computer-readable storage medium storing computer-executable instructions, and the computer-executable instructions are used to execute and implement:

[0153] Such as a message processing method applied to a CR device; or,

[0154] Such as a message processing method applied to a BRAS device.

[0155] An embodiment of the present application further provides a computer program product, including a computer program or computer instructions, which are stored in a computer-readable storage medium. The processor of the 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 executes and implements:

[0156] For example, a message processing method applied to a CR device; or,

[0157] For example, a message processing method applied to a BRAS device.

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

[0159] Those of ordinary skill in the art can understand that all or part of the processes in the methods of the above embodiments can be completed by instructing 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 methods. Among them, any reference to a memory, storage, database, or other medium used in the embodiments provided by the present application can include non-volatile and / or volatile memories. Non-volatile memories can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memories can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in many forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), 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), etc.

[0160] Those of ordinary skill in the art will understand that all or some of the steps and systems disclosed above can be implemented as software, firmware, hardware, and their appropriate combinations. Some or all of the 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 as hardware, or as an integrated circuit, such as an application-specific integrated circuit. Such software can be distributed on a computer-readable medium, which can include a computer storage medium (or non-transitory medium) and a communication medium (or transitory medium). As is well known to those of ordinary skill in the art, the term computer storage medium includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information, such as computer-readable instructions, data structures, program modules, or other data. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technologies, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store the desired information and can be accessed by a computer. In addition, it is well known to those of ordinary skill in the art that communication media typically contain computer-readable instructions, data structures, program modules, or other data in a modulated data signal such as a carrier wave or other transmission mechanism, and can include any information delivery medium.

[0161] The above has illustrated some embodiments of the present application with reference to the accompanying drawings, and thus does not limit the scope of the rights of the present invention. Any modifications, equivalent replacements, and improvements made by those skilled in the art without departing from the scope and essence of the present invention shall fall within the scope of the rights of the present application.

Claims

1. A method for processing a message, the method comprises: encapsulating a bit-index explicit replication (BIER) header for a multicast message to obtain an encapsulated multicast message, wherein the BIER header includes a bit string (BitString) field, and the BitString field includes a first mapping bit string for mapping an identifier of the multicast message; sending the encapsulated multicast message.

2. The method according to claim 1, wherein, the BitString field further includes a second mapping bit string for mapping routing information of the multicast message, and the routing information of the multicast message includes: a destination broadband remote access server (BRAS) node corresponding to the multicast message; or, a transmission link corresponding to the multicast message.

3. The method according to claim 1, wherein, the BIER header further includes a third mapping bit string for jointly mapping the identifier of the multicast message 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 BIER header for the multicast message, the method further includes: obtaining address information corresponding to the multicast message, where the address information at least includes destination address information; searching for the identifier of the corresponding multicast message in a preset multicast flow mapping table according to the address information.

6. The method according to claim 5, wherein, the method further includes: receiving the multicast flow mapping table sent by a controller, where the multicast flow mapping table includes the identifier and address information corresponding to the multicast message; or, configuring a corresponding identifier for the multicast message according to the address information corresponding to the multicast message, constructing a multicast flow mapping table according to the address information and identifier corresponding to the multicast message, and sending the multicast flow mapping table to a 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 length of the first mapping bit string supported by a router node through which the transmission path of the multicast message passes.

8. The method according to claim 7, wherein, the method further includes: interacting with other router nodes in the domain through a routing protocol to exchange the lengths of the first mapping bit strings supported by each other.

9. The method according to claim 7, wherein, the method further includes: reporting the length of the first mapping bit string supported by the present node to a controller. Receive the length of the first mapping bit string supported by other router nodes within the domain sent by the controller; or, receive the first mapping bit string length information associated with the multicast packet sent by the controller, where 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 packet, and the first mapping bit string length information is determined by the controller according to the length of the first mapping bit string supported by the router nodes included in the transmission path of the multicast packet.

10. A method for processing a packet, the method comprises: Receiving a multicast packet, where the multicast packet includes a Bit Index Explicit Replication (BIER) header, the BIER header includes a Bit String field, and the Bit String field includes a first mapping bit string; Determining an identifier of the multicast packet according to the first mapping bit string; Determining a destination user node according to the identifier of the multicast packet; Forwarding the multicast packet to the destination user node.

11. The method according to claim 10, wherein, The Bit String field further includes a second mapping bit string, and the second mapping bit string is used to map the routing information of the multicast packet, and the routing information of the multicast packet includes: The destination BRAS node corresponding to the multicast packet; or, The transmission link corresponding to the multicast packet.

12. The method according to claim 10, wherein, The BIER header further includes a third mapping bit string, and determining the identifier of the multicast packet according to the first mapping bit string includes: Determining the identifier of the multicast packet 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, Determining the destination user node according to the identifier of the multicast packet includes: Looking up, according to the identifier of the multicast packet, destination address information corresponding to the identifier in a preset multicast flow mapping table; Determining the destination user node according to the destination address information.

15. The method according to claim 14, wherein, The multicast flow mapping table is obtained by receiving from a controller or a Bit Forwarding Ingress Router (BFIR) node.

16. The method according to claim 10, wherein, The method further includes: Interacting with other router nodes within the domain through a routing protocol to exchange the lengths of the first mapping bit strings supported by each other; or, Reporting the length of the first mapping bit string supported by the present node to the controller.

17. An electronic device, comprises: One or more processors; A memory, on which one or more programs are stored, and when the one or more programs are executed by the one or more processors, the one or more processors are caused to implement: The packet processing method according to any one of claims 1-9; or, The packet processing method according to any one of claims 10-16.

18. A computer-readable storage medium having a computer program stored thereon, and when the program is executed by a processor, it realizes: The packet processing method according to any one of claims 1-9; Or, The packet processing method according to any one of claims 10-16.

Images