WO2022041916A1 - 报文头的处理方法及装置、存储介质、电子装置 - Google Patents

报文头的处理方法及装置、存储介质、电子装置 Download PDF

Info

Publication number
WO2022041916A1
WO2022041916A1 PCT/CN2021/098409 CN2021098409W WO2022041916A1 WO 2022041916 A1 WO2022041916 A1 WO 2022041916A1 CN 2021098409 W CN2021098409 W CN 2021098409W WO 2022041916 A1 WO2022041916 A1 WO 2022041916A1
Authority
WO
WIPO (PCT)
Prior art keywords
header
ipv6
bier
field
bit
Prior art date
Application number
PCT/CN2021/098409
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 EP21859760.7A priority Critical patent/EP4207685A4/en
Priority to US18/022,378 priority patent/US20230370298A1/en
Publication of WO2022041916A1 publication Critical patent/WO2022041916A1/zh

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/1886—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast with traffic restrictions for efficiency improvement, e.g. involving subnets or subdomains
    • 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
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/30—Information retrieval; Database structures therefor; File system structures therefor of unstructured textual data
    • G06F16/31—Indexing; Data structures therefor; Storage structures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/30—Information retrieval; Database structures therefor; File system structures therefor of unstructured textual data
    • G06F16/33—Querying
    • G06F16/3331—Query processing
    • G06F16/334—Query execution
    • 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/302—Route determination based on requested QoS
    • H04L45/306—Route determination based on the nature of the carried application
    • 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/72—Routing based on the source address
    • 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
    • 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
    • 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2212/00—Encapsulation of packets

