Message header processing method and device, storage medium, and electronic device

Abstract

An embodiment of the present invention provides a method and device for processing a message header, a storage medium, and an electronic device. The method includes: processing fields in an IPv6 message header according to fields in a BIER message header explicitly copied by bit index in at least one of the following ways: using the BIER message header explicitly copied by bit index as the type of a routing extension header of the IPv6 message header, and processing the remaining segments Segments Left field in the IPv6 message header in a predefined manner; using the BIER message header explicitly copied by bit index as the type of other extension headers of the IPv6 message header, including as a new option in a Hop‑by‑Hop extension header; filling the source address Source Address field of the IPv6 message header with the bit forwarding router routing prefix BFR‑Prefix of the BIER message header explicitly copied by bit index; embedding the bit index forwarding table index BIFT‑ID field in the BIER message header explicitly copied by bit index into the target field of the IPv6 message header, thereby solving the problem in the related art that optimization cannot be effectively implemented in the process of combining and encapsulating BIER messages and IPv6 messages.

Description

Technical Field

[0001] The embodiments of the present invention relate to the field of communications, and in particular, to a method and device for processing a message header, a storage medium, and an electronic device. Background Art

[0002] Internet Protocol Version 6 (IPv6) is the next generation IP protocol designed by the Internet Engineering Task Force (IETF) to replace IPv4. The use of IPv6 can not only solve the problem of the number of network address resources, but also solve the obstacles for various access devices to connect to the Internet.

[0003] Bit Indexed Explicit Replication (BIER) (RFC8279) is a new type of multicast data forwarding technology, which represents the nodes at the edge of the network with only one bit. The multicast traffic is transmitted in the intermediate network, and 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 nodes route according to the bits to ensure that the traffic can be sent to all destination nodes. The intermediate node forwarding device first uses routing protocols, such as the Open Shortest Path First (OSPF) protocol in the three-layer network and the Intermediate System-to-Intermediate System (ISIS) protocol, to form a Bit Index Forwarding Table (BIFT) table for guiding BI ER forwarding. When receiving traffic encapsulated with a BIER header, it completes the forwarding of the message to the destination node based on BIFT. BIER, a data plane forwarding technology, eliminates the delay in establishing a multicast tree because there is no problem with establishing a multicast tree. When link or node problems occur in the network, the convergence speed is the same as the OSPF or ISIS protocol, which greatly reduces the delay compared to the original multicast tree reconstruction.

[0004] When transmitting, BIER technology only needs to encapsulate a certain multicast traffic in a BIER message as a payload. For the ingress device BFIR (Bit-Forwarding Ingress Router) of the BIER domain, it needs to know which BIER domain egress devices BFERs (Bit-Forwarding Egress Routers) need this multicast traffic, so that after BFER receives this multicast traffic, it can forward it to the multicast receivers outside the BIER domain that need to receive this traffic. BIER technology can be directly encapsulated in Ethernet messages for transmission (protocol number 0xAB37). When some nodes cannot support direct identification of Ethernet BIER messages, if Ethernet messages are still used for transmission, the nodes that cannot correctly identify the message will become black holes and discard the messages.

[0005] Regarding the problem of how to optimize the process of combining and encapsulating BIER messages and IPv6 messages in related technologies, no effective solution has been proposed yet. Summary of the invention

[0006] The embodiments of the present invention provide a method and device for processing a message header, a storage medium, and an electronic device, so as to at least solve the problem that the related art has not yet provided a technical solution on how to optimize the process of combining and encapsulating BIER messages and IPv6 messages.

[0007] According to one embodiment of the present invention, a method for processing a message header is provided, comprising: processing fields in an IPv6 message header according to fields in a BIER message header explicitly copied by bit index in at least one of the following ways: using the BIER message header explicitly copied by bit index as the type of a routing extension header of an IPv6 message header, and processing the remaining segments Segments Left field in the IPv6 message header in a predefined manner; using the BIER message header explicitly copied by bit index as the type of other extension headers of an IPv6 message header, wherein the types of other extension headers include options in a Hop-by-Hop extension header; filling in the source address Source Address field of the IPv6 message header with the bit forwarding router routing prefix BFR-Prefix of the BIER message header explicitly copied by bit index; and embedding the bit index forwarding table index BIFT-ID field in the BIER message header explicitly copied by bit index into the target field of the IPv6 message header.

[0008] In an exemplary embodiment, the remaining segments SegmentsLeft field in the IPv6 message header is processed in a predefined manner, including at least one of the following: setting the remaining segments Segments Left field to a target value so that all nodes ignore the processing of the remaining segments Segments Left field; setting the remaining segments Segments Left field value of the bit forwarding entry router BFIR to 255, and when the intermediate node forwards the message hop by hop, the field value is decremented by 1, and when the field value is 0, it indicates that a loop occurs in the message forwarding process; setting the remaining segments Segments Left field value of the entry node of the bit forwarding entry router BFIR to the maximum number of hops to reach the edge device, and when the intermediate node forwards the message hop by hop, the field value is decremented by 1, and when the field value is 0, it indicates that a loop occurs in the message forwarding process; setting the remaining segments Segments Left field value of the bit forwarding entry router BFIR to 255, and when the intermediate node forwards the message hop by hop, the field value is decremented by 1, and when the field value is 0, it indicates that a loop occurs in the message forwarding process. When an IPv6 packet with a Left field value of 255 arrives at the bit forwarding egress router BFER, the number of hops that the IPv6 packet has passed is calculated based on the value of the current remaining segments Segments Left field; the remaining segments Segments Left field is set to the maximum boundary value of the boundary that the IPv6 packet is to pass through, and the field value is subtracted by 1 when passing through the boundary. When the field value is 0, it indicates that the packet has reached the maximum boundary and can no longer be forwarded to the next area.

[0009] In an exemplary embodiment, after the bit-indexed explicit copy of the BIER message header is used as the type of the routing extension header of the IPv6 message header and the remaining segments Segments Left field in the IPv6 message header is processed in a predefined manner, the method further includes: notifying each node through the control plane of its own support for the bit-indexed explicit copy of the BIER message header as the type of the routing extension header of the IPv6 message header.

[0010] In an exemplary embodiment, the method also includes: notifying each node of its own support for using the bit-indexed explicitly copied BIER message header as the type of routing extension header of the IPv6 message header in one of the following ways: notifying in TLV mode, notifying by carrying the bit-indexed explicitly copied BIER information in the internal gateway protocol IGP, or notifying by carrying the bit-indexed explicitly copied BIER information in the border gateway protocol BGP.

[0011] In an exemplary embodiment, the method also includes: setting each node's own support for explicitly copying the bit-indexed BIER message header as the type of routing extension header of the IPv6 message header under the notification of the bit-forwarding router routing prefix BFR-Prefix or the bit-forwarding router identifier BFR-ID, and announcing it in the form of sub-TLV or sub-sub-TLV.

[0012] In an exemplary embodiment, before filling the bit forwarding router routing prefix BFR-Prefix of the bit indexed explicit copy of the BIER message header into the source address Source Address field of the IPv6 message header, the method further includes: in the event that there are nodes among all nodes that cannot guarantee the delivery capability of the source address Source Address field of the IPv6 message header, announcing and collecting the delivery capability information of the source address Source Address field of the IPv6 message header of all nodes through the control plane.

[0013] In an exemplary embodiment, after filling the source address Source Address field of the IPv6 message header with the bit forwarding router routing prefix BFR-Prefix of the bit indexed explicit copy of the BIER message header, the method further includes: when it is confirmed that the protection capability of the source address Source Address field of the IPv6 message header is not supported, setting N bits of other unused fields in the IPv6 message header to 1 to indicate that the source address Source Address of the IPv6 message header needs to be protected, wherein the value of N is not less than 1.

[0014] In an exemplary embodiment, before embedding the bit indexed forwarding table index BIFT-ID field in the bit indexed explicit copy BIER message header into the destination field of the IPv6 message header, the method further includes: modifying the address in the IPv6 message to set the routable prefix of the IPv6 message in the first target number bits in the IPv6 message.

[0015] In an exemplary embodiment, after modifying the address in the IPv6 message, the method further includes: embedding the bit index forwarding table index BIFT-ID field into the destination address DA in the IPv6 message; or embedding the bit index forwarding table index BIFT-ID field into the source address SA in the IPv6 message; or filling the bit index forwarding table index BIFT-ID into the flow label Flow Label field of the IPv6 message header without changing the destination address DA and source address SA in the IPv6 message.

[0016] In an exemplary embodiment, the method further includes: moving the forwarding table entry locating operation of the bit index forwarding table index BIFT-ID in the bit index explicit copy BIER message header forward to the IPv6 message.

[0017] In an exemplary embodiment, the method further comprises: explicitly copying the function FUNCTION field of the BIER table entry lookup using a specific bit representation bit index in the IPv6 message address.

[0018] According to another embodiment of the present invention, a packet header processing device is also provided, including: a processing module, used to process the fields in the IPv6 packet header according to the fields in the bit-indexed explicitly copied BIER packet header in at least one of the following ways: using the bit-indexed explicitly copied BIER packet header as the type of the routing extension header of the IPv6 packet header, and processing the remaining segments Segments Left field in the IPv6 packet header in a predefined manner; using the bit-indexed explicitly copied BIER packet header as the type of other extension headers of the IPv6 packet header, wherein the types of the other extension headers include options in the Hop-by-Hop extension header; filling the source address Source Address field of the IPv6 packet header with the bit-indexed explicitly copied BIER packet header's bit-forwarding router routing prefix BFR-Prefix; embedding the bit-indexed explicitly copied forwarding table index BIFT-ID field in the bit-indexed explicitly copied BIER packet header into the target field of the IPv6 packet header.

[0019] In an exemplary embodiment, the above-mentioned processing module is also used to process the remaining segments Segments Left field in the IPv6 message header in a predefined manner, including at least one of the following: setting the remaining segments Segments Left field to a target value so that all nodes ignore the processing of the remaining segments Segments Left field; setting the remaining segments Segments Left field value of the bit forwarding entry router BFIR to 255, and when the intermediate node forwards the message hop by hop, the field value is decremented by 1, and when the field value is 0, it indicates that a loop occurs in the message forwarding process; setting the remaining segments Segments Left field value of the entry node of the bit forwarding entry router BFIR to the maximum number of hops to reach the edge device, and when the intermediate node forwards the message hop by hop, the field value is decremented by 1, and when the field value is 0, it indicates that a loop occurs in the message forwarding process; setting the remaining segments Segments Left field value of the bit forwarding entry router BFIR to 255, and when the intermediate node forwards the message hop by hop, the field value is decremented by 1, and when the field value is 0, it indicates that a loop occurs in the message forwarding process; When an IPv6 packet with a Left field value of 255 arrives at the bit forwarding egress router BFER, the number of hops that the IPv6 packet has passed is calculated based on the value of the current remaining segments Segments Left field; the remaining segments Segments Left field is set to the maximum boundary value of the boundary that the IPv6 packet is to pass through, and the field value is subtracted by 1 when passing through the boundary. When the field value is 0, it indicates that the packet has reached the maximum boundary and can no longer be forwarded to the next area.

[0020] In an exemplary embodiment, the above-mentioned device also includes: a notification module, which is used to notify each node through the control plane of its own support for using the bit index explicit replication BIER message header as the type of routing extension header of the IPv6 message header.

