WO2022142390A1 - 报文封装、解封装方法、装置、存储介质及电子装置 - Google Patents

报文封装、解封装方法、装置、存储介质及电子装置 Download PDF

Info

Publication number
WO2022142390A1
WO2022142390A1 PCT/CN2021/113849 CN2021113849W WO2022142390A1 WO 2022142390 A1 WO2022142390 A1 WO 2022142390A1 CN 2021113849 W CN2021113849 W CN 2021113849W WO 2022142390 A1 WO2022142390 A1 WO 2022142390A1
Authority
WO
WIPO (PCT)
Prior art keywords
header
ipv6
bier
packet
encapsulation
Prior art date
Application number
PCT/CN2021/113849
Other languages
English (en)
French (fr)
Inventor
魏月华
张征
Original Assignee
中兴通讯股份有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 中兴通讯股份有限公司 filed Critical 中兴通讯股份有限公司
Priority to EP21913137.2A priority Critical patent/EP4274123A4/en
Priority to US18/270,055 priority patent/US20240073128A1/en
Publication of WO2022142390A1 publication Critical patent/WO2022142390A1/zh

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/56—Routing software
    • H04L45/566—Routing instructions carried by the data packet, e.g. active networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/74—Address processing for routing
    • H04L45/745—Address table lookup; Address filtering
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/16—Multipoint routing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/34—Source routing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/74—Address processing for routing
    • H04L45/741—Routing in networks with a plurality of addressing schemes, e.g. with both IPv4 and IPv6
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0876—Network architectures or network communication protocols for network security for authentication of entities based on the identity of the terminal or configuration, e.g. MAC address, hardware or software configuration or device fingerprint
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/16—Implementing security features at a particular protocol layer
    • H04L63/166—Implementing security features at a particular protocol layer at the transport layer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1095—Replication or mirroring of data, e.g. scheduling or transport for data synchronisation between network nodes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/563—Data redirection of data network streams
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22—Parsing or analysis of headers