Definitions

  • the embodiments of the present disclosure 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.
  • IPv6 Internet Protocol Version 6
  • IETF Internet Engineering Task Force
  • Bit Indexed Explicit Replication (BIER for short) (RFC8279) is a new type of multicast data forwarding technology.
  • the nodes at the edge of the network are represented by only one bit, and the multicast traffic is transmitted in the intermediate network. , additionally encapsulates a specific BIER header, which marks all destination nodes of the multicast stream in the form of bit strings, and 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 passes a routing protocol in advance, such as the Open Shortest Path First (OSPF Open Shortest Path First, OSPF) protocol in the three-layer network, the Intermediate System-to-Intermediate System (Intermediate System-to-Intermediate System, referred to as ISIS) ) protocol to form a Bit Index Forwarding Table (BIFT) table for guiding BIER forwarding.
  • OSPF Open Shortest Path First
  • ISIS 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.
  • BIER technology When the BIER technology is transmitted, only a certain multicast traffic needs to be encapsulated in a BIER packet and transmitted as a payload.
  • BFIR Bit-Forwarding Ingress Router
  • BFERs Bit-Forwarding Egress Routers
  • BIER technology can be directly encapsulated in Ethernet packets for transmission (protocol number 0xAB37). When some nodes cannot support direct identification of Ethernet BIER packets, if Ethernet packets are still used for transmission, the node of the packet cannot be correctly identified. Will become a black hole and discard packets.
  • Embodiments of the present disclosure provide a packet header processing method and device, a storage medium, and an electronic device, so as to at least solve the problem of how to optimize the process of combining BIER packets and IPv6 packets in the related art.
  • Technical solutions are provided.
  • a method for processing a packet header including: processing the fields in the IPv6 packet header by explicitly copying the fields in the BIER packet header according to the bit index in at least one of the following ways : Explicitly copy the bit index of the BIER message header as the type of the routing extension header of the IPv6 message header, and process the remaining segment Segments Left field in the IPv6 message header according to a predefined method; Copy the BIER header as the type of other extension headers of the IPv6 header, wherein the types of the other extension headers include options in the Hop-by-Hop extension header; in the source address Source of the IPv6 header Fill in the bit index in the Address field to explicitly copy the bit forwarding router routing prefix BFR-Prefix of the BIER message header; embed the bit index forwarding table index BIFT-ID field in the explicit copy of the bit index in the BIER message header into the destination field of the IPv6 header.
  • the remaining segment Segments Left field in the IPv6 packet header is processed in a predefined manner, including at least one of the following: setting the remaining segment Segments Left field to a target value, so that all Nodes ignore the processing of the remaining segment Segments Left field; set the remaining segment Segments Left field value of the bit forwarding entry router BFIR to 255, when the intermediate node sends the message hop by hop, the field value is decremented by 1 Processing, when the field value is 0, it indicates that there is a loop in the packet forwarding process; the bit forwarding ingress router BFIR sets the value of the Segment Left field of the remaining segment of the ingress node to the maximum number of hops to reach the edge device, and when the intermediate node jumps one by one When sending a message, the value of the field is decremented by 1.
  • the value of the field When the value of the field is 0, it indicates that a loop occurs in the message forwarding process; the value of the Segment Left field of the remaining segment of the bit forwarding entry router BFIR is set to 255, and the intermediate node When the message is sent hop by hop, the value of the field is decremented by 1.
  • the IPv6 message with the Segment Left field value of the remaining segment of 255 arrives at the bit forwarding egress router BFER, it is calculated according to the value of the Segment Left field of the current remaining segment.
  • the Segment Left field of the remaining segment is set to the maximum boundary value of the boundary to be passed by the IPv6 message, and when passing through the boundary, the field value is processed by subtracting 1, When the value of the field is 0, it indicates that the packet cannot be forwarded to the next area when it reaches the maximum boundary.
  • the bit index is explicitly copied to the BIER header as the type of the routing extension header of the IPv6 header, and the remaining segment Segments Left field in the IPv6 header is performed in a predefined manner.
  • the method further includes: announcing, through the control plane, each node's own support for explicitly copying the BIER packet header with the bit index as the type of the routing extension header of the IPv6 packet header.
  • the method further includes: announcing the support of each node for explicitly copying the bit index of the BIER packet header as the type of the routing extension header of the IPv6 packet header in one of the following ways: TLV mode For advertisement, the bit index carried in the interior gateway protocol IGP explicitly copies the BIER information for advertisement, and the bit index carried in the border gateway protocol BGP explicitly copies the BIER information for advertisement.
  • the method further includes: setting the forwarding router routing prefix in-bit when each node supports the type of routing extension header that explicitly copies the bit index of the BIER packet header as the IPv6 packet header. Under the notification of BFR-Prefix or bit forwarding router identification BFR-ID, it is advertised in the form of sub-TLV or sub-sub-TLV.
  • the method before filling the source address Source Address field of the IPv6 packet header with the bit index to explicitly copy the bit forwarding router routing prefix BFR-Prefix of the BIER packet header, the method further includes: Including: in the case of nodes that cannot guarantee the transmission capability of the source address Source Address field of the IPv6 message header in all nodes, advertising and collecting the source address Source Address of the IPv6 message header of all nodes through the control plane Information about the transfer capability of the field.
  • the method further Including: when confirming that the guarantee capability of the Source Address field of the IPv6 packet header is not supported, setting the N bits of other unused fields in the IPv6 packet header to 1 to indicate that the IPv6 The source address Source Address of the packet header needs to be guaranteed, wherein the value of N is not less than 1.
  • the method before explicitly copying the bit index forwarding table index BIFT-ID field in the BIER packet header into the target field of the IPv6 packet header, the method further includes : modify the address in the IPv6 message, so as to set the routable prefix of the IPv6 message in the number of bits before the target 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 the bit index forwarding table index BIFT-ID field is embedded in the source address SA in the IPv6 message; or the bit index forwarding table index BIFT-ID is filled in the flow label Flow of the IPv6 message header In the Label field, the destination address DA and the source address SA in the IPv6 message are not changed.
  • the method further includes: moving forward the forwarding table entry positioning operation of the bit index forwarding table index BIFT-ID in the BIER message header by explicitly copying the bit index into the IPv6 message .
  • the method further includes: explicitly copying the function FUNCTION field of the BIER entry lookup by using a specific bit in the IPv6 message address to represent the bit index.
  • an apparatus for processing a packet header including: a processing module configured to explicitly copy the fields in the BIER packet header according to the bit index in at least one of the following manners to the IPv6 packet
  • the fields in the header are processed: the bit index is explicitly copied to the BIER header as the type of the routing extension header of the IPv6 header, and the remaining segment Segments Left field in the IPv6 header is processed in a predefined manner.
  • the above processing module is further configured to process the remaining segment Segments Left field in the IPv6 packet header in a predefined manner, including at least one of the following: Set to the target value, so that all nodes ignore the processing of the remaining segment Segments Left field; set the remaining segment Segments Left field value of the bit forwarding ingress router BFIR to 255, when the intermediate node sends the message hop by hop, the 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; the bit forwarding ingress router BFIR sets the value of the Segment Left field of the remaining segment of the ingress node to the maximum number of hops reaching the edge device , when the intermediate node sends the message hop by hop, the value of the field is decremented by 1.
  • the value of the field When the value of the field is 0, it indicates that a loop occurs in the message forwarding process; the bits are forwarded to the remaining segment Segments Left field of the entry router BFIR. The value is set to 255. When the intermediate node sends the message hop by hop, the value of the field is decremented by 1.
  • the IPv6 message with the Segment Left field value of 255 in the remaining segment arrives at the forwarding egress router BFER, according to the current remaining segment
  • the value of the Segments Left field calculates the number of hops that the IPv6 packet passes through; the remaining segment Segments Left field is set to the maximum boundary value of the boundary to be passed by the IPv6 packet, and when passing through the boundary, the The value of the field is decremented by 1, and when the value of the field is 0, it indicates that the packet cannot be forwarded to the next area when it reaches the maximum boundary.
  • the above-mentioned apparatus further includes: a notification module configured to notify each node through the control plane of its own support for explicitly copying the BIER header with the bit index as the type of the routing extension header of the IPv6 header.
  • the above notification module is further configured to notify each node of its own support for the type of routing extension header that explicitly copies the bit index of the BIER header as the IPv6 header by one of the following methods: TLV
  • TLV The bit index carried in the interior gateway protocol IGP explicitly replicates the BIER information for advertising, and the bit index carried in the border gateway protocol BGP explicitly replicates the BIER information for advertising.
  • the above-mentioned advertisement module is further configured to set the forwarding router route in position when each node supports the type of routing extension header that explicitly copies the bit index of the BIER packet as the IPv6 packet header. Under the notification of the prefix BFR-Prefix or the bit forwarding router identifier BFR-ID, it is advertised in the form of sub-TLV or sub-sub-TLV.
  • the above-mentioned apparatus further includes: a guarantee module, configured to notify, through the control plane, when there are nodes in all nodes that cannot guarantee the transmission capability of the Source Address field of the IPv6 packet header And collect the delivery capability information of the Source Address field of the IPv6 header of all nodes.
  • a guarantee module configured to notify, through the control plane, when there are nodes in all nodes that cannot guarantee the transmission capability of the Source Address field of the IPv6 packet header And collect the delivery capability information of the Source Address field of the IPv6 header of all nodes.
  • the above-mentioned apparatus further includes: a determining module, configured to, when it is confirmed that the guarantee capability of the Source Address field of the IPv6 packet header is not supported, determine other parameters in the IPv6 packet header.
  • the N bit of the unused field is set to 1 to indicate that the source address Source Address of the IPv6 packet header needs to be guaranteed, wherein the value of N is not less than 1.
  • the above-mentioned apparatus further includes: a modification module configured to modify the address in the IPv6 packet, so as to set the routable prefix of the IPv6 packet in the address in the IPv6 packet in the previous target quantity.
  • the above modification module is further configured to embed the bit index forwarding table index BIFT-ID field into the destination address DA in the IPv6 message; or to insert the bit index forwarding table index BIFT-ID
  • the ID field is embedded in the source address SA in the IPv6 message; or the bit index forwarding table index BIFT-ID is filled in the Flow Label field of the IPv6 message header, and the flow label in the IPv6 message is not changed.
  • Destination address DA and source address SA is
  • the above modification module is further configured to move forward the forwarding table entry locating operation of the bit index forwarding table index BIFT-ID in the BIER message header by explicitly copying the bit index into the IPv6 message conduct.
  • the above modification module is further configured to explicitly copy the function FUNCTION field of BIER entry lookup by using a specific bit in the IPv6 message address to represent the bit index.
  • 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 any one of the above methods when running steps in the examples.
  • an electronic device comprising a memory and a processor, wherein the memory stores a computer program, the processor is configured to run the computer program to execute any of the above Steps in Method Examples.
  • the following processing can be performed on the explicit copying of the BIER packet and the IPv6 packet by the bit index: at least one of the following methods is used to explicitly copy the field in the BIER packet header according to the bit index, and the field in the IPv6 packet header is copied. Processing: Explicitly copy the bit index of the BIER packet header as the type of the routing extension header of the IPv6 packet header, and process the remaining Segments Left field in the IPv6 packet header in a predefined manner; display the bit index to the segment Left field.
  • Types of other extension headers of the BIER header as the IPv6 header wherein the types of the other extension headers include new options as the Hop-by-Hop extension header; in the source of the IPv6 header
  • the address Source Address field is filled with the bit index to explicitly copy the bit forwarding router routing prefix BFR-Prefix of the BIER message header; the bit index is explicitly copied to the bit index forwarding table index BIFT-ID in the BIER message header
  • the field is embedded in the target field of the IPv6 packet header, thereby realizing the combination of BIER packet encapsulation and IPv6 packet encapsulation, optimizing packet encapsulation and processing flow without affecting the function at all, improving forwarding Efficiency, by adopting the above technical solutions, the problems in the related art, such as the failure to effectively realize optimization in the process of combined encapsulation of BIER packets and IPv6 packets, are solved.
  • FIG. 1 is a block diagram of a hardware structure of a computer terminal according to a method for processing a packet header according to an embodiment of the present disclosure
  • FIG. 2 is a flowchart of a method for processing a packet header according to an embodiment of the present disclosure
  • FIG. 3 is a schematic diagram of a bit-indexed explicit copy BIER message encapsulated in an IPv6 message according to an embodiment of the present disclosure
  • FIG. 4 is a schematic diagram of a TLV according to an embodiment of the present disclosure.
  • FIG. 5 is a schematic diagram of a message transmission mechanism applied in the BIER domain according to an embodiment of the present disclosure
  • FIG. 6 is a schematic structural diagram of an apparatus for processing a packet header according to an embodiment of the present disclosure.
  • FIG. 1 is a hardware structural block diagram of a computer terminal according to a method for processing a packet header according to an embodiment of the present disclosure.
  • the computer terminal may include one or more (only one is shown in FIG.
  • processor 102 may include, but is not limited to, a processing device such as a microprocessor MCU or a programmable logic device FPGA, etc.
  • the above-mentioned computer terminal may further include a transmission device 106 and an input/output device 108 configured as a communication function.
  • the structure shown in FIG. 1 is only a schematic diagram, which does not limit the structure of the above-mentioned computer terminal.
  • the computer terminal 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 configured to store computer programs, for example, software programs and modules of application software, such as computer programs corresponding to the method for processing packet headers in the embodiments of the present disclosure.
  • the processor 102 runs the computer programs stored in the memory 104 , so as to perform various functional applications and data processing, 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 computer terminal 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 arranged to receive or transmit data via a network.
  • the specific example of the above-mentioned network may include a wireless network provided by the communication provider of the computer 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 configured to communicate with the Internet in a wireless manner.
  • RF Radio Frequency
  • multicast technology is being used more and more on the Internet, such as multi-party conferences, distance education, telemedicine, and webcasting.
  • IPv6 IPv6
  • the explicit BIER encapsulation of the bit index is encapsulated in the IPv6 header. has become a must-have feature.
  • a new packet encapsulation method which combines BIER encapsulation with bit index explicit copying and IPv6 encapsulation, and optimizes it. Combined with the capability announcement of the control plane, optimization is performed without affecting the function at all. Packet encapsulation and processing flow to improve forwarding efficiency.
  • FIG. 2 is a flowchart of a method for processing a packet header according to an embodiment of the present disclosure. As shown in FIG. 2 , the process includes: Follow the steps below:
  • step S202 at least one of the following methods is used to explicitly copy the fields in the BIER packet header according to the bit index to process the fields in the IPv6 packet header:
  • the following processing can be performed on the explicit copying of the BIER packet and the IPv6 packet by the bit index: at least one of the following methods is used to explicitly copy the field in the BIER packet header according to the bit index, and the field in the IPv6 packet header is copied. Processing: Explicitly copy the bit index of the BIER packet header as the type of the routing extension header of the IPv6 packet header, and process the remaining Segments Left field in the IPv6 packet header in a predefined manner; display the bit index to the segment Left field.
  • Types of other extension headers of the BIER header as the IPv6 header wherein the types of the other extension headers include new options as the Hop-by-Hop extension header; in the source of the IPv6 header
  • the address Source Address field is filled with the bit index to explicitly copy the bit forwarding router routing prefix BFR-Prefix of the BIER message header; the bit index is explicitly copied to the bit index forwarding table index BIFT-ID in the BIER message header
  • the field is embedded in the target field of the IPv6 packet header, thereby realizing the combination of BIER packet encapsulation and IPv6 packet encapsulation, optimizing packet encapsulation and processing flow without affecting the function at all, improving forwarding Efficiency, by adopting the above technical solutions, the problems in the related art, such as the failure to effectively realize optimization in the process of combined encapsulation of BIER packets and IPv6 packets, are solved.
  • the execution subject of the above steps may be a base station, a terminal, etc., but is not limited thereto.
  • the Routing Type can be directly set to BIER.
  • the remaining segment Segments Left field in the IPv6 packet header is processed in a predefined manner, including at least one of the following: setting the remaining segment Segments Left field to a target value, so that all Nodes ignore the processing of the remaining segment Segments Left field; set the remaining segment Segments Left field value of the bit forwarding entry router BFIR to 255, when the intermediate node sends the message hop by hop, the field value is decremented by 1 Processing, when the field value is 0, it indicates that there is a loop in the packet forwarding process; the bit forwarding ingress router BFIR sets the value of the Segment Left field of the remaining segment of the ingress node to the maximum number of hops to reach the edge device, and when the intermediate node jumps one by one When sending a message, the value of the field is decremented by 1.
  • the value of the field When the value of the field is 0, it indicates that a loop occurs in the message forwarding process; the value of the Segment Left field of the remaining segment of the bit forwarding entry router BFIR is set to 255, and the intermediate node When the message is sent hop by hop, the value of the field is decremented by 1.
  • the IPv6 message with the Segment Left field value of the remaining segment of 255 arrives at the bit forwarding egress router BFER, it is calculated according to the value of the Segment Left field of the current remaining segment.
  • the Segment Left field of the remaining segment is set to the maximum boundary value of the boundary to be passed by the IPv6 message, and when passing through the boundary, the field value is processed by subtracting 1, When the value of the field is 0, it indicates that the packet cannot be forwarded to the next area when it reaches the maximum boundary.
  • the set target value of the Segments Left field of the remaining segment 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 for all nodes. way of support.
  • the entry node BFIR sets the value of the Segment Left field of the remaining segment to 255, or sets the value of the Segment Left field of the remaining segment to the estimated maximum number of hops to the edge device, and then when the intermediate node sends hop-by-hop , the value of this field is decremented by 1.
  • the value of this field is reduced to 0, it means that a loop may occur in the packet forwarding process, and an alarm prompt or abnormal log recording is required, and the packet is no longer forwarded. Prevent packets from being forwarded out of domains that should not be forwarded.
  • the entry node BFIR sets the value of the Segment Left field of the remaining segment to 255, and the intermediate node decrements it by 1 when forwarding hop by hop.
  • the current segment left value can be used to calculate the length of the packet.
  • Hop count the hop count can be recorded and reported to the controller or other modules for statistical purposes.
  • the message may pass through multiple IGP domains or some BIER internal boundaries, it is possible to estimate how many such boundaries to pass through, and fill in the boundary value in the value of the Segments Left field of the remaining segment.
  • the value of the Segment Left field of the remaining segment is only on the BFER, when it is forwarded to other IGP domains, or other BIER internal boundaries, the field value is decremented by 1. If there is a single-domain forwarding, the field value is not processed. When the value of the field is 0, it indicates that the packet cannot be forwarded to the next area when it reaches the maximum boundary.
  • bit index is explicitly copied to the BIER header as the type of other extension headers of the IPv6 header, wherein the types of the other extension headers include the type of the extension header as the Hop-by-Hop extension header. options.
  • an option about the BIER type can also be added to other extension headers of the IPv6 header.
  • the bit index is explicitly copied to the BIER header as the type of the routing extension header of the IPv6 header, and the remaining segment Segments Left field in the IPv6 header is performed in a predefined manner.
  • the method further includes: notifying, through the control plane, the support of each node for explicitly copying the BIER packet header as the type of the routing extension header of the IPv6 packet header, that is, in the embodiment of the present disclosure, in the After the BIER packet header is used as a new type of IPv6 routing extension header, each node is notified through the control plane that it supports the new BIER type of the routing extension header.
  • the method further includes: announcing the support of each node for explicitly copying the bit index of the BIER packet header as the type of the routing extension header of the IPv6 packet header in one of the following ways: TLV mode For advertisement, the bit index carried in the interior gateway protocol IGP explicitly copies the BIER information for advertisement, and the bit index carried in the border gateway protocol BGP explicitly copies the BIER information for advertisement.
  • the method further includes: setting the forwarding router routing prefix in-bit when each node supports the type of routing extension header that explicitly copies the bit index of the BIER packet header as the IPv6 packet header. Under the notification of BFR-Prefix or bit forwarding router identification BFR-ID, it is advertised in the form of sub-TLV or sub-sub-TLV.
  • the notification method of the control plane includes that each node announces its own support for the new BIER type of the Routing extension header. It can be advertised in the IGP or BGP by means of TLV, that is, in the BFR-Prefix or BFR- Under the notification of id, the notification is made in the form of sub-TLV or sub-sub-TLV.
  • TLV Time Division Multiple Access
  • the notification method can also be in the form of TLV.
  • the source address Source Address (SA) and destination address Destination Address (DA) fields in the IPv6 packet header may also be the local subnet Link-local address, or through some
  • SA Source Address
  • DA Destination Address
  • the SA and DA operations on the outer IPv6 header may cause the original SA and DA information. lost. This will make the BFR-prefix information of BFIR lost. Therefore, in order to ensure that the information is not lost, it is necessary to take some specific measures to ensure the protection.
  • the protection methods include:
  • the method before filling the source address Source Address field of the IPv6 packet header with the bit index to explicitly copy the bit forwarding router routing prefix BFR-Prefix of the BIER packet header, the method further includes: Including: in the case of nodes that cannot guarantee the transmission capability of the source address Source Address field of the IPv6 message header in all nodes, advertising and collecting the source address Source Address of the IPv6 message header of all nodes through the control plane Information about the transfer capability of the field.
  • the method further Including: when confirming that the guarantee capability of the Source Address field of the IPv6 packet header is not supported, setting the N bits of other unused fields in the IPv6 packet header to 1 to indicate that the IPv6 The source address Source Address of the packet header needs to be guaranteed, wherein the value of N is not less than 1.
  • not all nodes in the domain can support the guarantee capability of the Source Address field of the IPv6 header.
  • other unused fields in the IPv6 header can be used, such as the Traffic Class field, or the reserved field in the BIER header, etc. , by setting one or several bits in these fields to 1, it indicates that the Source Address field of the IIPv6 packet header needs to be guaranteed.
  • the method before explicitly copying the bit index forwarding table index BIFT-ID field in the BIER packet header into the target field of the IPv6 packet header, the method further includes : modify the address in the IPv6 message, so as to set the routable prefix of the IPv6 message in the number of bits before the target in the IPv6 message.
  • the routable prefix of the IPv6 message is set in the former target number bits in the IPv6 message, wherein the number of target bits may be 64 bits or 96 bits, which is not limited in this disclosure. .
  • the IPv6 address can be divided into two parts: prefix + BIFT-ID, and the reachable prefix in the domain can be placed in the first 96 bits.
  • the position in the 96 bits, so that the prefix can be up to 96 bits long; the remaining 32 bits are dedicated to storing the BIFT-ID value.
  • 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 a prefix of up to 108 bits.
  • the IPv6 address is divided into three parts, except the LOC representing the prefix, and then define a new FUNCT as the BIER function,
  • the BIFT-ID is filled in the ARG position.
  • This method is suitable for the case where the BFR-Prefix length of the node is short.
  • the LOC part is 64 bits
  • the FUNC part is 32 bits
  • the ARG bit is 32 bits.
  • the method further includes: embedding the bit index forwarding table index BIFT-ID field into the destination address DA in the IPv6 message or the bit index forwarding table index BIFT-ID field is embedded in the source address SA in the IPv6 message; or the bit index forwarding table index BIFT-ID is filled in the flow label Flow of the IPv6 message header In the Label field, the destination address DA and source address SA in the IPv6 message are not changed, that is, the BIFT-ID is filled in the Flow Label field in the IPv6 header, and SA and DA are not changed.
  • This method is applicable if the BFR- Prefix must be represented by a 128-bit address.
  • the IPv6 address is divided into two parts: prefix + BIFT-ID
  • the IPv6 routable prefix of the next hop will be filled in the front of the DA.
  • 96 bits and the BIFT-ID of the next hop is filled in the last 32 bits of the DA; when the BIFT-ID field is embedded in the source address SA in the IPv6 packet, the DA fills in the IPv6 reachable route prefix of the next hop as usual.
  • the first 96 bits of the prefix are not modified, and only the last 32 bits are modified into the BIFT-ID of the next hop.
  • the ARG is filled with the BIFT-ID of the next hop; when the BIFT-ID field is embedded in the source address SA in the IPv6 packet, the DA part is filled in as the IPv6 reachable route prefix BFR-prefix of the next hop and the LOC of SA as usual. The part remains unchanged. If the FUNCT part is not the function representing BIER, it is modified to the function value representing BIER, and the ARG part of SA is filled in as the BIFT-ID of the next hop.
  • the control plane does not need to be specially expanded. However, if not all nodes support this function, in order to avoid error handling, it is also necessary to introduce the process of capability notification.
  • the method can still define a new Type type through the TLV method shown in Figure 4, and follow the BFR-prefix of BIER, etc.
  • the information is carried when the information is advertised, that is, the information is carried when the information is advertised through IGP or BGP. In this way, nodes can learn about each other's support for this function from other nodes.
  • defining a new type of sub-TLV or sub-sub-TLV indicates BIFT-ID optimization
  • different types of lower-level sub-sub-TLV or sub-sub-sub-TLV indicate different BIFT-ID optimization methods to Announcement
  • both are announced at the same time to indicate that BIFT-ID optimization is supported, and can be specific to the supported method
  • only a new type of sub-TLV or sub-sub-TLV is defined to indicate BIFT-ID optimization, and the value carried in the value directly Use 1/2/3 to represent different specific BIFT-ID optimization methods.
  • the method further includes: moving forward the forwarding table entry positioning operation of the bit index forwarding table index BIFT-ID in the BIER message header by explicitly copying the bit index into the IPv6 message .
  • the method further includes: explicitly copying the function FUNCTION field of the BIER entry lookup by using a specific bit in the IPv6 message address to represent the bit index.
  • the BIER packet is explicitly copied by the bit index as a new type of the IPv6 Routing extension header.
  • the specific definition is shown in the figure.
  • the Routing extension header defines a new type value, such as 5, indicating that the bit index is explicitly copied BIER type, in the "type-specific data" of the Routing extension header, the bit index is explicitly copied and filled in the BIER header.
  • control plane extension uniformly, as follows:
  • Control plane notification process All nodes participating in bit index explicit replication BIER forwarding need to expand the control plane and advertise it. If all nodes in the domain support bit index explicit replication BIER forwarding, then all nodes will participate in the control plane notification process. :
  • Each node announces its own support for the BIER type of the newly added bit index in the Routing extension header. It can follow the IGP by means of TLV, or the bit index in the BGP explicitly replicates the BIER information for announcement, that is, it is placed in place and forwarded. Under the notification of the routing prefix BFR-Prefix or BFR-id of the router, it is advertised in the form of sub-TLV or sub-sub-TLV, as shown in Figure 4, using type 20 or other values, indicating that it supports Routing extension header encapsulation The bit index explicitly copies the BIER type.
  • optional embodiment 1 that is, about the remaining segment Segments Left processing method 1: set the remaining segment Segments Left field to 0 or 255 or Any other value, all nodes ignore processing of this field. This method is the simplest, so it can also be used as the default support method for all nodes;
  • bit forwarding ingress router BFIR When the bit forwarding ingress router BFIR receives the multicast packet, it normally performs the bit index and explicit duplication of the BIER packet header according to the received BFER and encapsulates the outer IPv6 header, and follows the following encapsulation principles:
  • Step 1101 Generate a Routing extension header representing the explicit copy BIER type of the bit index, and set the Routing Type field in the Routing extension header to a value representing the explicit copy BIER type of the bit index, such as 5. Set the remaining segment Segments Left field to 0, or another value such as 255.
  • Step 1102 Set the Next Header of the Routing extension header to the value 59 (representing the subsequent No Next Header), or explicitly copy the Proto in the BIER header according to the bit index, find the corresponding value and set it, for example, explicitly copy the BIER by the bit index
  • the Proto value in the message header is 4, indicating that its payload is an IPv4 message, and the Next Header value of the Routing extension header is also set to 4 (representing IPv4); if the bit index explicitly replicates the Proto value in the BIER message header 6, indicating that the following is an IPv6 packet, then the Next Header value of the Routing extension header is set to 41 (representing an IPv6 packet).
  • the BFR When the BFR receives the packet, it finds that it carries the Routing extension header, and further parses the Routing extension header, and finds that the type is the type that indicates the explicit copy BIER of the bit index, and then processes it according to the following process:
  • Step 1201 Perform a normal processing flow for the explicit copy BIER message with the bit index in the Routing extension header, and search for the explicit copy of the BIER routing table by the local position index according to the Bit String in the explicit copy of the BIER message header and forward it. , although the remaining segment Segments Left value is 0 or other values, this value is ignored.
  • bit forwarding ingress router BFIR may itself be a branch node, and it will also encapsulate and send multiple packets according to the branch.
  • BFER When BFER receives the packet, it processes and finds that it carries the Routing extension header, and further parses the Routing extension header. According to the type, it is found that the BIER type is explicitly copied by the bit index, and the processing is performed according to the following process:
  • Step 1301 Perform the normal processing flow on the explicit copy BIER message of the bit index 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 that contains the explicit copy of the bit index of the BIER type. After the header, it is forwarded to the receiver.
  • the packet will continue to be forwarded to the next-hop node according to the BFR process.
  • the second embodiment (that is, the second processing method for the remaining segment Segments Left) is optional:
  • the entry node BFIR sets the value of the Segment Left field of the remaining segment to 255, or sets the value of the Segment Left field of the remaining segment to the estimated maximum number of hops to the edge device, and then when the intermediate node forwards hop by hop, this field is set.
  • the value is decremented by 1. When the value of this field is reduced to 0, it indicates that a loop may occur in the packet forwarding process, and an alarm prompt or abnormal log recording is required, and the packet is not forwarded, so as to prevent the packet from being Forwarding out of domain ranges that should not be forwarded.
  • bit forwarding ingress router BFIR When the bit forwarding ingress router BFIR receives the multicast packet, it normally performs the bit index and explicit duplication of the BIER packet header according to the received BFER and encapsulates the outer IPv6 header, and follows the following encapsulation principles:
  • Step 2101 Generate a Routing extension header representing the explicit copy BIER type of the bit index, and set the Routing Type field in the Routing extension header to a value representing the explicit copy BIER type of the bit index, such as 5.
  • a value representing the explicit copy BIER type of the bit index such as 5.
  • Set the Segments Left field of the remaining segment to 255, or estimate the maximum hop value to be passed. For example, it is estimated that it will take 10 hops to reach the farthest receiver, then the value can also be set to 10.
  • step 2102 the setting content is the same as that in step 1102 in the first optional embodiment.
  • the BFR When the BFR receives the packet, it finds that it carries the Routing extension header, and further parses the Routing extension header, and finds that the type is the type that indicates the explicit copy BIER of the bit index, and then processes it according to the following process:
  • step 2201 the normal processing flow is performed on the explicit copying of the BIER message of the bit index in the Routing extension header, and the remaining segment Segments Left is decremented by 1.
  • the remaining segment Segments Left is 0, it indicates that the maximum number of hops has been reached, If the Bit String in the BIER packet header is explicitly copied according to the bit index, the local bit index is explicitly copied to the BIER routing table, and it is found that there is still a next hop to be forwarded. In this case, if the remaining segment Segments Left is not 0, the forwarding process is continued according to step 1201 in the first optional embodiment.
  • BFER When BFER receives the packet, it processes and finds that it carries the Routing extension header, and further parses the Routing extension header. According to the type, it is found that the BIER type is explicitly copied by the bit index, and the processing is performed according to the following process:
  • Step 2301 Carry out the normal processing flow for the explicit copy BIER message of the bit index in the Routing extension header, and when it is found that the local node is the egress node, remove the entire outer IPv6 encapsulation, including the Routing extension that contains the explicit copy of the bit index of the BIER type. After the header, it is forwarded to the receiver.
  • Step 2302 if it is found that this node is a transmission node, that is, there are both receivers and next-hop devices that need 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 any more. The next hop node needs to be alarmed or reported to the controller for processing. When the value of the remaining segment Segments Left is not 0, decrement the remaining segment Segments Left by 1, and continue to forward the packet to the next-hop node according to the BFR process.
  • the third embodiment (that is, the third processing method for the remaining segment Segments Left) is optional:
  • the entry node BFIR sets the value of the Segment Left field of the remaining segment to 255, and the intermediate node decrements it by 1 when it forwards hop by hop.
  • the number of hops the message passes through can be calculated based on the value of the current remaining segment Segment Left. , the hop count can be recorded and reported to the controller or other modules for statistical purposes.
  • bit forwarding ingress router BFIR When the bit forwarding ingress router BFIR receives the multicast packet, it normally performs the bit index and explicit duplication of the BIER packet header according to the received BFER and encapsulates the outer IPv6 header, and follows the following encapsulation principles:
  • Step 3101 is the same as 2101 in the second optional embodiment, wherein the Segments Left field of the remaining segment is set to 255.
  • step 2102 the setting content is the same as that in step 1102 in the first optional embodiment.
  • the BFR When the BFR receives the packet, it finds that it carries the Routing extension header, and further parses the Routing extension header, and finds that the type is the type that indicates the explicit copy BIER of the bit index, and then processes it according to the following process:
  • Step 3201 is the same as step 2201 in the second optional embodiment.
  • BFER When BFER receives the packet, it processes and finds that it carries the Routing extension header, and further parses the Routing extension header. According to the type, it is found that the BIER type is explicitly copied by the bit index, and the processing is performed according to the following process:
  • Step 3301 is the same as step 2301 in the second optional embodiment. But at the same time, the current remaining segment Segments Left value is reported to the controller or other management modules, so that the controller can obtain the number of hops passed by the packet. It is convenient for subsequent hop number setting.
  • the fourth embodiment (that is, the remaining segment Segments Left processing mode 4):
  • Segment Segments Left field value only on BFER, when forwarding to other IGP domains, or other BIER internal boundaries, the field value is decremented by 1. If there is a single-domain forwarding, the field value is not processed, when the field value When it is 0, it indicates that the packet cannot be forwarded to the next area when it reaches the maximum boundary.
  • bit forwarding ingress router BFIR When the bit forwarding ingress router BFIR receives the multicast packet, it normally performs the bit index and explicit duplication of the BIER packet header according to the received BFER and encapsulates the outer IPv6 header, and follows the following encapsulation principles:
  • Step 4101 is the same as 2101 of the second optional embodiment, wherein the remaining segment Segments Left field is set to the estimated maximum boundary value, as shown in Figure 5, assuming that this bit index explicitly replicates the longest spanning 3 IGPs in the BIER field. Area, you can set the remaining segment Segments Left field to 3.
  • step 4102 the setting content is the same as that in step 1102 in the first optional embodiment.
  • the BFR When the BFR receives the packet, it finds that it carries the Routing extension header, and further parses the Routing extension header, and finds that the type is the type that indicates the explicit copy BIER of the bit index, and then processes it according to the following process:
  • Step 4201 when the BFR performs the bit index explicit copy 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.
  • searching for the next hop if the next hop is still in the same Area , for example, the next hop forwarded by BFR2 in Figure 5 still belongs to Area3, then normal forwarding will not be performed on the remaining segment Segments Left.
  • BFR2 finds that the next hop is in another Area4, BFR2 cannot forward the next hop to the next hop belonging to Area4, and needs to alarm or notify the controller of an abnormal situation.
  • the remaining segment Segments Left needs to be decremented by 1.
  • BFR nodes such as BFR1 and BFR2 that cross the IGP Area, and the forwarding next hop is another Area, for example, BFR1 forwards from Area1 to the next hop in Area2, or BFR2 forwards from Area3 to Area4
  • the remaining segment Segments Left is decremented by 1 only when the next hop is forwarded by BFR1. If the next hop forwarded by BFR1 still belongs to Area1, the remaining segment Segments Left will not be decremented by 1.
  • BFER When BFER receives the packet, it processes and finds that it carries the Routing extension header, and further parses the Routing extension header. According to the type, it is found that the BIER type is explicitly copied by the bit index, and the processing is performed according to the following process:
  • Step 4301 is the same as step 2301 in the second optional embodiment.
  • step 4302 when the current BFER is also a transfer node, the operation and judgment of the remaining segment Segments Left are performed according to the steps in step 4201.
  • BIER can be deeply combined with IPv6, using the IPv6 routing extension header, carrying the BIER packet header information for multicast routing, and combining the Segments Left
  • the processing method of the field can effectively control the transmission range of BIER packets on the IPv6 network. Combined with means such as controller reporting, the forwarding of BIER packets on the IPv6 network is more controllable.
  • the Source Address field of IPv6 can be filled in as the bit forwarding router routing prefix BFR-Prefix of the bit forwarding entry router BFIR.
  • the bit forwarding router routing prefix BFR-Prefix of the bit forwarding entry router BFIR that is, the advertised prefix address used for the bit index to explicitly copy the BIER route calculation. It is encapsulated into the Source Address field of the IPv6 header, so that the message can carry the BFIR information of the ingress node forwarding the ingress router, so that the ingress node can be found during fault detection, performance detection, and repeated traffic judgment.
  • the bit forwarding router routing prefix BFR-Prefix of the bit forwarding entry router BFIR itself is the IPv6 address of the BFIR node of the bit forwarding entry router. The value is filled in the Source Address field of IPv6.
  • the Source Address (SA) and Destination Address (DA) fields of the IPv6 header may also be filled with Link-local addresses, or through some explicit bit-indexed addresses that do not support
  • SA and DA operations on the outer IPv6 header may be As a result, the original SA and DA information is lost.
  • the routing prefix BFR-Prefix information of the bit forwarding router of the bit forwarding ingress router BFIR will be lost. Therefore, in order to ensure that the information is not lost, some specific measures need to be taken to ensure the protection. For details, see the following steps:
  • Step 1 Control plane extension: If all nodes can use a uniform method to ensure the transmission of the Source Address field (ie IPv6 SA) of the IPv6 packet header, no special control plane extension is required. If there are nodes that cannot guarantee IPv6 SA delivery, the control plane needs to advertise and collect this capability before operating on the data plane. The notification method can still be performed in the TLV method shown in Figure 4, and the IPv6 SA guarantee is supported by a new extension type method.
  • IPv6 SA Source Address field
  • bit forwarding ingress routers BFIR, BFER and all BFRs support this function, they all carry the IPv6 SA guarantee capability in the advertisement. Unannounced if this capability is not supported. Specific announcements can be made through IGP, BGP protocol extensions.
  • Step 2 Data plane processing.
  • the bit forwarding ingress router BFIR When the bit forwarding ingress router BFIR receives the multicast packet, it normally performs the bit index explicit copying of the BIER packet header according to the received BFER, and encapsulates the outer IPv6 header according to the following encapsulation principles. :
  • Step 5101 Encapsulate the SA in 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.
  • Step 5102 when not all nodes in the domain can support the IPv6 SA guarantee capability, other unused fields in the IPv6 header, such as the Traffic Class field, or the bit index, can be used to explicitly copy the reserved fields in the BIER header, etc.
  • the manner in which one or several bits in these fields are set to 1 indicates that the IPv6 SA needs to be guaranteed.
  • BFR When BFR receives a packet, it processes it according to the following process:
  • Step 5201 when explicitly copying the BIER message header according to the bit index, if it is found that IPv6 SA guarantee processing is not required, then forwarding is performed according to the normal process; if it is found that IPv6 SA guarantee processing is required, the next hop is found to perform forwarding processing , keep the SA in the current IPv6 header unchanged, and the DA can be set as the global routable IPv6 address of the next hop. There may be many situations in forwarding, the next hop is directly connected or the next hop is not directly connected.
  • next hop When the next hop is directly connected, if the next hop supports IPv6 encapsulation, the SA can remain unchanged and the DA can be sent directly after the next hop global routable IPv6 address; if the next hop supports Ethernet encapsulation or MPLS encapsulation , the current IPv6 header cannot be directly replaced, but the outer layer of the IPv6 header is re-encapsulated with Ethernet or MPLS, the SA in the IPv6 header remains unchanged, and the DA in the IPv6 header is set to the global routable IPv6 address of the next hop.
  • the tunnel technology needs to be used 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 used tunnel is still an IPv6 tunnel and the SA does not need to be modified, the packet can be sent directly. If the tunnel used is a GRE (Generic Routing Encapsulation) tunnel, and the SA needs to be modified as the starting point of the tunnel, then the tunnel encapsulation needs to be performed outside the current IPv6 header to ensure that the SA will not be modified.
  • GRE Generic Routing Encapsulation
  • the forwarding ingress router BFIR may also encounter the situation that the next hop needs to be encapsulated by the tunnel, and it will be processed in the same way as the BFR.
  • BFER When BFER receives a packet, if it finds that the packet is not guaranteed by SA, no special treatment is required. If it is found that the packet is guaranteed by SA, it is processed according to the following process:
  • Step 5301 in the case of an outer tunnel, strip 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 entry router BFIR. It can be used for fault or path detection, or for judging and discarding duplicate packets.
  • the BIER header already has a BFIR-ID, which represents the BFR-id value of the entry node BFIR, which is usually used for performance measurement or fault detection.
  • BFIR-ID represents the BFR-id value of the entry node BFIR, which is usually used for performance measurement or fault detection.
  • the exit node BFER can also judge based on the value of the BFIR-ID, choose to receive the traffic of a certain BFIR-ID, and discard the traffic sent by other BFIRs flow.
  • the entry node BFIR does not assign a BFR-ID, that is to say, all exit node BFER must be assigned a BFR-ID, but the entry node BFIR is not necessarily, so there may be BFIR does not assign a BFR-ID, which makes it impossible to fill in the BFIR-ID value in the BIER header.
  • the egress node BFER cannot judge the duplicate traffic based on this value. If there is duplicate traffic, it will cause the forwarding of the duplicate traffic.
  • the BFR-prefix of BFIR that is, the advertised prefix address used for BIER route calculation
  • the BFR-prefix of BFIR is encapsulated into the Source Address field of the IPv6 header, so that the message can carry the entry node BFIR. information, so that the entry node can be found when fault detection, performance detection, and repeated traffic judgment.
  • the repeated traffic judgment of BIER can be advanced to It is performed in IPv6 packets, and the BFIR of the ingress device does not need to allocate BFR-IDs, so BIER can realize repeated traffic judgment, which can save the number of BFR-IDs allocated, and the realization of repeated traffic judgment is more accurate.
  • the index BIFT-ID of the bit index forwarding table can also be optimized, including the following optional implementation six to optional embodiments 3 examples of eight:
  • bit index forwarding table index BIFT-ID optimization method if all nodes can adopt the 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 advertise and collect this capability before the data plane operates.
  • the notification method can still be carried out in the TLV method shown in Figure 4.
  • the new extension type indicates that the optimization of bit index forwarding table index BIFT-ID is supported, and the bit forwarding entry router BFIR, BFER and all BFRs, when supporting this function, are all supported.
  • the bit index forwarding table index BIFT-ID optimization capability is carried in the announcement, and no announcement is made if this capability is not supported.
  • the specific announcement can be extended through the IGP and BGP protocols.
  • bit forwarding ingress router BFIR When the bit forwarding ingress router BFIR receives the multicast packet, it normally performs the bit index and explicit duplication of the BIER packet header according to the received BFER and encapsulates the outer IPv6 header, and follows the following encapsulation principles:
  • Step 6101 Encapsulate the first 96 bits of the DA in the IPv6 header as the next-hop bit forwarding router routing prefix BFR-Prefix, and fill the bit index forwarding table index BIFT-ID advertised by the next hop into the lower 32 bits of the DA.
  • BFR When BFR receives a packet, it processes it according to the following process:
  • Step 6201 when performing a conventional local prefix judgment according to the received message, take the first 96 bits of the IPv6 DA to search and judge, and when it is found that it is a local prefix, then perform a bit index on the last 32 bits of the DA to explicitly copy the BIER entry. Positioning operation, and then explicitly copy the BIER header according to the bit index to look up the table.
  • Step 6202 when preparing to copy the message to the next hop, if the next hop supports the bit index forwarding table index BIFT-ID optimization method, then perform IPv6 message encapsulation according to the next hop optimization method, for example, the next hop also supports
  • the next hop bit forwarding router routing prefix BFR-Prefix When the first 96 bits of DA are encapsulated as bit forwarding router routing prefix BFR-Prefix, and the last 32 bits are encapsulated as bit index forwarding table index BIFT-ID, the next hop bit forwarding router routing prefix BFR-Prefix and bit are encapsulated according to this rule.
  • Index forwarding table index BIFT-ID When the first 96 bits of DA are encapsulated as bit forwarding router routing prefix BFR-Prefix, and the last 32 bits are encapsulated as bit index forwarding table index BIFT-ID, the next hop bit forwarding router routing prefix BFR-Prefix and bit are encapsulated according to this rule.
  • next hops support another bit index forwarding table index BIFT-ID optimization method, for example, it supports the first 64-bit encapsulation as a bit forwarding router routing prefix BFR-Prefix, and the middle 32-bit encapsulation as a representation bit index to explicitly copy BIER
  • the next hop bit forwarding router routing prefix BFR-Prefix and the bit index forwarding table index BIFT-ID are encapsulated according to this principle.
  • bit index forwarding table index BIFT-ID optimization process is not performed on the content of the IPv6 header.
  • Step 6301 similar to Step 6201, except that it is judged to be a local prefix, the BIER message header will be explicitly copied according to the bit index to determine that there is a local receiver, then the message will be stripped of the IPv6 header and the bit index. Explicitly copy the BIER message sent to the receiver after the header.
  • step 6302 if the current BFER node is also a transmission node, that is, there is still a next hop to continue sending, the method of step 6202 can be used.
  • the encapsulation method is changed according to different conditions of the next hop, which is applicable to all nodes including bit forwarding ingress routers BFIR, BFR, and BFER transmission, not just BFR nodes.
  • bit forwarding ingress router BFIR When the bit forwarding ingress router BFIR receives the multicast packet, it normally performs the bit index and explicit duplication of the BIER packet header according to the received BFER and encapsulates the outer IPv6 header, and follows the following encapsulation principles:
  • Step 7101 Encapsulate the first 96 bits of the SA in the IPv6 header as the current forwarding router routing prefix BFR-Prefix, and fill the lower 32 bits of the SA with the bit index forwarding table index BIFT-ID advertised by the next hop.
  • BFR When BFR receives a packet, it processes it according to the following process:
  • Step 7201 when performing conventional local prefix judgment according to the received message, and processing according to the normal DA search process, when it is found that it is a local prefix, the last 32 bits of the SA are then subjected to the location operation of explicitly copying the BIER entry by the bit index, Then explicitly copy the BIER header according to the bit index for table lookup.
  • Step 7202 When preparing to copy the message to the next hop, if the next hop supports the bit index forwarding table index BIFT-ID optimization method, then perform IPv6 message encapsulation according to the optimization method of the next hop, for example, the next hop also supports When the first 96 bits of SA are encapsulated as a bit forwarding router routing prefix BFR-Prefix, and the last 32 bits are encapsulated as a bit index forwarding table index BIFT-ID, the next hop bit index forwarding table index BIFT-ID is encapsulated according to this rule to SA in the lower 32 bits.
  • next hops support another bit index forwarding table index BIFT-ID optimization method, for example, it supports the first 64-bit encapsulation as a bit forwarding router routing prefix BFR-Prefix, and the middle 32-bit encapsulation as a representation bit index to explicitly copy BIER function, when the last 32 bits encapsulate the bit index forwarding table index BIFT-ID, the next hop bit index forwarding table index BIFT-ID is encapsulated into the lower 32 bits of SA according to this principle.
  • bit index forwarding table index BIFT-ID optimization process is not performed on the content of the IPv6 header.
  • Step 7301 similar to Step 7201, except that it is judged to be a local prefix, the BIER message header will be explicitly copied according to the bit index to determine that there is a local receiver, then the message will be stripped of the IPv6 header and bit index. Explicitly copy the BIER message sent to the receiver after the header.
  • Step 7302 if the current BFER node is also a transmission node, that is, there is still a next hop to continue sending, the method of step 7202 can be used.
  • the encapsulation method is changed according to different conditions of the next hop, which is applicable to all nodes including bit forwarding ingress routers BFIR, BFR, and BFER transmission, not just BFR nodes.
  • bit forwarding ingress router BFIR When the bit forwarding ingress router BFIR receives the multicast packet, it normally performs the bit index and explicit duplication of the BIER packet header according to the received BFER and encapsulates the outer IPv6 header, and follows the following encapsulation principles:
  • Step 8101 encapsulate the SA/DA of the IPv6 header according to the normal processing method, and encapsulate the Flow Label field as the bit index forwarding table index BIFT-ID of the next hop.
  • BFR When BFR receives a packet, it processes it according to the following process:
  • Step 8201 according to the normal local prefix judgment according to the received message, the process is processed according to the normal DA search process, and when it is found that it is 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 BIER The positioning operation of the table entry, and then explicitly copy the BIER header according to the bit index to look up the table.
  • Step 8202 when preparing to copy the message to the next hop, if the next hop supports the bit index forwarding table index BIFT-ID optimization method, then perform IPv6 message encapsulation according to the next hop optimization method, for example, the next hop also supports The bit index forwarding table index BIFT-ID is encapsulated into the Flow Label field, and the bit index forwarding table index BIFT-ID of the next hop is encapsulated into the Flow Label field according to this rule.
  • next hops support another bit index forwarding table index BIFT-ID optimization method, for example, it supports embedding the bit index forwarding table index BIFT-ID into the DA, and the first 96 bits are encapsulated as a bit forwarding router routing prefix BFR-Prefix, the middle 32 bits are encapsulated as the function of explicitly copying the BIER of the bit index, and when the last 32 bits are encapsulated in the bit index forwarding table index BIFT-ID, the bit index forwarding table index BIFT-ID of the next hop will be indexed according to this principle. Packed into the lower 32 bits of the DA.
  • bit index forwarding table index BIFT-ID optimization process is not performed on the content of the IPv6 header.
  • Step 8301 similar to Step 8201, except that it is determined to be a local prefix, the BIER message header will be explicitly copied according to the bit index to determine that there is a local receiver, then the IPv6 header and bit index of the message will be stripped off and the BIER message will be explicitly copied. sent to the receiver after the header.
  • Step 8302 if the current BFER node is also a transmission node, that is, there is still a next hop to continue sending, the method of step 8202 can be used.
  • the encapsulation method is changed according to different conditions of the next hop, which is applicable to all nodes including bit forwarding ingress routers BFIR, BFR, and BFER transmission, not just BFR nodes.
  • an optional embodiment of the present disclosure proposes a new message encapsulation method, which combines the bit index explicit copy BIER encapsulation with the IPv6 encapsulation, uses the fields in the outer IPv6 header, and does not affect the On the premise of the function implementation, optimize the fields in the BIER packet header that is explicitly copied by the bit index, including three categories.
  • This embodiment also provides an apparatus for processing a packet header, the apparatus is configured to implement the above-mentioned embodiments and optional implementation manners, and what has been described will not be repeated.
  • the term "module” may be a combination of software and/or hardware that implements a predetermined function.
  • the apparatus described in the following embodiments is preferably implemented in software, implementations in hardware, or a combination of software and hardware, are also possible and contemplated.
  • FIG. 6 is a structural block diagram of an apparatus for processing a packet header according to an embodiment of the present disclosure. As shown in FIG. 6 , the apparatus includes:
  • the processing module 70 is configured to process 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: explicitly copying the BIER message header by the bit index as the IPv6 message The type of the routing extension header of the header, and the remaining segment Segments Left field in the IPv6 header is processed according to a predefined method; the bit index is explicitly copied to the BIER header as the extension of the IPv6 header.
  • Type wherein the type of the other extension header is included as an option in the Hop-by-Hop extension header; Fill in the bit index in the Source Address field of the IPv6 header to explicitly copy the BIER message
  • the bit forwarding router of the header routes the prefix BFR-Prefix; the bit index is explicitly copied to the bit index forwarding table index BIFT-ID field in the BIER message header, and the BIFT-ID field is embedded into the target field of the IPv6 message header.
  • the following processing can be performed on the explicit copying of the BIER packet and the IPv6 packet by the bit index: at least one of the following methods is used to explicitly copy the field in the BIER packet header according to the bit index, and the field in the IPv6 packet header is copied. Processing: Explicitly copy the bit index of the BIER packet header as the type of the routing extension header of the IPv6 packet header, and process the remaining Segments Left field in the IPv6 packet header in a predefined manner; display the bit index to the segment Left field.
  • Types of other extension headers of the BIER header as the IPv6 header wherein the types of the other extension headers include new options as the Hop-by-Hop extension header; in the source of the IPv6 header
  • the address Source Address field is filled with the bit index to explicitly copy the bit forwarding router routing prefix BFR-Prefix of the BIER message header; the bit index is explicitly copied to the bit index forwarding table index BIFT-ID in the BIER message header
  • the field is embedded in the target field of the IPv6 packet header, thereby realizing the combination of BIER packet encapsulation and IPv6 packet encapsulation, optimizing packet encapsulation and processing flow without affecting the function at all, improving forwarding Efficiency, by adopting the above technical solutions, the problems in the related art, such as the failure to effectively realize optimization in the process of combined encapsulation of BIER packets and IPv6 packets, are solved.
  • the Routing Type can be directly set to BIER.
  • the processing module 70 processes the Segment Left field of the remaining segment in the IPv6 packet header in a predefined manner, including at least one of the following: setting the Segment Left field of the remaining segment as a target value, so that all nodes ignore the processing of the remaining segment Segments Left field; the value of the remaining segment Segments Left field of the bit forwarding entry router BFIR is set to 255, when the intermediate node sends the message hop by hop, to the field The value is subtracted by 1. When the field value is 0, it indicates that there is a loop in the packet forwarding process; the bit forwarding ingress router BFIR sets the value of the Segment Left field of the remaining segment of the ingress node to the maximum number of hops to reach the edge device.
  • the value of the field is decremented by 1.
  • the value of the field is 0, it indicates that a loop occurs in the message forwarding process; the value of the Segment Left field of the remaining segment of the bit forwarding entry router BFIR is set to 255, when the intermediate node sends the message hop-by-hop, the value of the field is decremented by 1.
  • the IPv6 message with the value of the Segment Left field of the remaining segment of 255 arrives at the forwarding egress router BFER, it is processed according to the current segment Left field of the remaining segment.
  • the value calculates the number of hops that the IPv6 message passes through; the remaining segment Segments Left field is set to the maximum boundary value of the boundary to be passed by the IPv6 message, and the field value is carried out when passing through the boundary. Decrement by 1, when the value of the field is 0, it indicates that the packet cannot be forwarded to the next area when it reaches the maximum boundary.
  • the set target value of the Segments Left field of the remaining segment 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 value of all nodes. way of support;
  • the entry node BFIR sets the value of the Segment Left field of the remaining segment to 255, or sets the value of the Segment Left field of the remaining segment to the estimated maximum number of hops to the edge device, and then when the intermediate node sends hop-by-hop , the value of this field is decremented by 1.
  • the value of this field is reduced to 0, it means that a loop may occur in the packet forwarding process, and an alarm prompt or abnormal log recording is required, and the packet is no longer forwarded. Prevent packets from being forwarded out of domains that should not be forwarded.
  • the entry node BFIR sets the value of the Segment Left field of the remaining segment to 255, and the intermediate node decrements it by 1 when forwarding hop by hop.
  • the current segment left value can be used to calculate the length of the packet.
  • Hop count the hop count can be recorded and reported to the controller or other modules for statistical purposes.
  • the message may pass through multiple IGP domains or some BIER internal boundaries, it is possible to estimate how many such boundaries to pass through, and fill in the boundary value in the value of the Segments Left field of the remaining segment.
  • the value of the Segment Left field of the remaining segment is only on the BFER, when it is forwarded to other IGP domains, or other BIER internal boundaries, the field value is decremented by 1. If there is a single-domain forwarding, the field value is not processed. When the value of the field is 0, it indicates that the packet cannot be forwarded to the next area when it reaches the maximum boundary.
  • the processing module is further configured to explicitly copy the bit index of the BIER packet header as the type of other extension headers of the IPv6 packet header, wherein the type of the other extension headers includes Hop-by -Hop option in extension header.
  • an option about the BIER type can also be added to other extension headers of the IPv6 header.
  • the above-mentioned apparatus further includes: a notification module, configured to notify each node through the control plane of its own support for the type of routing extension header that uses the bit index to explicitly copy the BIER packet header as the IPv6 packet header, That is, in the embodiment of the present disclosure, after the BIER header is used as a new type of the IPv6 routing extension header, each node is notified through the control plane that it supports the newly added BIER type of the Routing extension header.
  • a notification module configured to notify each node through the control plane of its own support for the type of routing extension header that uses the bit index to explicitly copy the BIER packet header as the IPv6 packet header, That is, in the embodiment of the present disclosure, after the BIER header is used as a new type of the IPv6 routing extension header, each node is notified through the control plane that it supports the newly added BIER type of the Routing extension header.
  • the above notification module is further configured to notify each node of its own support for the type of routing extension header that explicitly copies the bit index of the BIER header as the IPv6 header by one of the following methods: TLV
  • TLV The bit index carried in the interior gateway protocol IGP explicitly replicates the BIER information for advertising, and the bit index carried in the border gateway protocol BGP explicitly replicates the BIER information for advertising.
  • the above-mentioned advertisement module is further configured to set the forwarding router route in position when each node supports the type of routing extension header that explicitly copies the bit index of the BIER packet as the IPv6 packet header. Under the notification of the prefix BFR-Prefix or the bit forwarding router identifier BFR-ID, it is advertised in the form of sub-TLV or sub-sub-TLV.
  • the notification method of the control plane includes that each node announces its own support for the new BIER type of the Routing extension header. It can be advertised in the IGP or BGP by means of TLV, that is, in the BFR-Prefix or BFR- Under the notification of id, the notification is made in the form of sub-TLV or sub-sub-TLV.
  • TLV Time Division Multiple Access
  • the notification method can also be in the form of TLV.
  • the source address Source Address (SA) and destination address Destination Address (DA) fields in the IPv6 packet header may also be the local subnet Link-local address, or through some
  • SA Source Address
  • DA Destination Address
  • the SA and DA operations on the outer IPv6 header may cause the original SA and DA information. lost. This will make the BFR-prefix information of BFIR lost. Therefore, in order to ensure that the information is not lost, it is necessary to take some specific measures to ensure the protection.
  • the protection methods include:
  • the above-mentioned apparatus further includes: a guarantee module, configured to notify, through the control plane, when there are nodes in all nodes that cannot guarantee the transmission capability of the Source Address field of the IPv6 packet header And collect the delivery capability information of the Source Address field of the IPv6 header of all nodes.
  • a guarantee module configured to notify, through the control plane, when there are nodes in all nodes that cannot guarantee the transmission capability of the Source Address field of the IPv6 packet header And collect the delivery capability information of the Source Address field of the IPv6 header of all nodes.
  • the above-mentioned apparatus further includes: a determining module, configured to, when it is confirmed that the guarantee capability of the Source Address field of the IPv6 packet header is not supported, determine other parameters in the IPv6 packet header.
  • the N bit of the unused field is set to 1 to indicate that the source address Source Address of the IPv6 packet header needs to be guaranteed, wherein the value of N is not less than 1.
  • not all nodes in the domain can support the guarantee capability of the Source Address field of the IPv6 header.
  • other unused fields in the IPv6 header can be used, such as the Traffic Class field, or the reserved field in the BIER header, etc. , 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 guaranteed.
  • the above-mentioned apparatus further includes: a modification module configured to modify the address in the IPv6 packet, so as to set the routable prefix of the IPv6 packet in the address in the IPv6 packet in the previous target quantity.
  • the routable prefix of the IPv6 message is set in the former target number bits in the IPv6 message, wherein the number of target bits may be 64 bits or 96 bits, which is not limited in this disclosure. .
  • the IPv6 address can be divided into two parts: prefix + BIFT-ID, and the reachable prefix in the domain can be placed in the first 96 bits.
  • the position in the 96 bits, so that the prefix can be up to 96 bits long; the remaining 32 bits are dedicated to storing the BIFT-ID value.
  • 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 a prefix of up to 108 bits.
  • the IPv6 address is divided into three parts, except the LOC representing the prefix, and then define a new FUNCT as the BIER function,
  • the BIFT-ID is filled in the ARG position.
  • This method is suitable for the case where the BFR-Prefix length of the node is short.
  • the LOC part is 64 bits
  • the FUNC part is 32 bits
  • the ARG bit is 32 bits.
  • the above modification module is further configured to embed the bit index forwarding table index BIFT-ID field into the destination address DA in the IPv6 message; or to insert the bit index forwarding table index BIFT-ID
  • the ID field is embedded in the source address SA in the IPv6 message; or the bit index forwarding table index BIFT-ID is filled in the Flow Label field of the IPv6 message header, and the flow label in the IPv6 message is not changed.
  • the destination address DA and the source address SA 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 applicable to the scenario where the BFR-Prefix must be represented by a 128-bit address .
  • the IPv6 address is divided into two parts: prefix + BIFT-ID
  • the IPv6 routable prefix of the next hop will be filled in the front of the DA.
  • 96 bits and the BIFT-ID of the next hop is filled in the last 32 bits of the DA; when the BIFT-ID field is embedded in the source address SA in the IPv6 packet, the DA fills in the IPv6 reachable route prefix of the next hop as usual.
  • the first 96 bits of the prefix are not modified, and only the last 32 bits are modified into the BIFT-ID of the next hop.
  • the ARG is filled with the BIFT-ID of the next hop; when the BIFT-ID field is embedded in the source address SA in the IPv6 packet, the DA part is filled in as the IPv6 reachable route prefix BFR-prefix of the next hop and the LOC of SA as usual. The part remains unchanged. If the FUNCT part is not the function representing BIER, it is modified to the function value representing BIER, and the ARG part of SA is filled in as the BIFT-ID of the next hop.
  • the control plane does not need to be specially expanded. However, if not all nodes support this function, in order to avoid error handling, it is also necessary to introduce the process of capability notification.
  • the method can still define a new Type type through the TLV method shown in Figure 4, and follow the BFR-prefix of BIER, etc.
  • the information is carried when advertised, that is, the information is carried when advertised through IGP or BGP. In this way, nodes can learn about each other's support for this function from other nodes.
  • defining a new type of sub-TLV or sub-sub-TLV indicates BIFT-ID optimization
  • different types of lower-level sub-sub-TLV or sub-sub-sub-TLV indicate different BIFT-ID optimization methods to Announcement
  • both are announced at the same time to indicate that BIFT-ID optimization is supported, and can be specific to the supported method
  • only a new type of sub-TLV or sub-sub-TLV is defined to indicate BIFT-ID optimization, and the value carried in the value directly Use 1/2/3 to represent different specific BIFT-ID optimization methods.
  • the above modification module is further configured to move forward the forwarding table entry locating operation of the bit index forwarding table index BIFT-ID in the BIER message header by explicitly copying the bit index into the IPv6 message conduct.
  • the above modification module is further configured to explicitly copy the function FUNCTION field of BIER entry lookup by using a specific bit in the IPv6 message address to represent the bit index.
  • the above modules can be implemented by software or hardware, and the latter can be implemented in the following ways, but not limited to this: the above modules are all located in the same processor; or, the above modules can be combined in any combination The forms are located in different processors.
  • Embodiments of the present disclosure also 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 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 disks, magnetic disks or CD-ROMs and other media that can store computer programs.
  • ROM Read-Only Memory
  • RAM Random Access Memory
  • An embodiment of the present disclosure also provides 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 disclosure 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 disclosure is not limited to any particular combination of hardware and software.

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Theoretical Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Data Mining & Analysis (AREA)
  • Computer Security & Cryptography (AREA)
  • Software Systems (AREA)
  • Computational Linguistics (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本公开实施例提供了一种报文头的处理方法及装置、存储介质、电子装置，上述方法包括：至少通过以下方式之一根据位索引显式复制BIER报文头中的字段对IPv6报文头中的字段进行处理：将位索引显式复制BIER报文头作为IPv6报文头的路由扩展头的类型，且按照预定义方式对IPv6报文头中的剩余段Segments Left字段进行处理；将位索引显式复制BIER报文头作为IPv6报文头的其他扩展头的类型，其中，包括作为Hop-by-Hop扩展头中的新选项；在IPv6报文头的来源地址Source Address字段中填入位索引显式复制BIER报文头的位转发路由器路由前缀BFR-Prefix；将位索引显式复制BIER报文头中的位索引转发表索引BIFT-ID字段嵌入到IPv6报文头的目标字段中，解决了相关技术中，未能有效实现在BIER报文与IPv6报文结合封装的过程中进行优化等问题。

Description

报文头的处理方法及装置、存储介质、电子装置 技术领域
本公开实施例涉及通信领域，具体而言，涉及一种报文头的处理方法及装置、存储介质、电子装置。
背景技术
互联网协议第6版(Internet Protocol Version 6，简称为IPv6)是互联网工程任务组(Internet Engineering Task Force，简称为IETF)设计的用于替代IPv4的下一代IP协议。IPv6的使用，不仅能解决网络地址资源数量的问题，而且也解决了多种接入设备连入互联网的障碍。
位索引显式复制(Bit Indexed Explicit Replication，简称为BIER)(RFC8279)是一种新型组播数据转发技术，该将网络边缘的节点都只用一个bit位来表示，组播流量在中间网络传输，额外封装一个特定的BIER报文头，这个报文头以bit位串的形式标注了该组播流的所有目的节点，中间网络转发节点根据bit位进行路由，保障流量能够发送到所有目的节点。中间节点转发设备事先通过路由协议，如三层网络中的开放式最短路径优先(OSPF Open Shortest Path First，简称为OSPF)协议，中间系统到中间系统(Intermediate System-to-Intermediate System，简称为ISIS)协议，形成用于指导BIER转发的位索引转发表(Bit Index Forwarding Table，简称为BIFT)表，在收到封装BIER报文头的流量时，依据BIFT来完成报文到目的节点的转发。BIER这种数据面转发技术因为没有组播树的建立问题，消除了组播树建立的时延，并且在网络出现链路或者节点问题时，收敛速度同OSPF或ISIS协议，比原来的组播树重建降低了巨大的时延。
BIER技术在传输的时候，仅需要将某条组播流量封装在BIER报文内作为载荷(payload)传输。对于BIER域的入口设备BFIR(Bit-Forwarding Ingress Router)来说，需要知道哪些BIER域的出口设备BFERs(Bit-Forwarding Egress Routers)需要这条组播流量，这样在BFER收到这条组播流量后，才能转发给BIER域外需要收到这条流量的组播接收者。BIER技术可以直接封装在以太报文中进行传输(协议号0xAB37)，在某些节点不能支持对以太BIER报文进行直接辨识时，如果仍然采用以太报文传输，不能正确辨识该报文的节点将成为黑洞丢弃报文。
针对相关技术中，如何在BIER报文与IPv6报文结合封装的过程中进行优化的问题，尚未提出有效的解决方案。
发明内容
本公开实施例提供了一种报文头的处理方法及装置、存储介质、电子装置，以至少解决相关技术中尚未提供如何在BIER报文与IPv6报文结合封装的过程中进行优化的问题的技术方案。
根据本公开的一个实施例，提供了一种报文头的处理方法，包括：至少通过以下方式之一根据位索引显式复制BIER报文头中的字段对IPv6报文头中的字段进行处理：将位索引显式复制BIER报文头作为IPv6报文头的路由扩展头的类型，且按照预定义方式对所述IPv6报文头中的剩余段Segments Left字段进行处理；将位索引显式复制BIER报文头作为IPv6报 文头的其他扩展头的类型，其中，所述其他扩展头的类型包括作为Hop-by-Hop扩展头中的选项；在所述IPv6报文头的来源地址Source Address字段中填入所述位索引显式复制BIER报文头的位转发路由器路由前缀BFR-Prefix；将所述位索引显式复制BIER报文头中的位索引转发表索引BIFT-ID字段嵌入到所述IPv6报文头的目标字段中。
在一个示例性实施例中，按照预定义方式对所述IPv6报文头中的剩余段Segments Left字段进行处理，至少包括以下之一：将所述剩余段Segments Left字段设置为目标值，使所有节点均忽略对所述剩余段Segments Left字段的处理；将位转发入口路由器BFIR的剩余段Segments Left字段值设置为255，当中间节点逐跳转发报文时，对所述字段值进行减1处理，当字段值为0时，指示报文转发过程出现环路；将位转发入口路由器BFIR将入口节点的剩余段Segments Left字段值设置为到达边缘设备的最大跳数，当中间节点逐跳转发报文时，对所述字段值进行减1处理，当字段值为0时，指示报文转发过程出现环路；将位转发入口路由器BFIR的剩余段Segments Left字段值设置为255，中间节点逐跳转发报文时，对所述字段值进行减1处理，在剩余段Segments Left字段值为255的IPv6报文到达位转发出口路由器BFER时，根据当前剩余段Segments Left字段的值计算出所述IPv6报文经过的跳数；将所述剩余段Segments Left字段设置为所述IPv6报文待经过的边界的最大边界值，当经过所述边界时对所述字段值进行减1处理，当所述字段值为0时，指示报文到达最大边界不能再继续转发到下一个区域。
在一个示例性实施例中，将位索引显式复制BIER报文头作为IPv6报文头的路由扩展头的类型，且按照预定义方式对所述IPv6报文头中的剩余段Segments Left字段进行处理之后，所述方法还包括：通过控制面通告各节点自身对将位索引显式复制BIER报文头作为IPv6报文头的路由扩展头的类型的支持。
在一个示例性实施例中，所述方法还包括：通过以下方式之一通告各节点自身对将位索引显式复制BIER报文头作为IPv6报文头的路由扩展头的类型的支持：TLV方式进行通告，携带在内部网关协议IGP中的位索引显式复制BIER信息进行通告，携带在边界网关协议BGP中的位索引显式复制BIER信息进行通告。
在一个示例性实施例中，所述方法还包括：在将各节点自身对将位索引显式复制BIER报文头作为IPv6报文头的路由扩展头的类型的支持设置在位转发路由器路由前缀BFR-Prefix或者位转发路由器标识BFR-ID的通知下，以sub-TLV或者sub-sub-TLV的方式进行通告。
在一个示例性实施例中，在所述IPv6报文头的来源地址Source Address字段中填入所述位索引显式复制BIER报文头的位转发路由器路由前缀BFR-Prefix之前，所述方法还包括：在所有节点中存在无法保障所述IPv6报文头的来源地址Source Address字段的传递能力的节点的情况下，通过控制面通告和收集所有节点的所述IPv6报文头的来源地址Source Address字段的传递能力的信息。
在一个示例性实施例中，在所述IPv6报文头的来源地址Source Address字段中填入所述位索引显式复制BIER报文头的位转发路由器路由前缀BFR-Prefix之后，所述方法还包括：在确认所述IPv6报文头的来源地址Source Address字段的保障能力不被支持时，将所述IPv6报文头中的其他未使用的字段的N位设置为1，以指示所述IPv6报文头的来源地址Source Address需要进行保障处理，其中，所述N的值不小于1。
在一个示例性实施例中，将所述位索引显式复制BIER报文头中的位索引转发表索引 BIFT-ID字段嵌入到所述IPv6报文头的目标字段中之前，所述方法还包括：对所述IPv6报文中的地址进行改造，以将所述IPv6报文的可路由前缀设置在所述IPv6报文中的前目标数量位中。
在一个示例性实施例中，对所述IPv6报文中的地址进行改造之后，所述方法还包括：将所述位索引转发表索引BIFT-ID字段嵌入所述IPv6报文中目的地址DA中；或将所述位索引转发表索引BIFT-ID字段嵌入所述IPv6报文中来源地址SA中；或将所述位索引转发表索引BIFT-ID填入所述IPv6报文头的流标签Flow Label字段中，不改动所述IPv6报文中目的地址DA与来源地址SA。
在一个示例性实施例中，所述方法还包括：将所述位索引显式复制BIER报文头中的位索引转发表索引BIFT-ID的转发表项定位操作前移到IPv6报文中进行。
在一个示例性实施例中，所述方法还包括：用所述IPv6报文地址中的特定位表示位索引显式复制BIER表项查找的功能FUNCTION字段。
根据本公开的另一个实施例，还提供了一种报文头的处理装置，包括：处理模块，设置为至少通过以下方式之一根据位索引显式复制BIER报文头中的字段对IPv6报文头中的字段进行处理：将位索引显式复制BIER报文头作为IPv6报文头的路由扩展头的类型，且按照预定义方式对所述IPv6报文头中的剩余段Segments Left字段进行处理；将位索引显式复制BIER报文头作为IPv6报文头的其他扩展头的类型，其中，所述其他扩展头的类型包括作为Hop-by-Hop扩展头中的选项；在所述IPv6报文头的来源地址Source Address字段中填入所述位索引显式复制BIER报文头的位转发路由器路由前缀BFR-Prefix；将所述位索引显式复制BIER报文头中的位索引转发表索引BIFT-ID字段嵌入到所述IPv6报文头的目标字段中。
在一个示例性实施例中，上述处理模块，还设置为按照预定义方式对所述IPv6报文头中的剩余段Segments Left字段进行处理，至少包括以下之一：将所述剩余段Segments Left字段设置为目标值，使所有节点均忽略对所述剩余段Segments Left字段的处理；将位转发入口路由器BFIR的剩余段Segments Left字段值设置为255，当中间节点逐跳转发报文时，对所述字段值进行减1处理，当字段值为0时，指示报文转发过程出现环路；将位转发入口路由器BFIR将入口节点的剩余段Segments Left字段值设置为到达边缘设备的最大跳数，当中间节点逐跳转发报文时，对所述字段值进行减1处理，当字段值为0时，指示报文转发过程出现环路；将位转发入口路由器BFIR的剩余段Segments Left字段值设置为255，中间节点逐跳转发报文时，对所述字段值进行减1处理，在剩余段Segments Left字段值为255的IPv6报文到达位转发出口路由器BFER时，根据当前剩余段Segments Left字段的值计算出所述IPv6报文经过的跳数；将所述剩余段Segments Left字段设置为所述IPv6报文待经过的边界的最大边界值，当经过所述边界时对所述字段值进行减1处理，当所述字段值为0时，指示报文到达最大边界不能再继续转发到下一个区域。
在一个示例性实施例中，上述装置还包括：通告模块，设置为通过控制面通告各节点自身对将位索引显式复制BIER报文头作为IPv6报文头的路由扩展头的类型的支持。
在一个示例性实施例中，上述通告模块，还设置为通过以下方式之一通告各节点自身对将位索引显式复制BIER报文头作为IPv6报文头的路由扩展头的类型的支持：TLV方式进行通告，携带在内部网关协议IGP中的位索引显式复制BIER信息进行通告，携带在边界网关协议BGP中的位索引显式复制BIER信息进行通告。
在一个示例性实施例中，上述通告模块，还设置为在将各节点自身对将位索引显式复制BIER报文头作为IPv6报文头的路由扩展头的类型的支持设置在位转发路由器路由前缀BFR-Prefix或者位转发路由器标识BFR-ID的通知下，以sub-TLV或者sub-sub-TLV的方式进行通告。
在一个示例性实施例中，上述装置还包括：保障模块，设置为在所有节点中存在无法保障所述IPv6报文头的来源地址Source Address字段的传递能力的节点的情况下，通过控制面通告和收集所有节点的所述IPv6报文头的来源地址Source Address字段的传递能力的信息。
在一个示例性实施例中，上述装置还包括：确定模块，设置为在确认所述IPv6报文头的来源地址Source Address字段的保障能力不被支持时，将所述IPv6报文头中的其他未使用的字段的N位设置为1，以指示所述IPv6报文头的来源地址Source Address需要进行保障处理，其中，所述N的值不小于1。
在一个示例性实施例中，上述装置还包括：改造模块，设置为对所述IPv6报文中的地址进行改造，以将所述IPv6报文的可路由前缀设置在所述IPv6报文中的前目标数量位中。
在一个示例性实施例中，上述改造模块，还设置为将所述位索引转发表索引BIFT-ID字段嵌入所述IPv6报文中目的地址DA中；或将所述位索引转发表索引BIFT-ID字段嵌入所述IPv6报文中来源地址SA中；或将所述位索引转发表索引BIFT-ID填入所述IPv6报文头的流标签Flow Label字段中，不改动所述IPv6报文中目的地址DA与来源地址SA。
在一个示例性实施例中，上述改造模块，还设置为将所述位索引显式复制BIER报文头中的位索引转发表索引BIFT-ID的转发表项定位操作前移到IPv6报文中进行。
在一个示例性实施例中，上述改造模块，还设置为用所述IPv6报文地址中的特定位表示位索引显式复制BIER表项查找的功能FUNCTION字段。
根据本公开的又一个实施例，还提供了一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机程序，其中，所述计算机程序被设置为运行时执行上述任一项方法实施例中的步骤。
根据本公开的又一个实施例，还提供了一种电子装置，包括存储器和处理器，所述存储器中存储有计算机程序，所述处理器被设置为运行所述计算机程序以执行上述任一项方法实施例中的步骤。
通过本公开，可以对位索引显式复制BIER报文和IPv6报文进行如下处理：至少通过以下方式之一根据位索引显式复制BIER报文头中的字段对IPv6报文头中的字段进行处理：将位索引显式复制BIER报文头作为IPv6报文头的路由扩展头的类型，且按照预定义方式对所述IPv6报文头中的剩余段Segments Left字段进行处理；将位索引显式复制BIER报文头作为IPv6报文头的其他扩展头的类型，其中，所述其他扩展头的类型包括作为Hop-by-Hop扩展头中的新选项；在所述IPv6报文头的来源地址Source Address字段中填入所述位索引显式复制BIER报文头的位转发路由器路由前缀BFR-Prefix；将所述位索引显式复制BIER报文头中的位索引转发表索引BIFT-ID字段嵌入到所述IPv6报文头的目标字段中，进而实现了将BIER报文封装与IPv6报文封装结合起来，在完全不影响功能的情况下，优化报文的封装与处理流程，提高转发效率，采用上述技术方案，解决了相关技术中，未能有效实现在BIER报文与IPv6报文结合封装的过程中进行优化等问题。
附图说明
图1是本公开实施例的一种报文头的处理方法的计算机终端的硬件结构框图；
图2是根据本公开实施例的报文头的处理方法的流程图；
图3是根据本公开实施例的位索引显式复制BIER报文封装在IPv6报文中的示意图；
图4是根据本公开实施例的TLV的示意图；
图5是根据本公开实施例的应用在BIER域的报文传输机制的示意图；
图6是根据本公开实施例的报文头的处理装置的结构示意图。
具体实施方式
下文中将参考附图并结合实施例来详细说明本公开的实施例。
需要说明的是，本公开的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。
本申请实施例中所提供的方法实施例可以在计算机终端或者类似的运算装置中执行。以运行在计算机终端上为例，图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)模块，其设置为通过无线方式与互联网进行通讯。
相关技术中，组播技术在互联网上正得到越来越多的应用，比如多方会议，远程教育，远程医疗，网络直播等。随着IPv6的部署，这些组播数据报文，穿越IPv6网络已成为必须，对于一些不能直接支持位索引显式复制BIER以太封装报文处理的节点，将位索引显式复制BIER封装在IPv6头中已成为一个必须具备的功能。
本公开实施例以下提出一种新的报文封装方式，将位索引显式复制BIER封装与IPv6封装结合起来，并进行优化，结合控制面的能力通告，在完全不影响功能的情况下，优化报文的封装与处理流程，提高转发效率。
在本实施例中提供了一种运行于上述计算机终端的报文头的处理方法，图2是根据本公开实施例的报文头的处理方法的流程图，如图2所示，该流程包括如下步骤：
步骤S202，至少通过以下方式之一根据位索引显式复制BIER报文头中的字段对IPv6报文头中的字段进行处理：
将位索引显式复制BIER报文头作为IPv6报文头的路由扩展头的类型，且按照预定义方式对所述IPv6报文头中的剩余段Segments Left字段进行处理；
将位索引显式复制BIER报文头作为IPv6报文头的其他扩展头的类型，其中，所述其他扩展头的类型包括作为Hop-by-Hop扩展头中的选项；
在所述IPv6报文头的来源地址Source Address字段中填入所述位索引显式复制BIER报文头的位转发路由器路由前缀BFR-Prefix；
将所述位索引显式复制BIER报文头中的位索引转发表索引BIFT-ID字段嵌入到所述IPv6报文头的目标字段中。
通过本公开，可以对位索引显式复制BIER报文和IPv6报文进行如下处理：至少通过以下方式之一根据位索引显式复制BIER报文头中的字段对IPv6报文头中的字段进行处理：将位索引显式复制BIER报文头作为IPv6报文头的路由扩展头的类型，且按照预定义方式对所述IPv6报文头中的剩余段Segments Left字段进行处理；将位索引显式复制BIER报文头作为IPv6报文头的其他扩展头的类型，其中，所述其他扩展头的类型包括作为Hop-by-Hop扩展头中的新选项；在所述IPv6报文头的来源地址Source Address字段中填入所述位索引显式复制BIER报文头的位转发路由器路由前缀BFR-Prefix；将所述位索引显式复制BIER报文头中的位索引转发表索引BIFT-ID字段嵌入到所述IPv6报文头的目标字段中，进而实现了将BIER报文封装与IPv6报文封装结合起来，在完全不影响功能的情况下，优化报文的封装与处理流程，提高转发效率，采用上述技术方案，解决了相关技术中，未能有效实现在BIER报文与IPv6报文结合封装的过程中进行优化等问题。
其中，上述步骤的执行主体可以为基站、终端等，但不限于此。
应用上述步骤S202的技术方案，如图3所示，这种情况下，将Routing Type可直接设置为BIER。
在一个示例性实施例中，按照预定义方式对所述IPv6报文头中的剩余段Segments Left字段进行处理，至少包括以下之一：将所述剩余段Segments Left字段设置为目标值，使所有节点均忽略对所述剩余段Segments Left字段的处理；将位转发入口路由器BFIR的剩余段Segments Left字段值设置为255，当中间节点逐跳转发报文时，对所述字段值进行减1处理，当字段值为0时，指示报文转发过程出现环路；将位转发入口路由器BFIR将入口节点的剩余段Segments Left字段值设置为到达边缘设备的最大跳数，当中间节点逐跳转发报文时，对所述字段值进行减1处理，当字段值为0时，指示报文转发过程出现环路；将位转发入口路由器BFIR的剩余段Segments Left字段值设置为255，中间节点逐跳转发报文时，对所述字段值进行减1处理，在剩余段Segments Left字段值为255的IPv6报文到达位转发出口路由器BFER时，根据当前剩余段Segments Left字段的值计算出所述IPv6报文经过的跳数；将所述剩余段Segments Left字段设置为所述IPv6报文待经过的边界的最大边界值，当经过所述边界时对所述字段值进行减1处理，当所述字段值为0时，指示报文到达最大边界不能再继续转发到下一个区域。
可以理解的是，在将BIER报文头作为IPv6报文头的路由Routing扩展头的新类型时，需要对IPv6报文头中的剩余段Segments Left字段根据功能需要选择不同的预定义方式进行剩余段Segments Left字段的处理。
可选的，设置的剩余段Segments Left字段的目标值可以是0或者255或者其他任意值，进而使得所有节点均忽略对该字段的处理，由于该方式最简单，因此也可以作为所有节点的默认支持方式。
可选的，由入口节点BFIR将剩余段Segments Left字段值设置为255，或者将剩余段Segments Left字段值设置为可以预估的到达边缘设备的最大跳数，进而在中间节点逐跳转发时，将该字段值进行减1处理，当该字段值减小到0时，说明报文在转发过程中可能出现环路，需要进行告警提示或者异常日志记录，并不再转发该报文，从而避免报文被转发出不应该转发的域范围。
可选的，由入口节点BFIR将剩余段Segments Left字段值设置为255，中间节点逐跳转发时进行减1处理，到达出口节点BFER时，可以根据当前Segments Left的值计算出报文经过的跳数，该跳数可以记录并上报给控制器或者其他模块，用作统计目的。
可选的，由于报文可能会经过多个IGP域，或者一些BIER内部的边界，因此，可以预估出大概要经过多少个这样的边界，将边界值填在剩余段Segments Left字段值中，这时的剩余段Segments Left字段值，仅在BFER上，转发给其他IGP域，或者其他BIER内部边界时，对字段值进行减1处理，如果出现单域内转发时对字段值不进行处理，当所述字段值为0时，指示报文到达最大边界不能再继续转发到下一个区域。
在一个示例性实施例中，将位索引显式复制BIER报文头作为IPv6报文头的其他扩展头的类型，其中，所述其他扩展头的类型包括作为Hop-by-Hop扩展头中的选项。
简而言之，为了提高位索引显式复制BIER报文头在IPv6报文头中的应用效果，还可以在IPv6报文头的其他扩展头中也添加关于BIER类型的选项。
在一个示例性实施例中，将位索引显式复制BIER报文头作为IPv6报文头的路由扩展头的类型，且按照预定义方式对所述IPv6报文头中的剩余段Segments Left字段进行处理之后，所述方法还包括：通过控制面通告各节点自身对将位索引显式复制BIER报文头作为IPv6报文头的路由扩展头的类型的支持，即在本公开实施例中，在将BIER报文头作为IPv6路由Routing扩展头新类型后，通过控制面通告各节点自身对Routing扩展头新增BIER类型的支持进行通告。
在一个示例性实施例中，所述方法还包括：通过以下方式之一通告各节点自身对将位索引显式复制BIER报文头作为IPv6报文头的路由扩展头的类型的支持：TLV方式进行通告，携带在内部网关协议IGP中的位索引显式复制BIER信息进行通告，携带在边界网关协议BGP中的位索引显式复制BIER信息进行通告。
在一个示例性实施例中，所述方法还包括：在将各节点自身对将位索引显式复制BIER报文头作为IPv6报文头的路由扩展头的类型的支持设置在位转发路由器路由前缀BFR-Prefix或者位转发路由器标识BFR-ID的通知下，以sub-TLV或者sub-sub-TLV的方式进行通告。
例如，控制面进行通告方式包含各节点通告自身对Routing扩展头新增BIER类型的支持，可以通过TLV的方式，跟随在IGP，或者BGP中BIER信息进行通告，即放在BFR-Prefix或者BFR-id的通知下，以sub-TLV或者sub-sub-TLV的方式进行通告。当通告对Segments Left 处理方式的支持情况时，如果所有节点仅统一支持某一种Segments Left字段处理方式，则不需要进一步的通告，但如果有节点支持不同的Segments Left字段处理方式，则需要进行通告进行区分，通告方式也可以是TLV形式。
在所有节点均支持BIER的情况下，填入IPv6报文头中的来源地址Source Address(SA)和目的地址Destination Address(DA)字段的也可能是本地子网Link-local地址，或者经过某些不支持BIER节点时，会引入IPv6隧道，使不支持BIER处理的节点无需看到BIER报文并处理，这时对外层IPv6头的SA，DA操作，都可能会导致原有的SA，DA信息丢失。这样会使得BFIR的BFR-prefix信息丢失。因此为了保证该信息不丢失，需要采取一些特定的手段进行保障，保障方式包括：
在一个示例性实施例中，在所述IPv6报文头的来源地址Source Address字段中填入所述位索引显式复制BIER报文头的位转发路由器路由前缀BFR-Prefix之前，所述方法还包括：在所有节点中存在无法保障所述IPv6报文头的来源地址Source Address字段的传递能力的节点的情况下，通过控制面通告和收集所有节点的所述IPv6报文头的来源地址Source Address字段的传递能力的信息。
在一个示例性实施例中，在所述IPv6报文头的来源地址Source Address字段中填入所述位索引显式复制BIER报文头的位转发路由器路由前缀BFR-Prefix之后，所述方法还包括：在确认所述IPv6报文头的来源地址Source Address字段的保障能力不被支持时，将所述IPv6报文头中的其他未使用的字段的N位设置为1，以指示所述IPv6报文头的来源地址Source Address需要进行保障处理，其中，所述N的值不小于1。
例如，在域内并非所有节点都能支持IPv6报文头的来源地址Source Address字段的保障能力，这时可利用IPv6头中其他未使用的字段，如Traffic Class字段，或者BIER头中的保留字段等，利用这些字段中的某1位或者几位设置为1的方式，表明IIPv6报文头的来源地址Source Address字段需要得到保障处理。
在一个示例性实施例中，将所述位索引显式复制BIER报文头中的位索引转发表索引BIFT-ID字段嵌入到所述IPv6报文头的目标字段中之前，所述方法还包括：对所述IPv6报文中的地址进行改造，以将所述IPv6报文的可路由前缀设置在所述IPv6报文中的前目标数量位中。
需要说明的是，在IPv6报文中的前目标数量位中设置IPv6报文的可路由前缀，其中，目标位数量可以是64位，也可以是96位，本公开对此不做过多限定。
可选的，可将IPv6地址分为前缀+BIFT-ID两个部分，将域内的可达前缀放在其前96位中，也就是用于封装报文时，将IPv6可路由前缀放在前96位中的位置，这样可以支持前缀最长可达96位的情况；剩下32位专门用于存放BIFT-ID值。当然也可以将前108位用来存放可达前缀，后20位用来存放BIFT-ID值，这样可以支持前缀最长可达108位。
可选的，按照draft-ietf-spring-srv6-network-programming中定义的格式LOC:FUNCT:ARG，将IPv6地址分为3个部分，除了表示前缀的LOC，再定义新的FUNCT为BIER function，并将BIFT-ID填入ARG的位置，该方法适用于节点的BFR-Prefix长度较短的情况，例如，LOC部分为64位，FUNC为32位，ARG位32位。
在一个示例性实施例中，对所述IPv6报文中的地址进行改造之后，所述方法还包括：将所述位索引转发表索引BIFT-ID字段嵌入所述IPv6报文中目的地址DA中；或将所述位索引 转发表索引BIFT-ID字段嵌入所述IPv6报文中来源地址SA中；或将所述位索引转发表索引BIFT-ID填入所述IPv6报文头的流标签Flow Label字段中，不改动所述IPv6报文中目的地址DA与来源地址SA，即将BIFT-ID填入IPv6头中的Flow Label字段，对SA和DA不做改动，这种方法适用于如果BFR-Prefix都必须用128位的地址来表示的场景。
也就是说，在将IPv6地址分为前缀+BIFT-ID两个部分，当BIFT-ID字段嵌入IPv6报文中目的地址DA中时，会将下一跳的IPv6可路由前缀填入DA的前96位以及将下一跳的BIFT-ID填入DA后32位；当将BIFT-ID字段嵌入IPv6报文中来源地址SA中时，DA照常填写下一跳的IPv6可达路由前缀，SA的前96位前缀不做修改，仅将其后32位修改成下一跳的BIFT-ID。
此外，按照draft-ietf-spring-srv6-network-programming中定义的格式LOC:FUNCT:ARG，将IPv6地址分为3个部分，除了表示前缀的LOC，再定义新的FUNCT为BIER function，并将BIFT-ID填入ARG的位置，当BIFT-ID字段嵌入IPv6报文中目的地址DA中时，DA的LOC部分填写为下一跳的BFR-prefix，FUNC定义为新的表示BIER的function值，ARG则填入下一跳的BIFT-ID；当将BIFT-ID字段嵌入IPv6报文中来源地址SA中时，DA部分照常填写为下一跳的IPv6可达路由前缀BFR-prefix，SA的LOC部分保持不变，FUNCT部分如果不是表示BIER的function则修改成表示BIER的function值，SA的ARG部分则填写为下一跳的BIFT-ID。
需要说明的是，在进行BIFT-ID的优化使用时，在所有节点都支持统一的BFIT-ID优化手段的情况下，控制面不需要特别扩展。但如果并非所有节点都支持该功能时，为了避免错误处理，也需要引入能力通告的过程，方式仍然可以通过图4所示的TLV方式，定义新的Type类型，在跟随BIER的BFR-prefix等信息通告时携带，也就是通过IGP或者BGP的通告时携带这些信息。这样节点能互相了解到其他节点对该功能的支持情况。比如定义一个新类型的sub-TLV或者sub-sub-TLV表示BIFT-ID优化，更低一级的sub-sub-TLV或者sub-sub-sub-TLV不同Type表示不同的BIFT-ID优化方式来通告；两者同时通告来标明支持BIFT-ID优化，并能具体到支持的方式上；或者仅定义新类型的sub-TLV或者sub-sub-TLV表示BIFT-ID优化，携带的Value值里直接用1/2/3表示不同的具体BIFT-ID优化方式。
在一个示例性实施例中，所述方法还包括：将所述位索引显式复制BIER报文头中的位索引转发表索引BIFT-ID的转发表项定位操作前移到IPv6报文中进行。
在一个示例性实施例中，所述方法还包括：用所述IPv6报文地址中的特定位表示位索引显式复制BIER表项查找的功能FUNCTION字段。
为了更好的理解上述报文头的处理流程，以下结合可选实施例对上述技术方案进行说明，但不用于限定本公开实施例的技术方案。
由于位索引显式复制BIER报文与IPv6报文进行结合封装优化方式存在多种，可选的，当将位索引显式复制BIER报文头作为IPv6的Routing扩展头新类型时，包括如下可选实施例一至可选实施例四的4个可选实施例：
如图3所示，将位索引显式复制BIER报文作为IPv6的Routing扩展头的一个新类型，具体定义如图所示，Routing扩展头定义新类型值，比如5，表示位索引显式复制BIER类型，在Routing扩展头的“type-specific data”中，将位索引显式复制BIER报文头填入。对Routing扩展头中的“剩余段Segments Left”字段设置可能存在多种情况，详见下面可选实施例中的描述。
针对以下的可选实施例，为了便于理解，需要对控制面扩展统一进行定义，具体如下：
控制面通告流程：所有参与位索引显式复制BIER转发的节点需要扩展控制面，并进行通告，如果该域内所有节点均支持位索引显式复制BIER转发，那么所有节点都将参与控制面通告流程：
1.各节点通告自身对Routing扩展头新增位索引显式复制BIER类型的支持，可以通过TLV的方式，跟随在IGP，或者BGP中位索引显式复制BIER信息进行通告，即放在位转发路由器路由前缀BFR-Prefix或者BFR-id的通知下，以sub-TLV或者sub-sub-TLV的方式进行通告，如图4所示，使用类型20或者别的数值，表示是支持Routing扩展头封装位索引显式复制BIER类型。
2.通告对剩余段Segments Left处理方式的支持情况，如果所有节点仅统一支持某一种剩余段Segments Left字段处理方式，则不需要进一步的通告，但如果有节点支持不同的剩余段Segments Left字段处理方式，则需要进行通告进行区分，具体的通告方式可以有两种，一种是生成次一级的TLV跟随位索引显式复制BIER新Routing扩展头类型的通告TLV进行，格式可以是类似如图3的方式，用Type1/2/3/4等表示剩余段Segments Left的不同处理方式。另一种通告方式是直接使用Routing扩展头封装位索引显式复制BIER类型的sub-TLV或者sub-sub-TLV，其Value值为1/2/3/4等来表示对剩余段Segments Left不同处理方式的支持。
当将位索引显式复制BIER报文头作为IPv6的Routing扩展头新类型时，可选实施例一(即关于剩余段Segments Left处理方式一)：设置的剩余段Segments Left字段为0或者255或者其他任意值，所有节点均忽略对该字段的处理。该方式最简单，因此也可以作为所有节点的默认支持方式；
如图3所示，控制面按照上面所述的方法进行后，数据面封装与转发流程如下：
当位转发入口路由器BFIR收到组播报文，根据需要接收的BFER正常进行位索引显式复制BIER报文头封装后，封装外部IPv6头时，遵循以下的封装原理：
步骤1101，生成表示位索引显式复制BIER类型的Routing扩展头，将Routing扩展头中的Routing Type字段设置为代表位索引显式复制BIER类型的值，比如5。将剩余段Segments Left字段设置为0，或者255等其他值。
步骤1102，将Routing扩展头的Next Header设置为值59(表示后续No Next Header)，或者根据位索引显式复制BIER报文头中Proto，查找对应的值进行设置，比如位索引显式复制BIER报文头中的Proto值为4，表示其payload是IPv4报文，则Routing扩展头的Next Header值也设置为4(表示IPv4)；假如位索引显式复制BIER报文头中的Proto值为6，表示后续是IPv6报文，则Routing扩展头的Next Header值设置为41(表示IPv6报文)。
当BFR收到报文时，处理发现携带Routing扩展头，进一步解析Routing扩展头，发现其中类型为表示位索引显式复制BIER的类型，则按照如下的流程进行处理：
步骤1201，对Routing扩展头里的位索引显式复制BIER报文进行正常的处理流程，按照位索引显式复制BIER报文头中的Bit String查找本地位索引显式复制BIER路由表并进行转发，虽然剩余段Segments Left值为0或者其他值，对该值进行忽略处理。
在当前节点为分支节点，下一跳有多个时，复制生成多个位索引显式复制BIER报文，封装在IPv6Routing的位索引显式复制BIER类型扩展头中，封装方式类似位转发入口路由器 BFIR处理。
当然位转发入口路由器BFIR也可能本身就是分支节点，也会封装根据分支封装多个报文发送。
当BFER收到报文时，处理发现携带Routing扩展头，进一步解析Routing扩展头，根据类型发现是位索引显式复制BIER类型后，按照如下流程进行处理：
步骤1301，对Routing扩展头里的位索引显式复制BIER报文进行正常处理流程，发现本地节点是出口节点时，去掉整个外层IPv6封装，包括内含位索引显式复制BIER类型的Routing扩展头后，再转发给接收者。
进一步的，如果发现本节点是传送节点，即既有接收者，又有下一跳设备需要转发的，则根据BFR的流程继续转发该报文给下一跳节点。
当将位索引显式复制BIER报文头作为IPv6的Routing扩展头新类型时，可选实施例二(即关于剩余段Segments Left处理方式二)：
由入口节点BFIR将剩余段Segments Left字段值设置为255，或者将剩余段Segments Left字段值设置为可以预估的到达边缘设备的最大跳数，进而在中间节点逐跳转发时，将该字段值进行减1处理，当该字段值减小到0时，说明报文在转发过程中可能出现环路，需要进行告警提示或者异常日志记录，并不再转发该报文，从而避免报文被转发出不应该转发的域范围。
如图3所示，控制面按照上面所述的方法进行后，数据面封装与转发流程如下：
当位转发入口路由器BFIR收到组播报文，根据需要接收的BFER正常进行位索引显式复制BIER报文头封装后，封装外部IPv6头时，遵循以下的封装原理：
步骤2101，生成表示位索引显式复制BIER类型的Routing扩展头，将Routing扩展头中的Routing Type字段设置为代表位索引显式复制BIER类型的值，比如5。将剩余段Segments Left字段设置为255，或者预估将要经过的最大跳数值，比如预计到达最远接收者要10跳，则该值也可以设置为10。
步骤2102，设置内容同可选实施例一中的步骤1102。
当BFR收到报文时，处理发现携带Routing扩展头，进一步解析Routing扩展头，发现其中类型为表示位索引显式复制BIER的类型，则按照如下的流程进行处理：
步骤2201，对Routing扩展头里的位索引显式复制BIER报文进行正常的处理流程，对剩余段Segments Left进行减1处理，当发现剩余段Segments Left为0时，表明已经到达最大跳数，如果按照位索引显式复制BIER报文头中的Bit String查找本地位索引显式复制BIER路由表发现还有下一跳需要转发，则不能再转发，需要进行告警处理，或者上送控制器报告该情况；如果剩余段Segments Left不为0，则按照可选实施例一中的步骤1201继续转发处理。
当BFER收到报文时，处理发现携带Routing扩展头，进一步解析Routing扩展头，根据类型发现是位索引显式复制BIER类型后，按照如下流程进行处理：
步骤2301，对Routing扩展头里的位索引显式复制BIER报文进行正常处理流程，发现本地节点是出口节点时，去掉整个外层IPv6封装，包括内含位索引显式复制BIER类型的Routing扩展头后，再转发给接收者。
步骤2302，如果发现本节点是传送节点，即既有接收者，又有下一跳设备需要转发的， 则需要根据步骤2201中的原则，在剩余段Segments Left值为0时，不能再转发给下一跳节点，并需要进行告警或者上报控制器处理。在剩余段Segments Left值不为0时，对剩余段Segments Left进行减1操作，根据BFR的流程继续转发该报文给下一跳节点。
当将位索引显式复制BIER报文头作为IPv6的Routing扩展头新类型时，可选实施例三(即关于剩余段Segments Left处理方式三)：
由入口节点BFIR将剩余段Segments Left字段值设置为255，中间节点逐跳转发时进行减1处理，到达出口节点BFER时，可以根据当前剩余段Segments Left的值计算出报文经过的跳数，该跳数可以记录并上报给控制器或者其他模块，用作统计目的。
如图3所示，控制面按照上面所述的方法进行后，数据面封装与转发流程如下：
当位转发入口路由器BFIR收到组播报文，根据需要接收的BFER正常进行位索引显式复制BIER报文头封装后，封装外部IPv6头时，遵循以下的封装原理：
步骤3101，同可选实施例二的2101，其中将剩余段Segments Left字段设置为255。
步骤2102，设置内容同可选实施例一中的步骤1102。
当BFR收到报文时，处理发现携带Routing扩展头，进一步解析Routing扩展头，发现其中类型为表示位索引显式复制BIER的类型，则按照如下的流程进行处理：
步骤3201，同可选实施例二中的步骤2201处理。
当BFER收到报文时，处理发现携带Routing扩展头，进一步解析Routing扩展头，根据类型发现是位索引显式复制BIER类型后，按照如下流程进行处理：
步骤3301，同可选实施例二中的步骤2301处理。但同时将当前的剩余段Segments Left值，上报控制器或者其他管理模块，使控制器可以获取报文经过的跳数。便于后续的跳数设置。
当将位索引显式复制BIER报文头作为IPv6的Routing扩展头新类型时，可选实施例四(即关于剩余段Segments Left处理方式四)：
由于报文可能会经过多个IGP域，或者一些BIER内部的边界，因此，可以预估出大概要经过多少个这样的边界，将边界值填在剩余段Segments Left字段值中，这时的剩余段Segments Left字段值，仅在BFER上，转发给其他IGP域，或者其他BIER内部边界时，对字段值进行减1处理，如果出现单域内转发时对字段值不进行处理，当所述字段值为0时，指示报文到达最大边界不能再继续转发到下一个区域。
如图3所示，控制面按照上面所述的方法进行后，数据面封装与转发流程如下：
当位转发入口路由器BFIR收到组播报文，根据需要接收的BFER正常进行位索引显式复制BIER报文头封装后，封装外部IPv6头时，遵循以下的封装原理：
步骤4101，同可选实施例二的2101，其中将剩余段Segments Left字段设置为预估的最大边界值，如图5所示，假设这个位索引显式复制BIER域内最长跨越3个IGP的Area，则可以将剩余段Segments Left字段设置为3。
步骤4102，设置内容同可选实施例一中的步骤1102。
当BFR收到报文时，处理发现携带Routing扩展头，进一步解析Routing扩展头，发现其中类型为表示位索引显式复制BIER的类型，则按照如下的流程进行处理：
步骤4201，在BFR进行位索引显式复制BIER报文处理转发时，如果发现剩余段Segments Left值为0，表示已经到达最大边界，查找下一跳时，如果下一跳仍然在同一个Area中，比 如图5中的BFR2转发的下一跳仍然属于Area3，则正常转发，不会对剩余段Segments Left进行操作。但如果BFR2发现下一跳在另一个Area4，则BFR2不能转发该给属于Area4的下一跳，并且需要告警或者通报控制器出现异常情况。
因此如果是转发给同一个IGP Area中的其他节点，不对剩余段Segments Left做任何操作，只有转发给其他IGP Area的下一跳时，才需要对剩余段Segments Left做减1操作。如图5所示，仅在BFR1，BFR2这样的跨越IGP Area的BFR节点，并且转发下一跳是另一个Area，比如BFR1从Area1转发给Area2中的下一跳，或者BFR2从Area3转发给Area4的下一跳时，才对剩余段Segments Left进行减1操作，如果BFR1转发的下一跳仍然属于Area1，则不会对剩余段Segments Left做减1操作。
当BFER收到报文时，处理发现携带Routing扩展头，进一步解析Routing扩展头，根据类型发现是位索引显式复制BIER类型后，按照如下流程进行处理：
步骤4301，同可选实施例二中的步骤2301处理。
步骤4302，当本BFER同时是传送节点时，对剩余段Segments Left的操作与判断依照步骤4201中的进行。
采用上述关于IPv6报文头中的剩余段Segments Left字段的优化手段，可以将BIER与IPv6深度结合，利用IPv6的路由扩展头，携带用于组播路由的BIER报文头信息，并且结合Segments Left字段的处理方式，可以有效控制BIER报文在IPv6网络的传递范围，结合控制器上报等手段，让BIER报文在IPv6网络中的转发更为可控。
由于位索引显式复制BIER报文与IPv6报文进行结合封装优化方式存在多种，可选的，可将IPv6的Source Address字段填写为位转发入口路由器BFIR的位转发路由器路由前缀BFR-Prefix，具体步骤如下可选实施例五所示：
在位索引显式复制BIER报文头与IPv6头结合使用时，将位转发入口路由器BFIR的位转发路由器路由前缀BFR-Prefix，也就是用于位索引显式复制BIER算路的通告前缀地址，封装到IPv6头的Source Address字段，从而使报文能够携带入口节点位转发入口路由器BFIR的信息，以便故障检测，性能检测，重复流量判断时能够找到入口节点。
在位索引显式复制BIER转发建立，本身是依据IPv6平面建立时，位转发入口路由器BFIR的位转发路由器路由前缀BFR-Prefix本身就是位转发入口路由器BFIR节点的IPv6地址，这时可以直接将该值填入IPv6的Source Address字段中。
在所有节点均支持位索引显式复制BIER的情况下，填入IPv6头Source Address(SA)和Destination Address(DA)字段的也可能是Link-local地址，或者经过某些不支持位索引显式复制BIER节点时，会引入IPv6隧道，使不支持位索引显式复制BIER处理的节点无需看到位索引显式复制BIER报文并处理，这时对外层IPv6头的SA，DA操作，都可能会导致原有的SA，DA信息丢失。这样会使得位转发入口路由器BFIR的位转发路由器路由前缀BFR-Prefix信息丢失。因此为了保证该信息不丢失，需要采取一些特定的手段进行保障，详见如下步骤：
步骤一：控制面扩展：如果所有节点都能采用统一方式保障IPv6报文头的来源地址Source Address字段(即IPv6 SA)传递，则不需要特别的控制面扩展。如果存在无法保障IPv6 SA传递的节点，则在数据面进行操作前，控制面需要通告和收集该能力。通告方式仍然可以采用图4所示TLV的方式进行，以新的扩展类型方式表明支持IPv6 SA保障。
位转发入口路由器BFIR，BFER及所有BFR，在支持该功能时，均在通告中携带IPv6 SA保障能力。不支持该能力的不做通告。具体通告可通过IGP，BGP协议扩展进行。
步骤二：数据面处理，当位转发入口路由器BFIR收到组播报文，根据需要接收的BFER正常进行位索引显式复制BIER报文头封装后，封装外部IPv6头时，遵循以下的封装原理：
步骤5101，将IPv6头的SA封装为位转发入口路由器BFIR的位转发路由器路由前缀BFR-Prefix，或者其他任何可以用来唯一标识位转发入口路由器BFIR的IPv6地址。
步骤5102，在域内并非所有节点都能支持IPv6 SA保障能力时，可利用IPv6头中其他未使用的字段，如Traffic Class字段，或者位索引显式复制BIER报文头中的保留字段等，利用这些字段中的某1位或者几位设置为1的方式，表明IPv6的SA需要得到保障处理。
当BFR收到报文时，按照如下的流程进行处理：
步骤5201，当根据位索引显式复制BIER报文头，如果发现不需要进行IPv6 SA保障处理，则依照正常流程进行转发；如果发现需要进行IPv6 SA保障处理，在查找到下一跳进行转发处理时，将当前IPv6头中的SA保持不变，DA可以设置为下一跳的全局可路由IPv6地址，转发可能会存在多种情况，下一跳直连或者下一跳非直连。
在下一跳直连时，如果下一跳支持IPv6封装，则在SA保持不变，DA设置为下一跳全局可路由IPv6地址后可以直接发送；如果下一跳支持的是以太封装或者MPLS封装，则不能直接替换掉当前IPv6头，而是将IPv6头外层再封装以太或者MPLS，IPv6头中的SA保持不变，IPv6头中的DA设置为下一跳的全局可路由IPv6地址。
当下一跳非直连时，需要采用隧道技术进行封装，IPv6头中的SA保持不变，DA设置为下一跳全局可路由IPv6地址。如果采用的隧道仍然为IPv6隧道，且无需修改SA，则可直接发送该报文。如果采用的隧道为GRE(Generic Routing Encapsulation)等隧道，需要修改SA为隧道起点，这时则需要在当前IPv6头之外再进行隧道封装，保证SA不会被修改。
当然位转发入口路由器BFIR也可能遇到下一跳需要进行隧道封装的情况，会采用跟BFR相同的方式进行处理。
当BFER收到报文时，如果发现报文没有进行SA保障，则无需特别处理。如果发现报文进行了SA保障，则按照如下流程进行处理：
步骤5301，在有外层隧道的情况下，剥除外层隧道，将IPv6头中的SA取出，作为位转发入口路由器BFIR的位转发路由器路由前缀BFR-Prefix进行处理。可以用于故障或者路径检测，或者用于重复报文判断与丢弃。
需要注意的是，在任何一跳发现因故障，检测或者其他原因需要报告给位转发入口路由器BFIR时，将被保障的SA作为目的地址发送报文。
BIER报文头已经有BFIR-ID，这个值表示的是入口节点BFIR的BFR-id值，通常用来做性能测量，或者故障检测时使用。在网络中有重复多个BFIR转发同一条流量时，比如BFIR保护场景，出口节点BFER也可以依据BFIR-ID的值来进行判断，选择接收某一个BFIR-ID的流量，丢弃其他BFIR发来的流量。
但在BIER的实际应用中，可能存在入口节点BFIR没有分配BFR-ID的情况，也就是说，所有的出口节点BFER是必须分配BFR-ID的，但入口节点BFIR则并不一定，因此可能存在BFIR没有分配BFR-ID的情况，这样也就会让BIER报文头中的BFIR-ID值无法填入的情况。这时出口节点BFER无法根据该值进行重复流量判断，在有重复流量存在的情况下，会造成重 复流量的转发。
因此在BIER报文头与IPv6头结合使用时，将BFIR的BFR-prefix，也就是用于BIER算路的通告前缀地址，封装到IPv6头的Source Address字段，从而使报文能够携带入口节点BFIR的信息，以便故障检测，性能检测，重复流量判断时能够找到入口节点。
利用在所述IPv6报文头的来源地址Source Address字段中填入所述位索引显式复制BIER报文头的位转发路由器路由前缀BFR-Prefix的优化手段，可以将BIER的重复流量判断提前到IPv6报文中进行，并且入口设备BFIR无需分配BFR-ID，就能实现BIER重复流量判断，可以节省BFR-ID的分配数量，重复流量判断实现更为确切。
由于位索引显式复制BIER报文与IPv6报文进行结合封装优化方式存在多种，可选的，还可以对位索引转发表索引BIFT-ID优化，包括以下可选实施六至可选实施例八的3个实施例：
需要说明的是，在进行如下可选实施例的数据面流程之前，如果所有节点都能采用统一的位索引转发表索引BIFT-ID优化方式，则不需要特别的控制面扩展。如果存在不同处理方式，或者某些节点不能支持位索引转发表索引BIFT-ID优化，则在数据面进行操作前，控制面需要通告和收集该能力。通告方式仍然可以采用图4所示TLV的方式进行，以新的扩展类型方式表明支持位索引转发表索引BIFT-ID优化，位转发入口路由器BFIR，BFER及所有BFR，在支持该功能时，均在通告中携带位索引转发表索引BIFT-ID优化能力，不支持该能力的不做通告，具体通告可通过IGP，BGP协议扩展进行。
可选实施例六：
对位索引转发表索引BIFT-ID携带方式进行优化，在网络中的节点其位转发路由器路由前缀BFR-Prefix长度小于或等于96位时，将位索引转发表索引BIFT-ID的信息填入IPv6的DA。即将IPv6报文中DA的最后32位用来存放位索引转发表索引BIFT-ID值，前面用来存放正常的IPv6可达路由前缀位转发路由器路由前缀BFR-Prefix。这时的处理步骤为：数据面处理；
当位转发入口路由器BFIR收到组播报文，根据需要接收的BFER正常进行位索引显式复制BIER报文头封装后，封装外部IPv6头时，遵循以下的封装原理：
步骤6101，将IPv6头的DA前96位封装为下一跳的位转发路由器路由前缀BFR-Prefix，将下一跳通告的位索引转发表索引BIFT-ID填入DA的低32位中。
当BFR收到报文时，按照如下的流程进行处理：
步骤6201，根据收到报文进行常规的本地前缀判断时，取IPv6 DA的前96位进行查找判断，发现是本地前缀时，再将DA的后32位进行位索引显式复制BIER表项的定位操作，然后根据位索引显式复制BIER报文头进行查表。
步骤6202，在准备复制报文给下一跳时，如果下一跳支持位索引转发表索引BIFT-ID优化方法，则按照下一跳的优化方式进行IPv6报文封装，比如下一跳也支持DA前96位封装为位转发路由器路由前缀BFR-Prefix，后32位封装为位索引转发表索引BIFT-ID时，则根据此规则进行封装下一跳的位转发路由器路由前缀BFR-Prefix和位索引转发表索引BIFT-ID。
如果有的下一跳支持另外的位索引转发表索引BIFT-ID优化方式，比如支持的是前64位封装为位转发路由器路由前缀BFR-Prefix，中间32位封装为表示位索引显式复制BIER的function，后32位封装位索引转发表索引BIFT-ID时，则根据该原则将下一跳的位转发路由 器路由前缀BFR-Prefix和位索引转发表索引BIFT-ID封装起来。
如果有的下一跳不支持位索引转发表索引BIFT-ID优化方式，则不对IPv6头的内容进行位索引转发表索引BIFT-ID优化处理。
当BFER收到报文时，按照如下流程进行处理：
步骤6301，类似步骤6201，除了判断是本地前缀外，还会根据位索引显式复制BIER报文头判断出本地有接收者，则将报文剥掉IPv6头和位索引显式复制BIER报文头后发送给接收者。
步骤6302，如果本BFER节点也是传送节点，即还有下一跳需要继续发送，则可采用步骤6202方式进行。
需要注意的是，根据下一跳的不同情况进行封装方式变更，适用于包括位转发入口路由器BFIR，BFR，传送BFER所有节点，而不仅仅是BFR节点。
可选实施例七：
对位索引转发表索引BIFT-ID携带方式进行优化，在网络中的节点其位转发路由器路由前缀BFR-Prefix长度小于或等于96位时，将位索引转发表索引BIFT-ID的信息填入IPv6的SA。即将IPv6报文中SA的最后32位用来存放位索引转发表索引BIFT-ID值，前面用来存放正常的IPv6可达路由前缀位转发路由器路由前缀BFR-Prefix。这时的处理步骤为：
数据面处理：
当位转发入口路由器BFIR收到组播报文，根据需要接收的BFER正常进行位索引显式复制BIER报文头封装后，封装外部IPv6头时，遵循以下的封装原理：
步骤7101，将IPv6头的SA前96位封装为当前位转发路由器路由前缀BFR-Prefix，将下一跳通告的位索引转发表索引BIFT-ID填入SA的低32位中。
当BFR收到报文时，按照如下的流程进行处理：
步骤7201，根据收到报文进行常规的本地前缀判断时依照正常的DA查找流程进行处理，发现是本地前缀时，再将SA的后32位进行位索引显式复制BIER表项的定位操作，然后根据位索引显式复制BIER报文头进行查表。
步骤7202，在准备复制报文给下一跳时，如果下一跳支持位索引转发表索引BIFT-ID优化方法，则按照下一跳的优化方式进行IPv6报文封装，比如下一跳也支持SA前96位封装为位转发路由器路由前缀BFR-Prefix，后32位封装为位索引转发表索引BIFT-ID时，则根据此规则进行封装下一跳的位索引转发表索引BIFT-ID到SA的低32位中。
如果有的下一跳支持另外的位索引转发表索引BIFT-ID优化方式，比如支持的是前64位封装为位转发路由器路由前缀BFR-Prefix，中间32位封装为表示位索引显式复制BIER的function，后32位封装位索引转发表索引BIFT-ID时，则根据该原则将下一跳的位索引转发表索引BIFT-ID封装到SA的低32位中。
如果有的下一跳不支持位索引转发表索引BIFT-ID优化方式，则不对IPv6头的内容进行位索引转发表索引BIFT-ID优化处理。
当BFER收到报文时，按照如下流程进行处理：
步骤7301，类似步骤7201，除了判断是本地前缀外，还会根据位索引显式复制BIER报文头判断出本地有接收者，则将报文剥掉IPv6头和位索引显式复制BIER报文头后发送给接收者。
步骤7302，如果本BFER节点也是传送节点，即还有下一跳需要继续发送，则可采用步骤7202方式进行。
需要注意的是，根据下一跳的不同情况进行封装方式变更，适用于包括位转发入口路由器BFIR，BFR，传送BFER所有节点，而不仅仅是BFR节点。
可选实施例八：
对位索引转发表索引BIFT-ID携带方式进行优化，将位索引转发表索引BIFT-ID填入IPv6报文的Flow Label字段。这时的处理步骤为：
数据面处理：
当位转发入口路由器BFIR收到组播报文，根据需要接收的BFER正常进行位索引显式复制BIER报文头封装后，封装外部IPv6头时，遵循以下的封装原理：
步骤8101，将IPv6头的SA/DA根据正常处理方法进行封装，将Flow Label字段封装为下一跳的位索引转发表索引BIFT-ID。
当BFR收到报文时，按照如下的流程进行处理：
步骤8201，根据收到报文进行常规的本地前缀判断时依照正常的DA查找流程进行处理，发现是本地前缀时，将Flow Label字段作为位索引转发表索引BIFT-ID进行位索引显式复制BIER表项的定位操作，然后根据位索引显式复制BIER报文头进行查表。
步骤8202，在准备复制报文给下一跳时，如果下一跳支持位索引转发表索引BIFT-ID优化方法，则按照下一跳的优化方式进行IPv6报文封装，比如下一跳也支持将位索引转发表索引BIFT-ID封装到Flow Label字段中，则根据此规则进行封装下一跳的位索引转发表索引BIFT-ID到Flow Label字段中。
如果有的下一跳支持另外的位索引转发表索引BIFT-ID优化方式，比如支持的是对将位索引转发表索引BIFT-ID内嵌到DA中，前96位封装为位转发路由器路由前缀BFR-Prefix，中间32位封装为表示位索引显式复制BIER的function，后32位封装位索引转发表索引BIFT-ID时，则根据该原则将下一跳的位索引转发表索引BIFT-ID封装到DA的低32位中。
如果有的下一跳不支持位索引转发表索引BIFT-ID优化方式，则不对IPv6头的内容进行位索引转发表索引BIFT-ID优化处理。
当BFER收到报文时，按照如下流程进行处理：
步骤8301，类似步骤8201，除了判断是本地前缀外，还会根据位索引显式复制BIER报文头判断出本地有接收者，则将报文剥掉IPv6头和位索引显式复制BIER报文头后发送给接收者。
步骤8302，如果本BFER节点也是传送节点，即还有下一跳需要继续发送，则可采用步骤8202方式进行。
需要注意的是，根据下一跳的不同情况进行封装方式变更，适用于包括位转发入口路由器BFIR，BFR，传送BFER所有节点，而不仅仅是BFR节点。
通过以上BIFT-ID的优化使用，可以将BIER与IPv6结合使用的优势进一步激发出来，拓宽BIER应用场景，优化转发处理与效率。
综上，通过上述技术方案，本公开可选实施例提出一种新的报文封装方式，将位索引显式复制BIER封装与IPv6封装结合起来，利用外层IPv6头中的字段，在不影响功能实现的前提下，对位索引显式复制BIER报文头中的字段进行优化处理，包括三个大类，将位索引显式 复制BIER报文头封装为IPv6的Routing扩展头新类型，所述IPv6报文头的来源地址Source Address字段的优化，以及位索引转发表索引BIFT-ID优化，引入能力通告进行协商，起到优化报文封装及提高处理速度，拓宽位索引显式复制BIER使用场景的目的，此外，充分利用二者的结合，可以实现数据报文携带封装的优化，对处理流程进行加速，对组播技术的发展有优秀的促进作用。
通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到根据上述实施例的方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本公开的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，或者网络设备等)执行本公开各个实施例所述的方法。
在本实施例中还提供了一种报文头的处理装置，该装置设置为实现上述实施例及可选实施方式，已经进行过说明的不再赘述。如以下所使用的，术语“模块”可以实现预定功能的软件和/或硬件的组合。尽管以下实施例所描述的装置较佳地以软件来实现，但是硬件，或者软件和硬件的组合的实现也是可能并被构想的。
图6是根据本公开实施例的报文头的处理装置的结构框图，如图6所示，该装置包括：
处理模块70，设置为至少通过以下方式之一根据位索引显式复制BIER报文头中的字段对IPv6报文头中的字段进行处理：将位索引显式复制BIER报文头作为IPv6报文头的路由扩展头的类型，且按照预定义方式对所述IPv6报文头中的剩余段Segments Left字段进行处理；将位索引显式复制BIER报文头作为IPv6报文头的其他扩展头的类型，其中，所述其他扩展头的类型包括作为Hop-by-Hop扩展头中的选项；在所述IPv6报文头的来源地址Source Address字段中填入所述位索引显式复制BIER报文头的位转发路由器路由前缀BFR-Prefix；将所述位索引显式复制BIER报文头中的位索引转发表索引BIFT-ID字段嵌入到所述IPv6报文头的目标字段中。
通过本公开，可以对位索引显式复制BIER报文和IPv6报文进行如下处理：至少通过以下方式之一根据位索引显式复制BIER报文头中的字段对IPv6报文头中的字段进行处理：将位索引显式复制BIER报文头作为IPv6报文头的路由扩展头的类型，且按照预定义方式对所述IPv6报文头中的剩余段Segments Left字段进行处理；将位索引显式复制BIER报文头作为IPv6报文头的其他扩展头的类型，其中，所述其他扩展头的类型包括作为Hop-by-Hop扩展头中的新选项；在所述IPv6报文头的来源地址Source Address字段中填入所述位索引显式复制BIER报文头的位转发路由器路由前缀BFR-Prefix；将所述位索引显式复制BIER报文头中的位索引转发表索引BIFT-ID字段嵌入到所述IPv6报文头的目标字段中，进而实现了将BIER报文封装与IPv6报文封装结合起来，在完全不影响功能的情况下，优化报文的封装与处理流程，提高转发效率，采用上述技术方案，解决了相关技术中，未能有效实现在BIER报文与IPv6报文结合封装的过程中进行优化等问题。
应用上述技术方案，如图3所示，这种情况下，将Routing Type可直接设置为BIER。
在一个示例性实施例中，处理模块70，按照预定义方式对所述IPv6报文头中的剩余段Segments Left字段进行处理，至少包括以下之一：将所述剩余段Segments Left字段设置为目标值，使所有节点均忽略对所述剩余段Segments Left字段的处理；将位转发入口路由 器BFIR的剩余段Segments Left字段值设置为255，当中间节点逐跳转发报文时，对所述字段值进行减1处理，当字段值为0时，指示报文转发过程出现环路；将位转发入口路由器BFIR将入口节点的剩余段Segments Left字段值设置为到达边缘设备的最大跳数，当中间节点逐跳转发报文时，对所述字段值进行减1处理，当字段值为0时，指示报文转发过程出现环路；将位转发入口路由器BFIR的剩余段Segments Left字段值设置为255，中间节点逐跳转发报文时，对所述字段值进行减1处理，在剩余段Segments Left字段值为255的IPv6报文到达位转发出口路由器BFER时，根据当前剩余段Segments Left字段的值计算出所述IPv6报文经过的跳数；将所述剩余段Segments Left字段设置为所述IPv6报文待经过的边界的最大边界值，当经过所述边界时对所述字段值进行减1处理，当所述字段值为0时，指示报文到达最大边界不能再继续转发到下一个区域。
可以理解的是，在将BIER报文头作为IPv6报文头的路由Routing扩展头的新类型时，需要对IPv6报文头中的剩余段Segments Left字段根据功能需要选择不同的预定义方式进行剩余段Segments Left字段的处理。
可选的，设置的剩余段Segments Left字段的目标值可以是0或者255或者其他任意值，进而使得所有节点均忽略对该字段的处理，由于该方式最简单，因此也可以作为所有节点的默认支持方式；
可选的，由入口节点BFIR将剩余段Segments Left字段值设置为255，或者将剩余段Segments Left字段值设置为可以预估的到达边缘设备的最大跳数，进而在中间节点逐跳转发时，将该字段值进行减1处理，当该字段值减小到0时，说明报文在转发过程中可能出现环路，需要进行告警提示或者异常日志记录，并不再转发该报文，从而避免报文被转发出不应该转发的域范围。
可选的，由入口节点BFIR将剩余段Segments Left字段值设置为255，中间节点逐跳转发时进行减1处理，到达出口节点BFER时，可以根据当前Segments Left的值计算出报文经过的跳数，该跳数可以记录并上报给控制器或者其他模块，用作统计目的。
可选的，由于报文可能会经过多个IGP域，或者一些BIER内部的边界，因此，可以预估出大概要经过多少个这样的边界，将边界值填在剩余段Segments Left字段值中，这时的剩余段Segments Left字段值，仅在BFER上，转发给其他IGP域，或者其他BIER内部边界时，对字段值进行减1处理，如果出现单域内转发时对字段值不进行处理，当所述字段值为0时，指示报文到达最大边界不能再继续转发到下一个区域。
在一个示例性实施例中，处理模块，还设置为将位索引显式复制BIER报文头作为IPv6报文头的其他扩展头的类型，其中，所述其他扩展头的类型包括作为Hop-by-Hop扩展头中的选项。
简而言之，为了提高位索引显式复制BIER报文头在IPv6报文头中的应用效果，还可以在IPv6报文头的其他扩展头中也添加关于BIER类型的选项。
在一个示例性实施例中，上述装置还包括：通告模块，设置为通过控制面通告各节点自身对将位索引显式复制BIER报文头作为IPv6报文头的路由扩展头的类型的支持，即在本公开实施例中，在将BIER报文头作为IPv6路由Routing扩展头新类型后，通过控制面通告各节点自身对Routing扩展头新增BIER类型的支持进行通告。
在一个示例性实施例中，上述通告模块，还设置为通过以下方式之一通告各节点自身对 将位索引显式复制BIER报文头作为IPv6报文头的路由扩展头的类型的支持：TLV方式进行通告，携带在内部网关协议IGP中的位索引显式复制BIER信息进行通告，携带在边界网关协议BGP中的位索引显式复制BIER信息进行通告。
在一个示例性实施例中，上述通告模块，还设置为在将各节点自身对将位索引显式复制BIER报文头作为IPv6报文头的路由扩展头的类型的支持设置在位转发路由器路由前缀BFR-Prefix或者位转发路由器标识BFR-ID的通知下，以sub-TLV或者sub-sub-TLV的方式进行通告。
例如，控制面进行通告方式包含各节点通告自身对Routing扩展头新增BIER类型的支持，可以通过TLV的方式，跟随在IGP，或者BGP中BIER信息进行通告，即放在BFR-Prefix或者BFR-id的通知下，以sub-TLV或者sub-sub-TLV的方式进行通告。当通告对Segments Left处理方式的支持情况时，如果所有节点仅统一支持某一种Segments Left字段处理方式，则不需要进一步的通告，但如果有节点支持不同的Segments Left字段处理方式，则需要进行通告进行区分，通告方式也可以是TLV形式。
在所有节点均支持BIER的情况下，填入IPv6报文头中的来源地址Source Address(SA)和目的地址Destination Address(DA)字段的也可能是本地子网Link-local地址，或者经过某些不支持BIER节点时，会引入IPv6隧道，使不支持BIER处理的节点无需看到BIER报文并处理，这时对外层IPv6头的SA，DA操作，都可能会导致原有的SA，DA信息丢失。这样会使得BFIR的BFR-prefix信息丢失。因此为了保证该信息不丢失，需要采取一些特定的手段进行保障，保障方式包括：
在一个示例性实施例中，上述装置还包括：保障模块，设置为在所有节点中存在无法保障所述IPv6报文头的来源地址Source Address字段的传递能力的节点的情况下，通过控制面通告和收集所有节点的所述IPv6报文头的来源地址Source Address字段的传递能力的信息。
在一个示例性实施例中，上述装置还包括：确定模块，设置为在确认所述IPv6报文头的来源地址Source Address字段的保障能力不被支持时，将所述IPv6报文头中的其他未使用的字段的N位设置为1，以指示所述IPv6报文头的来源地址Source Address需要进行保障处理，其中，所述N的值不小于1。
例如，在域内并非所有节点都能支持IPv6报文头的来源地址Source Address字段的保障能力，这时可利用IPv6头中其他未使用的字段，如Traffic Class字段，或者BIER头中的保留字段等，利用这些字段中的某1位或者几位设置为1的方式，表明IPv6报文头的来源地址Source Address字段需要得到保障处理。
在一个示例性实施例中，上述装置还包括：改造模块，设置为对所述IPv6报文中的地址进行改造，以将所述IPv6报文的可路由前缀设置在所述IPv6报文中的前目标数量位中。
需要说明的是，在IPv6报文中的前目标数量位中设置IPv6报文的可路由前缀，其中，目标位数量可以是64位，也可以是96位，本公开对此不做过多限定。
可选的，可将IPv6地址分为前缀+BIFT-ID两个部分，将域内的可达前缀放在其前96位中，也就是用于封装报文时，将IPv6可路由前缀放在前96位中的位置，这样可以支持前缀最长可达96位的情况；剩下32位专门用于存放BIFT-ID值。当然也可以将前108位用来存放可达前缀，后20位用来存放BIFT-ID值，这样可以支持前缀最长可达108位。
可选的，按照draft-ietf-spring-srv6-network-programming中定义的格式LOC:FUNCT:ARG，将IPv6地址分为3个部分，除了表示前缀的LOC，再定义新的FUNCT为BIER function，并将BIFT-ID填入ARG的位置，该方法适用于节点的BFR-Prefix长度较短的情况，例如，LOC部分为64位，FUNC为32位，ARG位32位。
在一个示例性实施例中，上述改造模块，还设置为将所述位索引转发表索引BIFT-ID字段嵌入所述IPv6报文中目的地址DA中；或将所述位索引转发表索引BIFT-ID字段嵌入所述IPv6报文中来源地址SA中；或将所述位索引转发表索引BIFT-ID填入所述IPv6报文头的流标签Flow Label字段中，不改动所述IPv6报文中目的地址DA与来源地址SA，即将BIFT-ID填入IPv6头中的Flow Label字段，对SA和DA不做改动，这种方法适用于如果BFR-Prefix都必须用128位的地址来表示的场景。
也就是说，在将IPv6地址分为前缀+BIFT-ID两个部分，当BIFT-ID字段嵌入IPv6报文中目的地址DA中时，会将下一跳的IPv6可路由前缀填入DA的前96位以及将下一跳的BIFT-ID填入DA后32位；当将BIFT-ID字段嵌入IPv6报文中来源地址SA中时，DA照常填写下一跳的IPv6可达路由前缀，SA的前96位前缀不做修改，仅将其后32位修改成下一跳的BIFT-ID。
此外，按照draft-ietf-spring-srv6-network-programming中定义的格式LOC:FUNCT:ARG，将IPv6地址分为3个部分，除了表示前缀的LOC，再定义新的FUNCT为BIER function，并将BIFT-ID填入ARG的位置，当BIFT-ID字段嵌入IPv6报文中目的地址DA中时，DA的LOC部分填写为下一跳的BFR-prefix，FUNC定义为新的表示BIER的function值，ARG则填入下一跳的BIFT-ID；当将BIFT-ID字段嵌入IPv6报文中来源地址SA中时，DA部分照常填写为下一跳的IPv6可达路由前缀BFR-prefix，SA的LOC部分保持不变，FUNCT部分如果不是表示BIER的function则修改成表示BIER的function值，SA的ARG部分则填写为下一跳的BIFT-ID。
需要说明的是，在进行BIFT-ID的优化使用时，在所有节点都支持统一的BFIT-ID优化手段的情况下，控制面不需要特别扩展。但如果并非所有节点都支持该功能时，为了避免错误处理，也需要引入能力通告的过程，方式仍然可以通过图4所示的TLV方式，定义新的Type类型，在跟随BIER的BFR-prefix等信息通告时携带，也就是通过IGP或者BGP的通告时携带这些信息。这样节点能互相了解到其他节点对该功能的支持情况。比如定义一个新类型的sub-TLV或者sub-sub-TLV表示BIFT-ID优化，更低一级的sub-sub-TLV或者sub-sub-sub-TLV不同Type表示不同的BIFT-ID优化方式来通告；两者同时通告来标明支持BIFT-ID优化，并能具体到支持的方式上；或者仅定义新类型的sub-TLV或者sub-sub-TLV表示BIFT-ID优化，携带的Value值里直接用1/2/3表示不同的具体BIFT-ID优化方式。
在一个示例性实施例中，上述改造模块，还设置为将所述位索引显式复制BIER报文头中的位索引转发表索引BIFT-ID的转发表项定位操作前移到IPv6报文中进行。
在一个示例性实施例中，上述改造模块，还设置为用所述IPv6报文地址中的特定位表示位索引显式复制BIER表项查找的功能FUNCTION字段。
需要说明的是，上述各个模块是可以通过软件或硬件来实现的，对于后者，可以通过以下方式实现，但不限于此：上述模块均位于同一处理器中；或者，上述各个模块以任意组合的形式分别位于不同的处理器中。
本公开的实施例还提供了一种计算机可读存储介质，该计算机可读存储介质中存储有计 算机程序，其中，该计算机程序被设置为运行时执行上述任一项方法实施例中的步骤。
在一个示例性实施例中，上述计算机可读存储介质可以包括但不限于：U盘、只读存储器(Read-Only Memory，简称为ROM)、随机存取存储器(Random Access Memory，简称为RAM)、移动硬盘、磁碟或者光盘等各种可以存储计算机程序的介质。
本公开的实施例还提供了一种电子装置，包括存储器和处理器，该存储器中存储有计算机程序，该处理器被设置为运行计算机程序以执行上述任一项方法实施例中的步骤。
在一个示例性实施例中，上述电子装置还可以包括传输设备以及输入输出设备，其中，该传输设备和上述处理器连接，该输入输出设备和上述处理器连接。
本实施例中的具体示例可以参考上述实施例及示例性实施方式中所描述的示例，本实施例在此不再赘述。
显然，本领域的技术人员应该明白，上述的本公开的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，并且在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本公开不限制于任何特定的硬件和软件结合。
以上所述仅为本公开的可选实施例而已，并不用于限制本公开，对于本领域的技术人员来说，本公开可以有各种更改和变化。凡在本公开的原则之内，所作的任何修改、等同替换、改进等，均应包含在本公开的保护范围之内。