[0021] In an exemplary embodiment, the above-mentioned notification module is also used to notify each node of its own support for using the bit-indexed explicitly copied BIER message header as the type of routing extension header of the IPv6 message header in one of the following ways: notification in TLV mode, notification by carrying the bit-indexed explicitly copied BIER information in the internal gateway protocol IGP, and notification by carrying the bit-indexed explicitly copied BIER information in the border gateway protocol BGP.

[0022] In an exemplary embodiment, the above-mentioned notification module is also used to announce in the form of sub-TLV or sub-sub-TLV under the notification of the bit forwarding router routing prefix BFR-Prefix or the bit forwarding router identifier BFR-ID, when each node's own support for explicitly copying the BIER message header with a bit index as the type of routing extension header of the IPv6 message header is set.

[0023] In an exemplary embodiment, the above-mentioned device also includes: a guarantee module, which is used to announce and collect information on the delivery capability of the source address Source Address field of the IPv6 packet header of all nodes through the control plane when there is a node among all nodes that cannot guarantee the delivery capability of the source address Source Address field of the IPv6 packet header.

[0024] In an exemplary embodiment, the above-mentioned device also includes: a determination module, which is used to set N bits of other unused fields in the IPv6 message header to 1 when it is confirmed that the security capability of the source address Source Address field of the IPv6 message header is not supported, to indicate that the source address Source Address of the IPv6 message header needs to be secured, wherein the value of N is not less than 1.

[0025] In an exemplary embodiment, the apparatus further comprises: a transformation module, configured to transform the address in the IPv6 message so as to set the routable prefix of the IPv6 message in the first target number of bits in the IPv6 message.

[0026] In an exemplary embodiment, the above-mentioned transformation module is also used to embed the bit-indexed forwarding table index BIFT-ID field into the destination address DA in the IPv6 message; or embed the bit-indexed forwarding table index BIFT-ID field into the source address SA in the IPv6 message; or fill the bit-indexed forwarding table index BIFT-ID into the flow label Flow Label field of the IPv6 message header without changing the destination address DA and source address SA in the IPv6 message.

[0027] In an exemplary embodiment, the above-mentioned transformation module is also used to move the forwarding table entry locating operation of the bit index forwarding table index BIFT-ID in the bit index explicit copy BIER message header forward to the IPv6 message.

[0028] In an exemplary embodiment, the above-mentioned transformation module is also used to explicitly copy the function FUNCTION field of the BIER table entry search using a specific bit representation bit index in the IPv6 message address.

[0029] According to yet another embodiment of the present invention, a computer-readable storage medium is provided, in which a computer program is stored, wherein the computer program is configured to execute the steps of any one of the above method embodiments when run.

[0030] According to yet another embodiment of the present invention, there is provided an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to execute the steps in any one of the above method embodiments.

[0031] Through the present invention, the bit index explicitly copied BIER message and IPv6 message can be processed as follows: the fields in the IPv6 message header are processed according to the fields in the bit index explicitly copied BIER message header in at least one of the following ways: the bit index explicitly copied BIER message header is used as the type of the routing extension header of the IPv6 message header, and the remaining segments Segments Left field in the IPv6 message header is processed in a predefined manner; the bit index explicitly copied BIER message header is used as the type of other extension headers of the IPv6 message header, wherein the type of the other extension header includes a new option in the Hop-by-Hop extension header; the source address Source in the IPv6 message header The bit forwarding router routing prefix BFR-Prefix of the bit index explicitly copied BIER message header is filled in the Address field; the bit index forwarding table index BIFT-ID field in the bit index explicitly copied BIER message header is embedded in the target field of the IPv6 message header, thereby realizing the combination of BIER message encapsulation and IPv6 message encapsulation, optimizing the message encapsulation and processing flow without affecting the function at all, and improving the forwarding efficiency. The above technical solution solves the problem that the related technology fails to effectively realize the optimization in the process of combining and encapsulating BIER message and IPv6 message. BRIEF DESCRIPTION OF THE DRAWINGS

[0032] Figure 1 It is a hardware structure block diagram of a computer terminal of a method for processing a message header according to an embodiment of the present invention;

[0033] Figure 2 is a flowchart of a method for processing a message header according to an embodiment of the present invention;

[0034] Figure 3 It is a schematic diagram of explicitly copying a BIER message as a Routing extension header of IPv6 according to a bit index of an embodiment of the present invention;

[0035] Figure 4 is a schematic diagram of a TLV according to an embodiment of the present invention;

[0036] Figure 5 It is a schematic diagram of a message transmission mechanism applied in a BIER domain according to an embodiment of the present invention;

[0037] Figure 6 It is a structural schematic diagram of a packet header processing device according to an embodiment of the present invention. DETAILED DESCRIPTION

[0038] Hereinafter, embodiments of the present invention will be described in detail with reference to the accompanying drawings and in combination with the embodiments.

[0039] It should be noted that the terms "first", "second", etc. in the specification and claims of the present invention and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence.

[0040] The method embodiments provided in the embodiments of the present application can be executed in a computer terminal or a similar computing device. Taking running on a computer terminal as an example, Figure 1 FIG. 1 is a hardware structure block diagram of a computer terminal of a method for processing a message header according to an embodiment of the present invention. Figure 1 As shown, the computer terminal may include one or more ( Figure 1 Only one is shown in the figure) a processor 102 (the processor 102 may include but is not limited to a processing device such as a microprocessor MCU or a programmable logic device FPGA) and a memory 104 for storing data, wherein the above-mentioned computer terminal may also include a transmission device 106 and an input / output device 108 for communication functions. It can be understood by those skilled in the art that Figure 1 The structure shown is only for illustration and does not limit the structure of the above-mentioned computer terminal. Figure 1 More or fewer components as shown, or with Figure 1 Different configurations are shown.

[0041] The memory 104 can be used to store computer programs, for example, software programs and modules of application software, such as the computer program corresponding to the method for processing the message header in the embodiment of the present invention. The processor 102 executes various functional applications and data processing by running the computer program stored in the memory 104, that is, to implement the above method. The memory 104 may include a high-speed random access memory, and may also include a non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some examples, the memory 104 may further include a memory remotely arranged relative to the processor 102, and these remote memories may be connected to the computer terminal 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.

[0042] The transmission device 106 is used to receive or send data via a network. The specific example of the above network may include a wireless network provided by a communication provider of a computer terminal. In one example, the transmission device 106 includes a network adapter (Network Interface Controller, referred to as NIC), which can be connected to other network devices through a base station so as to communicate with the Internet. In one example, the transmission device 106 can be a radio frequency (RF) module, which is used to communicate with the Internet wirelessly.

[0043] Among the related technologies, multicast technology is being used more and more on the Internet, such as multi-party conferencing, distance education, telemedicine, webcasting, etc. With the deployment of IPv6, it has become necessary for these multicast data packets to traverse the IPv6 network. For some nodes that cannot directly support the processing of bit-indexed explicit replication BIER Ethernet encapsulation messages, encapsulating bit-indexed explicit replication BIER in the IPv6 header has become a must-have function.

[0044] The following embodiment of the present invention proposes a new message encapsulation method, which combines the bit index explicit replication BIER encapsulation with IPv6 encapsulation and optimizes it. Combined with the capability notification of the control plane, it optimizes the encapsulation and processing flow of the message and improves the forwarding efficiency without affecting the function at all.

[0045] In this embodiment, a method for processing a message header running on the above-mentioned computer terminal is provided. Figure 2 is a flow chart of a method for processing a message header according to an embodiment of the present invention, such as Figure 2 As shown, the process includes the following steps:

[0046] Step S202, processing the fields in the IPv6 message header by explicitly copying the fields in the BIER message header according to the bit index in at least one of the following ways:

[0047] The bit index explicitly copies the BIER message header as the type of the routing extension header of the IPv6 message header, and processes the remaining segments Segments Left field in the IPv6 message header in a predefined manner;

[0048] Explicitly copy the BIER message header with a bit index as the type of other extension headers of the IPv6 message header, wherein the type of the other extension header includes options in a Hop-by-Hop extension header;

[0049] Fill in the source address Source Address field of the IPv6 message header with the bit forwarding router routing prefix BFR-Prefix of the BIER message header that is explicitly copied by the bit index;

[0050] The bit index explicit copy of the bit index forwarding table index BIFT-ID field in the BIER message header is embedded into the target field of the IPv6 message header.

[0051] Through the present invention, the bit index explicitly copied BIER message and IPv6 message can be processed as follows: the fields in the IPv6 message header are processed according to the fields in the bit index explicitly copied BIER message header in at least one of the following ways: the bit index explicitly copied BIER message header is used as the type of the routing extension header of the IPv6 message header, and the remaining segments Segments Left field in the IPv6 message header is processed in a predefined manner; the bit index explicitly copied BIER message header is used as the type of other extension headers of the IPv6 message header, wherein the type of the other extension header includes a new option in the Hop-by-Hop extension header; the source address Source in the IPv6 message header The bit forwarding router routing prefix BFR-Prefix of the bit index explicitly copied BIER message header is filled in the Address field; the bit index forwarding table index BIFT-ID field in the bit index explicitly copied BIER message header is embedded in the target field of the IPv6 message header, thereby realizing the combination of BIER message encapsulation and IPv6 message encapsulation, optimizing the message encapsulation and processing flow without affecting the function at all, and improving the forwarding efficiency. The above technical solution solves the problem that the related technology fails to effectively realize the optimization in the process of combining and encapsulating BIER message and IPv6 message.

[0052] The execution subject of the above steps may be a base station, a terminal, etc., but is not limited thereto.

[0053] Apply the technical solution of step S202 above, such as Figure 3 As shown, in this case, the Routing Type can be directly set to BIER.

[0054] In an exemplary embodiment, the remaining segments SegmentsLeft field in the IPv6 message header is processed in a predefined manner, including at least one of the following: setting the remaining segments Segments Left field to a target value so that all nodes ignore the processing of the remaining segments Segments Left field; setting the remaining segments Segments Left field value of the bit forwarding entry router BFIR to 255, and when the intermediate node forwards the message hop by hop, the field value is decremented by 1, and when the field value is 0, it indicates that a loop occurs in the message forwarding process; setting the remaining segments Segments Left field value of the entry node of the bit forwarding entry router BFIR to the maximum number of hops to reach the edge device, and when the intermediate node forwards the message hop by hop, the field value is decremented by 1, and when the field value is 0, it indicates that a loop occurs in the message forwarding process; setting the remaining segments Segments Left field value of the bit forwarding entry router BFIR to 255, and when the intermediate node forwards the message hop by hop, the field value is decremented by 1, and when the field value is 0, it indicates that a loop occurs in the message forwarding process. When an IPv6 packet with a Left field value of 255 arrives at the bit forwarding egress router BFER, the number of hops that the IPv6 packet has passed is calculated based on the value of the current remaining segments Segments Left field; the remaining segments Segments Left field is set to the maximum boundary value of the boundary that the IPv6 packet is to pass through, and the field value is subtracted by 1 when passing through the boundary. When the field value is 0, it indicates that the packet has reached the maximum boundary and can no longer be forwarded to the next area.

[0055] It is understandable that when the BIER message header is used as a new type of routing extension header of the IPv6 message header, it is necessary to select different predefined methods to process the Segments Left field in the IPv6 message header according to functional requirements.