Definitions

  • the embodiments of the present application relate to the field of communications, and in particular, to a packet encapsulation and decapsulation method, device, storage medium, and electronic device.
  • IPv6 is the abbreviation of "Internet Protocol Version 6" (Internet Protocol Version 6) in English. It is the next-generation IP protocol designed by the Internet Engineering Task Force (IETF) to replace IPv4. The number of addresses is known as the An address can be programmed for every grain of sand in the world. After years of development of IPv6 technology, the latest standard is RFC8200. The biggest problem of IPv4 is the lack of network address resources, which seriously restricts the application and development of the Internet. 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.
  • IETF Internet Engineering Task Force
  • BIER Bit Indexed Explicit Replication, Bit Index Explicit Replication
  • the intermediate node forwarding device passes the routing protocol in advance, such as OSPF (OSPF Open Shortest Path First, Open Shortest Path First) protocol in the three-layer network, ISIS (Intermediate System-to-Intermediate System, intermediate system to intermediate system) protocol, form The BIFT (Bit Index Forwarding Table, Bit Index Forwarding Table) table used to guide BIER forwarding, when receiving the traffic encapsulated with the BIER header, complete the forwarding of the message to the destination node according to BIFT.
  • OSPF OSPF Open Shortest Path First, Open Shortest Path First
  • ISIS Intermediate System-to-Intermediate System, intermediate system to intermediate system
  • BIFT Bit Index Forwarding Table
  • BIER is a data plane forwarding technology that eliminates the delay in establishing a multicast tree because it does not have the problem of establishing a multicast tree, and when a link or node problem occurs in the network, the convergence speed is the same as that of OSPF or ISIS, which is faster than the original multicast. Tree reconstruction reduces huge latency.
  • IPv6 technology has been researched for many years.
  • the fragmentation mechanism defined in RFC8200 provides a good mechanism to transform the packet into multiple small packets for transmission when the packet is too large and the path cannot be directly transmitted.
  • ESP RRC4303 also Provides a guarantee mechanism for the security of the message. There is no problem when these two extension headers are used alone, but if they are combined with the BIER technology, the packets cannot be organized, and the logic may be confused and cannot be parsed.
  • the intermediate device will process the fragmentation/AH/ESP extension header after processing the DOH, but in fact the fragmentation/AH/ESP extension header does not need to be processed by the intermediate device, resulting in redundant judgment or processing. Device performance is degraded and may cause erroneous processing. However, if other means such as configuration or mandatory commands are used to make the intermediate device not process the fragment/AH/ESP extension header located after the BIER option header of the DOH, this process is not a general process and will affect other normal processes that do not carry the BIER header. IPv6 packet processing.
  • IPv6 header is encapsulated after the DOH that carries the BIER option header, and the fragmentation/AH/ESP extension header is placed after the IPv6 header, filling in the destination IPv6 address in the IPv6 header becomes a problem again. Fill in 0, The device needs to do special processing for the IPv6 address in this case, and assigning a special address alone will increase the control complexity.
  • draft-zzhang-tsvwg-generic-transport-functions-00 proposes a general fragmentation header mechanism GFH (Generic Fragmentation Header), which can be combined with other technologies to solve the logical problem of packet processing on the transmission path. For example, it can be easily combined with BIERin6 technology (draft-zhang-bier-bierin6-07). But when the BIER header (the format is the same as or similar to that defined in RFC8296) is combined with IPv6 using a similar method in draft-xie-bier-ipv6-encapsulation, no efficient and concise solution has been proposed.
  • GFH Generic Fragmentation Header
  • Embodiments of the present application provide a packet encapsulation and decapsulation method, device, storage medium, and electronic device, so as to at least solve the problem of how to combine the general fragmentation header mechanism in the related art with the BIER header encapsulated in the IPv6 extension header .
  • a packet encapsulation method comprising:
  • the bit index is explicitly copied and the BIER header is encapsulated in the 6th edition of the Internet Protocol. in the IPv6 extension header of an IPv6 packet.
  • a packet decapsulation method comprising:
  • a device for encapsulating a message includes:
  • the first encapsulation module is configured to combine with the general fragmentation header GFH, the general encapsulation security header GESP or the general authentication header GAH, and encapsulate the bit index explicit copy BIER header in the IPv6 extension header of the Internet Protocol Version 6 IPv6 message.
  • a packet decapsulation device comprising:
  • the decapsulation module is configured to decapsulate the bit index from the IPv6 extension header of the IPv6 message of the Internet Protocol Version 6 and explicitly copy the BIER header, wherein the BIER header is combined with the general fragmentation header GFH, the general encapsulation security header GESP or the general The authentication header GAH is combined and encapsulated in the IPv6 extension header.
  • a computer-readable storage medium is also provided, where a computer program is stored in the storage medium, wherein the computer program is configured to execute any one of the above method embodiments when running steps in .
  • an electronic device comprising a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to execute any one of the above Steps in Method Examples.
  • the embodiment of the present application combined with the general fragmentation header GFH, the general encapsulation security header GESP, or the general authentication header GAH, explicitly duplicates the bit index BIER header and encapsulates it in the IPv6 extension header of the Internet Protocol Version 6 IPv6 message, which can solve related problems.
  • the problem of how to combine the general fragmentation header mechanism in technology with the BIER header encapsulated in the IPv6 extension header is to realize that when the BIER header is encapsulated in the IPv6 extension header, it is different from the general fragmentation header/general encapsulation security header/general authentication header. Combined, the functions of fragmentation, encapsulation security and authentication of BIER multicast packets can be implemented concisely and efficiently.
  • FIG. 1 is a block diagram of a hardware structure of a mobile terminal of a message encapsulation or decapsulation method according to an embodiment of the present application
  • FIG. 2 is a flowchart of a message encapsulation method according to an embodiment of the present application
  • FIG. 3 is a flowchart of a message decapsulation method according to an embodiment of the present application.
  • FIG. 4 is a schematic diagram 1 of message encapsulation according to the present embodiment.
  • FIG. 5 is a second schematic diagram of packet encapsulation according to the present embodiment.
  • FIG. 6 is a schematic diagram of a BIER technology transmission network according to the present embodiment.
  • FIG. 7 is a flowchart 1 of data packet encapsulation according to the present preferred embodiment.
  • FIG. 8 is a flow chart 1 of the device according to this embodiment performing decapsulation processing on a packet.
  • FIG. 9 is a flow chart 2 of data packet encapsulation according to the present preferred embodiment.
  • FIG. 10 is a flow chart 2 of the device according to the present embodiment performing decapsulation processing on a message
  • FIG. 11 is a flow chart 3 of data packet encapsulation according to the present preferred embodiment.
  • FIG. 12 is a flowchart 3 of the device decapsulating a message according to the present embodiment.
  • FIG. 13 is a fourth flowchart of data packet encapsulation according to the present preferred embodiment.
  • FIG. 14 is a fourth flowchart of the device decapsulating a message according to the present embodiment.
  • 15 is a block diagram of a message encapsulation apparatus according to the present embodiment.
  • FIG. 16 is a block diagram of a packet decapsulation apparatus according to the present embodiment.
  • FIG. 1 is a block diagram of the hardware structure of a mobile terminal of a message encapsulation or decapsulation method according to an embodiment of the present application.
  • the router may include one or more (only shown in FIG. 1 ).
  • a processor 102 may include, but is not limited to, a processing device such as a microprocessor MCU or a programmable logic device FPGA, etc.
  • a memory 104 for storing data
  • the above router may also include a communication function
  • the transmission device 106 and the input and output device 108 can understand that the structure shown in FIG. 1 is for illustration only, and does not limit the structure of the above router.
  • a router may also include more or fewer components than shown in FIG. 1 , or have a different configuration than that shown in FIG. 1 .
  • the memory 104 may be used to store computer programs, for example, software programs and modules of application software, such as computer programs corresponding to the packet encapsulation or decapsulation methods in the embodiments of the present application.
  • the processor 102 runs the computer programs stored in the memory 104 , so as to perform various functional application processes, that is, to implement the above method.
  • Memory 104 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory.
  • memory 104 may further include memory located remotely from processor 102, which may be connected to a router through a network. Examples of such networks include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.
  • Transmission means 106 are used to receive or transmit data via a network.
  • the specific example of the above-mentioned network may include the wireless network provided by the communication provider of the mobile terminal.
  • the transmission device 106 includes a network adapter (Network Interface Controller, NIC for short), which can be connected to other network devices through a base station so as to communicate with the Internet.
  • the transmission device 106 may be a radio frequency (Radio Frequency, RF for short) module, which is used to communicate with the Internet in a wireless manner.
  • RF Radio Frequency
  • FIG. 2 is a flowchart of a packet encapsulation method according to an embodiment of the present application. As shown in FIG. 2 , the process includes the following steps :
  • Step S202 combined with the general fragmentation header GFH, the general encapsulation security header GESP or the general authentication header GAH, and encapsulates the bit index explicit copy BIER header in the IPv6 extension header of the Internet Protocol Version 6 IPv6 message.
  • the IPv6 extension header is HBH (Hop-by-Hop Options Header, Hop-by-Hop Options Header), DOH (Destination Options Header, Address Options Header) or RH (Routing Header, Routing Header).
  • the Proto field of the BIER header is set to a value G_TBD_X for indicating the GFH, the GESP or the GAH, wherein the values of the GFH, the GESP and the GAH are G_TBD_X is different.
  • the GFH, the GESP or the GAH is encapsulated, wherein the Next Header in the GFH, the GESP or the GAH is used to indicate the packet type transmitted by the BIER.
  • the Next Header field of the IPv6 extension header is set to 59.
  • an IPv6 header is encapsulated in the outer layer of the IPv6 extension header, wherein the Next Header field in the IPv6 header is used to indicate that the IPv6 header is followed by the HBH, the DOH or the described RH.
  • the Proto field of the BIER header is set to 0 or other reserved value.
  • the GFH, the GESP or the GAH is encapsulated, wherein the Next Header in the GFH, the GESP or the GAH is used to indicate the packet type transmitted by the BIER.
  • the Next Header field of the IPv6 extension header is set to an upper layer protocol value UL_TBD_X for indicating the GFH, the GESP or the GAH.
  • an IPv6 header is encapsulated in the outer layer of the IPv6 extension header, wherein the Next Header field in the IPv6 header is used to indicate that the IPv6 header is followed by the HBH, the DOH or the described RH.
  • FIG. 3 is a flowchart of the packet decapsulation method according to an embodiment of the present application. As shown in FIG. 3 , the process includes the following steps:
  • Step S302 decapsulate the bit index and explicitly copy the BIER header from the IPv6 extension header of the Internet Protocol Version 6 IPv6 message, wherein the BIER header and the general fragmentation header GFH, the general encapsulation security header GESP or the general authentication header GAH Combined, encapsulated in the IPv6 extension header.
  • step S302 may specifically include:
  • processing the IPv6 extension header and the BIER header in the IPv6 extension header optionally, before step S3021, further includes decapsulating the IPv6 header, and obtaining the IPv6 header according to the Next Header field of the IPv6 header IPv6 extension header HBH, DOH or RH;
  • S3023 if it is an egress device, carry out packet processing and forwarding according to the Next Header field of the IPv6 extension header and/or the Proto field in the BIER header, further, S3023 may specifically include: if the Proto field of the BIER header field is the value G_TBD_X used to indicate the GFH, the GESP or the GAH, and/or the Next Header field of the IPv6 extension header is 59, then the IPv6 extension header is stripped, and according to the BIER header
  • the value G_TBD_X of the Proto field carries out the analysis of general fragmentation, general encapsulation security or general authentication message; if the Proto field of the BIER header is 0 and/or the Next Header field of the IPv6 extension header is the upper layer protocol value UL_TBD_X, Then, the general fragmentation, general encapsulation security or general authentication packets are parsed according to the IPv6 upper layer protocol.
  • This application takes the BIER header encapsulated in DOH, HBH or RH as an example, and proposes a method to be used in combination with technologies such as general fragmentation, general encapsulation security, and general authentication, so that BIER messages can be sent in not limited to DOH, HBH or RH, etc.
  • encapsulation it can be used in combination with technologies such as general sharding, general encapsulation security, and general authentication, and logically implement functions such as sharding, encapsulation security, or authentication.
  • This application proposes two packet encapsulation and processing methods, which can realize that when the BIER header is encapsulated in the IPv6 extension header, it can be combined with the general fragmentation header/general encapsulation security header/general authentication header, and jump out of the processing procedures of RFC8200. Simple and efficient implementation of BIER multicast packet fragmentation, encapsulation security and authentication functions.
  • Packet encapsulation and processing method 1 The encapsulation method of IPv6 Header remains unchanged, and the Next Header field is still filled with 0, or 60, or 43, etc., indicating that it is an IPv6 extension header such as HBH, DOH, or RH.
  • IPv6 extension headers such as HBH/DOH/RH no longer fills in the value of the IPv6 extension header that indicates fragmentation/encapsulation security/authentication defined in RFC8200, but fills in 59 (IPv6-NoNxt), using 59 is borrowed from the existing definition of RFC8200, indicating that there is no other IPv6 extension header or protocol packet after the IPv6 extension header.
  • FIG. 4 is a schematic diagram 1 of packet encapsulation according to this embodiment.
  • the Proto field is filled with the value G_TBD_X representing GFH.
  • Fig. 5 is a schematic diagram 2 of packet encapsulation according to this embodiment.
  • the Proto field of the header is filled with the value representing GESP.
  • the Proto field is filled in to indicate that the case of GAH is similar to that in Figure 4 or 5, and will not be repeated here.
  • the encapsulation security header GESP or the general authentication header GAH is combined with the BIER header encapsulated in IPv6 extension headers such as HBH/DOH/RH to realize the fragmentation, encapsulation security and authentication functions of BIER multicast packets.
  • the Next Header in GFH/GESP/GAH fills in the type of packets transmitted by BIER, including Ethernet/MPLS/IPv4/IPv6, etc.
  • the device After the device receives the above message, it first processes the IPv6 extension headers such as HBH/DOH/RH, and then processes the BIER header carried in the HBH/DOH/RH.
  • the processing flow of the BIER header and the judgment of whether to export the device are performed according to the principles defined in RFC8279. . If the local device is an intermediate device, the forwarding is performed after processing the HBH/DOH/RH. If this device is an export device, HBH/DOH/RH will be stripped and GFH/GESP/GAH will be processed according to the Proto instructions in the BIER header.
  • the BIER encapsulated in the IPv6 extension header can be used in combination with GFH/GESP/GAH, and the functions of fragmentation, encapsulation security and authentication of BIER multicast packets can be implemented concisely and efficiently.
  • Service Function Chain Service Function Chain
  • NSH Network Service Header
  • Processing is similar when the BIER head is located at HBH/DOH/RH.
  • the only difference is that the Next Header of the IPv6 header is set to 60 for DOH, 0 for HBH, and 43 for RH.
  • the following takes DOH as an example for description.
  • the NSH header of the SFC protocol is located in HBH/DOH/RH, the processing method is similar.
  • Fig. 6 is a schematic diagram of the BIER technology transmission network according to this embodiment.
  • the network entry device BFIR receives a multicast message and finds that it needs to be transmitted through the BIER technology, and the message is too large and exceeds this
  • the maximum transmission unit of the network is set, after the packet is fragmented, when a single fragmented packet is encapsulated, the positions of the fields are shown in Figure 4, and Figure 7 is the process of data packet encapsulation according to this preferred embodiment.
  • Step S701 encapsulating GFH
  • the encapsulation process of GFH is the same as the fragmentation process defined in RFC8200
  • the original multicast packet type value is filled into the Next Header field of GFH
  • the original multicast packet is an IPv4 packet
  • the original multicast packet is an IPv6 packet
  • fill in 41. 4 or 41 conforms to the IANA standard https://www.iana.org/assignments/protocol-numbers/protocol -numbers.xhtml
  • Step S702 DOH encapsulation, the NH of DOH is set to 59, the Next Header field of DOH, instead of filling in the original value of 44 (IPv6-Frag) for the fragment header, fill in 59 (IPv6-NoNxt), using 59 is borrowed from RFC8200
  • IPv6-Frag the original value of 44
  • IPv6-NoNxt the Next Header field of DOH
  • Step S703 encapsulate the BIER header, encapsulate the BIER header into the DOH as an option, and fill in the Proto field of the BIER header as a value G_TBD_X representing GFH, such as 10.
  • This encapsulation method combines the GFH with the BIER header encapsulated in the DOH to achieve fragmentation of the message transmitted by the BIER, avoiding the additional processing overhead of the device caused by inserting the fragmentation extension header FH after the DOH.
  • Step S704 encapsulate the outer IPv6 header, and fill in the Next Header field with 60, indicating that the follow-up is DOH.
  • FIG. 8 is a flow chart 1 of a device performing decapsulation processing on a packet according to this embodiment, as shown in FIG. 8 , including:
  • Step 801 Process the outer IPv6 header, and find the extension header DOH according to the Next Header indication value of the IPv6 header 60.
  • Step 802 Process the DOH, read the NH value of 59, and find the BIER header according to the option type in the DOH. Because the Next Header field of the DOH is filled with 59 (IPv6-NoNxt), it is considered that there are no other IPv6 extension headers and other protocols after the DOH Packets will not cause additional processing overhead on the device, improving the processing and forwarding performance of the device.
  • Step 803 processing the BIER header, the processing flow of the BIER header is performed according to the principles defined in RFC8279.
  • Step 804 determine whether it is an export device, if the determination result is no, execute step S805, and if the determination result is yes, execute step S806;
  • Step S805 forward the message, if the device is an intermediate device, corresponding to the BFRm (Bit-Forwarding Router, bit forwarding router) and BFRn devices in Figure 6, after processing the BIER message, it is found that the device is not an export device, then processing After the DOH is completed, it continues to forward to the next hop of BIER, and does not process subsequent GFH packets. If the device is found to be an egress device, which corresponds to the BFER1 (Bit-Forwarding Egress Router, bit forwarding egress router) or BFER2 or BFER3 device in Figure 6, the DOH and outer IPv6 encapsulation will be stripped.
  • BFRm Bit-Forwarding Router, bit forwarding router
  • BFRn devices in Figure 6 after processing the BIER message, it is found that the device is not an export device, then processing After the DOH is completed, it continues to forward to the next hop of BIER, and does not process subsequent GFH packets. If the device is found to be an e
  • Step 806 according to the Proto in the BIER header indicating that the next is GFH, the GFH is processed, and the processing flow is performed with reference to the definition in draft-zzhang-tsvwg-generic-transport-functions. Therefore, the BIER encapsulated in the IPv6 extension header can still be used in combination with the general fragmentation header, and the problem of multicast packet transmission exceeding the maximum transmission unit of the network can be solved.
  • step 807 a fragmented packet is obtained, the GFH is processed, and after the packet is fragmented and reassembled, the packet is forwarded to the receiver.
  • FIG. 9 is a flowchart 2 of the data message encapsulation according to the present preferred embodiment, as shown in FIG. 9, which specifically includes:
  • Step 901 Perform ESP encapsulation on the data packet.
  • the encapsulation method adopts the definition in RFC4303, and the original multicast packet type value is filled into the Next Header field of the ESP.
  • the original multicast packet is an IPv4 packet, then The Next Header field of ESP is filled with 4. If the original multicast packet is an IPv6 packet, it is filled with 41.
  • Step 902 encapsulate DOH, the Next Header field of DOH, fill in as 59 (IPv6-NoNxt), use 59 to borrow the existing definition of RFC8200, indicating that there is no other IPv6 extension header or protocol message after the extension header;
  • Step 903 encapsulate the BIER header, set the Proto to G_TBD_X, encapsulate the BIER header into the DOH as an option, and fill in the Proto field of the BIER header as a value representing GESP, such as 20.
  • This encapsulation method combines GESP with the BIER header encapsulated in the DOH to implement the encapsulation security function of the message transmitted by the BIER, avoiding the extra processing overhead of the device caused by inserting the ESP extension header after the DOH.
  • Step 904 encapsulate the outer layer IPv6 header, encapsulate the IPv6 header in the outer layer of the DOH, and fill in the Next Header field with 60, indicating that the follow-up is DOH.
  • FIG. 10 is a second flowchart of the device decapsulating a packet according to this embodiment, as shown in FIG. 10 , including:
  • Step 1001 Process the outer IPv6 header, and find the extension header DOH according to the Next Header indication value 60 of the IPv6 header.
  • Step 1002 process the DOH, read the NH, and find the BIER header according to the option type in the DOH. Because the value of the Next Header field of the DOH is 59 (IPv6-NoNxt), it is considered that there are no other IPv6 extension headers and other protocol packets after the DOH. , will not cause additional processing overhead of the device, and improve the processing and forwarding performance of the device.
  • IPv6-NoNxt IPv6-NoNxt
  • Step 1003 Process the BIER header, read the Proto to know that the follow-up is GESP, the processing flow of the BIER header and the judgment of whether to export the device are performed according to the principles defined in RFC8279.
  • Step 1004 determine whether it is an export device, if the determination result is no, execute step S1005, and if the determination result is yes, execute step S1006;
  • Step 1005 Forward the message. If the device is an intermediate device, corresponding to the BFRm and BFRn devices in Figure 6, and after processing the BIER message, it is found that the device is not an egress device, and then forwards it to the next hop of BIER after processing the DOH. , do not process subsequent GESP packets. If it is found that this device is an egress device, which corresponds to the BFER1, BFER2, or BFER3 device in Figure 6, the DOH and the outer IPv6 encapsulation are stripped.
  • Step 1006 Process the GESP according to the Proto indication in the BIER header, and the GESP processing flow is performed with reference to the definition in RFC4303. Therefore, the BIER encapsulated in the IPv6 extension header can still be used in combination with the general encapsulation security header, thereby solving the problem of secure transmission of multicast packet encapsulation.
  • Step 1007 Obtain the security encapsulation packet, process the GESP, and send the packet to the receiver after passing the security judgment. If the packet fails the security judgment, the packet is discarded.
  • the network entry device may also choose other security methods, such as AH.
  • AH Next Header field of the DOH is still filled with 59 (IPv6-NoNxt), indicating that there are no other IPv6 extension headers after the DOH. As well as other protocol packets, it will not cause additional processing overhead of the device, and improve the processing and forwarding performance of the device.
  • the Proto in the BIER header is filled in as the type value representing GAH, and the use of GAH is in compliance with RFC4302. In this way, the BIER encapsulated in the IPv6 extension header can still be used in combination with the general authentication header to solve the problem of multicast packet authentication.
  • ESP can also be used in conjunction with AH.
  • AH conforms to RFC4303.
  • AH will be used as a component of GESP, and the above-mentioned encapsulation method and processing flow are adopted at this time. Therefore, BIER can be used in combination with encapsulation security and authentication to improve the security of multicast packets.
  • Packet encapsulation and processing method 2 The encapsulation method of the IPv6 Header remains unchanged, and the Next Header field is still filled with 0, or 60, or 43, indicating that it is an HBH, or DOH, or RHIPv6 extension header.
  • the Next Header field in HBH/DOH/RH cannot be filled with the value of the IPv6 extension header defined in RFC8200 that indicates fragmentation/encapsulation security/authentication, but is filled with the value UL_TBD_X that directly represents the upper layer protocol of GFH/GESP/GAH.
  • the device can jump out of the IPv6 extension header processing procedure defined by RFC8200, avoiding the extra overhead of IPv6 extension header processing.
  • the Proto field is filled with 0 or other reserved values, which is not used as the judgment of the subsequent packet type. This avoids the errors that may be caused by both the Next Header and BIER Proto of HBH/DOH/RH indicating GFH/GESP/GAH together.
  • the Next Header in GFH/GESP/GAH fills in the type of packets transmitted by BIER, including Ethernet/MPLS/IPv4/IPv6, etc.
  • the device After receiving the above packet, the device first processes IPv6 extension headers such as HBH/DOH/RH, and then processes the BIER header carried in HBH/DOH/RH.
  • IPv6 extension headers such as HBH/DOH/RH
  • the processing flow of the BIER header and the judgment of whether to export the device are carried out according to the principles defined in RFC8279. Whether to process GFH/GESP/GAH is judged according to the processing flow of the BIER header. If it is an intermediate device, it will forward it after processing HBH/DOH/RH. If found to be an export device, HBH/DOH/RH is stripped and GFH/GESP/GAH is processed according to the Next Header in HBH/DOH/RH.
  • the BIER node determines whether it needs to be processed. If the device is a non-export device, it will not be processed. If the device is an export device, then Process to realize the combined application of BIER and GFH/GESP/GAH. In this way, the fragmentation, encapsulation security and authentication functions of multicast packets are implemented.
  • the processing overhead of the IPv6 extension header of the device will not be occupied, and the message processing efficiency of the device can be improved.
  • Service Function Chain Service Function Chain
  • NSH Network Service Header
  • the GFH/GESP/GAH technology is still under development, and the fields carried in the GFH, the field location and length and other information may change in the future, but the purpose of this application is to implement the encapsulation in the BIER header and the IPv6 extension header.
  • the general fragmentation header/general encapsulation security header/general authentication header it jumps out of the limitations of the processing procedures of RFC8200, and realizes the fragmentation, encapsulation security and authentication functions of BIER multicast packets concisely and efficiently.
  • the Next Header field has the same meaning as the Next protocol, protocol, Proto and other fields, and both indicate the type of the packet/protocol carried.
  • Processing is similar when the BIER head is located at HBH/DOH/RH.
  • the only difference is that the Next Header of the IPv6 header is set to 60 for DOH, 0 for HBH, and 43 for RH.
  • the following takes DOH as an example for description.
  • the forwarding headers of other protocols such as NSH of the SFC protocol are located in HBH/DOH/RH, the processing method is similar.
  • FIG. 11 is a flowchart 3 of data packet encapsulation according to this preferred embodiment, as shown in FIG. 11 , including:
  • Step 1101 Encapsulate GFH.
  • the encapsulation process of GFH is similar to the fragmentation process defined in RFC8200, and the original multicast packet type value is filled into the Next Header field of GFH, for example, the original multicast packet is an IPv4 packet. If the original multicast packet is an IPv6 packet, fill in 41 in the Next Header field of the GFH.
  • Step 1102 encapsulate DOH, and perform DOH encapsulation on the outer layer of GFH.
  • the Next Header field of DOH does not fill in the original value of 44 (IPv6-Frag) for the fragment header, but fills in a new value, that is, the value allocated for GFH.
  • the upper-layer protocol (Upper-Layer header) value is UL_TBD_X, such as 145. This encapsulation method not only realizes the GFH fragmentation function, but also allows the device to jump out of the IPv6 extension header processing procedure defined by RFC8200, avoiding the extra overhead of IPv6 extension header processing.
  • Step 1103 encapsulate the BIER header, set the Proto of the BIER to 0 or other reserved values, and encapsulate the BIER header into the DOH as an option.
  • This encapsulation method avoids the errors that may be caused by GFH being jointly indicated by DOH's Next Header and BIER Proto.
  • Step 1104 encapsulate the outer layer IPv6 header, encapsulate the IPv6 header in the outer layer of the DOH, and fill in the Next Header field with 60, indicating that the following is the DOH.
  • FIG. 12 is a flowchart 3 of the device decapsulating a packet according to this embodiment, as shown in FIG. 12 , including:
  • Step 1201 processing the IPv6 header, and finding the extension header DOH according to the Next Header indication value 60 of the IPv6 header.
  • Step 1202 process DOH, because the Next Header field of DOH is filled with a value indicating the upper-layer protocol (Upper-Layer header) (eg 145), this value indicates that the Next header is not an IPv6 extension header, so it will be considered that there is no other IPv6 extension after DOH head. And find the BIER header according to the option type in DOH.
  • Upper-Layer header eg 145
  • Step 1203 Process the BIER header, read the Proto value as 0 or other reserved values, the processing flow of the BIER header and the judgment of whether to export the device are performed according to the principles defined in RFC8279.
  • Step 1204 determine whether it is an export device, if the determination result is no, go to step S1205, and if the determination result is yes, go to step S1206;
  • Step 1205 Forward the message. If the device is an intermediate device, corresponding to the BFRm and BFRn devices in Figure 6, and after processing the BIER message, it is found that the device is not an egress device, and then forwards it to the next hop of BIER after processing the DOH. ; If the device is found to be an egress device, which corresponds to the BFER1 or BFER2 or BFER3 device in Figure 6, the DOH and outer IPv6 encapsulation will be stripped. In this case, since GFH is an upper-layer protocol rather than an extension header, the BIER node determines whether it needs to be processed. If the device is not an export device, it will not be processed, and if the device is an export device, it will be processed. So as to realize the combined application of BIER and GFH.
  • Step 1206 Process the GFH according to the Next Header instruction in the DOH, and the process of processing the GFH is performed with reference to the definition in draft-zzhang-tsvwg-generic-transport-functions-00.
  • the general fragmentation processing of multicast packets is realized, and the packets exceeding the maximum transmission unit of the network can still be transmitted smoothly.
  • step 1207 a fragmented packet is obtained, the GFH is processed, and after the packet is fragmented and reassembled, the packet is forwarded to the receiver.
  • FIG. 13 is a fourth flowchart of data packet encapsulation according to the present preferred embodiment, as shown in FIG. 13 , including:
  • Step 1301 Encapsulate GESP, and perform GESP encapsulation on the data packet.
  • the encapsulation method adopts the definition in RFC4303, and fills the original multicast packet type value into the Next Header field of GESP.
  • the original multicast packet is an IPv4 packet. If the original multicast packet is an IPv6 packet, fill in 41 in the Next Header field of GESP.
  • Step 1302 encapsulate DOH.
  • the Next Header field of DOH is not filled with the original value of 50 representing ESP, but filled with a new upper-layer protocol value allocated for GESP, such as 180; this encapsulation method not only implements GESP encapsulation
  • the security function also allows the device to jump out of the IPv6 extension header processing procedure defined by RFC8200, avoiding the extra overhead of IPv6 extension header processing.
  • Step 1303 encapsulate the BIER header, set the Proto of the BIER to 0 or other reserved values, encapsulate the BIER header into the DOH as an option, and fill in the Proto field of the BIER header with 0.
  • This encapsulation method avoids the confusion caused by both the Next Header of DOH and the BIER Proto indicating GESP together.
  • Step 1304 Encapsulate the outer layer IPv6 header, encapsulate the IPv6 header in the outer layer of the DOH, and fill in the Next Header field with 60, indicating that the follow-up is DOH.
  • FIG. 14 is a fourth flowchart of the device decapsulating a packet according to this embodiment, as shown in FIG. 14 , including:
  • Step 1401 processing the IPv6 header, and finding the extension header DOH according to the Next Header indication value 60 of the IPv6 header.
  • Step 1402 processing DOH, because the Next Header field of DOH has a value (Upper-Layer header) UL_TBD_X (for example, 180) indicating the upper-layer protocol, this value indicates that the Nextheader is not an IPv6 extension header, so GESP will be used as the upper-layer protocol. And find the BIER header according to the option type in DOH.
  • UL_TBD_X for example, 180
  • Step 1403 Process the BIER header, read the Proto value as 0 or other reserved values, the processing flow of the BIER header and the judgment of whether to export the device are performed according to the principles defined in RFC8279.
  • Step 1404 determine whether it is an export device, if the determination result is no, execute step S1405, and if the determination result is yes, execute step S1406;
  • Step 1405 if the device is an intermediate device, corresponding to the BFRm and BFRn devices in FIG. 6, and after processing the BIER message, it is found that the device is not an egress device, after processing the DOH, it continues to forward it to the next hop of the BIER, and does not process subsequent packets. GESP packets. If it is found that this device is an egress device, which corresponds to the BFER1, BFER2, or BFER3 device in Figure 6, the DOH and the outer IPv6 encapsulation are removed. In this case, because GESP is an upper-layer protocol rather than an IPv6 extension header, the BIER node determines whether processing is required. If the device is a non-export device, it will not be processed, and if the device is an export device, it will be processed. So as to realize the combined application of BIER and GESP.
  • Step 1406 Process the GESP according to the Proto instruction in the BIER header, and the process of processing the GESP is performed with reference to the definition in RFC4303. In this way, the general encapsulation security processing of multicast packets is implemented, and the security of packet transmission is ensured.
  • Step 1407 Obtain the security encapsulation packet, process the GESP, and send the packet to the receiver after passing the security judgment. If the packet fails the security judgment, the packet is discarded.
  • the network entry device may also choose other security methods, such as AH.
  • the Next Header field of DOH is filled with the new upper-layer protocol value allocated by GAH, indicating that GAH is not an IPv6 extension header. It will not occupy the processing overhead of the IPv6 extension header of the device, and improve the processing and forwarding performance of the device; the use of GAH complies with RFC4302.
  • fill in the Proto field of BIER to 0, so as to avoid the confusion caused by both the Next Header of DOH and the BIER Proto indicating GAH together. In this way, the BIER encapsulated in the IPv6 extension header can still be used in combination with the general authentication header to solve the problem of multicast packet authentication.
  • ESP can also be used in conjunction with AH.
  • AH conforms to RFC4303.
  • AH will be used as a component of GESP, and the above-mentioned encapsulation method and processing flow are adopted at this time. Therefore, BIER can be used in combination with encapsulation security and authentication to improve the security of multicast packets.
  • the packet size exceeds the maximum transmission unit of the network after GESP or GAH encapsulation is performed on the packet, it needs to be fragmented, and then encapsulated and forwarded.
  • FIG. 15 is a block diagram of the packet encapsulation apparatus according to this embodiment. As shown in FIG. 15 , the apparatus includes:
  • the first encapsulation module 152 is configured to combine with the general fragmentation header GFH, the general encapsulation security header GESP or the general authentication header GAH, and encapsulate the bit index explicit copy BIER header in the IPv6 extension header of the Internet Protocol Version 6 IPv6 message.
  • the IPv6 extension header is HBH, DOH or RH.
  • the Proto field of the BIER header is set to a value G_TBD_X for indicating the GFH, the GESP or the GAH.
  • the apparatus further comprises: a second encapsulation module configured to encapsulate the GFH, the GESP or the GAH, wherein the Next in the GFH, the GESP or the GAH Header is used to indicate the packet type transmitted by BIER.
  • the Next Header field of the IPv6 extension header is set to 59.
  • the apparatus further includes: a third encapsulation module, configured to encapsulate an IPv6 header at the outer layer of the IPv6 extension header, wherein the Next Header field in the IPv6 header is used to indicate the The IPv6 header is followed by the HBH, the DOH or the RH.
  • a third encapsulation module configured to encapsulate an IPv6 header at the outer layer of the IPv6 extension header, wherein the Next Header field in the IPv6 header is used to indicate the The IPv6 header is followed by the HBH, the DOH or the RH.
  • the Proto field of the BIER header is set to 0 or other reserved value.
  • the apparatus further comprises: a fourth encapsulation module configured to encapsulate the GFH, the GESP or the GAH, wherein the Next in the GFH, the GESP or the GAH Header is used to indicate the packet type transmitted by BIER.
  • the Next Header field of the IPv6 extension header is set to an upper layer protocol value UL_TBD_X for indicating the GFH, the GESP or the GAH.
  • the apparatus further includes: a fifth encapsulation module, configured to encapsulate an IPv6 header at the outer layer of the IPv6 extension header, wherein the Next Header field in the IPv6 header is used to indicate the The IPv6 header is followed by the HBH, the DOH or the RH.
  • a fifth encapsulation module configured to encapsulate an IPv6 header at the outer layer of the IPv6 extension header, wherein the Next Header field in the IPv6 header is used to indicate the The IPv6 header is followed by the HBH, the DOH or the RH.
  • FIG. 16 is a block diagram of the packet decapsulation device according to this embodiment. As shown in FIG. 16 , the device includes:
  • the decapsulation module 162 is configured to decapsulate the BIER header by decapsulating the bit index from the IPv6 extension header of the IPv6 message of Internet Protocol Version 6, wherein the BIER header and the general fragmentation header GFH, the general encapsulation security header GESP or The general authentication header GAH is combined and encapsulated in the IPv6 extension header.
  • the decapsulation module 162 includes:
  • a first processing submodule configured to process the IPv6 extension header and the BIER header in the IPv6 extension header
  • the forwarding sub-module is set to forward packets if it is an intermediate device
  • the second processing submodule is set to, if it is an export device, to process and forward the message according to the Next Header field of the IPv6 extension header and/or the Proto field in the BIER header.
  • the second processing sub-module is further configured to, if the Proto field of the BIER header is a value G_TBD_X for indicating the GFH, the GESP or the GAH, and/or all The Next Header field of the described IPv6 extension header is 59, then strip the described IPv6 extension header, and carry out general fragmentation, general encapsulation security or general authentication message analysis according to the value G_TBD_X of the Proto field of the BIER header; if all If the Proto field of the BIER header is 0 and/or the Next Header field of the IPv6 extension header is the upper layer protocol value UL_TBD_X, then carry out general fragmentation, general encapsulation security or general authentication message analysis according to the IPv6 upper layer protocol.
  • Embodiments of the present application further provide a computer-readable storage medium, where a computer program is stored in the computer-readable storage medium, wherein the computer program is configured to execute the steps in any one of the above method embodiments when running.
  • the above-mentioned computer-readable storage medium may include, but is not limited to, a USB flash drive, a read-only memory (Read-Only Memory, referred to as ROM for short), and a random access memory (Random Access Memory, referred to as RAM for short) , mobile hard disk, magnetic disk or CD-ROM and other media that can store computer programs.
  • ROM Read-Only Memory
  • RAM Random Access Memory
  • Embodiments of the present application further provide an electronic device, including a memory and a processor, where 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.
  • the above-mentioned electronic device may further include a transmission device and an input-output device, wherein the transmission device is connected to the above-mentioned processor, and the input-output device is connected to the above-mentioned processor.
  • modules or steps of the present application can be implemented by a general-purpose computing device, and they can be centralized on a single computing device, or distributed in a network composed of multiple computing devices
  • they can be implemented in 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, can be performed in a different order than shown here.
  • the described steps, or they are respectively made into individual integrated circuit modules, or a plurality of modules or steps in them are made into a single integrated circuit module to realize.
  • the present application is not limited to any particular combination of hardware and software.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Power Engineering (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本申请实施例提供了一种报文封装、解封装方法、装置、存储介质及电子装置，该报文封装方法包括：与通用分片头GFH、通用封装安全头GESP或通用认证头GAH结合，将位索引显式复制BIER头封装在互联网协议第6版IPv6报文的IPv6扩展头中，可以解决相关技术中通用的分片头机制与封装在IPv6扩展头中的BIER头如何结合使用的问题，实现在BIER头封装在IPv6扩展头中时，与通用的分片头/通用封装安全头/通用认证头相结合，简洁高效的实现BIER组播报文的分片、封装安全和认证功能。

Description

报文封装、解封装方法、装置、存储介质及电子装置 技术领域
本申请实施例涉及通信领域，具体而言，涉及一种报文封装、解封装方法、装置、存储介质及电子装置。
背景技术
IPv6是英文“Internet Protocol Version 6”(互联网协议第6版)的缩写，是互联网工程任务组(Internet Engineering Task Force，简称为IETF)设计的用于替代IPv4的下一代IP协议，其地址数量号称可以为全世界的每一粒沙子编上一个地址。IPv6的技术经过多年的发展，目前最新的标准是RFC8200。由于IPv4最大的问题在于网络地址资源不足，严重制约了互联网的应用和发展。IPv6的使用，不仅能解决网络地址资源数量的问题，而且也解决了多种接入设备连入互联网的障碍。
BIER(Bit Indexed Explicit Replication，位索引显式复制)(RFC8279)是一种新型组播数据转发技术，该技术将网络边缘的节点都只用一个bit位来表示，组播流量在中间网络传输，额外封装一个特定的BIER头，这个报文头以bit位串的形式标注了该组播流的所有目的节点，中间网络转发节点根据bit位进行路由，保障流量能够发送到所有目的节点。中间节点转发设备事先通过路由协议，如三层网络中的OSPF(OSPF Open Shortest Path First，开放式最短路径优先)协议，ISIS(Intermediate System-to-Intermediate System，中间系统到中间系统)协议，形成用于指导BIER转发的BIFT(Bit Index Forwarding Table，位索引转发表)表，在收到封装BIER头的流量时，依据BIFT来完成报文到目的节点的转发。BIER这种数据面转发技术因为没有组播树的建立问题，消除了组播树建立的时延，并且在网络出现链路或者节点问题时，收敛速度同OSPF或ISIS协议，比原来的组播树重建降低了巨大的时延。
IPv6技术研究已经多年，RFC8200里定义的分片机制，在报文过大，路径无法直接传输时，提供很好的机制将报文变成多个小报文进行传输，另外ESP(RFC4303)也为报文的安全提供了保障机制。这两个扩展头单独使用的时候并没有问题，但如果将其与BIER技术结合起来，存在报文无法组织，可能出现逻辑混乱无法解析的情况。
draft-xie-bier-ipv6-encapsulation-08中提出将分片或者AH/ESP(Authentication Header/Encapsulating Security Payload，认证头/封装安全)扩展头作为IPv6普通扩展头放在DOH的BIER选项头后，再要求只有到BIER出口设备才需要处理分片/AH/ESP扩展头，这样的实现方式对网络的中间设备(非入口/出口设备)有特殊要求，即按照RFC8200国际标准规定的的IPv6报文处理流程，中间设备将在处理完DOH后接着处理分片/AH/ESP扩展头，但实际上分片/AH/ESP扩展头并不需要中间设备进行处理，由此造成冗余判断或处理，设备性能降低，并且可能造成错误处理。而如果采取其他手段比如配置，或者强制命令让中间设备不处理位于DOH的BIER选项头后的分片/AH/ESP扩展头，这个流程又并非通用流程，会影响到其他没有携带BIER头的正常IPv6报文处理。另外，如果在携带BIER选项头的DOH后再 封装IPv6头，再将分片/AH/ESP扩展头放在该IPv6头之后的话，IPv6头里的目的IPv6地址填写又成为问题，填写为0，需要设备针对在这种情况的IPv6地址做特殊处理，单独分配一个特殊地址又会增加控制复杂度。
draft-zzhang-tsvwg-generic-transport-functions-00提出一种通用的分片头机制GFH(Generic Fragmentation Header)，可以与其他技术结合，从而解决报文在传输路径上的处理逻辑问题。例如可以很容易的和BIERin6技术(draft-zhang-bier-bierin6-07)结合使用。但当BIER头(格式与RFC8296中定义相同或者类似)采用draft-xie-bier-ipv6-encapsulation中类似的方法与IPv6结合时，则还没有提出高效简洁的解决方案。
发明内容
本申请实施例提供了一种报文封装、解封装方法、装置、存储介质及电子装置，以至少解决相关技术中通用的分片头机制与封装在IPv6扩展头中的BIER头如何结合使用的问题。
根据本申请的一个实施例，提供了一种报文封装方法，所述方法包括：
与通用分片头GFH、通用封装安全头(Generic Encapsulating Security Payload，简称为GESP)或通用认证头(Generic Authentication Header，简称为GAH)结合，将位索引显式复制BIER头封装在互联网协议第6版IPv6报文的IPv6扩展头中。
根据本申请的另一个实施例，还提供了一种报文解封装方法，所述方法包括：
从互联网协议第6版IPv6报文的IPv6扩展头中解封装出位索引显式复制BIER头，其中，所述BIER头与通用分片头GFH、通用封装安全头GESP或通用认证头GAH结合，封装在所述IPv6扩展头中。
根据本申请的另一个实施例，还提供了一种报文封装装置，所述装置包括：
第一封装模块，设置为与通用分片头GFH、通用封装安全头GESP或通用认证头GAH结合，将位索引显式复制BIER头封装在互联网协议第6版IPv6报文的IPv6扩展头中。
根据本申请的另一个实施例，还提供了一种报文解封装装置，所述装置包括：
解封装模块，设置为从互联网协议第6版IPv6报文的IPv6扩展头中解封装出位索引显式复制BIER头，其中，所述BIER头与通用分片头GFH、通用封装安全头GESP或通用认证头GAH结合，封装在所述IPv6扩展头中。
根据本申请的又一个实施例，还提供了一种计算机可读的存储介质，所述存储介质中存储有计算机程序，其中，所述计算机程序被设置为运行时执行上述任一项方法实施例中的步骤。
根据本申请的又一个实施例，还提供了一种电子装置，包括存储器和处理器，所述存储器中存储有计算机程序，所述处理器被设置为运行所述计算机程序以执行上述任一项方法实施例中的步骤。
本申请实施例，与通用分片头GFH、通用封装安全头GESP或通用认证头GAH结合，将位索引显式复制BIER头封装在互联网协议第6版IPv6报文的IPv6扩展头中，可以解决相关技术中通用的分片头机制与封装在IPv6扩展头中的BIER头如何结合使用的问题，实现在BIER头封装在IPv6扩展头中时，与通用的分片头/通用封装安全头/通用认证头 相结合，简洁高效的实现BIER组播报文的分片、封装安全和认证功能。
附图说明
图1是本申请实施例的报文封装或解封装方法的移动终端的硬件结构框图；
图2是根据本申请实施例的报文封装方法的流程图；
图3是根据本申请实施例的报文解封装方法的流程图；
图4是根据本实施例的报文封装的示意图一；
图5是根据本实施例的报文封装的示意图二；
图6是根据本实施例的BIER技术传输网络的示意图；
图7是根据本优选实施例的数据报文封装的流程图一；
图8是根据本实施例的设备对报文进行解封装处理的流程图一。
图9是根据本优选实施例的数据报文封装的流程图二；
图10是根据本实施例的设备对报文进行解封装处理的流程图二；
图11是根据本优选实施例的数据报文封装的流程图三；
图12是根据本实施例的设备对报文进行解封装处理的流程图三；
图13是根据本优选实施例的数据报文封装的流程图四；
图14是根据本实施例的设备对报文进行解封装处理的流程图四；
图15是根据本实施例的报文封装装置的框图；
图16是根据本实施例的报文解封装装置的框图。
具体实施方式
下文中将参考附图并结合实施例来详细说明本申请的实施例。
需要说明的是，本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。
本申请实施例中所提供的方法实施例可以在路由器、移动终端、计算机终端或者类似的运算装置中执行。以运行在路由器上为例，图1是本申请实施例的报文封装或解封装方法的移动终端的硬件结构框图，如图1所示，路由器可以包括一个或多个(图1中仅示出一个)处理器102(处理器102可以包括但不限于微处理器MCU或可编程逻辑器件FPGA等的处理装置)和用于存储数据的存储器104，其中，上述路由器还可以包括用于通信功能的传输设备106以及输入输出设备108。本领域普通技术人员可以理解，图1所示的结构仅为示意，其并不对上述路由器的结构造成限定。例如，路由器还可包括比图1中所示更多或者更少的组件，或者具有与图1所示不同的配置。
存储器104可用于存储计算机程序，例如，应用软件的软件程序以及模块，如本申请实施例中的报文封装或解封装方法对应的计算机程序，处理器102通过运行存储在存储器104内的计算机程序，从而执行各种功能应用处理，即实现上述的方法。存储器104可包括高速随机存储器，还可包括非易失性存储器，如一个或者多个磁性存储装置、闪存、或者其他非易失性固态存储器。在一些实例中，存储器104可进一步包括相对于处理器102远程设置的存储器，这些远程存储器可以通过网络连接至路由器。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。
传输装置106用于经由一个网络接收或者发送数据。上述的网络具体实例可包括移动终 端的通信供应商提供的无线网络。在一个实例中，传输装置106包括一个网络适配器(Network Interface Controller，简称为NIC)，其可通过基站与其他网络设备相连从而可与互联网进行通讯。在一个实例中，传输装置106可以为射频(Radio Frequency，简称为RF)模块，其用于通过无线方式与互联网进行通讯。
在本实施例中提供了一种运行于上述路由器或网络架构的网络切片连接方法，图2是根据本申请实施例的报文封装方法的流程图，如图2所示，该流程包括如下步骤：
步骤S202，与通用分片头GFH、通用封装安全头GESP或通用认证头GAH结合，将位索引显式复制BIER头封装在互联网协议第6版IPv6报文的IPv6扩展头中。
在一示例性实施例中，所述IPv6扩展头为HBH(Hop-by-Hop Options Header，逐跳选项头)、DOH(Destination Options Header，地址选项头)或RH(Routing Header，路由头)。
在一示例性实施例中，所述BIER头的Proto字段设置为用于指示所述GFH、所述GESP或所述GAH的值G_TBD_X，其中，所述GFH、所述GESP以及所述GAH的值G_TBD_X不同。
在一示例性实施例中，封装所述GFH、所述GESP或所述GAH，其中，所述GFH、所述GESP或所述GAH中的Next Header用于指示BIER传输的报文类型。
在一示例性实施例中，所述IPv6扩展头的Next Header字段设置为59。
在一示例性实施例中，在所述IPv6扩展头的外层封装IPv6头，其中，所述IPv6头中的Next Header字段用于指示所述IPv6头之后是所述HBH、所述DOH或所述RH。
在一示例性实施例中，所述BIER头的Proto字段设置为0或其他保留值。
在一示例性实施例中，封装所述GFH、所述GESP或所述GAH，其中，所述GFH、所述GESP或所述GAH中的Next Header用于指示BIER传输的报文类型。
在一示例性实施例中，所述IPv6扩展头的Next Header字段设置为用于指示所述GFH、所述GESP或所述GAH的上层协议值UL_TBD_X。
在一示例性实施例中，在所述IPv6扩展头的外层封装IPv6头，其中，所述IPv6头中的Next Header字段用于指示所述IPv6头之后是所述HBH、所述DOH或所述RH。
根据本申请的另一个实施例，还提供了一种报文解封装方法，图3是根据本申请实施例的报文解封装方法的流程图，如图3所示，该流程包括如下步骤：
步骤S302，从互联网协议第6版IPv6报文的IPv6扩展头中解封装出位索引显式复制BIER头，其中，所述BIER头与通用分片头GFH、通用封装安全头GESP或通用认证头GAH结合，封装在所述IPv6扩展头中。
在一示例性实施例中，上述步骤S302具体可以包括：
S3021，处理所述IPv6扩展头，和所述IPv6扩展头中的所述BIER头；可选的，在步骤S3021之前，还包括解封装IPv6头，根据所述IPv6头的Next Header字段获取所述IPv6扩展头HBH、DOH或RH；
S3022，若为中间设备，进行报文转发；
S3023，若为出口设备，根据所述IPv6扩展头的Next Header字段和/或所述BIER头中的Proto字段进行报文处理和转发，进一步的，S3023具体可以包括：如果所述BIER头的Proto字段为用于指示所述GFH、所述GESP或所述GAH的值G_TBD_X，和/或所述IPv6扩展头的Next Header字段为59，则剥除所述IPv6扩展头，并根据所述BIER头的Proto字段的值G_TBD_X 进行通用分片、通用封装安全或通用认证报文的解析；如果所述BIER头的Proto字段为0和/或所述IPv6扩展头的Next Header字段为上层协议值UL_TBD_X，则按照IPv6上层协议进行通用分片、通用封装安全或通用认证报文的解析。
本申请以BIER头封装在DOH，HBH或者RH中为例，提出与通用分片、通用封装安全、通用认证等技术结合使用的方法，从而可以让BIER报文在不限于DOH、HBH或RH等封装形式下，都能与通用分片、通用封装安全、通用认证等技术结合使用，逻辑清晰的实现分片、封装安全或认证等功能。
本申请提出2种报文封装与处理方式，可以实现在BIER头封装在IPv6扩展头中时，与通用的分片头/通用封装安全头/通用认证头相结合，跳出RFC8200的处理规程的限制，简洁高效的实现BIER组播报文的分片、封装安全和认证功能。
报文封装与处理方式一：IPv6 Header的封装方式不变，其Next Header字段仍然填为0、或者60、或者43等，表明是HBH，或者DOH，或者RH等IPv6扩展头。但HBH/DOH/RH等IPv6扩展头中的Next Header字段，不再填写RFC8200中定义的指示分片/封装安全/认证的IPv6扩展头的值，而是填写为59(IPv6-NoNxt)，使用59是借用RFC8200已有的定义，表示该IPv6扩展头后没有其他IPv6扩展头或者协议报文。图4是根据本实施例的报文封装的示意图一，如4所示，对于封装在HBH/DOH/RH中的BIER头，其Proto字段，填写为表示GFH的值G_TBD_X。图5是根据本实施例的报文封装的示意图二，如图5所示，对于封装在HBH/DOH/RH中的BIER头，其Proto字段，填写为表示GESP的值，对于通过封装在HBH/DOH/RH中的BIER头，其Proto字段，填写为表示GAH的情况与图4或5类似，不再赘述。这样可以避免HBH/DOH/RH指示RFC8200中定义的分片IPv6扩展头FH、封装安全IPv6扩展头ESP或认证头IPv6扩展头AH所导致的设备额外处理开销，又能将通用分片头GFH、通用封装安全头GESP或通用认证头GAH与封装在HBH/DOH/RH等IPv6扩展头中的BIER头结合起来，实现BIER组播报文的分片、封装安全和认证功能。GFH/GESP/GAH中的Next Header填写用BIER传输的报文的类型，包括以太/MPLS/IPv4/IPv6等。
设备收到上述报文后，先处理HBH/DOH/RH等IPv6扩展头，接着处理HBH/DOH/RH中携带的BIER头，BIER头的处理流程及是否出口设备的判断根据RFC8279定义的原则进行。如果本设备是中间设备，则处理HBH/DOH/RH后，进行转发。如果本设备是出口设备，则会剥除HBH/DOH/RH，并根据BIER头中的Proto指示处理GFH/GESP/GAH。从而实现封装在IPv6扩展头中的BIER与GFH/GESP/GAH结合使用，简洁高效的实现BIER组播报文的分片、封装安全和认证功能。
对于其他的一些传输技术，比如业务功能链(Service Function Chain)，其定义的NSH(Network Service Header)，采用以上类似的封装方法与处理流程，同样能够实现这些技术与通用分片/通用封装安全/通用认证处理结合，保证各类报文的传输与安全。
下面以具体实施例中对使用报文封装与处理方式一进行详细说明。
在BIER头位于HBH/DOH/RH时，处理方法类似。区别仅在IPv6头的Next Header针对DOH设置为60，HBH设置为0，针对RH设置为43。以下以DOH为例进行说明。同样，在SFC协议的NSH头位于HBH/DOH/RH时，处理方法类似。
图6是根据本实施例的BIER技术传输网络的示意图，如图6所示，网络入口设备BFIR 在收到组播报文，发现需要通过BIER技术传输，并且该报文过大，超过了本网络的最大传输单元设置，则将报文进行分片处理后，进行单个分片报文封装时，字段的位置如图4所示，图7是根据本优选实施例的数据报文封装的流程图一，如图7所示，具体包括：
步骤S701，封装GFH，GFH的封装流程同RFC8200中已定义的分片处理，并将原始的组播报文类型值填入到GFH的Next Header字段，比如原始组播报文是IPv4报文，则GFH的Next Header字段填为4，如果原始组播报文是IPv6报文，则填写为41。4或者41符合IANA的标准https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml
步骤S702，DOH封装，DOH的NH设置为59，DOH的Next Header字段，不填写原来针对分片头的值44(IPv6-Frag)，而是填写为59(IPv6-NoNxt)，使用59是借用RFC8200已有的定义，表示该DOH扩展头后没有其他IPv6扩展头或者协议报文。
步骤S703，封装BIER头，将BIER头作为option封装到DOH之内，将BIER头的Proto字段填写为表示GFH的值G_TBD_X，例如10。
这个封装方式将GFH与封装在DOH的BIER头结合起来实现了对用BIER传输的报文的分片，避免了DOH后插入分片扩展头FH所导致的设备额外处理开销。
步骤S704，封装外层IPv6头，其Next Header字段填为60，表明后续是DOH。
图8是根据本实施例的设备对报文进行解封装处理的流程图一，如图8所示，包括：
步骤801，处理外层IPv6头，根据IPv6头的Next Header指示值60，找到扩展头DOH。
步骤802，处理DOH，读取NH值59，并根据DOH里的option类型找到BIER头，因为DOH的Next Header字段填写为59(IPv6-NoNxt)，所以认为DOH后没有其他IPv6扩展头以及其他协议报文，不会导致设备额外处理开销，提高设备处理与转发性能。
步骤803，处理BIER头，BIER头的处理流程及根据RFC8279定义的原则进行。
步骤804，根据BIER处理结果判断是否为出口设备，在判断结果为否的情况下，执行步骤S805，在判断结果为是的情况下，执行步骤S806；
步骤S805，转发报文，如果该设备是中间设备，对应于图6中的BFRm(Bit-Forwarding Router，位转发路由器)和BFRn设备，处理BIER报文后发现本设备并非出口设备，则在处理完DOH后继续转发给BIER下一跳，不处理后续的GFH报文。如果发现本设备是出口设备，对应于图6中的BFER1(Bit-Forwarding Egress Router，位转发出口路由器)或者BFER2或者BFER3设备，则剥除DOH及外层IPv6封装。
步骤806，根据BIER头中的Proto指示后续是GFH，对GFH进行处理，处理流程参照draft-zzhang-tsvwg-generic-transport-functions中的定义进行。从而实现封装在IPv6扩展头中的BIER仍然能与通用分片头结合使用，解决超过本网络最大传输单元的组播报文传输问题。
步骤807，得到分片报文，处理完GFH，在对报文进行分片重组后，再转发给接收者。
如图6所示网络，网络入口设备BFIR收到组播报文，发现需要经过封装安全，通用ESP的封装简称GESP，采用RFC4303中的基础定义。报文封装过程，字段的位置参照图5所示，图9是根据本优选实施例的数据报文封装的流程图二，如图9所示，具体包括：
步骤901，对数据报文进行ESP封装，封装方法采用RFC4303中的定义，将原始的组播 报文类型值填入到ESP的Next Header字段，比如原始的组播报文是IPv4报文，则ESP的Next Header字段填为4，如果原始的组播报文是IPv6报文，则填写为41。
步骤902，封装DOH，DOH的Next Header字段，填写为59(IPv6-NoNxt)，使用59是借用RFC8200已有的定义，表示该扩展头后没有其他IPv6扩展头或者协议报文；
步骤903，封装BIER头，Proto设置为G_TBD_X，将BIER头作为option封装到DOH之内，将BIER头的Proto字段填写为表示GESP的值，例如20。
这个封装方式将GESP与封装在DOH的BIER头结合起来实现了对用BIER传输的报文的封装安全功能，避免了DOH后插入ESP扩展头所导致的设备额外处理开销。
步骤904，封装外层IPv6头，在DOH的外层封装IPv6头，其Next Header字段填为60，表明后续是DOH。
图10是根据本实施例的设备对报文进行解封装处理的流程图二，如图10所示，包括：
步骤1001，处理外层IPv6头，根据IPv6头的Next Header指示值60，找到扩展头DOH。
步骤1002，处理DOH，读取NH，并根据DOH里的option类型找到BIER头，因为DOH的Next Header字段值为59(IPv6-NoNxt)，所以认为DOH后没有其他IPv6扩展头以及其他协议报文，不会导致设备额外处理开销，提高设备处理与转发性能。
步骤1003，处理BIER头，读取Proto获知后续为GESP，BIER头的处理流程及是否出口设备的判断根据RFC8279定义的原则进行。
步骤1004，根据BIER处理结果判断是否为出口设备，在判断结果为否的情况下，执行步骤S1005，在判断结果为是的情况下，执行步骤S1006；
步骤1005，转发报文，如果该设备是中间设备，对应于图6中的BFRm和BFRn设备，处理BIER报文后发现本设备并非出口设备，则在处理完DOH后继续转发给BIER下一跳，不处理后续的GESP报文。如果发现本设备是出口设备，对应于图6中的BFER1或者BFER2或者BFER3设备，则剥除DOH及外层IPv6封装。
步骤1006，根据BIER头中的Proto指示处理GESP，GESP处理流程参照RFC4303中的定义进行。从而实现封装在IPv6扩展头中的BIER仍然能与通用封装安全头结合使用，解决组播报文封装安全传输问题。
步骤1007，得到安全封装报文，处理完GESP，报文安全判断通过后，再发送给接收者，如果报文没有通过安全判断，则进行丢弃。
在以上的实施例中，网络入口设备也可能选择其他的安全方式，比如AH，则在实例2中，DOH的Next Header字段仍然填写为59(IPv6-NoNxt)，表示DOH后没有其他IPv6扩展头以及其他协议报文，不会导致设备额外处理开销，提高设备处理与转发性能；另将BIER头的Proto填写为表示GAH的类型值，GAH的使用遵从与RFC4302。从而实现封装在IPv6扩展头中的BIER仍然能与通用认证头结合使用，解决组播报文认证问题。
另外，根据RFC4303，ESP也可结合AH使用。这时AH的使用遵从于RFC4303。AH将作为GESP的组成部分，这时采用上述封装方法与处理流程。从而实现BIER能与封装安全与认证同时结合使用，提高组播报文的安全性。
需要注意的是，如果对报文进行GESP或者GAH封装后，报文大小超过了本网络的最大传输单元设置，则需要进行分片处理，之后进行封装与转发。
报文封装与处理方式二：IPv6 Header的封装方式不变，其Next Header字段仍然填为0、或者60、或者43，表明是HBH，或者DOH，或者RHIPv6扩展头。但HBH/DOH/RH中的Next Header字段，不能填写RFC8200中定义的指示分片/封装安全/认证的IPv6扩展头的值，而是填写为直接表示GFH/GESP/GAH上层协议的值UL_TBD_X，这样，既实现了分片、封装安全和认证功能，又让设备跳出了RFC8200定义的IPv6扩展头的处理规程，避免了IPv6扩展头处理的额外开销。而对于封装在HBH/DOH/RH中的BIER头，其Proto字段，填写为0或者其他保留值，不作为后续报文类型的判断。这样避免了HBH/DOH/RH的Next Header与BIER Proto两者共同指示GFH/GESP/GAH可能带来的错误。GFH/GESP/GAH中的Next Header填写用BIER传输的报文的类型，包括以太/MPLS/IPv4/IPv6等。
设备收到上述报文后，先处理HBH/DOH/RH等IPv6扩展头，接着处理HBH/DOH/RH中携带的BIER头。其中的BIER头的处理流程及是否出口设备的判断根据RFC8279定义的原则进行。对于是否处理GFH/GESP/GAH则根据BIER头的处理流程进行判断，如果是中间设备，在处理完HBH/DOH/RH后，进行转发。如果发现是出口设备，则会剥除HBH/DOH/RH，并根据HBH/DOH/RH中的Next Header处理GFH/GESP/GAH。这种情况下因为GFH/GESP/GAH是上层协议而不是IPv6扩展头，由BIER节点来判断是否需要处理，在本设备为非出口设备的情况下不进行处理，在本设备是出口设备时则进行处理，实现BIER与GFH/GESP/GAH的结合应用。从而实现组播报文的分片、封装安全和认证功能。
因所述报文的IPv6扩展头中的Next Header指示的GFH/GESP/GAH是上层协议，因此不会占用设备的IPv6扩展头处理开销，可以提高设备的报文处理效率。
对于其他的一些传输技术，比如业务功能链(Service Function Chain)，其定义的NSH(Network Service Header)，采用以上类似的封装方法与处理流程，同样能够实现这些技术与通用分片/通用封装安全/通用认证处理结合，保证各类报文的传输与安全。
需要指出的是，GFH/GESP/GAH技术还在发展中，GFH中携带的字段，字段位置和长度等信息在未来还有可能发生变化，但是本申请主旨是实现在BIER头封装在IPv6扩展头中时，与通用的分片头/通用封装安全头/通用认证头相结合，跳出RFC8200的处理规程的限制，简洁高效的实现BIER组播报文的分片、封装安全和认证功能。此外，IETF标准中，对于Next Header字段与Next protocol，protocol，Proto等字段含义等同，均指示的是所携带的报文/协议类型。
下面以具体实施例对使用报文封装与处理方式二进行详细说明。
在BIER头位于HBH/DOH/RH时，处理方法类似。区别仅在IPv6头的Next Header针对DOH设置为60，HBH设置为0，针对RH设置为43。以下以DOH为例进行说明。同样，在SFC协议的NSH等其他协议转发头位于HBH/DOH/RH时，处理方法类似。
如图6所示的网络，网络入口设备BFIR收到组播报文，发现需要通过BIER技术传输，并且该报文过大，超过了本网络的最大传输单元，则将报文进行分片处理后，进行单个分报文封装时，图11是根据本优选实施例的数据报文封装的流程图三，如图11所示，包括：
步骤1101，封装GFH，GFH的封装流程类同RFC8200中已定义的分片处理，并将原始的组播报文类型值填入到GFH的Next Header字段，比如原始的组播报文是IPv4报文，则GFH的Next Header字段填为4，如果原始的组播报文是IPv6报文，则填写为41。
步骤1102,封装DOH，在GFH的外层进行DOH封装，DOH的Next Header字段，不填写原来针对分片头的值44(IPv6-Frag)，而是填写为一个新的值，即针对GFH分配的上层协议(Upper-Layer header)值UL_TBD_X，比如145。这样的封装方式既实现了GFH分片功能，又让设备跳出了RFC8200定义的IPv6扩展头的处理规程，避免了IPv6扩展头处理的额外开销。
步骤1103，封装BIER头，BIER的Proto设置为0或者其他保留值，将BIER头作为option封装到DOH之内。这样的封装方式，避免了DOH的Next Header与BIER Proto两者共同指示GFH可能带来的错误。
步骤1104，封装外层IPv6头，在DOH的外层封装IPv6头，其Next Header字段填为60，表明后续是DOH。
图12是根据本实施例的设备对报文进行解封装处理的流程图三，如图12所示，包括：
步骤1201，处理IPv6头，根据IPv6头的Next Header指示值60，找到扩展头DOH。
步骤1202，处理DOH，因为DOH的Next Header字段填写为一个指示上层协议的值(Upper-Layer header)(例如145)，这个值表示Next header不是IPv6扩展头，所以会认为DOH后没有其他IPv6扩展头。并根据DOH里的option类型找到BIER头。
步骤1203，处理BIER头，读取Proto值为0或者其他保留值，BIER头的处理流程及是否出口设备的判断根据RFC8279定义的原则进行。
步骤1204，根据BIER处理结果判断是否为出口设备，在判断结果为否的情况下，执行步骤S1205，在判断结果为是的情况下，执行步骤S1206；
步骤1205，转发报文，如果该设备是中间设备，对应于图6中的BFRm和BFRn设备，处理BIER报文后发现本设备并非出口设备，则在处理完DOH后继续转发给BIER下一跳；如果发现本设备是出口设备，对应于图6中的BFER1或者BFER2或者BFER3设备，则剥除DOH及外层IPv6封装。这种情况下GFH因为是上层协议而不是扩展头，由BIER节点来判断是否需要处理，在本设备并非出口设备的情况下不进行处理，在本设备是出口设备时则进行处理。从而实现BIER与GFH的结合应用。
步骤1206，根据DOH中的Next Header指示处理GFH，对GFH进行处理的流程参照draft-zzhang-tsvwg-generic-transport-functions-00中的定义进行。从而实现组播报文的通用分片处理，保证超过本网络最大传输单元的报文仍然能够顺利传输。
步骤1207，得到分片报文，处理完GFH，在对报文进行分片重组后，再转发给接收者。
如图6所示的网络，网络入口设备BFIR在收到组播报文，发现需要经过封装安全，通用ESP的封装简称GESP，采用RFC4303中的基础定义。图13是根据本优选实施例的数据报文封装的流程图四，如图13所示，包括：
步骤1301，封装GESP，对数据报文进行GESP封装，封装方法采用RFC4303中的定义，将原始的组播报文类型值填入到GESP的Next Header字段，比如原始的组播报文是IPv4报文，则GESP的Next Header字段填为4，如果原始的组播报文是IPv6报文，则填写为41。
步骤1302，封装DOH，DOH的Next Header字段，不填写为原来表示ESP的值50，而是填写为一个新的，针对GESP分配的上层协议值，比如180；这样的封装方式既实现了GESP 封装安全功能，又让设备跳出了RFC8200定义的IPv6扩展头的处理规程，避免了IPv6扩展头处理的额外开销。
步骤1303，封装BIER头，BIER的Proto设置为0或者其他保留值，将BIER头作为option封装到DOH之内，将BIER头的Proto字段填写0。这样的封装方式，避免了DOH的Next Header与BIER Proto两者共同指示GESP所带来的混淆。
步骤1304，封装外层IPv6头，在DOH的外层封装IPv6头，其Next Header字段填为60，表明后续是DOH。
图14是根据本实施例的设备对报文进行解封装处理的流程图四，如图14所示，包括：
步骤1401，处理IPv6头，根据IPv6头的Next Header指示值60，找到扩展头DOH。
步骤1402，处理DOH，因为DOH的Next Header字段一个指示上层协议的值(Upper-Layer header)UL_TBD_X(例如180)，这个值表示Nextheader不是IPv6扩展头，所以会把GESP作为上层协议。并根据DOH里的option类型找到BIER头。
步骤1403，处理BIER头，读取Proto值为0或者其他保留值，BIER头的处理流程及是否出口设备的判断根据RFC8279定义的原则进行。
步骤1404，根据BIER处理结果判断是否为出口设备，在判断结果为否的情况下，执行步骤S1405，在判断结果为是的情况下，执行步骤S1406；
步骤1405，如果该设备是中间设备，对应于图6中的BFRm和BFRn设备，处理BIER报文后发现本设备并非出口设备，则在处理完DOH后继续转发给BIER下一跳，不处理后续的GESP报文。如果发现本设备是出口设备，对应于图6中的BFER1或者BFER2或者BFER3设备，则剥除DOH及外层IPv6封装。这种情况下因为GESP是上层协议而不是IPv6扩展头，由BIER节点来判断是否需要处理，在本设备为非出口设备的情况下不进行处理，在本设备是出口设备时则进行处理。从而实现BIER与GESP的结合应用。
步骤1406，根据BIER头中的Proto指示处理GESP，对GESP进行处理的流程参照RFC4303中的定义进行。从而实现组播报文的通用封装安全处理，保证报文传输的安全性。
步骤1407，得到安全封装报文，处理完GESP，报文安全判断通过后，再发送给接收者，如果报文没有通过安全判断，则进行丢弃。
在以上的实施例中，网络入口设备也可能选择其他的安全方式，比如AH，则在实施例二中，DOH的Next Header字段填写为GAH分配的新上层协议值，表示GAH并非IPv6扩展头，不会占用设备IPv6扩展头处理开销，提高设备处理与转发性能；GAH的使用遵从与RFC4302。另将BIER的Proto字段填写为0，从而避免DOH的Next Header与BIER Proto两者共同指示GAH所带来的混淆。从而实现封装在IPv6扩展头中的BIER仍然能与通用认证头结合使用，解决组播报文认证问题。
另外，根据RFC4303，ESP也可结合AH使用。这时AH的使用遵从于RFC4303。AH将作为GESP的组成部分，这时采用上述封装方法与处理流程。从而实现BIER能与封装安全与认证同时结合使用，提高组播报文的安全性。
需要注意的是，如果对报文进行GESP或者GAH封装后，报文大小超过了本网络的最大传输单元，则需要进行分片处理，之后进行封装与转发。
根据本申请的另一个实施例，还提供了一种报文封装装置，图15是根据本实施例的报文封装装置的框图，如图15所示，所述装置包括：
第一封装模块152，设置为与通用分片头GFH、通用封装安全头GESP或通用认证头GAH结合，将位索引显式复制BIER头封装在互联网协议第6版IPv6报文的IPv6扩展头中。
在一示例性实施例中，所述IPv6扩展头为HBH、DOH或RH。
在一示例性实施例中，所述BIER头的Proto字段设置为用于指示所述GFH、所述GESP或所述GAH的值G_TBD_X。
在一示例性实施例中，所述装置还包括：第二封装模块，设置为封装所述GFH、所述GESP或所述GAH，其中，所述GFH、所述GESP或所述GAH中的Next Header用于指示BIER传输的报文类型。
在一示例性实施例中，所述IPv6扩展头的Next Header字段设置为59。
在一示例性实施例中，所述装置还包括：第三封装模块，设置为在所述IPv6扩展头的外层封装IPv6头，其中，所述IPv6头中的Next Header字段用于指示所述IPv6头之后是所述HBH、所述DOH或所述RH。
在一示例性实施例中，所述BIER头的Proto字段设置为0或其他保留值。
在一示例性实施例中，所述装置还包括：第四封装模块，设置为封装所述GFH、所述GESP或所述GAH，其中，所述GFH、所述GESP或所述GAH中的Next Header用于指示BIER传输的报文类型。
在一示例性实施例中，所述IPv6扩展头的Next Header字段设置为用于指示所述GFH、所述GESP或所述GAH的上层协议值UL_TBD_X。
在一示例性实施例中，所述装置还包括：第五封装模块，设置为在所述IPv6扩展头的外层封装IPv6头，其中，所述IPv6头中的Next Header字段用于指示所述IPv6头之后是所述HBH、所述DOH或所述RH。
根据本申请的另一个实施例，还提供了一种报文解封装装置，图16是根据本实施例的报文解封装装置的框图，如图16所示，所述装置包括：
解封装模块162，设置为从互联网协议第6版IPv6报文的IPv6扩展头中解封装出位索引显式复制BIER头，其中，所述BIER头与通用分片头GFH、通用封装安全头GESP或通用认证头GAH结合，封装在所述IPv6扩展头中。
在一示例性实施例中，所述解封装模块162包括：
第一处理子模块，设置为处理所述IPv6扩展头，和所述IPv6扩展头中的所述BIER头；
转发子模块，设置为若为中间设备，进行报文转发；
第二处理子模块，设置为若为出口设备，根据所述IPv6扩展头的Next Header字段和/或所述BIER头中的Proto字段进行报文处理和转发。
在一示例性实施例中，所述第二处理子模块，还设置为如果所述BIER头的Proto字段为用于指示所述GFH、所述GESP或所述GAH的值G_TBD_X，和/或所述IPv6扩展头的Next Header字段为59，则剥除所述IPv6扩展头，并根据所述BIER头的Proto字段的值G_TBD_X进行通用分片、通用封装安全或通用认证报文的解析；如果所述BIER头的Proto字段为0和/或所述IPv6扩展头的Next Header字段为上层协议值UL_TBD_X，则按照IPv6上层协议进行通用 分片、通用封装安全或通用认证报文的解析。
本申请的实施例还提供了一种计算机可读存储介质，该计算机可读存储介质中存储有计算机程序，其中，该计算机程序被设置为运行时执行上述任一项方法实施例中的步骤。
在一个示例性实施例中，上述计算机可读存储介质可以包括但不限于：U盘、只读存储器(Read-Only Memory，简称为ROM)、随机存取存储器(Random Access Memory，简称为RAM)、移动硬盘、磁碟或者光盘等各种可以存储计算机程序的介质。
本申请的实施例还提供了一种电子装置，包括存储器和处理器，该存储器中存储有计算机程序，该处理器被设置为运行计算机程序以执行上述任一项方法实施例中的步骤。
在一个示例性实施例中，上述电子装置还可以包括传输设备以及输入输出设备，其中，该传输设备和上述处理器连接，该输入输出设备和上述处理器连接。
本实施例中的具体示例可以参考上述实施例及示例性实施方式中所描述的示例，本实施例在此不再赘述。
显然，本领域的技术人员应该明白，上述的本申请的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，并且在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本申请不限制于任何特定的硬件和软件结合。
以上所述仅为本申请的优选实施例而已，并不用于限制本申请，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims (17)

  1. 一种报文封装方法，所述方法包括：
    与通用分片头GFH、通用封装安全头GESP或通用认证头GAH结合，将位索引显式复制BIER头封装在互联网协议第6版IPv6报文的IPv6扩展头中。
  2. 根据权利要求1所述的方法，其中，所述IPv6扩展头为逐跳选项头HBH、地址选项头DOH或路由头RH。
  3. 根据权利要求2所述的方法，其中，
    所述BIER头的Proto字段设置为用于指示所述GFH、所述GESP或所述GAH的值G_TBD_X。
  4. 根据权利要求3所述的方法，其中，所述方法还包括：
    封装所述GFH、所述GESP或所述GAH，其中，所述GFH、所述GESP或所述GAH中的Next Header用于指示BIER传输的报文类型。
  5. 根据权利要求4所述的方法，其中，
    所述IPv6扩展头的Next Header字段设置为59。
  6. 根据权利要求3所述的方法，其中，所述方法还包括：
    在所述IPv6扩展头的外层封装IPv6头，其中，所述IPv6头中的Next Header字段用于指示所述IPv6头之后是所述HBH、所述DOH或所述RH。
  7. 根据权利要求2所述的方法，其中，
    所述BIER头的Proto字段设置为0或其他保留值。
  8. 根据权利要求7所述的方法，其中，所述方法还包括：
    封装所述GFH、所述GESP或所述GAH，其中，所述GFH、所述GESP或所述GAH中的Next Header用于指示BIER传输的报文类型。
  9. 根据权利要求8所述的方法，其中，
    所述IPv6扩展头的Next Header字段设置为用于指示所述GFH、所述GESP或所述GAH的上层协议值UL_TBD_X。
  10. 根据权利要求9所述的方法，其中，所述方法还包括：
    在所述IPv6扩展头的外层封装IPv6头，其中，所述IPv6头中的Next Header字段用于指示所述IPv6头之后是所述HBH、所述DOH或所述RH。
  11. 一种报文解封装方法，所述方法包括：
    从互联网协议第6版IPv6报文的IPv6扩展头中解封装出位索引显式复制BIER头，其中，所述BIER头与通用分片头GFH、通用封装安全头GESP或通用认证头GAH结合，封装在所述IPv6扩展头中。
  12. 根据权利要求11所述的方法，其中，从互联网协议第6版IPv6扩展头中获得位索引显式复制BIER头，所述IPv6扩展头为逐跳选项头HBH、地址选项头DOH或路由头RH，包括：
    处理所述IPv6扩展头，和所述IPv6扩展头中的所述BIER头；
    若为中间设备，进行报文转发；
    若为出口设备，根据所述IPv6扩展头的Next Header字段和/或所述BIER头中的Proto字段进行报文处理和转发。
  13. 根据权利要求12所述的方法，其中，根据所述IPv6扩展头的Next Header字段和/或BIER头中的Proto字段进行报文处理和转发包括：
    如果所述BIER头的Proto字段为用于指示所述GFH、所述GESP或所述GAH的值G_TBD_X，和/或所述IPv6扩展头的Next Header字段为59，则根据所述BIER头的Proto字段的值G_TBD_X进行通用分片、通用封装安全或通用认证报文的解析；
    如果所述BIER头的Proto字段为0和/或所述IPv6扩展头的Next Header字段为上层协议值UL_TBD_X，则按照IPv6上层协议进行通用分片、通用封装安全或通用认证报文的解析。
  14. 一种报文封装装置，所述装置包括：
    第一封装模块，设置为与通用分片头GFH、通用封装安全头GESP或通用认证头GAH结合，将位索引显式复制BIER头封装在互联网协议第6版IPv6报文的IPv6扩展头中。
  15. 一种报文解封装装置，所述装置包括：
    解封装模块，设置为从互联网协议第6版IPv6报文的IPv6扩展头中解封装出位索引显式复制BIER头，其中，所述BIER头与通用分片头GFH、通用封装安全头GESP或通用认证头GAH结合，封装在所述IPv6扩展头中。
  16. 一种计算机可读的存储介质，所述存储介质中存储有计算机程序，其中，所述计算机程序被设置为运行时执行所述权利要求1至10、11至13任一项中所述的方法。
  17. 一种电子装置，包括存储器和处理器，所述存储器中存储有计算机程序，所述处理器被设置为运行所述计算机程序以执行所述权利要求1至10、11至13任一项中所述的方法。
PCT/CN2021/113849 2020-12-29 2021-08-20 报文封装、解封装方法、装置、存储介质及电子装置 WO2022142390A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP21913137.2A EP4274123A4 (en) 2020-12-29 2021-08-20 METHOD AND DEVICE FOR ENCAPSULATION AND DE-ENCAPSULATION OF PACKAGES, STORAGE MEDIUM, AND ELECTRONIC DEVICE
US18/270,055 US20240073128A1 (en) 2020-12-29 2021-08-20 Message encapsulation and de-encapsulation method and device, storage medium, and electronic device

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202011602820.XA CN113055294A (zh) 2020-12-29 2020-12-29 报文封装、解封装方法、装置、存储介质及电子装置
CN202011602820.X 2020-12-29

Publications (1)

Publication Number Publication Date
WO2022142390A1 true WO2022142390A1 (zh) 2022-07-07

Family

ID=76508462

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2021/113849 WO2022142390A1 (zh) 2020-12-29 2021-08-20 报文封装、解封装方法、装置、存储介质及电子装置

Country Status (4)

Country Link
US (1) US20240073128A1 (zh)
EP (1) EP4274123A4 (zh)
CN (1) CN113055294A (zh)
WO (1) WO2022142390A1 (zh)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113055294A (zh) * 2020-12-29 2021-06-29 中兴通讯股份有限公司 报文封装、解封装方法、装置、存储介质及电子装置
CN115174449B (zh) * 2022-05-30 2024-03-26 杭州初灵信息技术股份有限公司 一种传递随流检测信息的方法、系统、装置和存储介质

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106656524A (zh) * 2015-10-30 2017-05-10 中兴通讯股份有限公司 一种bier控制信息的传输方法、装置和系统
WO2019180306A1 (en) * 2018-03-21 2019-09-26 Nokia Solutions And Networks Oy Hierarchical bit indexed replication of multicast packets
CN112054959A (zh) * 2019-06-06 2020-12-08 华为技术有限公司 一种bier报文的发送方法和装置
CN113055294A (zh) * 2020-12-29 2021-06-29 中兴通讯股份有限公司 报文封装、解封装方法、装置、存储介质及电子装置

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9225639B2 (en) * 2011-01-31 2015-12-29 Intellectual Discovery Co., Ltd. Network system
CN112468397B (zh) * 2019-09-09 2023-09-26 华为技术有限公司 一种IPv6报文的处理方法及装置
EP4060952A4 (en) * 2019-12-25 2023-01-11 Huawei Technologies Co., Ltd. MESSAGE TRANSMITTING METHOD, DEVICE AND SYSTEM

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106656524A (zh) * 2015-10-30 2017-05-10 中兴通讯股份有限公司 一种bier控制信息的传输方法、装置和系统
WO2019180306A1 (en) * 2018-03-21 2019-09-26 Nokia Solutions And Networks Oy Hierarchical bit indexed replication of multicast packets
CN112054959A (zh) * 2019-06-06 2020-12-08 华为技术有限公司 一种bier报文的发送方法和装置
CN113055294A (zh) * 2020-12-29 2021-06-29 中兴通讯股份有限公司 报文封装、解封装方法、装置、存储介质及电子装置

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP4274123A4 *

Also Published As

Publication number Publication date
EP4274123A4 (en) 2024-07-03
EP4274123A1 (en) 2023-11-08
CN113055294A (zh) 2021-06-29
US20240073128A1 (en) 2024-02-29

Similar Documents

Publication Publication Date Title
US7899048B1 (en) Method and apparatus for remotely monitoring network traffic through a generic network
US11979322B2 (en) Method and apparatus for providing service for traffic flow
US9894003B2 (en) Method, apparatus and system for processing data packet
WO2020244651A1 (zh) 一种bier报文的发送方法和装置
EP3972226A1 (en) Network packet flow controller with extended session management
WO2016000513A1 (zh) 更新业务流报文的处理方式的方法及装置
WO2022142390A1 (zh) 报文封装、解封装方法、装置、存储介质及电子装置
WO2019205806A1 (zh) 数据包的处理方法及装置、存储介质、电子装置
WO2021213507A1 (zh) 数据包处理的方法及设备
US9467367B2 (en) Universal labels in internetworking
EP4333408A2 (en) Method and apparatus for managing routing disruptions in a computer network
US9445384B2 (en) Mobile device to generate multiple maximum transfer units and data transfer method
WO2022021818A1 (zh) 数据报文的处理方法及装置、存储介质、电子装置
CN107370654B (zh) 一种伪线数据报文的封装、解封装方法和相关装置
US9143448B1 (en) Methods for reassembling fragmented data units
US10419356B1 (en) Apparatus, system, and method for discovering network path maximum transmission units
TWI692950B (zh) 功能擴展式有線網路裝置
CN103986652B (zh) 一种路由跟踪方法和装置
CN111083032A (zh) 一种智能调度的overlay组网方法
WO2022267875A1 (zh) 一种报文传输的方法及相关设备
WO2023078144A1 (zh) 报文处理方法、装置及系统
US11496382B2 (en) System and method for recording a routing path within a network packet
WO2022242775A1 (zh) 一种报文处理的方法、系统和网络设备
US11456954B1 (en) Data packet fragmentation for replicated packet traffic through a software-defined wide area network
CN110505137B (zh) 功能扩展式有线网络装置

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 18270055

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2021913137

Country of ref document: EP

Effective date: 20230731