Claims (14)

  1. 一种报文头的处理方法，包括：
    至少通过以下方式之一根据位索引显式复制BIER报文头中的字段对IPv6报文头中的字段进行处理：
    将位索引显式复制BIER报文头作为IPv6报文头的路由扩展头的类型，且按照预定义方式对所述IPv6报文头中的剩余段Segments Left字段进行处理；
    将位索引显式复制BIER报文头作为IPv6报文头的其他扩展头的类型，其中，所述其他扩展头的类型包括作为Hop-by-Hop扩展头中的选项；
    在所述IPv6报文头的来源地址Source Address字段中填入所述位索引显式复制BIER报文头的位转发路由器路由前缀BFR-Prefix；
    将所述位索引显式复制BIER报文头中的位索引转发表索引BIFT-ID字段嵌入到所述IPv6报文头的目标字段中。
  2. 根据权利要求1所述的报文头的处理方法，其中，按照预定义方式对所述IPv6报文头中的剩余段Segments Left字段进行处理，至少包括以下之一：
    将所述剩余段Segments Left字段设置为目标值，使所有节点均忽略对所述剩余段Segments Left字段的处理；
    将位转发入口路由器BFIR的剩余段Segments Left字段值设置为255，当中间节点逐跳转发报文时，对所述字段值进行减1处理，当字段值为0时，指示报文转发过程出现环路；
    将位转发入口路由器BFIR将入口节点的剩余段Segments Left字段值设置为到达边缘设备的最大跳数，当中间节点逐跳转发报文时，对所述字段值进行减1处理，当字段值为0时，指示报文转发过程出现环路；
    将位转发入口路由器BFIR的剩余段Segments Left字段值设置为255，中间节点逐跳转发报文时，对所述字段值进行减1处理，在剩余段Segments Left字段值为255的IPv6报文到达位转发出口路由器BFER时，根据当前剩余段Segments Left字段的值计算出所述IPv6报文经过的跳数；
    将所述剩余段Segments Left字段值设置为所述IPv6报文待经过的边界的最大边界值，当经过所述边界时对所述字段值进行减1处理，当字段值为0时，指示报文到达最大边界不能再继续转发到下一个区域。
  3. 根据权利要求1所述的报文头的处理方法，其中，将位索引显式复制BIER报文头作为IPv6报文头的路由扩展头的类型，且按照预定义方式对所述IPv6报文头中的剩余段Segments Left字段进行处理之后，所述方法还包括：
    通过控制面通告各节点自身对将位索引显式复制BIER报文头作为IPv6报文头的路由扩展头的类型的支持。
  4. 根据权利要求3所述的报文头的处理方法，其中，所述方法还包括：
    通过以下方式之一通告各节点自身对将位索引显式复制BIER报文头作为IPv6报文头的路由扩展头的类型的支持：TLV方式进行通告，携带在内部网关协议IGP中的位索引显式复制BIER信息进行通告，携带在边界网关协议BGP中的位索引显式复制BIER信息进行通告。
  5. 根据权利要求3所述的报文头的处理方法，其中，所述方法还包括：
    在将各节点自身对将位索引显式复制BIER报文头作为IPv6报文头的路由扩展头的类型的支持设置在位转发路由器路由前缀BFR-Prefix或者位转发路由器标识BFR-ID的通知下，以sub-TLV或者sub-sub-TLV的方式进行通告。
  6. 根据权利要求1所述的报文头的处理方法，其中，在所述IPv6报文头的来源地址Source Address字段中填入所述位索引显式复制BIER报文头的位转发路由器路由前缀BFR-Prefix之前，所述方法还包括：
    在所有节点中存在无法保障所述IPv6报文头的来源地址Source Address字段的传递能力的节点的情况下，通过控制面通告和收集所有节点的所述IPv6报文头的来源地址Source Address字段的传递能力的信息。
  7. 根据权利要求1所述的报文头的处理方法，其中，在所述IPv6报文头的来源地址Source Address字段中填入所述位索引显式复制BIER报文头的位转发路由器路由前缀BFR-Prefix之后，所述方法还包括：
    在确认所述IPv6报文头的来源地址Source Address字段的保障能力不被支持时，将所述IPv6报文头中的其他未使用的字段的N位设置为1，以指示所述IPv6报文头的来源地址Source Address需要进行保障处理，其中，所述N的值不小于1。
  8. 根据权利要求1所述的报文头的处理方法，其中，将所述位索引显式复制BIER报文头中的位索引转发表索引BIFT-ID字段嵌入到所述IPv6报文头的目标字段中之前，所述方法还包括：
    对所述IPv6报文中的地址进行改造，以将所述IPv6报文的可路由前缀设置在所述IPv6报文中的前目标数量位中。
  9. 根据权利要求8所述的报文头的处理方法，其中，对所述IPv6报文中的地址进行改造之后，所述方法还包括：
    将所述位索引转发表索引BIFT-ID字段嵌入所述IPv6报文中目的地址DA中；或
    将所述位索引转发表索引BIFT-ID字段嵌入所述IPv6报文中来源地址SA中；或
    将所述位索引转发表索引BIFT-ID填入所述IPv6报文头的流标签Flow Label字段中，不改动所述IPv6报文中目的地址DA与来源地址SA。
  10. 根据权利要求8所述的报文头的处理方法，其中，所述方法还包括：将所述位索引显式复制BIER报文头中的位索引转发表索引BIFT-ID的转发表项定位操作前移到IPv6报文中进行。
  11. 根据权利要求8所述的报文头的处理方法，其中，所述方法还包括：用所述IPv6报文地址中的特定位表示位索引显式复制BIER表项查找的功能FUNCTION字段。
  12. 一种报文头的处理装置，包括：
    处理模块，设置为至少通过以下方式之一根据位索引显式复制BIER报文头中的字段对IPv6报文头中的字段进行处理：将位索引显式复制BIER报文头作为IPv6报文头的路由扩展头的类型，且按照预定义方式对所述IPv6报文头中的剩余段Segments Left字段进行处理；在所述IPv6报文头的来源地址Source Address字段中填入所述位索引显式复制BIER报文头的位转发路由器路由前缀BFR-Prefix；将所述位索引显式复制BIER报文头中的位索引转发表索引BIFT-ID字段嵌入到所述IPv6报文头的目标字段中。
  13. 一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机程序，其中， 所述计算机程序被处理器执行时实现所述权利要求1至11任一项中所述的方法的步骤。
  14. 一种电子装置，包括存储器、处理器以及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现所述权利要求1至11任一项中所述的方法的步骤。