[0056] Optionally, the target value of the Segments Left field can be set to 0 or 255 or any other value, so that all nodes ignore the processing of this field. Since this method is the simplest, it can also be used as the default support method for all nodes.

[0057] Optionally, the ingress node BFIR sets the value of the Segments Left field to 255, or sets the value of the Segments Left field to the estimated maximum number of hops to reach the edge device, and then decrements the value of the field by 1 when forwarding hop by hop at the intermediate node. When the value of the field decreases to 0, it indicates that a loop may occur in the forwarding process of the message, and an alarm prompt or abnormal log record is required, and the message will no longer be forwarded, thereby preventing the message from being forwarded out of a domain range that should not be forwarded.

[0058] Optionally, the ingress node BFIR sets the value of the remaining segments Segments Left field to 255, and the intermediate node decrements it by 1 when forwarding hop by hop. When the message reaches the egress node BFER, the number of hops the message has passed can be calculated based on the current Segments Left value. The number of hops can be recorded and reported to the controller or other modules for statistical purposes.

[0059] Optionally, since the message may pass through multiple IGP domains or some BIER internal boundaries, it is possible to estimate how many such boundaries it will pass through and fill the boundary value in the remaining segments Segments Left field value. At this time, the remaining segments Segments Left field value is only forwarded to other IGP domains or other BIER internal boundaries on BFER. The field value is reduced by 1. If forwarding occurs within a single domain, the field value is not processed. When the field value is 0, it indicates that the message has reached the maximum boundary and can no longer be forwarded to the next area.

[0060] In an exemplary embodiment, the bit-indexed explicitly copied BIER message header is used as the type of other extension headers of the IPv6 message header, wherein the type of other extension headers includes options in a Hop-by-Hop extension header.

[0061] In short, in order to improve the application effect of the bit index explicit copy BIER header in the IPv6 header, options about the BIER type can also be added to other extension headers of the IPv6 header.

[0062] In an exemplary embodiment, after using the bit-indexed explicitly copied BIER message header as the type of the routing extension header of the IPv6 message header and processing the remaining segments Segments Left field in the IPv6 message header in a predefined manner, the method further includes: notifying each node through the control plane of its own support for using the bit-indexed explicitly copied BIER message header as the type of the routing extension header of the IPv6 message header, that is, in an embodiment of the present invention, after using the BIER message header as a new type of IPv6 routing Routing extension header, each node is notified through the control plane of its own support for the newly added BIER type of the Routing extension header.

[0063] In an exemplary embodiment, the method also includes: notifying each node of its own support for using the bit-indexed explicitly copied BIER message header as the type of routing extension header of the IPv6 message header in one of the following ways: notifying in TLV mode, notifying by carrying the bit-indexed explicitly copied BIER information in the internal gateway protocol IGP, or notifying by carrying the bit-indexed explicitly copied BIER information in the border gateway protocol BGP.

[0064] In an exemplary embodiment, the method also includes: setting each node's own support for explicitly copying the bit-indexed BIER message header as the type of routing extension header of the IPv6 message header under the notification of the bit-forwarding router routing prefix BFR-Prefix or the bit-forwarding router identifier BFR-ID, and announcing it in the form of sub-TLV or sub-sub-TLV.

[0065] For example, the control plane notification method includes each node notifying its support for the newly added BIER type of the Routing extension header. It can be notified in the form of TLV, following the BIER information in IGP or BGP, that is, placed under the notification of BFR-Prefix or BFR-id, and notified in the form of sub-TLV or sub-sub-TLV. When notifying support for the SegmentsLeft processing method, if all nodes only support a certain Segments Left field processing method, no further notification is required. However, if a node supports different Segments Left field processing methods, a notification is required to distinguish them. The notification method can also be in the form of TLV.

[0066] When all nodes support BIER, the source address Source Address (SA) and destination address Destination Address (DA) fields in the IPv6 message header may also be filled with the local subnet Link-local address, or when passing through certain nodes that do not support BIER, an IPv6 tunnel will be introduced so that nodes that do not support BIER processing do not need to see and process the BIER message. At this time, the SA and DA operations on the outer IPv6 header may cause the loss of the original SA and DA information. This will cause the BFR-prefix information of the BFIR to be lost. Therefore, in order to ensure that this information is not lost, some specific measures need to be taken to ensure it, including:

[0067] In an exemplary embodiment, before filling the bit forwarding router routing prefix BFR-Prefix of the bit indexed explicit copy of the BIER message header into the source address Source Address field of the IPv6 message header, the method further includes: in the event that there are nodes among all nodes that cannot guarantee the delivery capability of the source address Source Address field of the IPv6 message header, announcing and collecting the delivery capability information of the source address Source Address field of the IPv6 message header of all nodes through the control plane.

[0068] In an exemplary embodiment, after filling the source address Source Address field of the IPv6 message header with the bit forwarding router routing prefix BFR-Prefix of the bit indexed explicit copy of the BIER message header, the method further includes: when it is confirmed that the protection capability of the source address Source Address field of the IPv6 message header is not supported, setting N bits of other unused fields in the IPv6 message header to 1 to indicate that the source address Source Address of the IPv6 message header needs to be protected, wherein the value of N is not less than 1.

[0069] For example, not all nodes in the domain can support the protection capability of the source address field of the IPv6 packet header. In this case, other unused fields in the IPv6 header, such as the Traffic Class field, or the reserved fields in the BIER header, can be used. By setting one or several bits in these fields to 1, it is indicated that the source address field of the IPv6 packet header needs to be protected.

[0070] In an exemplary embodiment, before embedding the bit indexed forwarding table index BIFT-ID field in the bit indexed explicit copy BIER message header into the destination field of the IPv6 message header, the method further includes: modifying the address in the IPv6 message to set the routable prefix of the IPv6 message in the first target number bits in the IPv6 message.

[0071] It should be noted that the routable prefix of the IPv6 message is set in the first target number of bits in the IPv6 message, wherein the target number of bits can be 64 bits or 96 bits, and the present invention does not impose too many restrictions on this.

[0072] Optionally, the IPv6 address can be divided into two parts: prefix + BIFT-ID. The reachable prefix in the domain is placed in the first 96 bits, that is, when used to encapsulate the message, the IPv6 routable prefix is ​​placed in the first 96 bits, which can support the situation where the prefix can be up to 96 bits; the remaining 32 bits are used to store the BIFT-ID value. Of course, the first 108 bits can also be used to store the reachable prefix, and the last 20 bits can be used to store the BIFT-ID value, which can support the prefix to be up to 108 bits.

[0073] Optionally, the IPv6 address is divided into three parts according to the format LOC:FUNCT:ARG defined in draft-ietf-spring-srv6-network-programming. In addition to the LOC representing the prefix, a new FUNCT is defined as the BIERfunction, and the BIFT-ID is filled in the position of ARG. This method is suitable for the case where the BFR-Prefix length of the node is shorter, for example, the LOC part is 64 bits, the FUNC is 32 bits, and the ARG part is 32 bits.

[0074] In an exemplary embodiment, after the address in the IPv6 message is modified, the method also includes: embedding the bit index forwarding table index BIFT-ID field into the destination address DA in the IPv6 message; or embedding the bit index forwarding table index BIFT-ID field into the source address SA in the IPv6 message; or filling the bit index forwarding table index BIFT-ID into the flow label Flow Label field of the IPv6 message header without changing the destination address DA and source address SA in the IPv6 message, that is, filling the BIFT-ID into the Flow Label field in the IPv6 header without changing the SA and DA. This method is suitable for scenarios where BFR-Prefix must be represented by a 128-bit address.

[0075] That is to say, when the IPv6 address is divided into two parts of prefix + BIFT-ID, when the BIFT-ID field is embedded in the destination address DA in the IPv6 message, the IPv6 routable prefix of the next hop will be filled in the first 96 bits of DA and the BIFT-ID of the next hop will be filled in the last 32 bits of DA; when the BIFT-ID field is embedded in the source address SA in the IPv6 message, DA will fill in the IPv6 reachable routable prefix of the next hop as usual, the first 96 bits of the prefix of SA will not be modified, and only the last 32 bits will be modified to the BIFT-ID of the next hop.

[0076] In addition, according to the format LOC:FUNCT:ARG defined in draft-ietf-spring-srv6-network-programming, the IPv6 address is divided into three parts. In addition to the LOC representing the prefix, a new FUNCT is defined as the BIER function, and the BIFT-ID is filled in the ARG position. When the BIFT-ID field is embedded in the destination address DA in the IPv6 message, the LOC part of DA is filled in with the BFR-prefix of the next hop, FUNC is defined as a new function value representing BIER, and ARG is filled in with the BIFT-ID of the next hop; when the BIFT-ID field is embedded in the source address SA in the IPv6 message, the DA part is filled in with the IPv6 reachable routing prefix BFR-prefix of the next hop as usual, the LOC part of SA remains unchanged, and if the FUNCT part is not a function representing BIER, it is modified to the function value representing BIER, and the ARG part of SA is filled in with the BIFT-ID of the next hop.

[0077] It should be noted that when optimizing the use of BIFT-ID, if all nodes support the unified BFIT-ID optimization method, the control plane does not need to be specially extended. However, if not all nodes support this function, in order to avoid error handling, the capability notification process also needs to be introduced. The method can still be achieved through Figure 4The TLV method shown defines a new Type type, which is carried when following the BFR-prefix and other information announcements of BIER, that is, this information is carried when announced through IGP or BGP. In this way, nodes can understand each other's support for this function. For example, a new type of sub-TLV or sub-sub-TLV is defined to represent BIFT-ID optimization, and a lower-level sub-sub-TLV or sub-sub-sub-TLV of different Type represents different BIFT-ID optimization methods for announcement; both are announced at the same time to indicate support for BIFT-ID optimization, and can be specific to the supported methods; or only a new type of sub-TLV or sub-sub-TLV is defined to represent BIFT-ID optimization, and the carried Value directly uses 1 / 2 / 3 to represent different specific BIFT-ID optimization methods.

[0078] In an exemplary embodiment, the method further includes: moving the forwarding table entry locating operation of the bit index forwarding table index BIFT-ID in the bit index explicit copy BIER message header forward to the IPv6 message.

[0079] In an exemplary embodiment, the method further comprises: explicitly copying the function FUNCTION field of the BIER table entry lookup using a specific bit representation bit index in the IPv6 message address.

[0080] In order to better understand the processing flow of the above-mentioned message header, the above-mentioned technical solution is described below in conjunction with an optional embodiment, but it is not used to limit the technical solution of the embodiment of the present invention.

[0081] Since there are multiple ways to optimize the encapsulation of the bit-indexed explicitly replicated BIER message combined with the IPv6 message, optionally, when the bit-indexed explicitly replicated BIER message header is used as a new type of IPv6 Routing extension header, the following four optional embodiments are included:

[0082] like Figure 3 As shown, the bit index explicitly copied BIER message is used as a new type of the Routing extension header of IPv6. The specific definition is shown in the figure. The Routing extension header defines a new type value, such as 5, which represents the bit index explicitly copied BIER type. The bit index explicitly copied BIER message header is filled in the "type-specific data" of the Routing extension header. There may be many situations for the setting of the "Segments Left" field in the Routing extension header. See the description in the optional embodiment below for details.

[0083] For the following optional embodiments, in order to facilitate understanding, it is necessary to uniformly define the control plane extension, as follows:

[0084] Control plane notification process: All nodes participating in bit index explicit replication BIER forwarding need to extend the control plane and make notifications. If all nodes in the domain support bit index explicit replication BIER forwarding, then all nodes will participate in the control plane notification process:

[0085] 1. Each node announces its support for the newly added bit index explicit replication BIER type of the Routing extension header. It can be announced in the form of TLV, following the bit index explicit replication BIER information in IGP, or BGP, that is, it is placed under the notification of the bit forwarding router routing prefix BFR-Prefix or BFR-id, and announced in the form of sub-TLV or sub-sub-TLV, such as Figure 4 As shown, using type 20 or other values ​​indicates that the Routing extension header encapsulation bit index explicitly copies the BIER type.

[0086] 2. Announce the support for the remaining segment Segments Left processing method. If all nodes only support a certain remaining segment Segments Left field processing method, no further announcement is required. However, if some nodes support different remaining segment Segments Left field processing methods, announcement is required to distinguish them. There are two specific announcement methods. One is to generate a second-level TLV followed by a bit index to explicitly copy the BIER new Routing extension header type announcement TLV. The format can be similar to Figure 3 Type 1 / 2 / 3 / 4 is used to indicate different processing methods for the remaining segments Segments Left. Another notification method is to directly use the Routing extension header encapsulation bit index to explicitly copy the BIER type sub-TLV or sub-sub-TLV, and its Value value is 1 / 2 / 3 / 4 to indicate support for different processing methods for the remaining segments Segments Left.

[0087] When the bit index is explicitly copied to the BIER message header as a new type of IPv6 Routing extension header, the optional implementation example 1 (i.e., the remaining segments Segments Left processing method 1) is as follows: the remaining segments Segments Left field is set to 0 or 255 or any other value, and all nodes ignore the processing of this field. This method is the simplest, so it can also be used as the default support method for all nodes;

[0088] like Figure 3As shown, after the control plane is performed according to the above method, the data plane encapsulation and forwarding process is as follows:

[0089] When the bit forwarding ingress router BFIR receives a multicast message, it will encapsulate the external IPv6 header after the bit index explicit copy BIER message header is encapsulated according to the BFER that needs to be received. The following encapsulation principles are followed when encapsulating the external IPv6 header:

[0090] Step 1101, generate a Routing extension header representing the bit index explicit copy BIER type, set the Routing Type field in the Routing extension header to a value representing the bit index explicit copy BIER type, such as 5. Set the remaining segments Segments Left field to 0, or other values ​​such as 255.

[0091] Step 1102, set the Next Header of the Routing extension header to a value of 59 (indicating that there will be no Next Header subsequently), or explicitly copy the Proto in the BIER message header according to the bit index, find the corresponding value and set it. For example, if the Proto value in the BIER message header explicitly copied by the bit index is 4, indicating that its payload is an IPv4 message, then the Next Header value of the Routing extension header is also set to 4 (indicating IPv4); if the Proto value in the BIER message header explicitly copied by the bit index is 6, indicating that there will be an IPv6 message subsequently, then the Next Header value of the Routing extension header is set to 41 (indicating an IPv6 message).

[0092] When BFR receives the message, it processes and finds that it carries the Routing extension header. After further parsing the Routing extension header, it finds that the type is the type indicating bit index explicit replication BIER, and then processes it according to the following process:

[0093] Step 1201, perform normal processing flow on the BIER message with explicit bit index copy in the Routing extension header, search the local BIER routing table with explicit bit index copy according to the Bit String in the BIER message header and forward it, although the value of the remaining segment Segments Left is 0 or other values, this value is ignored.

[0094] When the current node is a branch node and there are multiple next hops, multiple bit-indexed explicitly replicated BIER messages are copied and generated, which are encapsulated in the bit-indexed explicitly replicated BIER type extension header of IPv6 Routing. The encapsulation method is similar to the BFIR processing of the bit forwarding ingress router.

[0095] Of course, the bit forwarding entry router BFIR may also be a branch node itself, and it will also encapsulate multiple messages according to the branch and send them.

[0096] When BFER receives a message, it processes it and finds that it carries a Routing extension header. It further parses the Routing extension header and finds that it is a bit index explicit copy BIER type based on the type. It then processes it according to the following process:

[0097] Step 1301, perform normal processing on the BIER message with bit index explicit copy in the Routing extension header. When it is found that the local node is an egress node, remove the entire outer IPv6 encapsulation, including the Routing extension header containing the bit index explicit copy of the BIER type, and then forward it to the receiver.

[0098] Furthermore, if it is found that this node is a transmitting node, that is, there is both a receiver and a next-hop device that needs to be forwarded, the message will continue to be forwarded to the next-hop node according to the BFR process.

[0099] When the bit index is explicitly copied to the BIER message header as a new type of IPv6 Routing extension header, the second embodiment (i.e., the second processing method for the remaining segments Segments Left) may be selected:

[0100] The ingress node BFIR sets the Segments Left field value to 255, or sets the Segments Left field value to the estimated maximum number of hops to reach the edge device. When the intermediate node forwards the packet hop by hop, the field value is reduced by 1. When the field value is reduced to 0, it indicates that a loop may occur during the forwarding process of the packet, and an alarm or abnormal log record is required, and the packet is no longer forwarded, thereby preventing the packet from being forwarded out of a domain range that should not be forwarded.

[0101] like Figure 3 As shown, after the control plane is performed according to the above method, the data plane encapsulation and forwarding process is as follows:

[0102] When the bit forwarding ingress router BFIR receives a multicast message, it will encapsulate the external IPv6 header after the bit index explicit copy BIER message header is encapsulated according to the BFER that needs to be received. The following encapsulation principles are followed when encapsulating the external IPv6 header:

[0103] Step 2101, generate a Routing extension header representing the bit index explicit replication BIER type, and set the Routing Type field in the Routing extension header to a value representing the bit index explicit replication BIER type, such as 5. Set the remaining segments Segments Left field to 255, or estimate the maximum hop value to be traversed, such as if it is expected to take 10 hops to reach the farthest receiver, then this value can also be set to 10.

[0104] Step 2102, setting content is the same as step 1102 in optional embodiment 1.

[0105] When BFR receives the message, it processes and finds that it carries the Routing extension header. After further parsing the Routing extension header, it finds that the type is the type indicating bit index explicit replication BIER, and then processes it according to the following process:

[0106] Step 2201, perform normal processing on the BIER message explicitly copied by the bit index in the Routing extension header, and decrement the remaining segments Segments Left by 1. When it is found that the remaining segments Segments Left is 0, it indicates that the maximum number of hops has been reached. If the local bit index explicitly copied BIER routing table is searched according to the Bit String in the BIER message header explicitly copied by the bit index and it is found that there is still a next hop to be forwarded, it cannot be forwarded anymore and an alarm needs to be processed or the situation needs to be reported to the controller. If the remaining segments Segments Left is not 0, continue the forwarding process according to step 1201 in the optional embodiment 1.

[0107] When BFER receives a message, it processes it and finds that it carries a Routing extension header. It further parses the Routing extension header and finds that it is a bit index explicit copy BIER type based on the type. It then processes it according to the following process:

[0108] Step 2301, perform normal processing on the BIER message with bit index explicit copy in the Routing extension header. When it is found that the local node is the egress node, remove the entire outer IPv6 encapsulation, including the Routing extension header containing the bit index explicit copy of the BIER type, and then forward it to the receiver.

[0109] Step 2302: If it is found that this node is a transmission node, that is, there is both a receiver and a next-hop device that needs to be forwarded, then according to the principle in step 2201, when the value of the remaining segment Segments Left is 0, it cannot be forwarded to the next-hop node, and an alarm or report to the controller for processing is required. When the value of the remaining segment Segments Left is not 0, the remaining segment Segments Left is reduced by 1, and the message is forwarded to the next-hop node according to the BFR process.

[0110] When the bit index is explicitly copied to the BIER message header as a new type of IPv6 Routing extension header, the third embodiment (i.e., the third processing method for the remaining segments Segments Left) may be selected:

[0111] The ingress node BFIR sets the value of the remaining segments Segments Left field to 255, and the intermediate node decrements it by 1 when forwarding hop by hop. When it reaches the egress node BFER, the number of hops the message has passed can be calculated based on the current value of the remaining segments Segments Left. The number of hops can be recorded and reported to the controller or other modules for statistical purposes.

[0112] like Figure 3 As shown, after the control plane is performed according to the above method, the data plane encapsulation and forwarding process is as follows:

[0113] When the bit forwarding ingress router BFIR receives a multicast message, it will encapsulate the external IPv6 header after the bit index explicit copy BIER message header is encapsulated according to the BFER that needs to be received. The following encapsulation principles are followed when encapsulating the external IPv6 header:

[0114] Step 3101 is the same as 2101 of optional embodiment 2, wherein the Segments Left field is set to 255.

[0115] Step 3102, setting content is the same as step 1102 in optional embodiment 1.

[0116] When BFR receives the message, it processes and finds that it carries the Routing extension header. After further parsing the Routing extension header, it finds that the type is the type indicating bit index explicit replication BIER, and then processes it according to the following process:

[0117] Step 3201 is processed the same as step 2201 in the second optional embodiment.

[0118] When BFER receives a message, it processes it and finds that it carries a Routing extension header. It further parses the Routing extension header and finds that it is a bit index explicit copy BIER type based on the type. It then processes it according to the following process:

[0119] Step 3301 is processed in the same manner as step 2301 in the optional embodiment 2. However, the current remaining segment SegmentsLeft value is reported to the controller or other management module at the same time, so that the controller can obtain the number of hops that the message has passed through, which is convenient for subsequent hop number setting.

[0120] When the bit index is explicitly copied to the BIER message header as a new type of IPv6 Routing extension header, the fourth embodiment (i.e., the fourth processing method for the remaining segments Segments Left) may be selected:

[0121] Since the message may pass through multiple IGP domains or some BIER internal boundaries, it is possible to estimate how many such boundaries it will pass through and fill the boundary value in the remaining segments Segments Left field value. At this time, the remaining segments Segments Left field value is only forwarded to other IGP domains or other BIER internal boundaries on BFER. The field value is reduced by 1. If forwarding occurs within a single domain, the field value is not processed. When the field value is 0, it indicates that the message has reached the maximum boundary and can no longer be forwarded to the next area.

[0122] like Figure 3 As shown, after the control plane is performed according to the above method, the data plane encapsulation and forwarding process is as follows:

[0123] When the bit forwarding ingress router BFIR receives a multicast message, it will encapsulate the external IPv6 header after the bit index explicit copy BIER message header is encapsulated according to the BFER that needs to be received. The following encapsulation principles are followed when encapsulating the external IPv6 header:

[0124] Step 4101 is the same as step 2101 of the second optional embodiment, wherein the remaining segments Segments Left field is set to the estimated maximum boundary value, such as Figure 5 As shown, assuming that this bit index explicitly copies the Area that spans up to 3 IGPs in the BIER domain, the remaining segments Segments Left field can be set to 3.

[0125] Step 4102, setting content is the same as step 1102 in optional embodiment 1.

[0126] When BFR receives the message, it processes and finds that it carries the Routing extension header. After further parsing the Routing extension header, it finds that the type is the type indicating bit index explicit replication BIER, and then processes it according to the following process:

[0127] Step 4201, when BFR performs bit index explicit replication BIER message processing and forwarding, if the remaining segment Segments Left value is found to be 0, it means that the maximum boundary has been reached. When searching for the next hop, if the next hop is still in the same area, for example Figure 5 The next hop forwarded by BFR2 in the example still belongs to Area3, so it is forwarded normally and the remaining segments Segments Left will not be operated. However, if BFR2 finds that the next hop is in another Area4, BFR2 cannot forward the packet to the next hop belonging to Area4 and needs to alert or notify the controller of abnormal conditions.

[0128] Therefore, if the packet is forwarded to other nodes in the same IGP Area, no operation is performed on the remaining segments Segments Left. Only when the packet is forwarded to the next hop in another IGP Area, the remaining segments Segments Left need to be subtracted by 1. Figure 5 As shown in the figure, only when BFR1 and BFR2 are BFR nodes that cross IGP Areas and the next hop is another Area, such as BFR1 forwards from Area1 to the next hop in Area2, or BFR2 forwards from Area3 to the next hop in Area4, the remaining segments Segments Left are subtracted by 1. If the next hop forwarded by BFR1 still belongs to Area1, the remaining segments Segments Left will not be subtracted by 1.

[0129] When BFER receives a message, it processes it and finds that it carries a Routing extension header. It further parses the Routing extension header and finds that it is a bit index explicit copy BIER type based on the type. It then processes it according to the following process:

[0130] Step 4301 is processed the same as step 2301 in the second optional embodiment.

[0131] Step 4302, when this BFER is also a transmitting node, the operation and judgment on the remaining segments Segments Left are performed in accordance with step 4201.

[0132] By adopting the above-mentioned optimization method for the Segments Left field in the IPv6 packet header, BIER can be deeply integrated with IPv6. The IPv6 routing extension header can be used to carry the BIER packet header information used for multicast routing. Combined with the processing method of the Segments Left field, the transmission range of BIER packets in the IPv6 network can be effectively controlled. Combined with controller reporting and other means, the forwarding of BIER packets in the IPv6 network can be more controllable.

[0133] Since there are many ways to optimize the combination of bit index explicit replication BIER message and IPv6 message encapsulation, optionally, the Source Address field of IPv6 can be filled with the bit forwarding router routing prefix BFR-Prefix of the bit forwarding entry router BFIR. The specific steps are as shown in the optional embodiment 5 below:

[0134] When the bit-indexed explicitly replicated BIER message header is used in conjunction with the IPv6 header, the bit-forwarding router routing prefix BFR-Prefix of the bit-forwarding entry router BFIR, that is, the announcement prefix address used for the bit-indexed explicitly replicated BIER path calculation, is encapsulated into the Source Address field of the IPv6 header, so that the message can carry the information of the entry node bit-forwarding entry router BFIR, so that the entry node can be found during fault detection, performance detection, and duplicate traffic judgment.

[0135] When the bit index explicit replication BIER forwarding is established, which is itself established based on the IPv6 plane, the bit forwarding router routing prefix BFR-Prefix of the bit forwarding entry router BFIR itself is the IPv6 address of the bit forwarding entry router BFIR node. At this time, the value can be directly filled in the Source Address field of IPv6.

[0136] When all nodes support bit-indexed explicit replication (BIER), the Link-local addresses may be filled into the Source Address (SA) and Destination Address (DA) fields of the IPv6 header, or when passing through certain nodes that do not support bit-indexed explicit replication (BIER), an IPv6 tunnel will be introduced so that nodes that do not support bit-indexed explicit replication (BIER) processing do not need to see and process the bit-indexed explicit replication (BIER) message. At this time, the SA and DA operations on the outer IPv6 header may cause the loss of the original SA and DA information. This will cause the bit-forwarding router routing prefix (BFR-Prefix) information of the bit-forwarding ingress router (BFIR) to be lost. Therefore, in order to ensure that this information is not lost, some specific measures need to be taken to ensure it. See the following steps for details:

[0137] Step 1: Control plane extension: If all nodes can use a unified method to ensure the delivery of the source address field (i.e., IPv6 SA) of the IPv6 packet header, no special control plane extension is required. If there are nodes that cannot guarantee the delivery of IPv6 SA, the control plane needs to announce and collect this capability before operating on the data plane. The announcement method can still be used Figure 4 The TLV shown in the figure is used to indicate support for IPv6 SA assurance in a new extended type manner.

[0138] BFIR, BFER and all BFRs, when supporting this function, carry IPv6SA assurance capability in the announcement. Those that do not support this capability do not make announcements. Specific announcements can be made through IGP and BGP protocol extensions.

[0139] Step 2: Data plane processing, when the bit forwarding ingress router BFIR receives the multicast message, it will perform the bit index explicit copy BIER message header encapsulation according to the BFER that needs to be received. When encapsulating the external IPv6 header, it follows the following encapsulation principles:

[0140] Step 5101: encapsulate the SA of the IPv6 header into the bit forwarding router routing prefix BFR-Prefix of the bit forwarding ingress router BFIR, or any other IPv6 address that can be used to uniquely identify the bit forwarding ingress router BFIR.

[0141] Step 5102, when not all nodes in the domain can support IPv6 SA protection capabilities, other unused fields in the IPv6 header, such as the Traffic Class field, or the reserved fields in the BIER message header can be explicitly copied by bit index, etc., and one or several bits in these fields can be set to 1 to indicate that the IPv6 SA needs to be protected.

[0142] When BFR receives a message, it processes it according to the following process:

[0143] Step 5201, when the BIER message header is explicitly copied according to the bit index, if it is found that IPv6 SA security processing is not required, it is forwarded according to the normal process; if it is found that IPv6 SA security processing is required, when the next hop is found for forwarding processing, the SA in the current IPv6 header remains unchanged, and the DA can be set to the globally routable IPv6 address of the next hop. There may be multiple forwarding situations, the next hop is directly connected or the next hop is not directly connected.

[0144] When the next hop is directly connected, if the next hop supports IPv6 encapsulation, the SA remains unchanged and the DA is set to the globally routable IPv6 address of the next hop and can be sent directly; if the next hop supports Ethernet encapsulation or MPLS encapsulation, the current IPv6 header cannot be directly replaced. Instead, the outer layer of the IPv6 header is encapsulated with Ethernet or MPLS, the SA in the IPv6 header remains unchanged, and the DA in the IPv6 header is set to the globally routable IPv6 address of the next hop.

[0145] When the next hop is not directly connected, tunnel technology is required for encapsulation. The SA in the IPv6 header remains unchanged, and the DA is set to the next hop globally routable IPv6 address. If the tunnel used is still an IPv6 tunnel and there is no need to modify the SA, the message can be sent directly. If the tunnel used is a GRE (Generic Routing Encapsulation) tunnel, the SA needs to be modified to the starting point of the tunnel. In this case, tunnel encapsulation needs to be performed outside the current IPv6 header to ensure that the SA will not be modified.

[0146] Of course, the bit forwarding ingress router BFIR may also encounter a situation where the next hop needs to be tunnel encapsulated, and it will be handled in the same way as BFR.

[0147] When BFER receives a message, if it finds that the message is not SA-secured, no special processing is required. If it finds that the message is SA-secured, it will be processed according to the following process:

[0148] Step 5301: if there is an outer tunnel, remove the outer tunnel, take out the SA in the IPv6 header, and process it as the bit forwarding router routing prefix BFR-Prefix of the bit forwarding ingress router BFIR. It can be used for fault or path detection, or for duplicate message judgment and discarding.

[0149] It should be noted that when any hop finds that a fault, detection or other reason needs to be reported to the bit forwarding ingress router BFIR, the protected SA will be used as the destination address to send the message.

[0150] The BIER message header already has a BFIR-ID, which indicates the BFR-id value of the ingress node BFIR, and is usually used for performance measurement or fault detection. When there are multiple BFIRs in the network forwarding the same traffic, such as in the BFIR protection scenario, the egress node BFER can also make a judgment based on the value of the BFIR-ID, choose to receive traffic from a certain BFIR-ID, and discard traffic from other BFIRs.

[0151] However, in the actual application of BIER, there may be a situation where the ingress node BFIR does not allocate BFR-ID. In other words, all egress node BFERs must allocate BFR-ID, but the ingress node BFIR is not necessarily. Therefore, there may be a situation where the BFIR does not allocate BFR-ID, which will make it impossible to fill in the BFIR-ID value in the BIER message header. At this time, the egress node BFER cannot judge duplicate traffic based on this value, and if there is duplicate traffic, it will cause duplicate traffic to be forwarded.

[0152] Therefore, when the BIER message header is used in conjunction with the IPv6 header, the BFR-prefix of the BFIR, that is, the announcement prefix address used for BIER path calculation, is encapsulated into the Source Address field of the IPv6 header, so that the message can carry the information of the ingress node BFIR, so that the ingress node can be found during fault detection, performance detection, and duplicate traffic judgment.

[0153] By utilizing the optimization method of filling in the bit index in the source address field of the IPv6 message header to explicitly copy the bit forwarding router routing prefix BFR-Prefix of the BIER message header, the BIER duplicate traffic judgment can be advanced to the IPv6 message, and the ingress device BFIR does not need to allocate BFR-ID to realize BIER duplicate traffic judgment, which can save the number of BFR-ID allocations and make duplicate traffic judgment more accurate.

[0154] Since there are multiple ways to optimize the combination of bit index explicit replication BIER message and IPv6 message encapsulation, optionally, the bit index forwarding table index BIFT-ID can also be optimized, including the following three embodiments of optional implementation six to optional implementation eight:

[0155] It should be noted that before performing the data plane process of the following optional embodiment, if all nodes can adopt a unified bit index forwarding table index BIFT-ID optimization method, no special control plane extension is required. If there are different processing methods, or some nodes cannot support bit index forwarding table index BIFT-ID optimization, the control plane needs to announce and collect this capability before operating on the data plane. The announcement method can still be used Figure 4 The TLV shown in the figure indicates support for bit-indexed forwarding table index BIFT-ID optimization in a new extended type. The bit forwarding entry routers BFIR, BFER and all BFRs, when supporting this function, carry the bit-indexed forwarding table index BIFT-ID optimization capability in the announcement. If this capability is not supported, no announcement will be made. The specific announcement can be made through IGP and BGP protocol extensions.

[0156] Optional embodiment six:

[0157] The way to carry the bit index forwarding table index BIFT-ID is optimized. When the length of the bit forwarding router routing prefix BFR-Prefix of a node in the network is less than or equal to 96 bits, the information of the bit index forwarding table index BIFT-ID is filled into the IPv6 DA. That is, the last 32 bits of the DA in the IPv6 message are used to store the bit index forwarding table index BIFT-ID value, and the front is used to store the normal IPv6 reachable routing prefix bit forwarding router routing prefix BFR-Prefix. The processing steps at this time are: data plane processing;

[0158] When the bit forwarding ingress router BFIR receives a multicast message, it will encapsulate the external IPv6 header after the bit index explicit copy BIER message header is encapsulated according to the BFER that needs to be received. The following encapsulation principles are followed when encapsulating the external IPv6 header:

[0159] Step 6101, encapsulate the first 96 bits of the DA of the IPv6 header as the bit forwarding router routing prefix BFR-Prefix of the next hop, and fill the bit index forwarding table index BIFT-ID announced by the next hop into the lower 32 bits of DA.