PCT/CN2021/098409 2020-08-31 2021-06-04 报文头的处理方法及装置、存储介质、电子装置 WO2022041916A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP21859760.7A EP4207685A4 (en) 2020-08-31 2021-06-04 MESSAGE HEADER PROCESSING METHOD AND APPARATUS, STORAGE MEDIUM AND ELECTRONIC DEVICE
US18/022,378 US20230370298A1 (en) 2020-08-31 2021-06-04 Message header processing method and apparatus, storage medium and electronic device

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202010899306.0A CN112491718A (zh) 2020-08-31 2020-08-31 报文头的处理方法及装置、存储介质、电子装置
CN202010899306.0 2020-08-31

Publications (1)

Publication Number Publication Date
WO2022041916A1 true WO2022041916A1 (zh) 2022-03-03

Family

ID=74920926

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2021/098409 WO2022041916A1 (zh) 2020-08-31 2021-06-04 报文头的处理方法及装置、存储介质、电子装置

Country Status (4)

Country Link
US (1) US20230370298A1 (zh)
EP (1) EP4207685A4 (zh)
CN (1) CN112491718A (zh)
WO (1) WO2022041916A1 (zh)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115314150A (zh) * 2021-04-21 2022-11-08 中兴通讯股份有限公司 一种报文处理方法、装置、存储介质及电子装置
CN115733790A (zh) * 2021-09-02 2023-03-03 华为技术有限公司 报文转发方法、装置、设备及存储介质
CN116074235A (zh) * 2021-11-04 2023-05-05 华为技术有限公司 报文处理方法、装置及系统
CN116232989A (zh) * 2021-12-02 2023-06-06 中兴通讯股份有限公司 Bier报文转发方法、装置及存储介质
CN115460133B (zh) * 2022-08-12 2023-11-03 烽火通信科技股份有限公司 一种bier组播的硬件学习及转发的方法、装置及设备
CN117938813A (zh) * 2022-10-17 2024-04-26 中兴通讯股份有限公司 一种转发表索引的通告方法、节点及存储介质

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180091473A1 (en) * 2016-09-23 2018-03-29 Cisco Technology, Inc. Unicast media replication fabric using bit indexed explicit replication
CN110417657A (zh) * 2018-04-27 2019-11-05 华为技术有限公司 一种处理组播数据报文的方法及装置
CN110784411A (zh) * 2019-09-30 2020-02-11 华为技术有限公司 建立bier转发表项的方法、装置和系统
CN111147383A (zh) * 2018-11-02 2020-05-12 华为技术有限公司 报文转发的方法、发送报文的装置和接收报文的装置

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10469379B2 (en) * 2017-02-17 2019-11-05 Cisco Technology, Inc. System and method to facilitate content delivery to multiple recipients in a network environment
US10616063B1 (en) * 2018-10-12 2020-04-07 Nokia Solutions And Networks Oy Stateless multicast in IP networks

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180091473A1 (en) * 2016-09-23 2018-03-29 Cisco Technology, Inc. Unicast media replication fabric using bit indexed explicit replication
CN110417657A (zh) * 2018-04-27 2019-11-05 华为技术有限公司 一种处理组播数据报文的方法及装置
CN111147383A (zh) * 2018-11-02 2020-05-12 华为技术有限公司 报文转发的方法、发送报文的装置和接收报文的装置
CN110784411A (zh) * 2019-09-30 2020-02-11 华为技术有限公司 建立bier转发表项的方法、装置和系统