[0160] When BFR receives a message, it processes it according to the following process:

[0161] Step 6201, when performing conventional local prefix judgment based on the received message, take the first 96 bits of the IPv6 DA for search and judgment. When it is found to be a local prefix, the last 32 bits of the DA are used for bit indexing to explicitly copy the BIER table entry for positioning, and then the BIER message header is explicitly copied according to the bit index for table lookup.

[0162] Step 6202, when preparing to copy the message to the next hop, if the next hop supports the bit-indexed forwarding table index BIFT-ID optimization method, the IPv6 message encapsulation is performed according to the optimization method of the next hop. For example, if the next hop also supports the encapsulation of the first 96 bits of DA as the bit-indexed forwarding table index BFR-Prefix and the last 32 bits as the bit-indexed forwarding table index BIFT-ID, the bit-indexed forwarding table index BFR-Prefix and the bit-indexed forwarding table index BIFT-ID of the next hop are encapsulated according to this rule.

[0163] If some next hops support other bit-indexed forwarding table index BIFT-ID optimization methods, for example, the first 64 bits are encapsulated as the bit-indexed forwarding router routing prefix BFR-Prefix, the middle 32 bits are encapsulated to represent the function of bit-indexed explicit copying of BIER, and the last 32 bits are encapsulated as the bit-indexed forwarding table index BIFT-ID, then the bit-indexed forwarding table index BFR-Prefix and the bit-indexed forwarding table index BIFT-ID of the next hop are encapsulated according to this principle.

[0164] If some next hops do not support the bit-indexed forwarding table index BIFT-ID optimization method, the bit-indexed forwarding table index BIFT-ID optimization processing will not be performed on the content of the IPv6 header.

[0165] When BFER receives a message, it processes it as follows:

[0166] Step 6301 is similar to step 6201. In addition to determining that it is a local prefix, the bit index explicitly copied BIER message header will be used to determine whether there is a local receiver. The message will then be stripped of the IPv6 header and the bit index explicitly copied BIER message header and sent to the receiver.

[0167] Step 6302: If the BFER node is also a transmitting node, that is, there is a next hop to continue sending, the method of step 6202 can be used.

[0168] It should be noted that the encapsulation mode is changed according to different situations of the next hop, which is applicable to all nodes including the bit forwarding ingress router BFIR, BFR, and transmission BFER, not just the BFR node.

[0169] Optional embodiment seven:

[0170] The way to carry the bit index forwarding table index BIFT-ID is optimized. When the length of the bit forwarding router routing prefix BFR-Prefix of the node in the network is less than or equal to 96 bits, the information of the bit index forwarding table index BIFT-ID is filled into the IPv6 SA. That is, the last 32 bits of the SA in the IPv6 message are used to store the bit index forwarding table index BIFT-ID value, and the front is used to store the normal IPv6 reachable routing prefix bit forwarding router routing prefix BFR-Prefix. The processing steps at this time are:

[0171] Data processing:

[0172] When the bit forwarding ingress router BFIR receives a multicast message, it will encapsulate the external IPv6 header after the bit index explicit copy BIER message header is encapsulated according to the BFER that needs to be received. The following encapsulation principles are followed when encapsulating the external IPv6 header:

[0173] Step 7101, encapsulate the first 96 bits of the SA of the IPv6 header as the current bit forwarding router routing prefix BFR-Prefix, and fill the bit index forwarding table index BIFT-ID announced by the next hop into the lower 32 bits of SA.

[0174] When BFR receives a message, it processes it according to the following process:

[0175] Step 7201, when performing conventional local prefix judgment based on the received message, it is processed according to the normal DA search process. When it is found to be a local prefix, the last 32 bits of SA are explicitly copied to locate the BIER table entry based on the bit index, and then the BIER message header is explicitly copied based on the bit index for table lookup.

[0176] Step 7202, when preparing to copy the message to the next hop, if the next hop supports the bit-indexed forwarding table index BIFT-ID optimization method, the IPv6 message encapsulation is performed according to the optimization method of the next hop. For example, if the next hop also supports the encapsulation of the first 96 bits of SA as the bit-indexed forwarding table index BFR-Prefix and the last 32 bits as the bit-indexed forwarding table index BIFT-ID, the bit-indexed forwarding table index BIFT-ID of the next hop is encapsulated into the lower 32 bits of SA according to this rule.

[0177] If some next hops support other bit-indexed forwarding table index BIFT-ID optimization methods, for example, the first 64 bits are encapsulated as the bit-forwarding router routing prefix BFR-Prefix, the middle 32 bits are encapsulated to represent the function of bit-indexed explicit copy of BIER, and the last 32 bits are encapsulated as the bit-indexed forwarding table index BIFT-ID, then according to this principle, the bit-indexed forwarding table index BIFT-ID of the next hop is encapsulated into the lower 32 bits of SA.

[0178] If some next hops do not support the bit-indexed forwarding table index BIFT-ID optimization method, the bit-indexed forwarding table index BIFT-ID optimization processing will not be performed on the content of the IPv6 header.

[0179] When BFER receives a message, it processes it as follows:

[0180] Step 7301 is similar to step 7201. In addition to determining that it is a local prefix, the bit index explicitly copied BIER message header will be used to determine whether there is a local receiver. The message will then be stripped of the IPv6 header and the bit index explicitly copied BIER message header and sent to the receiver.

[0181] Step 7302: If the BFER node is also a transmitting node, that is, there is a next hop to continue sending, the method of step 7202 can be used.

[0182] It should be noted that the encapsulation mode is changed according to different situations of the next hop, which is applicable to all nodes including the bit forwarding ingress router BFIR, BFR, and transmission BFER, not just the BFR node.

[0183] Optional embodiment eight:

[0184] The bit index forwarding table index BIFT-ID is optimized to carry the bit index forwarding table index BIFT-ID into the Flow Label field of the IPv6 message. The processing steps are as follows:

[0185] Data processing:

[0186] When the bit forwarding ingress router BFIR receives a multicast message, it will encapsulate the external IPv6 header after the bit index explicit copy BIER message header is encapsulated according to the BFER that needs to be received. The following encapsulation principles are followed when encapsulating the external IPv6 header:

[0187] Step 8101, encapsulate the SA / DA of the IPv6 header according to the normal processing method, and encapsulate the Flow Label field into the bit index forwarding table index BIFT-ID of the next hop.

[0188] When BFR receives a message, it processes it according to the following process:

[0189] Step 8201, when performing routine local prefix judgment based on the received message, it is processed according to the normal DA search process. When it is found to be a local prefix, the Flow Label field is used as the bit index forwarding table index BIFT-ID to perform the bit index explicit copy of the BIER table entry positioning operation, and then the BIER message header is explicitly copied according to the bit index for table lookup.

[0190] Step 8202, when preparing to copy the message to the next hop, if the next hop supports the bit-indexed forwarding table index BIFT-ID optimization method, the IPv6 message encapsulation is performed according to the optimization method of the next hop. For example, if the next hop also supports the encapsulation of the bit-indexed forwarding table index BIFT-ID into the Flow Label field, the bit-indexed forwarding table index BIFT-ID of the next hop is encapsulated into the Flow Label field according to this rule.

[0191] If some next hops support other bit-indexed forwarding table index BIFT-ID optimization methods, such as supporting the embedding of the bit-indexed forwarding table index BIFT-ID into the DA, the first 96 bits are encapsulated as the bit-forwarding router routing prefix BFR-Prefix, the middle 32 bits are encapsulated as the function representing the bit-indexed explicit copy of BIER, and the last 32 bits are encapsulated as the bit-indexed forwarding table index BIFT-ID, then according to this principle, the bit-indexed forwarding table index BIFT-ID of the next hop is encapsulated into the lower 32 bits of the DA.

[0192] If some next hops do not support the bit-indexed forwarding table index BIFT-ID optimization method, the bit-indexed forwarding table index BIFT-ID optimization processing will not be performed on the content of the IPv6 header.

[0193] When BFER receives a message, it processes it as follows:

[0194] Step 8301 is similar to step 8201. In addition to determining that it is a local prefix, the bit index explicitly copied BIER message header will be used to determine whether there is a local receiver. The message will then be stripped of the IPv6 header and the bit index explicitly copied BIER message header and sent to the receiver.

[0195] Step 8302: If the BFER node is also a transmitting node, that is, there is a next hop to continue sending, the step 8202 method can be used.

[0196] It should be noted that the encapsulation mode is changed according to different situations of the next hop, which is applicable to all nodes including the bit forwarding ingress router BFIR, BFR, and transmission BFER, not just the BFR node.

[0197] Through the optimized use of the above BIFT-ID, the advantages of using BIER in combination with IPv6 can be further stimulated, broadening the application scenarios of BIER and optimizing forwarding processing and efficiency.

[0198] In summary, through the above technical scheme, an optional embodiment of the present invention proposes a new message encapsulation method, which combines the bit-indexed explicit copy BIER encapsulation with IPv6 encapsulation, and utilizes the fields in the outer IPv6 header to optimize the fields in the bit-indexed explicit copy BIER message header without affecting the function implementation, including three major categories, encapsulating the bit-indexed explicit copy BIER message header into a new type of IPv6 Routing extension header, optimizing the source address Source Address field of the IPv6 message header, and optimizing the bit-indexed forwarding table index BIFT-ID, introducing capability announcements for negotiation, thereby optimizing message encapsulation and improving processing speed, and broadening the use scenarios of the bit-indexed explicit copy BIER. In addition, by making full use of the combination of the two, it is possible to optimize the data message carrying encapsulation, accelerate the processing flow, and have an excellent promoting effect on the development of multicast technology.

[0199] Through the description of the above implementation methods, those skilled in the art can clearly understand that the method according to the above embodiment can be implemented by means of software plus a necessary general hardware platform, and of course can also be implemented by hardware, but in many cases the former is a better implementation method. Based on such an understanding, the technical solution of the present invention, or the part that contributes to the prior art, can be embodied in the form of a software product, which is stored in a storage medium (such as ROM / RAM, a magnetic disk, or an optical disk), and includes a number of instructions for a terminal device (which can be a mobile phone, a computer, a server, or a network device, etc.) to execute the methods described in each embodiment of the present invention.

[0200] In this embodiment, a message header processing device is also provided, which is used to implement the above-mentioned embodiments and preferred implementation modes, and the descriptions that have been made will not be repeated. As used below, the term "module" can implement a combination of software and / or hardware of a predetermined function. Although the devices described in the following embodiments are preferably implemented in software, the implementation of hardware, or a combination of software and hardware, is also possible and conceivable.

[0201] Figure 6 is a structural block diagram of a packet header processing device according to an embodiment of the present invention, such as Figure 6 As shown, the device comprises:

[0202] Processing module 70 is used to process the fields in the IPv6 message header according to the fields in the BIER message header explicitly copied by bit index in at least one of the following ways: using the BIER message header explicitly copied by bit index as the type of the routing extension header of the IPv6 message header, and processing the remaining segments Segments Left field in the IPv6 message header in a predefined manner; using the BIER message header explicitly copied by bit index as the type of other extension headers of the IPv6 message header, wherein the types of other extension headers include options in the Hop-by-Hop extension header; filling the source address SourceAddress field of the IPv6 message header with the bit forwarding router routing prefix BFR-Prefix of the BIER message header explicitly copied by bit index; embedding the bit index forwarding table index BIFT-ID field in the BIER message header explicitly copied by bit index into the target field of the IPv6 message header.

[0203] Through the present invention, the bit index explicitly copied BIER message and IPv6 message can be processed as follows: the fields in the IPv6 message header are processed according to the fields in the bit index explicitly copied BIER message header in at least one of the following ways: the bit index explicitly copied BIER message header is used as the type of the routing extension header of the IPv6 message header, and the remaining segments Segments Left field in the IPv6 message header is processed in a predefined manner; the bit index explicitly copied BIER message header is used as the type of other extension headers of the IPv6 message header, wherein the type of the other extension header includes a new option in the Hop-by-Hop extension header; the source address Source in the IPv6 message header The bit forwarding router routing prefix BFR-Prefix of the bit index explicitly copied BIER message header is filled in the Address field; the bit index forwarding table index BIFT-ID field in the bit index explicitly copied BIER message header is embedded in the target field of the IPv6 message header, thereby realizing the combination of BIER message encapsulation and IPv6 message encapsulation, optimizing the message encapsulation and processing flow without affecting the function at all, and improving the forwarding efficiency. The above technical solution solves the problem that the related technology fails to effectively realize the optimization in the process of combining and encapsulating BIER message and IPv6 message.

[0204] Apply the above technical solution, such as Figure 3 As shown, in this case, the Routing Type can be directly set to BIER.

[0205] In an exemplary embodiment, the processing module 70 processes the remaining segments Segments Left field in the IPv6 message header in a predefined manner, including at least one of the following: setting the remaining segments Segments Left field to a target value so that all nodes ignore the processing of the remaining segments Segments Left field; setting the remaining segments Segments Left field value of the bit forwarding entry router BFIR to 255, and when the intermediate node forwards the message hop by hop, the field value is decremented by 1, and when the field value is 0, it indicates that a loop occurs in the message forwarding process; setting the remaining segments Segments Left field value of the entry node of the bit forwarding entry router BFIR to the maximum number of hops to reach the edge device, and when the intermediate node forwards the message hop by hop, the field value is decremented by 1, and when the field value is 0, it indicates that a loop occurs in the message forwarding process; setting the remaining segments Segments Left field value of the bit forwarding entry router BFIR to 255, and when the intermediate node forwards the message hop by hop, the field value is decremented by 1, and when the field value is 0, it indicates that a loop occurs in the message forwarding process; When an IPv6 packet with a Left field value of 255 arrives at the bit forwarding egress router BFER, the number of hops that the IPv6 packet has passed is calculated based on the value of the current remaining segments Segments Left field; the remaining segments Segments Left field is set to the maximum boundary value of the boundary that the IPv6 packet is to pass through, and the field value is subtracted by 1 when passing through the boundary. When the field value is 0, it indicates that the packet has reached the maximum boundary and can no longer be forwarded to the next area.

[0206] It is understandable that when the BIER message header is used as a new type of routing extension header of the IPv6 message header, it is necessary to select different predefined methods to process the Segments Left field in the IPv6 message header according to functional requirements.

[0207] Optionally, the target value of the Segments Left field can be 0 or 255 or any other value, so that all nodes ignore the processing of this field. Since this method is the simplest, it can also be used as the default support method for all nodes;

[0208] Optionally, the ingress node BFIR sets the value of the Segments Left field to 255, or sets the value of the Segments Left field to the estimated maximum number of hops to reach the edge device, and then decrements the value of the field by 1 when forwarding hop by hop at the intermediate node. When the value of the field decreases to 0, it indicates that a loop may occur in the forwarding process of the message, and an alarm prompt or abnormal log record is required, and the message will no longer be forwarded, thereby preventing the message from being forwarded out of a domain range that should not be forwarded.

[0209] Optionally, the ingress node BFIR sets the value of the remaining segments Segments Left field to 255, and the intermediate node decrements it by 1 when forwarding hop by hop. When the message reaches the egress node BFER, the number of hops the message has passed can be calculated based on the current Segments Left value. The number of hops can be recorded and reported to the controller or other modules for statistical purposes.

[0210] Optionally, since the message may pass through multiple IGP domains or some BIER internal boundaries, it is possible to estimate how many such boundaries it will pass through and fill the boundary value in the remaining segments Segments Left field value. At this time, the remaining segments Segments Left field value is only forwarded to other IGP domains or other BIER internal boundaries on BFER. The field value is reduced by 1. If forwarding occurs within a single domain, the field value is not processed. When the field value is 0, it indicates that the message has reached the maximum boundary and can no longer be forwarded to the next area.

[0211] In an exemplary embodiment, the processing module is also used to explicitly copy the BIER message header with a bit index as a type of other extension header of the IPv6 message header, wherein the type of other extension header includes options in a Hop-by-Hop extension header.

[0212] In short, in order to improve the application effect of the bit index explicit copy BIER header in the IPv6 header, options about the BIER type can also be added to other extension headers of the IPv6 header.

[0213] In an exemplary embodiment, the above-mentioned device also includes: a notification module, which is used to notify each node through the control plane of its own support for the type of routing extension header that explicitly copies the BIER message header with bit index as the IPv6 message header, that is, in an embodiment of the present invention, after the BIER message header is used as a new type of IPv6 routing Routing extension header, each node itself is notified through the control plane of its support for the newly added BIER type of the Routing extension header.

[0214] In an exemplary embodiment, the above-mentioned notification module is also used to notify each node of its own support for using the bit-indexed explicitly copied BIER message header as the type of routing extension header of the IPv6 message header in one of the following ways: notification in TLV mode, notification by carrying the bit-indexed explicitly copied BIER information in the internal gateway protocol IGP, and notification by carrying the bit-indexed explicitly copied BIER information in the border gateway protocol BGP.

[0215] In an exemplary embodiment, the above-mentioned notification module is also used to announce in the form of sub-TLV or sub-sub-TLV under the notification of the bit forwarding router routing prefix BFR-Prefix or the bit forwarding router identifier BFR-ID, when each node's own support for explicitly copying the BIER message header with a bit index as the type of routing extension header of the IPv6 message header is set.

[0216] For example, the control plane notification method includes each node notifying its support for the newly added BIER type of the Routing extension header. It can be notified in the form of TLV, following the BIER information in IGP or BGP, that is, placed under the notification of BFR-Prefix or BFR-id, and notified in the form of sub-TLV or sub-sub-TLV. When notifying support for the SegmentsLeft processing method, if all nodes only support a certain Segments Left field processing method, no further notification is required. However, if a node supports different Segments Left field processing methods, a notification is required to distinguish them. The notification method can also be in the form of TLV.

[0217] When all nodes support BIER, the source address Source Address (SA) and destination address Destination Address (DA) fields in the IPv6 message header may also be filled with the local subnet Link-local address, or when passing through certain nodes that do not support BIER, an IPv6 tunnel will be introduced so that nodes that do not support BIER processing do not need to see and process the BIER message. At this time, the SA and DA operations on the outer IPv6 header may cause the loss of the original SA and DA information. This will cause the BFR-prefix information of the BFIR to be lost. Therefore, in order to ensure that this information is not lost, some specific measures need to be taken to ensure it, including:

[0218] In an exemplary embodiment, the above-mentioned device also includes: a guarantee module, which is used to announce and collect information on the delivery capability of the source address Source Address field of the IPv6 packet header of all nodes through the control plane when there is a node among all nodes that cannot guarantee the delivery capability of the source address Source Address field of the IPv6 packet header.

[0219] In an exemplary embodiment, the above-mentioned device also includes: a determination module, which is used to set N bits of other unused fields in the IPv6 message header to 1 when it is confirmed that the security capability of the source address Source Address field of the IPv6 message header is not supported, to indicate that the source address Source Address of the IPv6 message header needs to be secured, wherein the value of N is not less than 1.

[0220] For example, not all nodes in the domain can support the protection capability of the source address field of the IPv6 packet header. In this case, other unused fields in the IPv6 header, such as the Traffic Class field, or the reserved fields in the BIER header, can be used. By setting one or several bits in these fields to 1, it indicates that the source address field of the IPv6 packet header needs to be protected.

[0221] In an exemplary embodiment, the apparatus further comprises: a transformation module, configured to transform the address in the IPv6 message so as to set the routable prefix of the IPv6 message in the first target number of bits in the IPv6 message.

[0222] It should be noted that the routable prefix of the IPv6 message is set in the first target number of bits in the IPv6 message, wherein the target number of bits can be 64 bits or 96 bits, and the present invention does not impose too many restrictions on this.

[0223] Optionally, the IPv6 address can be divided into two parts: prefix + BIFT-ID. The reachable prefix in the domain is placed in the first 96 bits, that is, when used to encapsulate the message, the IPv6 routable prefix is ​​placed in the first 96 bits, which can support the situation where the prefix can be up to 96 bits; the remaining 32 bits are used to store the BIFT-ID value. Of course, the first 108 bits can also be used to store the reachable prefix, and the last 20 bits can be used to store the BIFT-ID value, which can support the prefix to be up to 108 bits.

[0224] Optionally, the IPv6 address is divided into three parts according to the format LOC:FUNCT:ARG defined in draft-ietf-spring-srv6-network-programming. In addition to the LOC representing the prefix, a new FUNCT is defined as the BIERfunction, and the BIFT-ID is filled in the position of ARG. This method is suitable for the case where the BFR-Prefix length of the node is shorter, for example, the LOC part is 64 bits, the FUNC is 32 bits, and the ARG part is 32 bits.

[0225] In an exemplary embodiment, the above-mentioned transformation module is also used to embed the bit-indexed forwarding table index BIFT-ID field into the destination address DA in the IPv6 message; or embed the bit-indexed forwarding table index BIFT-ID field into the source address SA in the IPv6 message; or fill the bit-indexed forwarding table index BIFT-ID into the flow label Flow Label field of the IPv6 message header without changing the destination address DA and the source address SA in the IPv6 message, that is, fill the BIFT-ID into the Flow Label field in the IPv6 header, and do not change the SA and DA. This method is suitable for scenarios where BFR-Prefix must be represented by a 128-bit address.

[0226] That is to say, when the IPv6 address is divided into two parts of prefix + BIFT-ID, when the BIFT-ID field is embedded in the destination address DA in the IPv6 message, the IPv6 routable prefix of the next hop will be filled in the first 96 bits of DA and the BIFT-ID of the next hop will be filled in the last 32 bits of DA; when the BIFT-ID field is embedded in the source address SA in the IPv6 message, DA will fill in the IPv6 reachable routable prefix of the next hop as usual, the first 96 bits of the prefix of SA will not be modified, and only the last 32 bits will be modified to the BIFT-ID of the next hop.

[0227] In addition, according to the format LOC:FUNCT:ARG defined in draft-ietf-spring-srv6-network-programming, the IPv6 address is divided into three parts. In addition to the LOC representing the prefix, a new FUNCT is defined as the BIER function, and the BIFT-ID is filled in the ARG position. When the BIFT-ID field is embedded in the destination address DA in the IPv6 message, the LOC part of DA is filled in with the BFR-prefix of the next hop, FUNC is defined as a new function value representing BIER, and ARG is filled in with the BIFT-ID of the next hop; when the BIFT-ID field is embedded in the source address SA in the IPv6 message, the DA part is filled in with the IPv6 reachable routing prefix BFR-prefix of the next hop as usual, the LOC part of SA remains unchanged, and if the FUNCT part is not a function representing BIER, it is modified to the function value representing BIER, and the ARG part of SA is filled in with the BIFT-ID of the next hop.