Non-Patent Citations (1)

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

Also Published As

Publication number Publication date
EP4207685A4 (en) 2024-01-17
US20230370298A1 (en) 2023-11-16
EP4207685A1 (en) 2023-07-05
CN112491718A (zh) 2021-03-12

Similar Documents

Publication Publication Date Title
WO2022041916A1 (zh) 报文头的处理方法及装置、存储介质、电子装置
US11902049B2 (en) BIER packet sending method and apparatus
US11979322B2 (en) Method and apparatus for providing service for traffic flow
JP7208386B2 (ja) パケット転送方法、パケット送信装置、およびパケット受信装置
US11438260B2 (en) Method and apparatus for forwarding MPLS data packet
CN109756425B (zh) 组播转发方法、装置以及bfr
CN110034971B (zh) 检测业务链的方法及装置
JP7322188B2 (ja) Ｂｉｅｒパケット送信方法及び装置
JP2022550160A (ja) Ｂｉｅｒ転送項目構築方法、装置、およびシステム
WO2018072704A1 (zh) 报文传输方法、装置、节点和计算机存储介质
US20190182145A1 (en) Information Management Method, Apparatus, and System
WO2016131225A1 (zh) 报文转发处理方法、装置、控制器及路由转发设备
US11362954B2 (en) Tunneling inter-domain stateless internet protocol multicast packets
EP3767898A1 (en) Packet forwarding method and apparatus
WO2022021818A1 (zh) 数据报文的处理方法及装置、存储介质、电子装置
EP4030698A1 (en) Packet processing method, device, system and apparatus as well as storage medium
WO2018177273A1 (zh) 一种基于bier信息的处理及装置
WO2023173989A1 (zh) 转发表的生成方法及装置、存储介质、电子装置
WO2020021558A1 (en) Methods, apparatus and machine-readable media relating to path computation in a communication network
WO2022042610A1 (zh) 信息处理方法、网络控制器、节点及计算机可读存储介质
US20230318966A1 (en) Packet Transmission Method, Correspondence Obtaining Method, Apparatus, and System
WO2022237563A1 (zh) 数据转发方法、装置、存储介质和电子装置
WO2023016550A1 (zh) 一种路由发送方法及设备
WO2022188488A1 (zh) 路径建立方法及其装置、节点、计算机可读存储介质
CN118055138A (zh) 标签分发协议邻居保活方法、装置和设备

Legal Events

Date Code Title Description
NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2021859760

Country of ref document: EP

Effective date: 20230331