[0228] It should be noted that when optimizing the use of BIFT-ID, if all nodes support the unified BFIT-ID optimization method, the control plane does not need to be specially extended. However, if not all nodes support this function, in order to avoid error handling, the capability notification process also needs to be introduced. The method can still be achieved through Figure 4 The TLV method shown defines a new Type type, which is carried when following the BFR-prefix and other information announcements of BIER, that is, this information is carried when announced through IGP or BGP. In this way, nodes can understand each other's support for this function. For example, a new type of sub-TLV or sub-sub-TLV is defined to represent BIFT-ID optimization, and a lower-level sub-sub-TLV or sub-sub-sub-TLV of different Type represents different BIFT-ID optimization methods for announcement; both are announced at the same time to indicate support for BIFT-ID optimization, and can be specific to the supported methods; or only a new type of sub-TLV or sub-sub-TLV is defined to represent BIFT-ID optimization, and the carried Value directly uses 1 / 2 / 3 to represent different specific BIFT-ID optimization methods.

[0229] In an exemplary embodiment, the above-mentioned transformation module is also used to move the forwarding table entry locating operation of the bit index forwarding table index BIFT-ID in the bit index explicit copy BIER message header forward to the IPv6 message.

[0230] In an exemplary embodiment, the above-mentioned transformation module is also used to explicitly copy the function FUNCTION field of the BIER table entry search using a specific bit representation bit index in the IPv6 message address.

[0231] It should be noted that the above modules can be implemented by software or hardware. For the latter, it can be implemented in the following ways, but not limited to: the above modules are all located in the same processor; or the above modules are located in different processors in any combination.

[0232] An embodiment of the present invention further provides a computer-readable storage medium, in which a computer program is stored, wherein the computer program is configured to execute the steps of any of the above method embodiments when running.

[0233] In an exemplary embodiment, the computer-readable storage medium may include, but is not limited to, various media that can store computer programs, such as a USB flash drive, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk or an optical disk.

[0234] An embodiment of the present invention further provides an electronic device, including a memory and a processor, wherein a computer program is stored in the memory, and the processor is configured to run the computer program to execute the steps in any one of the above method embodiments.

[0235] In an exemplary embodiment, the electronic device may further include a transmission device and an input / output device, wherein the transmission device is connected to the processor, and the input / output device is connected to the processor.

[0236] For specific examples in this embodiment, reference may be made to the examples described in the above embodiments and exemplary implementation modes, and this embodiment will not be described in detail herein.

[0237] Obviously, those skilled in the art should understand that the above modules or steps of the present invention can be implemented by a general computing device, they can be concentrated on a single computing device, or distributed on a network composed of multiple computing devices, they can be implemented by a program code executable by a computing device, so that they can be stored in a storage device and executed by the computing device, and in some cases, the steps shown or described can be executed in a different order than here, or they can be made into individual integrated circuit modules, or multiple modules or steps therein can be made into a single integrated circuit module for implementation. Thus, the present invention is not limited to any specific combination of hardware and software.

[0238] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. For those skilled in the art, the present invention may have various modifications and variations. Any modification, equivalent replacement, improvement, etc. made within the principle of the present invention shall be included in the protection scope of the present invention.

Claims

1. A method for processing a message header, characterized in that: include: The fields in the IPv6 header are processed by explicitly copying the fields in the BIER header according to the bit index in at least one of the following ways: The bit index explicitly copies the BIER message header as the type of the routing extension header of the IPv6 message header, and processes the remaining segments Segments Left field in the IPv6 message header in a predefined manner; The bit-indexed explicitly copied BIER message header is used as the type of routing extension header of the IPv6 message header, and the remaining segments Segments Left field in the IPv6 message header is processed in a predefined manner, and the bit-indexed explicitly copied BIER message header is used as the type of other extension headers of the IPv6 message header, wherein the type of other extension headers includes options in the Hop-by-Hop extension header; Fill in the source address Source Address field of the IPv6 message header with the bit forwarding router routing prefix BFR-Prefix of the BIER message header that is explicitly copied by the bit index; The bit index forwarding table index BIFT-ID field in the bit index explicit copy BIER message header is embedded into the target field of the IPv6 message header, wherein, The remaining segments Segments Left field in the IPv6 packet header is processed in a predefined manner, including at least one of the following: The remaining segments Segments Left field is set to a target value, so that all nodes ignore processing of the remaining segments Segments Left field; The Segments Left field value of the bit forwarding ingress router BFIR is set to 255. When the intermediate node forwards the message hop by hop, the field value is reduced by 1. When the field value is 0, it indicates that a loop occurs in the message forwarding process; The bit forwarding ingress router BFIR sets the Segments Left field value of the ingress node to the maximum number of hops to reach the edge device. When the intermediate node forwards the message hop by hop, the field value is reduced by 1. When the field value is 0, it indicates that a loop occurs in the message forwarding process; The remaining segments Segments Left field value of the bit forwarding inlet router BFIR is set to 255. When the intermediate node forwards the message hop by hop, the field value is reduced by 1. When the IPv6 message with the remaining segments Segments Left field value of 255 reaches the bit forwarding egress router BFER, the number of hops that the IPv6 message has passed is calculated according to the current remaining segments Segments Left field value; The Segments Left field value of the remaining segments is set to the maximum boundary value of the boundary that the IPv6 message is to pass through. When passing through the boundary, the field value is reduced by 1. When the field value is 0, it indicates that the message has reached the maximum boundary and can no longer be forwarded to the next area.

2. The method for processing a message header according to claim 1, characterized in that: After explicitly copying the bit index BIER message header as the type of the routing extension header of the IPv6 message header and processing the remaining segments Segments Left field in the IPv6 message header in a predefined manner, the method further includes: Each node is notified through the control plane of its support for explicitly copying the BIER message header with bit index as the type of routing extension header of the IPv6 message header.

3. The method for processing a message header according to claim 2, characterized in that: The method further comprises: Each node is notified of its support for using the bit-indexed explicitly copied BIER message header as the type of routing extension header of the IPv6 message header through one of the following methods: notification via TLV, notification via the bit-indexed explicitly copied BIER information carried in the Internal Gateway Protocol IGP, or notification via the bit-indexed explicitly copied BIER information carried in the Border Gateway Protocol BGP.

4. The method for processing a message header according to claim 2, characterized in that: The method further comprises: When each node's own support for explicitly copying the BIER message header with a bit index as the type of routing extension header of the IPv6 message header is set under the notification of the bit forwarding router routing prefix BFR-Prefix or the bit forwarding router identifier BFR-ID, it is announced in the form of sub-TLV or sub-sub-TLV.

5. The method for processing a message header according to claim 1, characterized in that: Before filling the source address Source Address field of the IPv6 message header with the bit forwarding router routing prefix BFR-Prefix of the bit indexed explicit copy of the BIER message header, the method further includes: In the case that there is a node among all nodes that cannot guarantee the delivery capability of the source address field of the IPv6 packet header, the information on the delivery capability of the source address field of the IPv6 packet header of all nodes is announced and collected through the control plane.

6. The method for processing a message header according to claim 1, characterized in that: After filling the source address Source Address field of the IPv6 message header with the bit forwarding router routing prefix BFR-Prefix of the bit indexed explicit copy of the BIER message header, the method further includes: When it is confirmed that the security capability of the source address Source Address field of the IPv6 packet header is not supported, N bits of other unused fields in the IPv6 packet header are set to 1 to indicate that the source address Source Address of the IPv6 packet header needs to be secured, wherein the value of N is not less than 1.

7. The method for processing a message header according to claim 1, characterized in that: Before embedding the bit index forwarding table index BIFT-ID field in the bit index explicit copy BIER message header into the target field of the IPv6 message header, the method further includes: The address in the IPv6 message is modified to set the routable prefix of the IPv6 message in the first target number bits in the IPv6 message.

8. The method for processing a message header according to claim 7, characterized in that: After modifying the address in the IPv6 message, the method further includes: Embedding the bit index forwarding table index BIFT-ID field into the destination address DA in the IPv6 message; or Embedding the bit index forwarding table index BIFT-ID field into the source address SA in the IPv6 message; or The bit index forwarding table index BIFT-ID is filled into the flow label Flow Label field of the IPv6 message header, and the destination address DA and the source address SA in the IPv6 message are not changed.

9. The method for processing a message header according to claim 7, characterized in that: The method also includes: moving the forwarding table entry locating operation of the bit index forwarding table index BIFT-ID in the bit index explicit copy BIER message header forward to the IPv6 message.

10. The method for processing a message header according to claim 7, characterized in that: The method also includes: using a specific bit in the IPv6 message address to represent a bit index to explicitly copy the function FUNCTION field of the BIER table entry search.

11. A packet header processing device, characterized in that: include: A processing module, used to process the fields in the IPv6 message header according to the fields in the BIER message header explicitly copied by bit index in at least one of the following ways: using the BIER message header explicitly copied by bit index as the type of the routing extension header of the IPv6 message header, and processing the remaining segments Segments Left field in the IPv6 message header in a predefined manner; using the BIER message header explicitly copied by bit index as the type of the routing extension header of the IPv6 message header, and processing the remaining segments Segments Left field in the IPv6 message header in a predefined manner, and using the BIER message header explicitly copied by bit index as the type of other extension headers of the IPv6 message header, wherein the type of the other extension header includes options in the Hop-by-Hop extension header; in the source address Source of the IPv6 message header The bit index explicitly copied BIER message header’s bit forwarding router routing prefix BFR-Prefix is ​​filled into the Address field; the bit index explicitly copied BIER message header’s bit index forwarding table index BIFT-ID field is embedded into the target field of the IPv6 message header, wherein, The remaining segments Segments Left field in the IPv6 packet header is processed in a predefined manner, including at least one of the following: The remaining segments Segments Left field is set to a target value, so that all nodes ignore processing of the remaining segments Segments Left field; The Segments Left field value of the bit forwarding ingress router BFIR is set to 255. When the intermediate node forwards the message hop by hop, the field value is reduced by 1. When the field value is 0, it indicates that a loop occurs in the message forwarding process; The bit forwarding ingress router BFIR sets the Segments Left field value of the ingress node to the maximum number of hops to reach the edge device. When the intermediate node forwards the message hop by hop, the field value is reduced by 1. When the field value is 0, it indicates that a loop occurs in the message forwarding process; The remaining segments Segments Left field value of the bit forwarding inlet router BFIR is set to 255. When the intermediate node forwards the message hop by hop, the field value is reduced by 1. When the IPv6 message with the remaining segments Segments Left field value of 255 reaches the bit forwarding egress router BFER, the number of hops that the IPv6 message has passed is calculated according to the current remaining segments Segments Left field value; The Segments Left field value of the remaining segments is set to the maximum boundary value of the boundary that the IPv6 message is to pass through. When passing through the boundary, the field value is reduced by 1. When the field value is 0, it indicates that the message has reached the maximum boundary and can no longer be forwarded to the next area.

12. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, wherein the computer program implements the steps of the method described in any one of claims 1 to 10 when executed by a processor.

13. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the computer program, the steps of the method described in any one of claims 1 to 10 are implemented.

Images