WO2022222582A1 - 一种报文处理方法、装置、存储介质及电子装置 - Google Patents

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

Info

Publication number
WO2022222582A1
WO2022222582A1 PCT/CN2022/075883 CN2022075883W WO2022222582A1 WO 2022222582 A1 WO2022222582 A1 WO 2022222582A1 CN 2022075883 W CN2022075883 W CN 2022075883W WO 2022222582 A1 WO2022222582 A1 WO 2022222582A1
Authority
WO
WIPO (PCT)
Prior art keywords
payload
target
packet
node
type
Prior art date
Application number
PCT/CN2022/075883
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 US18/282,592 priority Critical patent/US20240163208A1/en
Publication of WO2022222582A1 publication Critical patent/WO2022222582A1/zh

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/0078—Avoidance of errors by organising the transmitted data in a format specifically designed to deal with errors, e.g. location
    • H04L1/0083—Formatting with frames or packets; Protocol or part of protocol for error control
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/56—Routing software
    • H04L45/566—Routing instructions carried by the data packet, e.g. active networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/0078—Avoidance of errors by organising the transmitted data in a format specifically designed to deal with errors, e.g. location
    • H04L1/0085—Formatting with cells
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46—Interconnection of networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46—Interconnection of networks
    • H04L12/4633—Interconnection of networks using encapsulation techniques, e.g. tunneling
    • 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/50—Routing or path finding of packets in data switching networks using label swapping, e.g. multi-protocol label switch [MPLS]
    • 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
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • 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/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/161—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
    • 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
    • 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming

Definitions

  • the embodiments of the present disclosure relate to the field of communications, and in particular, to a packet processing method, device, storage medium, and electronic device.
  • BIER Bit Indexed Explicit Replication
  • the multicast technology means that the source host only sends one piece of data, and the destination address of the data is the multicast group address, so that all member devices belonging to the group can receive a copy of the data sent by the source host, and
  • the entry node BFIR (Bit-Forwarding Ingress Router) of the BIER domain encapsulates the multicast traffic entering the BIER domain as the payload of the BIER header. After forwarding by the intermediate nodes, the exit node BFER of the BIER domain After receiving the BIER message, after stripping the BIER header, the payload is forwarded to the corresponding receiver.
  • all nodes in the BIER domain can encapsulate and forward BIER packets, or if all devices in the network can be upgraded to support the complete BIER technology, the BIER technology can also be deployed smoothly.
  • the embodiments of the present disclosure provide a packet processing method and device, so as to at least solve the problem that the packet cannot be forwarded normally when the network node cannot support the complete BIER technology in the related art.
  • a packet processing method including:
  • the payload data is forwarded to the receiving end.
  • determining the type of the payload contained in the target message and the starting position of the payload includes:
  • the type of the payload and the starting location of the payload are determined based on the starting location of the target message.
  • the determining the starting position of the load based on the starting position includes:
  • the target packet is a packet of another type except the first type packet
  • obtain a first information value of the target packet where the first information value is used to indicate The length of the first information; the starting position of the payload is determined based on the value of the first information.
  • the determining the type of the payload based on the starting position of the target packet includes:
  • a target header field included in the target packet is determined based on the starting position of the target packet, and the payload is determined based on the target header field type;
  • a second offset calculation is performed on the target packet , to obtain the attribute value of the target packet; and determine the type of the payload based on the attribute value.
  • the method further includes: in the case that the target packet is determined to be a first type packet, based on the The source address performs a first positioning operation to obtain a first positioning result; forwarding the payload data to the receiving end includes: in the case of locating the target node based on the first positioning result, sending the payload data to the destination node. the target node to instruct the target node to send the payload data to the receiver;
  • the method further includes: in the case that the target packet is determined to be a packet of another type except the first type of packet, according to the type of the payload Finding the target node; forwarding the payload data to the receiving end includes: in the case that the target node is determined to be found, performing a third offset operation on the payload to obtain target payload data; transferring the target The payload data is sent to the target node to instruct the target node to send the payload data to the receiver.
  • the method before determining the type of the payload contained in the target message and the starting position of the payload, the method further includes:
  • the target message is a first type of message
  • determine whether the entry node is the first entry node corresponding to the locally stored first entry node identifier
  • the target packet is a packet of another type except the first type packet
  • acquire second information included in the target packet based on the second information and the target packet the starting position of the message, perform a fourth offset calculation on the target message to determine the node identification value of the first entry node; determine the entry node based on the node identification value and the second information Whether it is the first entry node corresponding to the locally stored first entry node identifier;
  • Determining the type of the payload contained in the target message and the starting position of the payload includes: in the case that the entry node is determined to be the first entry node corresponding to the locally stored first entry node identifier, Determine the type of the payload contained in the target message and the starting position of the payload.
  • the acquiring the first information value of the target packet includes at least one of the following:
  • the method further includes :
  • a second feedback is sent to the controller to instruct the controller to send a third feedback to the ingress node, where the third feedback is used to indicate refusal to receive a packet to be sent to the receiving end.
  • the method further includes:
  • the fourth feedback is used to indicate at least one of the following information: the egress node is a node that does not support the predetermined technology, and the egress node supports the capability level of the predetermined technology.
  • a device for processing a message including:
  • the receiving module is set to receive the target message from the entry node
  • a determining module configured to determine the type of the payload contained in the target message and the starting position of the payload
  • a parsing module configured to perform a payload parsing operation on the target message based on the type of the payload and the starting position of the payload to obtain payload data of the payload;
  • the sending module is configured to forward the payload data to the receiving end.
  • 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.
  • FIG. 1 is a block diagram of a hardware structure of a mobile terminal according to a method for processing a message according to an embodiment of the present disclosure
  • FIG. 2 is a flowchart of a message processing method according to an embodiment of the present disclosure
  • FIG. 3 is a format diagram 1 of a packet header encapsulation according to an embodiment of the present disclosure
  • FIG. 4 is a format diagram 2 of packet header encapsulation according to an embodiment of the present disclosure.
  • FIG. 5 is a format diagram 3 of a packet header encapsulation according to an embodiment of the present disclosure
  • FIG. 6 is a format diagram 4 of a packet header encapsulation according to an embodiment of the present disclosure
  • FIG. 7 is a node diagram 1 of a message processing method according to an embodiment of the present disclosure.
  • FIG. 8 is a second node diagram of a packet processing method according to an embodiment of the present disclosure.
  • FIG. 9 is a structural block diagram of a message processing apparatus according to an embodiment of the present disclosure.
  • FIG. 10 is a general flowchart of a message processing method according to a specific embodiment of the present disclosure.
  • FIG. 11 is a message header format diagram according to a specific embodiment of the present disclosure.
  • FIG. 12 is a schematic diagram of a TLV structure according to a specific embodiment of the present disclosure.
  • FIG. 14 is a node diagram according to the second embodiment of the present disclosure.
  • BFER1/BFER2 are upgraded at the software level, but not at the hardware level.
  • BFRm the last-hop device of BFER1 and BFER2, you need to record the special cases of BFER1 and BFER2, as well as the special encapsulation method sent to BFER1/BFER2, and when BIER packets are received and need to be forwarded to BFER1 and BFER2, BFRm except The normal BIER message is copied and forwarded to other nodes (such as possible BFER3/BFER4 or BFRn). Before sending it to BFER1/BFER2, the BIER header needs to be stripped off, and its payload is advertised by BFER1/BFER2. After the tunnel method is encapsulated, it is sent to the BFER1/BFER2 node.
  • FIG. 1 is a hardware structural block diagram of a mobile terminal according to a packet processing method according to an embodiment of the present disclosure.
  • the mobile terminal may include one or more (only one is shown in FIG. 1 ) processor 102 (the processor 102 may include, but is not limited to, a processing device such as a microprocessor MCU or a programmable logic device FPGA) and a memory 104 configured to store data, wherein the above-mentioned mobile terminal may further include a transmission device 106 and an input/output device 108 configured as a communication function.
  • processor 102 may include, but is not limited to, a processing device such as a microprocessor MCU or a programmable logic device FPGA
  • a memory 104 configured to store data
  • the above-mentioned mobile terminal may further include a transmission device 106 and an input/output device 108 configured as a communication function.
  • FIG. 1 is only a schematic diagram, which does not limit the structure of the above-mentioned mobile terminal.
  • the mobile terminal may also include more or fewer components than those 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 a computer program corresponding to a message processing method in an embodiment of the present disclosure.
  • the processor 102 executes the computer program stored in the memory 104 by running the computer program. , 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.
  • the memory 104 may further include memory located remotely from the processor 102, and these remote memories may be connected to the mobile 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 a communication provider of the mobile terminal.
  • the transmission device 106 includes a network adapter (Network Interface Controller, NIC for short), which can be connected to other network devices through a base station so as to communicate with the Internet.
  • the transmission device 106 may be a radio frequency (Radio Frequency, RF for short) module, which is configured to communicate with the Internet in a wireless manner.
  • RF Radio Frequency
  • FIG. 2 is a flowchart of a packet processing method according to an embodiment of the present disclosure. As shown in FIG. 2 , the flowchart includes the following steps:
  • Step S202 receiving the target message from the entry node
  • the target packet may be (but not limited to) a packet in IPV6 format, a packet with an ether type of 0xAB37, or a packet in MPLS format or a packet in other formats;
  • the entry node It can be a physical data interface, a virtual node in the process of data forwarding, or other units or modules with sending and receiving functions.
  • Step S204 determine the type of the load included in the target message and the starting position of the load
  • the type of the payload and the starting position of the payload may (but are not limited to) be determined according to data such as address information included in the header of the target packet, or may be a packet that skips the target packet.
  • the header is directly determined according to the starting position of the target header.
  • the method of skipping the packet header to obtain the starting position of the payload may be to strip off the IPv6 header and possible extension headers to obtain the starting position of the payload of the BIER packet when the type of the target packet is in the IPv6 format, such as removing the DOH (Destination Options Header, destination option header), etc.; it can also be based on the starting position of the target message, determine the BSL (BitStringLength, bit string length) information, and then determine the payload of the BIER message according to the length value L in the BSL information start position.
  • BSL BitStringLength, bit string length
  • the way to obtain the type of the payload can be when the target packet type is in IPV6 format and contains the destination address DA (Destination Address), and the BIER header of the target packet is encapsulated in the IPv6 DOH (Destination Options Header, destination option header) extension header.
  • the packet type of the payload is known; among them, the BIER header can also be encapsulated in the HBH (Hop-by-Hop Header, hop-by-hop option header), SRH ( IPv6 Segment Routing Header, segment routing extension header) and other extension headers, and the payload type is determined in a similar way.
  • HBH Hop-by-Hop Header, hop-by-hop option header
  • SRH IPv6 Segment Routing Header, segment routing extension header
  • the type of the target message is in IPV6 format and the address DA contained is a local address, it will offset 74 bits from the start position of the BIER header, read the 6-bit Proto value, and then determine the type of the payload message according to this value.
  • Step S206 based on the type of the payload and the starting position of the payload, perform a payload analysis operation on the target message to obtain payload data of the payload;
  • the acquired payload data includes (but is not limited to) information such as the forwarding destination node address of the payload, the forwarding time of the payload, and the forwarding frequency of the payload.
  • Step S208 forwarding the payload data to the receiving end.
  • the forwarding of the payload data may be simultaneous forwarding, batch forwarding, or other types of forwarding methods.
  • the number of receiving ends may be one or multiple. It can be that multiple receivers receive payload data at the same time, or multiple receivers can receive payload data in batches, or one receiver can receive multiple batches of payload data at the same time, or one receiver can receive multiple batches in batches. load data.
  • the ingress node BFIR of the BIER domain encapsulates the multicast traffic entering the BIER domain as the payload of the BIER header.
  • the egress node BFER of the BIER domain receives the BIER packet and strips it. After removing the BIER header, forward the payload to the corresponding receiver.
  • the payload data can be directly determined based on the type of the payload and the starting position of the payload, so as to realize the forwarding of the payload, so as to achieve the purpose of realizing the forwarding of the payload data without supporting the complete BIER technology.
  • the problem that the target message cannot be normally forwarded due to the fact that the network node cannot support the complete BIER technology is solved, and the message forwarding efficiency is improved.
  • the execution subject of the above steps may be a network node, but is not limited thereto, wherein the network node is located in equipment such as a base station and a terminal.
  • determining the type of the payload contained in the target message and the starting position of the payload include:
  • Step S2062 determining the starting position of the target message based on the type of the target message
  • Step S2064 determining the type of the payload and the starting location of the payload based on the starting location of the target message.
  • the starting position of the target packet can be determined by the destination address contained in it or the corresponding Next Header field;
  • the starting position of the target packet is determined by the type value it contains;
  • the target packet is an MPLS packet, the starting position of the target packet can be determined by the label value contained in the target packet; in the target packet If the message is a message of another type, the starting position of the target message may be determined in other ways.
  • determining the starting position of the target packet based on the type of the target packet includes:
  • Step S20642 determining the target information included in the target message for determining the starting position of the target message based on the type of the target message;
  • Step S20644 Determine the starting position of the target message based on the target information.
  • the target information includes (but is not limited to) a destination address DA, a NextHeader field, a type value, a tag value, and the like.
  • determining the starting position of the payload based on the starting position of the target packet includes:
  • Step S2042 in the case of determining that the target message is the first type of message, skip the message header of the target message to determine the starting position of the payload;
  • Step S2044 in the case where it is determined that the target message is a message of another type except the first type message, obtain a first information value of the target message, where the first information value is used to indicate the length of the first information ; Determine the starting position of the payload based on the first information value.
  • the first type of message may be a message in IPV6 format, or may be a message of other types; the first information may be BSL information included in the target message, and correspondingly, the first information value may be is the L value of the BSL information.
  • the destination address DA is a specific reserved address allocated for BIER, which can be determined by identifying the address. BIER message.
  • the field value of the NextHeader field contained in the IPv6 packet is read, and when the read value indicates that the field value is BIER type , the identification operation is performed by the value of this field to determine the BIER message, and the start position of the BIER header is obtained accordingly.
  • the target packet is a packet with an ether type of 0xAB37 and the encapsulation is shown in Figure 5
  • the BIER packet is determined according to the type value contained in the type of packet, and the start position of the BIER header is obtained accordingly.
  • the target packet is an MPLS packet and the encapsulation is similar to that shown in Figure 6, the local table entry is matched and searched according to the label value indicated by the first 4 bytes of the target packet.
  • determine the BIER message, and the start position of the label is the start position of the BIER header.
  • acquiring the first information value of the target packet includes at least one of the following:
  • a first reading process is performed on the target message to obtain first information; and a second matching process is performed based on the first information to obtain a first information value.
  • the manner of acquiring the first information can be selected differently according to requirements or usage environment, so as to adapt to various usage situations.
  • the first offset calculation can be (but not limited to) a 40-bit offset from the position of the BIER header, read a 4-bit BSL value, and then find the corresponding BSL length value L according to this value; similarly, the first The reading process can (but is not limited to) if the encoding method of the ID in the BIFT (Bit Index Forwarding Table, Bit Index Forwarding Table)-ID is ⁇ BSL, SD, SI> (SD: Sub-Domain, sub-domain; SI: Set If the Identifier, set identifier) triple is hard-coded, its encoding form can be that the first 4 bits are BSL, the next 8 bits are SD, and the last 8 bits are SI hard-coded. At this time, from the beginning of the BIER message The BSL value can be determined by reading 4 bits of the position, and then the corresponding BSL length value L is found according to the BSL value.
  • determining the type of the payload based on the starting position of the target packet includes:
  • Step S20646 in the case of determining that the target message is the first type of message, determine the target header field contained in the target message based on the starting position of the target message, and determine the type of the payload based on the target header field;
  • Step S20648 in the case where it is determined that the target message is a message of another type except the first type message, based on the starting position of the target message, perform a second offset calculation on the target message to obtain the target message.
  • the attribute value of the text; the type of payload is determined based on the attribute value.
  • the target header field may be (but not limited to) the Next Header field in the DOH extension header of IPv6, the Next Header field or other fields in the HBH extension header, or the SRH extension header and other extension headers.
  • the attribute value can be the Proto value of the message header, and the corresponding second offset calculation can be offset 74 bits from the start position of the BIER header to read the 6-bit Proto value.
  • the method further includes:
  • Step S2022 when it is determined that the target message is a first type message, perform a first positioning operation based on the source address included in the target message to obtain a first positioning result;
  • Forwarding payload data to the receiver includes:
  • Step S2082 in the case of locating the target node based on the first positioning result, send the payload data to the target node to instruct the target node to send the payload data to the receiving end.
  • the method further includes:
  • Step S2024 in the case of determining that the target message is a message of another type except the first type of message, search for the target node according to the type of the payload;
  • Forwarding payload data to the receiver includes:
  • Step S2084 if it is determined that the target node is found, perform a third offset operation on the payload to obtain target payload data; send the target payload data to the target node to instruct the target node to send the payload data to the receiver.
  • the source address may be the source address SA (Source Address) in the IPv6 packet, or may be other types of source addresses.
  • the multicast traffic entering the BIER domain is based on services such as MVPN (Multicast Virtual Private Network), or EVPN (Ethernet Virtual Private Network, Ethernet Virtual Private Network), because the edge node BFIR and There are multiple MVPN or EVPN instances on the BFER. Therefore, when the BFER receives a packet, it needs to locate a specific MVPN/EVPN instance before it can be further forwarded to the receiver.
  • MVPN Multicast Virtual Private Network
  • EVPN Ethernet Virtual Private Network
  • Virtual Private Network Virtual Private Network
  • the payload type is MPLS or IPv6 address, etc.
  • the payload type is MPLS or IPv6 address, etc.
  • the payload type is MPLS or IPv6 address, etc.
  • the payload type is MPLS or IPv6 address, etc.
  • the payload type is MPLS or IPv6 address, etc.
  • the payload type is MPLS or IPv6 address, etc.
  • the payload type is MPLS or IPv6 address, etc.
  • the method further includes:
  • Step S20402 when it is determined that the target message is a first type message, based on the source address included in the target message, determine whether the entry node is the first entry node corresponding to the locally stored first entry node identifier;
  • Step S20404 in the case of determining that the target message is a message of another type except the first type message, obtain the second information included in the target message, based on the second information and the starting position of the target message, Perform a fourth offset calculation on the target message to determine the node identification value of the first entry node; determine whether the entry node is the first entry node corresponding to the locally stored first entry node identity based on the node identification value and the second information ;
  • Determining the type of payload contained in the target packet and the starting position of the payload include:
  • Step S2046 when it is determined that the ingress node is the first ingress node corresponding to the locally stored first ingress node identifier, determine the type of the payload contained in the target packet and the starting position of the payload.
  • the second information may be SD (Sub-Domain, sub-domain) information, or may be other information.
  • its ingress node BFIR may have two or more. At this time, the two ingress node BFIRs will encapsulate and forward the BIER traffic to the egress node BFER. At this time, the egress The node BFER needs to select a BFIR to receive and forward the traffic to the receiver, and discard the same multicast traffic forwarded by other BFIRs.
  • the source address SA is used to determine the BFIR of the entry node, that is, if the SA (Source Address, source address) is the address of BFIR1, it will be processed and forwarded to the receiver.
  • the method further includes:
  • Step S20406 in the case that the ingress node is determined to be other than the first ingress node, discard the target packet.
  • the unnecessary packets sent by the entry node BFIR are directly discarded.
  • BFER1/BFER2 only processes and forwards packets from BFIR1 and discards packets from BFIR2; that is, if SA is the address of BFIR2, it directly discards the packet.
  • the method further includes:
  • Step S20408 performing fault detection processing on the target entry node
  • Step S204010 in the case of determining that the target entry node is in a fault state, update the locally stored first entry node identifier to the second entry node identifier, wherein the second entry node identifier is used to identify other than the first entry node. entry node.
  • BFER1/BFER2 switches to receive and forward traffic whose SA is the address of BFIR2 after learning the failure of BFIR1 through detection or other means.
  • obtaining the second information included in the target message includes at least one of the following:
  • a fifth offset calculation is performed on the target message to obtain the second information
  • a third matching process is performed on the local entry to obtain the second information.
  • acquiring the second information in different ways is to adapt to different usage backgrounds and usage ways, so as to adapt to different usage environments.
  • BIFT Bit Index Forwarding Table, Bit Index Forwarding Table
  • SI> triple hard-coded that is, the first 4 bits are BSL, and the next 8 bits are SD
  • the OSPF/ISIS extension notification method is used.
  • query the local table entry according to the BIFT-ID to obtain the SD value.
  • acquiring the first information value of the target packet includes at least one of the following:
  • the purpose of fixing the BSL value is to reduce the amount of computation involved in the packet parsing process, thereby further simplifying the operation on the BFER.
  • BFIR when BFIR communicates with BFER through BIER Overlay technology, BFIR informs BFER of its fixed BSL length, that is, BFIR uses a fixed BSL length when encapsulating the BIER header, such as 128 bits, or 256 bits, etc.
  • BIER Overlay technologies involved include but are not limited to MLD (Multicast Listener Discovery), PIM (Protocol Independent Multicast), MVPN, EVPN, etc.
  • the controller informs the BFIR to use a fixed BSL for BIER header encapsulation.
  • the methods of controller notification include but are not limited to BGP-LS, PCEP, NETCONF/RESTCONF plus YANG model and other methods.
  • a fixed BSL length is configured on the BFER, and the BSL length is all used when parsing the BIER header.
  • the payload processing method can also be fixed by a method similar to the fixed BSL value, the BIER Overlay extension between BFER and BFIR, and the notification between BFER and the controller can also be fixed in a similar way to the fixed BSL.
  • the method further includes:
  • the second feedback is sent to the controller to instruct the controller to send a third feedback to the ingress node, where the third feedback is used to indicate refusal to receive the packet to be sent to the receiving end.
  • the feedback indication when there is no receiving end, can avoid data redundancy and energy waste caused by the ingress node continuing to send data.
  • BFER performs payload processing
  • if it finds that there is no corresponding receiver locally it means that there is a problem with the message delivery.
  • BFER records the problem and informs BFIR in one of the following ways:
  • BFER announces through BIER Overlay technology, notifying BFIR that it does not receive the multicast traffic
  • BFER informs the controller through BGP-LS (Border Gateway Protocol-Link State), PCEP, NETCONF/RESTCONF plus YANG model, etc., and the controller then informs BFIR not to send the multicast traffic to the BFER;
  • BGP-LS Border Gateway Protocol-Link State
  • PCEP PCEP
  • NETCONF/RESTCONF plus YANG model etc.
  • BFER2 finds that there is no local receiver for a certain multicast traffic when forwarding BIER packets, BFER2 records the problem after discarding the packet, and uses the BIER Overlay technology or the controller to make it happen.
  • BIER Overlay technology or the controller to make it happen.
  • BFIR learns this information, when BFIR encapsulates the multicast traffic, it will delete the BFER2 node in the Bit-String of the encapsulated BIER header, so that the packet will not be sent to BFER2 again.
  • the method further includes:
  • Step S2010 Send fourth feedback to the ingress node or controller, where the fourth feedback is used to indicate at least one of the following information:
  • the exit node is a node that does not support the predetermined technology, and the exit node supports the capability level of the predetermined technology.
  • the fourth feedback is sent to the ingress node or controller to avoid the ingress node or controller from repeatedly sending traffic information.
  • the BFIR or the controller can determine that the corresponding BFER is in a state that cannot support the complete BIER technology by sending feedback information to the BFIR node or controller.
  • the reporting methods include (but are not limited to):
  • Mode 1 Select an unused bit in the Node Flag Bits of the Node Attribute TLV (defined by RFC7752) to indicate incomplete BIER technical support.
  • Method 2 A new type is defined in the Node Attribute TLV to indicate incomplete BIER technical support.
  • Mode 3 Add a sub-TLV to the BIER Information TLV in the Prefix Attribute TLV to indicate incomplete BIER technical support, where the BIER Information TLV is the definition in draft-ietf-bier-bgp-ls-bier-ext.
  • BGP-LS protocol extension For example, if BGP-LS protocol extension is not used, methods such as PCEP node capability extension, or the method of NETCONF/RESTCONF plus YANG model can also be used.
  • the method before sending the fourth feedback to the ingress node or the controller, the method further includes:
  • Step S20102 adding an identifier for indicating that the exit node is a node that does not support the predetermined technology in the target protocol information, so as to obtain a fourth feedback.
  • the state of the egress node can be quickly determined, thereby avoiding energy consumption and data redundancy.
  • adding an identifier for indicating that the exit node is a node that does not support the predetermined technology in the target protocol information can be implemented in the following ways:
  • Method 1 When deploying MVPN/EVPN services, it can be implemented by adding a new tunnel type in PMSI (Proyider Multicast Service Interface) Tunnel Attribute (PTA) to support non-complete BIER technology;
  • PMSI Process Multicast Service Interface
  • PTA Tunnel Attribute
  • Mode 2 BFER notifies the BFIR node to implement by adding a TLV to extend the BIER capability through protocols such as MLD/PIM/BGP, which carries incomplete BIER technical support capabilities;
  • BFER is in the BIER-info TLV/sub-TLV extended by routing protocols such as OSPF/ISIS of Underlay (defined in RFC8401/RFC8444), and the BIER capability is added to extend the sub-TLV, or directly use the BIER-info TLV/sub - A bit of a reserved field in the TLV to indicate incomplete BIER technical support. Because the Underlay information is received by all devices in the BIER domain, including BFIR, BFIR queries the information advertised by BFER to learn the incomplete BIER technical support of the BFER node.
  • routing protocols such as OSPF/ISIS of Underlay (defined in RFC8401/RFC8444)
  • OSPF/ISIS of Underlay defined in RFC8401/RFC8444
  • Method 4 After BFER reports its capabilities to the controller, the controller then informs BFIR through BGP-LS, PCEP (Path Computation Element Communication Protocol, Path Computation Communication Protocol), NETCONF/RESTCONF plus YANG model, etc., and the notification content is incomplete Support capability sub-TLV or sub-sub-TLV, etc.
  • the BFIR can learn the BFER situation that cannot fully support the BIER technology through the above method. At the same time, it does not perform special processing on the BFER by default, but can perform refined control through policies. If only one BFER needs to be received for a certain multicast traffic, and The BFER cannot fully support the BIER technology, so the BFIR can omit the operation of encapsulating the BIER header, and directly use IPinIP or other tunnel encapsulation forms to send packets to the BFER.
  • non-complete BIER technical capabilities can be graded, and different levels represent different BIER technical support capabilities.
  • level 1 means that only fixed BSL and fixed payload type processing is supported, and level 2 means that fixed payload processing is supported but BSL reading is supported.
  • Fetch processing level 3 means supporting BSL reading and payload type reading processing, etc.; or level 1 means supporting BSL reading processing, level 2 means supporting BSL and SD reading processing, level 3 means supporting BSL, SD and BFIR-ID read processing, etc.
  • BGP-LS/PCEP/YANG model extensions it is also possible to add sub-TLV or other extensions to the above-mentioned BGP-LS/PCEP/YANG model extensions, and carry specific level information, so that the controller or BFIR node can obtain more accurate BFER support for BIER technology , so that it can be combined with strategies to better adapt to different BIER networking deployment requirements. For example, if the BFIR learns that the BFER node only supports fixed BSL processing, the BFIR will only use the BSL to encapsulate the BIER header for BFER processing.
  • a message processing apparatus is also provided, and the apparatus is used to implement the above-mentioned embodiments and preferred implementations, 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. 9 is a structural block diagram of a message processing apparatus according to an embodiment of the present disclosure. As shown in FIG. 9 , the apparatus includes:
  • the receiving module 92 is configured to receive the target message from the entry node
  • Determining module 94 configured to determine the type of load contained in the target message and the starting position of the load
  • the parsing module 96 is configured to perform a payload parsing operation on the target message based on the type of the payload and the starting position of the payload to obtain payload data of the payload;
  • the sending module 98 is configured to forward the payload data to the receiving end.
  • the parsing module 96 includes:
  • the position determining unit 962 is set to determine the starting position of the target message based on the type of the target message;
  • the information determining unit 964 is configured to determine the type of payload and the starting location of the payload based on the starting location of the target message.
  • the information determining unit 964 includes:
  • the information determination subunit 9642 is set to determine the target information included in the target message for determining the starting position based on the type of the target message;
  • the first position determination subunit 9644 is configured to determine the starting position based on the target information.
  • the determining module 94 includes:
  • the first determining unit 942 is configured to skip the message header of the target message to determine the starting position of the payload when it is determined that the target message is the first type of message;
  • the second determining unit 944 is configured to obtain the first information value of the target packet when the target packet is determined to be a packet of another type except the first type of packet, wherein the first information value is determined by using is used to indicate the length of the first information; the starting position of the payload is determined based on the value of the first information.
  • the second determining unit 844 includes:
  • the first calculation subunit 9442 is configured to perform a first offset calculation on the target packet based on the starting position of the target packet, so as to obtain the first information contained in the target packet; performing a first matching process on the first information to obtain the first information value;
  • the first reading subunit 9444 is set to perform a first reading process on the target message based on the starting position of the target message to obtain the first information; and perform a second matching process based on the first information to obtain the first information value.
  • the information determining unit 964 further includes:
  • the first determination subunit 9646 is configured to determine the target header field contained in the target message based on the starting position of the target message when it is determined that the target message is a first type message, and determine the payload size based on the target header field. type;
  • the second determination subunit 9648 is configured to perform a second offset on the target packet based on the starting position of the target packet in the case that the target packet is determined to be a packet of another type except the first type packet Calculate to obtain the attribute value of the target packet; determine the type of the payload based on the attribute value.
  • the device also includes:
  • the positioning unit 922 is configured to perform a first positioning operation based on the source address included in the target message in the case of determining that the target message is a first type message after receiving the target message from the entry node, to obtain the first positioning result;
  • the sending module 98 includes:
  • the first sending unit 982 in the case of locating the target node based on the first positioning result, sends the payload data to the target node to instruct the target node to send the payload data to the receiving end;
  • the device also includes:
  • the search unit 924 is configured to, after receiving the target message from the entry node, search for the target node according to the type of the load under the condition that the target message is determined to be other types of messages except the first type message;
  • the sending module 98 includes:
  • the second sending unit 984 when it is determined that the target node is found, performs a third offset operation on the payload to obtain the target payload data; and sends the target payload data to the target node to instruct the target node to send the payload data to the target node. the receiving end.
  • the device further includes:
  • the first node determining unit 8402 is configured to, before determining the type of the payload contained in the target message and the starting position of the payload, in the case that the target message is determined to be the first type of message, based on the source content included in the target message.
  • the address determines whether the entry node is the first entry node corresponding to the locally stored first entry node identifier;
  • the second node determining unit 8404 in the case of determining that the target packet is a packet of another type except the first type packet, acquires second information included in the target packet, based on the second information and the target packet the starting position of the message, and perform the fourth offset calculation on the target message to determine the node identification value of the first entry node; based on the node identification value and the second information, determine whether the entry node is the same as the locally stored first entry node identification the corresponding first entry node;
  • the determination module 94 also includes:
  • the determining subunit 946 determines the type of the payload contained in the target packet and the starting position of the payload when the entry node is determined to be the first entry node corresponding to the locally stored first entry node identifier.
  • the device further includes:
  • the packet discarding unit 9406 discards the target packet when it is determined that the entry node is a node other than the first entry node.
  • the device further includes:
  • the fault detection unit 9408 performs fault detection processing on the target entry node
  • the node updating unit 94010 in the case of determining that the target entry node is in a fault state, updates the locally stored first entry node identifier to the second entry node identifier, wherein the second entry node identifier is used to identify other than the first entry node. other entry nodes.
  • the second node determining unit 3404 includes at least one of the following:
  • the offset calculation subunit 94042 is configured to perform the fifth offset calculation on the target packet based on the starting position of the target packet to obtain the second information;
  • the entry matching subunit 94044 is configured to perform a third matching process on the local entry according to the bit index table included in the target message to obtain the second information.
  • the second determining unit 944 further includes at least one of the following:
  • the first receiving subunit 9446 is configured to receive the first information value from the entry node
  • the second receiving subunit 9448 is configured to receive the first information value from the controller
  • the acquisition subunit 94410 is configured to acquire a preset first information value.
  • the device further includes:
  • the operation execution unit 968 is configured to, based on the type of the payload and the starting position of the payload, perform a payload parsing operation on the target message to obtain payload data of the payload, and when it is determined that there is no receiver for receiving the payload data , do at least one of the following:
  • the second feedback is sent to the controller to instruct the controller to send a third feedback to the ingress node, where the third feedback is used to indicate refusal to receive the packet to be sent to the receiving end.
  • the device further includes:
  • the feedback module 910 is configured to send fourth feedback to the ingress node or the controller, where the fourth feedback is used to indicate at least one of the following information:
  • the exit node is a node that does not support the predetermined technology, and the exit node supports the capability level of the predetermined technology.
  • the feedback module 910 further includes:
  • the instructing unit 9102 is configured to, before sending the fourth feedback to the ingress node or the controller, add an identifier for indicating that the egress node is a node that does not support the predetermined technology in the target protocol information to obtain the fourth feedback.
  • 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.
  • the packet processing method provided by the embodiment of the present disclosure mainly includes the following steps:
  • Step S101 the BFER receives the message (corresponding to the aforementioned step S202);
  • Step S102 after identifying the BIER message, skip the processing of the BIER header, or only process the fields in the BIER header (including at least one of the following: BSL, BFIR-ID, SD, BIFT-ID) to determine the BIER message
  • BSL BFIR-ID
  • SD BIFT-ID
  • Step S103 and then analyze the payload message according to the message type and start position of the payload (corresponding to the aforementioned step S206);
  • step S104 the parsing result is normally forwarded to the receiver R1/R2/R3 (corresponding to the foregoing step S208).
  • BFER when MVPN or EVPN and other services are deployed, BFER obtains the required key service instance information; and when the dual-root protection function is deployed, BFER needs to discard duplicate traffic according to specific fields;
  • BFER can optionally notify the controller of its incomplete BIER technical support capability through the BGP-LS protocol, or PCEP (protocol, or NETCONF, RESTCONF, etc., in the form of carrying YANG models or data). ; or BFER can optionally notify the BFIR node of its incomplete BIER technical support capability through the BIER Overlay protocol.
  • BFIR can optionally notify BFER of the BSL length of its encapsulation, or the encapsulation method of the payload, or both, through the BIER Overlay protocol.
  • BIER Overlay technologies include but are not limited to MLD (Multicast Listener Discovery), PIM (Protocol Independent Multicast, protocol independent multicast), MVPN, EVPN, etc.
  • BFER When BFER has no local receiver for a multicast traffic, BFER records the problem and feeds it back to BFIR through BIER Overlay technology, or BFER informs the controller, which then informs BFIR, and BFIR encapsulates subsequent packets of the multicast traffic
  • BFER node is deleted when the BIER header is used.
  • BFER1 and BFER2 cannot fully support BIER technology, but still behave as normal BFER nodes when BFER1 and BFER2 software signaling performs BIERUnderlay interaction, that is, when BFER1, BFER2 and BFRm and other nodes conduct
  • protocol signaling such as OSPF (Open Shortest Path First, Open Shortest Path First)/ISIS (Intermediate System-to-Intermediate System, intermediate system to intermediate system) interacts
  • OSPF Open Shortest Path First, Open Shortest Path First
  • ISIS Intermediate System-to-Intermediate System, intermediate system to intermediate system
  • BFIR will also regard BFER1 and BFER2 as normal BIER nodes; BFIR will normally BIER encapsulate the multicast traffic and forward it to the BIER domain, so that BFER1 and BFER2 will receive normal BIER packets; , multicast traffic can be IPv4, IPv6, or Ethernet traffic.
  • Step S1101 Identify the BIER message
  • Step S1102 skip the BIER header
  • Step S1103 Obtain the payload message type of the BIER header
  • Step S1104 Perform payload packet parsing based on the payload packet type, and normally forward the parsing result to the receiver R1/R2/R3.
  • step 1101 specifically includes:
  • step 1101a if the received message is an IPv6 message, the encapsulation is similar to that shown in FIG. 3, and the destination address is a specific reserved address allocated for BIER, and the BIER message is identified by this address.
  • Branch step 1101b if the received message is an IPv6 message, the encapsulation is similar to that shown in Figure 4, and its DA is the local interface address, read the Next Header field of IPv6, if the field value indicates the BIER type, pass this field The value identifies the BIER message; and accordingly obtains the start position of the BIER header.
  • step 1101c if the received packet is an ether type of 0xAB37 and the encapsulation is similar to that shown in Figure 5, the BIER packet is identified according to the type value; and the start position of the BIER header is obtained accordingly.
  • Branch step 1101d if the received MPLS message is encapsulated as shown in Figure 6, the local table entry is searched according to the first 4-byte label value of the message, and the indication information of the hit table entry is BIER type, thus identifying BIER message; the starting position of the label is the starting position of the BIER header.
  • Step 1102 specifically includes:
  • the branch step 1102a is followed by the branch step 1101a in the step 1101, and the IPv6 header and possible extension headers, such as DOH, etc., are stripped to obtain the start position of the payload of the BIER message.
  • the branch 1102b is connected to the branch 1101b in the step 1101.
  • the BSL information is obtained. There are two ways to obtain it:
  • Offset 40 bits from the position of the BIER header read the 4-bit BSL value, and find the corresponding BSL length value L according to this value (the corresponding definition is in RFC8296);
  • the encoding method of BIFT-ID is ⁇ BSL, SD, SI> (SD: Sub-Domain, sub-domain; SI: Set Identifier, set identifier) triple hard-coded, that is, the first 4 bits may be BSL, followed by 8 bits are SD, and the last 8 bits are hard-coded in SI mode, then read the 4-bit BSL value from the beginning of the BIER message, and find the corresponding BSL length value L according to this value.
  • SD Sub-Domain, sub-domain
  • SI Set Identifier, set identifier
  • the start position of the payload message is obtained according to the BSL: that is, the start position of the payload message is obtained by offsetting (12+L/8) bytes from the BIER header.
  • the 4-bit BSL value is 3, and the corresponding BSL length value is 256, it can be known by calculation that the start position of the payload message can be obtained by offsetting (12+256/8) 44 bytes from the BIER header.
  • the branch step 1102c is connected to the branch 1101c in the step 1101, and the processing method is the same as that of step 1102b.
  • the branch step 1102d is connected to the branch 1101d in the step 1101.
  • There are two processing methods the first one is the same as 1102b; the second type of BSL value acquisition is to query the local table entry from the label value obtained in the branch 1101d to obtain the BSL value; Then use the same calculation method of 1102b to obtain the start position of the payload packet.
  • Step 1103 specifically includes:
  • the branch step 1103a is connected to the branch 1101a in step 1101.
  • the BIER header is encapsulated in the DOH extension header of IPv6
  • the packet type of the payload is obtained according to the NextHeader field in the DOH extension header of the IPv6 header; the BIER header can also be encapsulated in the HBH, In other extension headers such as SRH, the processing method is similar.
  • the branch step 1103b is followed by the branch 1101b in step 1101, offsets 74 bits from the start position of the BIER header, reads the 6-bit Proto value, and determines the type of the payload message according to the value.
  • the branch step 1103c is connected to the branch 1101c in step 1101, and the processing method is the same as that of step 1103b.
  • the branch step 1103d is connected to the branch 1101d in step 1101, and the processing method is the same as that of step 1103b.
  • BFER2/BFER3 can skip the complex processing flow such as Bit-String in the BIER packet header, and obtain the packet type and starting position of the BIER payload, so that the payload packet can be parsed and forwarded to Receiver R1/R2/R3.
  • the multicast traffic entering the BIER domain may be based on services such as MVPN or EVPN. Because there are multiple MVPN or EVPN instances on the edge nodes BFIR and BFER, BFER needs to locate a specific MVPN/EVPN instance when receiving packets. can be further forwarded to the recipient. As shown in Figure 7, the multicast traffic entering the BIER domain is MVPN/EVPN traffic and belongs to VPN1 and VPN2. When BFER receives a packet, it needs to distinguish whether the packet should be forwarded to VPN1 or VPN2.
  • the data plane forwarding technology of BIER eliminates the delay in establishing a multicast tree because there is no 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. Compared with the original multicast tree reconstruction, the huge delay is reduced.
  • Branch step 1201a connect to branch 1101a in step 1101, use its IPv6 source address SA (Source Address) to locate the service instance to see if a certain VPN, such as VPN1, can be located; then after passing steps 1102a and 1103a, the payload The packet is forwarded to the receiver in the corresponding VPN such as VPN1.
  • SA Source Address
  • Branch step 1201b after passing through steps 1102b and 1103b, read the label value or IPv6 address of the payload according to the type of the payload packet is MPLS or IPv6 address, and find the corresponding VPN according to the value; and then offset the payload packet
  • the content of the message after being shifted by 4 bytes (payload is MPLS type) or 16 bytes (payload is IPv6 address type) is forwarded to the receiver in the corresponding VPN; it should be noted that because part of the content of the target message belongs to There is no need to forward the content to the recipient, so this part of the content needs to be brought up during use.
  • step 1201d branching to step 1201d, after passing through steps 1102d and 1103d, the processing method is the same as that of step 1201b.
  • two or more BFIRs may be deployed on the ingress node.
  • the deployed BFIRs will encapsulate and forward BIER traffic to the egress node BFER, and BFER needs to select one of them.
  • BFER needs to select one of them.
  • BFIR and the traffic from the BFIR is received and forwarded to the receiver, and the same multicast traffic forwarded by other BFIRs is discarded.
  • both BFIR1 and BFIR2 will be forwarded to BFER.
  • BFER only selects the traffic from BFIR1 to forward to the receiver, and repeats the traffic from BFIR2. throw away.
  • step 1301 includes:
  • the branch step 1301a is connected to the branch 1101a in the foregoing specific step 1101, and uses its IPv6 source address SA to perform BFIR judgment, and discards the unnecessary packets sent by the BFIR.
  • BFER1/BFER2 only processes and forwards packets from BFIR1 and discards packets from BFIR2; that is, if SA is the address of BFIR1, it will be processed and forwarded to the receiver, and if SA is BFIR2 If BFIR1 fails and cannot forward the packet, BFER1/BFER2 learns the failure of BFIR1 through detection or other means, and the receiving direction of the traffic is switched to accept and forward the traffic whose SA is the address of BFIR2.
  • the branch step 1301b is followed by the branch 1101b in the step 1101.
  • the SD information is obtained, and then according to the obtained SD information, the starting position of the BIER message is offset by 10 bytes to read the 2-byte BFIR-ID value.
  • the message format of ⁇ SD, BFIR-ID> is used to determine the BFIR information for sending the message. If it comes from an unwanted BFIR, it will be discarded.
  • the way to obtain SD information can be (but not limited to) the following two ways:
  • the encoding method of BIFT-ID is ⁇ BSL, SD, SI> triple hard-coded, that is, the first 4 bits are BSL, the next 8 bits are SD, and the last 8 bits are SI.
  • the start of the offset is 4 bits, and the SD value of 8 bits is read;
  • BIFT-ID is in the form of OSPF/ISIS extended advertisement, query the local table entry according to the BIFT-ID to obtain the SD value.
  • the branch step 1301c is connected to the branch 1101c in the aforementioned step 1101, wherein the method and processing method for obtaining the SD are the same as the aforementioned branch step 1301b.
  • the branch step 1301d is connected to the branch 1101d in the aforementioned step 1101, and the method 2 in the aforementioned branch step 1301b is used to obtain the SD information, and the processing method for determining the BFIR information is the same as the aforementioned branch step 1301b.
  • the fixed BSL value can be obtained in the following ways without packet parsing.
  • BFIR When BFIR communicates with BFER through BIER Overlay technology, BFIR sends feedback information to BFER to inform BFER of the fixed BSL length used by BFIR, that is, BFIR will only use a certain fixed BSL length for BIER header encapsulation and feedback to BFER ; For example, BFIR is fixed at 128 bits, or fixed at 256 bits, etc.
  • the involved BIER Overlay technologies include (but are not limited to) MLD, PIM, MVPN, EVPN, etc.
  • the BFER is informed of the BSL length that the BFIR uses fixedly by the controller.
  • the specific method is as follows: the controller sends feedback information to the BFER to feed back to the BFER that the BFIR uses a fixed BSL for BIER header encapsulation.
  • the manner in which the controller sends the feedback includes (but is not limited to) BGP-LS, PCEP, NETCONF/RESTCONF plus YANG model and other manners.
  • a fixed BSL length is configured on the BFER, and the BSL length is all used when performing BIER header parsing.
  • the BSL value is not read in the packet header, but the fixed BSL length value determined in the above manner is directly used for calculation to obtain the start position of the BIER payload.
  • the payload processing method can also be fixed by a method similar to fixing the BSL value; among them, the relationship between BFER and BFIR
  • the BIER Overlay extension of the BFER and the message feedback between the BFER and the controller can also be adopted in a manner similar to that of the fixed BSL, so there is no need to obtain the payload type through the packet parsing in step 1103.
  • step 1103 when BFER performs payload processing, if it finds that there is no corresponding receiver locally, it means that there is a problem with the message delivery. At this time, BFER records the problem and informs BFIR in one of the following ways:
  • BFER sends feedback information through BIER Overlay technology to feed back to BFIR that BFER does not receive the multicast traffic;
  • BFER sends feedback information to the controller through BGP-LS, PCEP, NETCONF/RESTCONF plus YANG model, etc., and the controller sends an instruction to BFIR to stop sending the multicast traffic to the BFER with the BFIR instruction; and after the BFIR learns the instruction , the multicast traffic is no longer sent to BFER.
  • BFER2 finds that there is no local receiver for a multicast traffic when forwarding a BIER packet, then BFER2 records the problem after discarding the packet, and sends it to BFIR through BIER Overlay technology information, or send the information to BFIR through the controller to let BFIR know the information, so that when BFIR encapsulates the multicast traffic, it will delete the BFER2 node in the Bit-String of the encapsulated BIER header. The effect of sending this packet to BFER2.
  • the BFIR node or the controller can be informed, so that the BFIR or the controller can know the information.
  • a new type is defined in the Node Attribute TLV to indicate incomplete BIER technical support.
  • Adding a sub-TLV to the BIER Information TLV in the Prefix Attribute TLV indicates incomplete BIER technical support, where the BIER Information TLV is defined in draft-ietf-bier-bgp-ls-bier-ext.
  • the PCEP node capability extension method or the NETCONF/RESTCONF plus YANG model method can also be used.
  • the controller can know the technical support of the BIER by the BFER, so that the BFER node will not be planned as a BFIR, so as to avoid problems caused by the lack of the BIER forwarding capability.
  • BFER can notify the BFIR node of BFER as incomplete BIER technical support through BIER Overlay/Underlay technology extension, or notify BFIR node of BFER as incomplete BIER technical support through the controller, and the specific optional notification methods are as follows:
  • BFER notifies the BFIR node to implement by adding an extended BIER capability TLV through protocols such as MLD/PIM/BGP, which carries incomplete BIER technical support capabilities;
  • BFER is in the BIER-info TLV/sub-TLV extended by routing protocols such as Underlay's OSPF/ISIS (defined in RFC8401/RFC8444), adding a BIER capability extension sub-TLV, or directly using the BIER-info TLV/sub-TLV A bit of the reserved field to indicate incomplete BIER technical support. Because the Underlay information is received by all devices in the BIER domain, including BFIR, BFIR queries the information advertised by BFER to learn the incomplete BIER technical support of the BFER node.
  • routing protocols such as Underlay's OSPF/ISIS (defined in RFC8401/RFC8444), adding a BIER capability extension sub-TLV, or directly using the BIER-info TLV/sub-TLV A bit of the reserved field to indicate incomplete BIER technical support. Because the Underlay information is received by all devices in the BIER domain, including BFIR, BFIR queries the information advertised by BFER to learn the incomplete BIER technical support of the BFER node.
  • the controller informs BFIR through BGP-LS, PCEP, NETCONF/RESTCONF plus YANG model, etc., and the content of the notification is sub-TLV or sub-sub-TLV that does not fully support the capability.
  • BFIR can learn the BFER situation that cannot fully support the BIER technology. By default, no special treatment is given to the BFER, but it can be finely controlled through policies. If only one BFER needs to be received for a certain multicast traffic, and the BFER cannot If BIER technology is fully supported, BFIR can omit the operation of encapsulating the BIER header, and directly use IPinIP or other tunnel encapsulation forms to send packets to BFER.
  • level 1 means that only fixed BSL and fixed payload type processing is supported, and level 2 means that fixed payload processing is supported but BSL read processing is supported.
  • level 3 means supporting BSL reading and payload type reading processing, etc.; or level 1 means supporting BSL reading processing, level 2 means supporting BSL and SD reading processing, level 3 means supporting BSL, SD and BFIR-ID reading processing etc.
  • 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 one of the above method embodiments when running.
  • the above-mentioned computer-readable storage medium may include, but is not limited to, a USB flash drive, a read-only memory (Read-Only Memory, referred to as ROM for short), and a random access memory (Random Access Memory, referred to as RAM for short) , mobile hard disk, magnetic disk or CD-ROM and other media that can store computer programs.
  • ROM Read-Only Memory
  • RAM Random Access Memory
  • 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)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本公开实施例提供了一种报文处理方法、装置、存储介质及电子装置，其中，该方法包括：接收来自入口节点的目标报文；确定目标报文中包含的载荷的类型以及载荷的起始位置；基于载荷的类型以及载荷的起始位置，对目标报文执行载荷解析操作，以得到载荷的载荷数据；将载荷数据转发至接收端。

Description

一种报文处理方法、装置、存储介质及电子装置
相关申请的交叉引用
本公开基于2021年4月21日提交的发明名称为“一种报文处理方法、装置、存储介质及电子装置”的中国专利申请CN202110432551.5，并且要求该专利申请的优先权，通过引用将其所公开的内容全部并入本公开。
技术领域
本公开实施例涉及通信领域，具体而言，涉及一种报文处理方法、装置、存储介质及电子装置。
背景技术
BIER(Bit Indexed Explicit Replication，位索引显式复制)(RFC8279)是一种新型组播数据转发技术，该将网络边缘的节点都只用一个bit位来表示，组播流量在中间网络传输，额外封装一个特定的BIER头，这个报文头以bit位串的形式标注了该组播流的所有目的节点BFER(Bit-Forwarding Egress Router，位转发出口路由器)，中间网络转发节点根据bit位进行路由，保障流量能够发送到所有目的节点。
其中，组播技术是指源主机只发送一份数据，数据的目的地址是组播组地址，从而使得凡属于该组的成员设备，均可收到一份源主机发送的数据的拷贝，而BIER域的入口节点BFIR(Bit-Forwarding Ingress Router，位转发入口路由器)将进入BIER域的组播流量作为BIER头的payload(载荷)进行封装，通过中间节点的转发后，BIER域的出口节点BFER收到BIER报文，剥除BIER头后，将Payload转发给相应的接收者。
在正常情况下，BIER域内的所有节点都能够对BIER报文进行封装与转发处理，或者在网络中的设备均能升级支持完整BIER技术的情况下，BIER技术也可以进行顺利的部署。
但实际网络中的设备不可能在同一时间升级，尤其连接接收者的出口节点数量众多、性能差异巨大，有的出口节点性能较高，可以很容易的升级支持完整BIER技术，但对于一些性能较差的出口设备，升级支持完整的BIER技术非常困难，极大的影响了BIER的正常运行。
发明内容
本公开实施例提供了一种报文处理方法及装置，以至少解决相关技术中存在的网络节点不能支持完整的BIER技术的情况下导致的报文转发不能正常转发的问题。
根据本公开的一个实施例，提供了一种报文处理方法，包括：
接收来自入口节点的目标报文；
确定所述目标报文中包含的载荷的类型以及所述载荷的起始位置；
基于所述载荷的类型以及所述载荷的起始位置，对所述目标报文执行载荷解析操作，以得到所述载荷的载荷数据；
将所述载荷数据转发至接收端。
在一个示例性实施例中，确定所述目标报文中包含的载荷的类型以及所述载荷的起始位置包括：
基于所述目标报文的类型确定所述目标报文的起始位置；
基于所述目标报文的起始位置确定所述载荷的类型以及所述载荷的起始位置。
在一个示例性实施例中，所述基于所述起始位置确定所述载荷的起始位置包括：
在确定所述目标报文为第一类型报文的情况下，跳过所述目标报文的报文头，以确定所述载荷的起始位置；
在确定所述目标报文为除所述第一类型报文之外的其他类型报文的情况下，获取所述目标报文的第一信息值，其中，所述第一信息值用于指示第一信息的长度；基于所述第一信息值确定所述载荷的起始位置。
在一个示例性实施例中，所述基于所述目标报文的起始位置确定所述载荷的类型包括：
在确定所述目标报文为第一类型报文的情况下，基于所述目标报文的起始位置确定所述目标报文中包含的目标头字段，基于所述目标头字段确定所述载荷的类型；
在确定所述目标报文为除所述第一类型报文之外的其他类型报文的情况下，基于所述目标报文的起始位置，对所述目标报文执行第二偏移计算，以得到所述目标报文的属性值；基于所述属性值确定所述载荷的类型。
在一个示例性实施例中，在接收来自入口节点的目标报文之后，所述方法还包括：在确定所述目标报文为第一类型报文的情况下，基于所述目标报文包含的源地址执行第一定位操作，以得到第一定位结果；将所述载荷数据转发至接收端包括：在基于所述第一定位结果定位到目标节点的情况下，将所述载荷数据发送至所述目标节点，以指示所述目标节点将所述载荷数据发送至所述接收端；
或者，
在接收来自入口节点的目标报文之后，所述方法还包括：在确定所述目标报文为除所述第一类型报文之外的其他类型报文的情况下，根据所述载荷的类型查找所述目标节点；将所述载荷数据转发至接收端包括：在确定查找到所述目标节点的情况下，对所述载荷执行第三偏移操作，以得到目标载荷数据；将所述目标载荷数据发送至所述目标节点，以指示所述目标节点将所述载荷数据发送至所述接收端。
在一个示例性实施例中，在确定所述目标报文中包含的载荷的类型以及所述载荷的起始位置之前，所述方法还包括：
在确定所述目标报文为第一类型报文的情况下，基于所述目标报文包含的源地址判断所述入口节点是否为与本地存储的第一入口节点标识对应的第一入口节点；
在确定所述目标报文为除所述第一类型报文之外的其他类型报文的情况下，获取所述目标报文中包括的第二信息，基于所述第二信息以及所述目标报文的起始位置，对所述目标报文执行第四偏移计算，以确定所述第一入口节点的节点标识值；基于所述节点标识值以及所述第二信息判断所述入口节点是否为与本地存储的第一入口节点标识对应的第一入口节点；
确定所述目标报文中包含的载荷的类型以及所述载荷的起始位置包括：在确定所述入口节点为与本地存储的第一入口节点标识对应的所述第一入口节点的情况下，确定所述目标报文中包含的载荷的类型以及所述载荷的起始位置。
在一个示例性实施例中，所述获取所述目标报文的第一信息值包括以下至少之一：
接收来自所述入口节点的所述第一信息值；
接收来自控制器的所述第一信息值；
获取预先设置的第一信息值。
在一个示例性实施例中，在基于所述载荷的类型以及所述载荷的起始位置，对所述目标报文执行载荷解析操作，以得到所述载荷的载荷数据之后，所述方法还包括：
在确定不存在用于接收所述载荷数据的所述接收端的情况下，执行以下操作至少之一：
向所述入口节点发送第一反馈，其中，所述第一反馈用于指示拒绝接收待发送至所述接收端的报文；
向控制器发送第二反馈，以指示所述控制器向所述入口节点发送第三反馈，其中，所述第三反馈用于指示拒绝接收待发送至所述接收端的报文。
在一个示例性实施例中，所述方法还包括：
向所述入口节点或控制器发送第四反馈，其中，所述第四反馈用于指示以下信息至少之一：出口节点为不支持预定技术的节点，出口节点支持预定技术的能力级别。
根据本公开的另一个实施例，提供了一种报文处理装置，包括：
接收模块，设置为接收来自入口节点的目标报文；
确定模块，设置为确定所述目标报文中包含的载荷的类型以及所述载荷的起始位置；
解析模块，设置为基于所述载荷的类型以及所述载荷的起始位置，对所述目标报文执行载荷解析操作，以得到所述载荷的载荷数据；
发送模块，设置为将所述载荷数据转发至接收端。
根据本公开的又一个实施例，还提供了一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机程序，其中，所述计算机程序被设置为运行时执行上述任一项方法实施例中的步骤。
根据本公开的又一个实施例，还提供了一种电子装置，包括存储器和处理器，所述存储器中存储有计算机程序，所述处理器被设置为运行所述计算机程序以执行上述任一项方法实施例中的步骤。
附图说明
图1是根据本公开实施例的一种报文处理方法的移动终端的硬件结构框图；
图2是根据本公开实施例的一种报文处理方法的流程图；
图3是根据本公开实施例的报文头封装的格式图一；
图4是根据本公开实施例的报文头封装的格式图二；
图5是根据本公开实施例的报文头封装的格式图三；
图6是根据本公开实施例的报文头封装的格式图四；
图7是根据本公开实施例的一种报文处理方法的节点图一；
图8是根据本公开实施例的一种报文处理方法的节点图二；
图9是根据本公开实施例的一种报文处理装置的结构框图；
图10是根据本公开具体实施例的一种报文处理方法的流程总图；
图11是根据本公开具体实施例的报文头格式图；
图12是根据本公开具体实施例的TLV结构示意图；
图13是根据本公开具体实施例一的流程图；
图14是根据本公开具体实施例二的节点图。
具体实施方式
下文中将参考附图并结合实施例来详细说明本公开的实施例。
需要说明的是，本公开的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。
如图8所示，假设BIER网络里有很多网络出口节点，从BFER1，BFER2直到BFERn；
假设BFER1和BFER2不能支持完整的BIER技术，则根据draft-ietf-bier-php，BFER1/BFER2在软件层面升级，但硬件层面则不进行升级。
对于BFER1和BFER2的次末跳设备BFRm，则需要记录BFER1和BFER2的特殊情况，以及发送给BFER1/BFER2的特殊封装方式，并在收到BIER报文且需要转发给BFER1和BFER2时，BFRm除了正常的BIER报文复制转发处理给其他节点，(比如可能的BFER3/BFER4或者BFRn之外)，在发给BFER1/BFER2之前，需要将BIER头剥除，将其payload根据BFER1/BFER2所通告的隧道方式进行封装后，再发给BFER1/BFER2节点。
随后BFER1/BFER2剥除隧道封装后，再找到对应的接收者并转发出去。
在这个过程中，因为部分出口节点BFER无法完整支持BIER技术，其上游设备，即前述的次末跳设备BFRm必须根据BFER1/BFER2的OSPF/ISIS等协议通告，记录其不支持BIER技术的状态，并记录其需要的隧道封装形式，并且在转发BIER报文时，为这样的BFER节点单独进行封装操作。
由此可见在不支持完整BIER技术的BFER节点非常多的情况下，该技术对BFER的上游节点，即次末跳节点，有很高的技术与性能要求，对其处理流程、转发流程都有很大的影响，因此并非该场景的最优选方案。
本申请实施例中所提供的方法实施例可以在移动终端、计算机终端或者类似的运算装置中执行。以运行在移动终端上为例，图1是本公开实施例的一种报文处理方法的移动终端的硬件结构框图。如图1所示，移动终端可以包括一个或多个(图1中仅示出一个)处理器102(处理器102可以包括但不限于微处理器MCU或可编程逻辑器件FPGA等的处理装置)和设置为存储数据的存储器104，其中，上述移动终端还可以包括设置为通信功能的传输设备106以及输入输出设备108。本领域普通技术人员可以理解，图1所示的结构仅为示意，其并不对上述移动终端的结构造成限定。例如，移动终端还可包括比图1中所示更多或者更少的组件，或者具有与图1所示不同的配置。
存储器104可设置为存储计算机程序，例如，应用软件的软件程序以及模块，如本公开实施例中的一种报文处理方法对应的计算机程序，处理器102通过运行存储在存储器104内的计算机程序，从而执行各种功能应用以及数据处理，即实现上述的方法。存储器104可包括高速随机存储器，还可包括非易失性存储器，如一个或者多个磁性存储装置、闪存、或者其他非易失性固态存储器。在一些实例中，存储器104可进一步包括相对于处理器102远程设置的存储器，这些远程存储器可以通过网络连接至移动终端。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。
传输装置106设置为经由一个网络接收或者发送数据。上述的网络具体实例可包括移动终端的通信供应商提供的无线网络。在一个实例中，传输装置106包括一个网络适配器(Network Interface Controller，简称为NIC)，其可通过基站与其他网络设备相连从而可与互联网进行通讯。在一个实例中，传输装置106可以为射频(Radio Frequency，简称为 RF)模块，其设置为通过无线方式与互联网进行通讯。
在本实施例中提供了一种报文处理方法，图2是根据本公开实施例的一种报文处理方法的流程图，如图2所示，该流程包括如下步骤：
步骤S202，接收来自入口节点的目标报文；
在本实施例中，目标报文可以(但不限于)是IPV6格式的报文，也可以是以太类型为0xAB37的报文，还可以是MPLS格式的报文或其它格式的报文；入口节点可以是实体的数据接口，也可以是数据转发过程中的虚拟节点，还可以是其它具有收发功能的单元或模块。
步骤S204，确定目标报文中包含的载荷的类型以及载荷的起始位置；
在本实施例中，载荷的类型以及载荷的起始位置可以(但不限于)是根据目标报文的报文头中包含的地址信息等数据来确定，也可以是跳过目标报文的报文头，直接根据目标报文头的起始位置进行确定。
例如，跳过报文头得到载荷的起始位置的方法可以是在目标报文类型为IPV6格式的情况下，剥除IPv6头及可能的扩展头，得到BIER报文的payload开始位置，例如剔除DOH(Destination Options Header，目的选项头)等；也可以是根据目标报文的起始位置，确定BSL(BitStringLength，位串长度)信息，再根据BSL信息中的长度值L确定BIER报文的payload开始位置。
而获取载荷的类型的方式，可以是当目标报文类型为IPV6格式且包含目的地址DA(Destination Address)，目标报文的BIER头封装在IPv6的DOH(Destination Options Header，目的选项头)扩展头中时，此时，根据IPv6头DOH扩展头中的Next Header字段，获知payload的报文类型；其中，BIER头也可封装在HBH(Hop-by-Hop Header，逐跳选项头)，SRH(IPv6 Segment Routing Header，段路由扩展头)等其他扩展头中，且载荷类型的确定方式类似。
当目标报文类型为IPV6格式且包含的地址DA为本地地址时，则从BIER头的开始位置偏移74位，读取6位的Proto值，再根据该值确定payload报文的类型。
步骤S206，基于载荷的类型以及载荷的起始位置，对目标报文执行载荷解析操作，以得到载荷的载荷数据；
在本实施例中，获取的载荷数据包括(但不限于)载荷的转发目的节点地址、载荷的转发时间、载荷的转发频次等信息。
步骤S208，将载荷数据转发至接收端。
在本实施例中，载荷数据的转发可以是同时转发的，也可以是分批次转发的，还可以是其它类型的转发方式，对应的，接收端的数量可以是一个，也可以是多个，可以是多个接收端同时接收载荷数据，也可以是多个接收端分批次接收载荷数据，还可以是一个接收端同时接收多批次的载荷数据，或一个接收端分批次接收多批次的载荷数据。
以BIER为例，BIER域的入口节点BFIR将进入BIER域的组播流量作为BIER头的payload(载荷)进行封装，通过中间节点的转发后，BIER域的出口节点BFER收到BIER报文，剥除BIER头后，将Payload转发给相应的接收者。
通过上述步骤，可以直接基于载荷的类型和载荷的起始位置确定出载荷数据，进而实现载荷的转发，从而达到在无需支持完整的BIER技术的情况下也能实现载荷数据的转发的目的，解决了网络节点不能支持完整的BIER技术的情况下导致的目标报文不能正常转发的问题，提 高了报文转发效率。
其中，上述步骤的执行主体可以为网络节点，但不限于此，其中，网络节点位于基站、终端等设备中。
在一个可选的实施例中，确定目标报文中包含的载荷的类型以及载荷的起始位置包括：
步骤S2062，基于目标报文的类型确定目标报文的起始位置；
步骤S2064，基于目标报文的起始位置确定载荷的类型以及载荷的起始位置。
在本实施例中，由于不同类型的目标报文中所包含的信息不同，因而需要设置不同的处理方式来处理对应的目标报文，以提高对报文的解析的精确度，保证后续的信息能够被准确转发至接收端。
例如，在目标报文为IPv6格式的情况下，可以通过其包含的目的地址或对应的Next Header字段确定目标报文的起始位置；在目标报文为以太类型为0xAB37的报文，则可以通过其包含的类型值来确定目标报文的起始位置；在目标报文为MPLS报文的情况下，可以通过目标报文包含的标签值来确定目标报文的起始位置；在目标报文为其它类型的报文的情况下，可以通过其它方式来确定目标报文的起始位置。
在一个可选的实施例中，基于目标报文的类型确定目标报文的起始位置包括：
步骤S20642，基于目标报文的类型确定目标报文中包括的用于确定目标报文的起始位置的目标信息；
步骤S20644，基于目标信息确定目标报文的起始位置。
在本实施例中，目标信息包括(但不限于)是目的地址DA、NextHeader字段、类型值以及标签值等。
在一个可选的实施例中，基于目标报文的起始位置确定载荷的起始位置包括：
步骤S2042，在确定目标报文为第一类型报文的情况下，跳过目标报文的报文头，以确定载荷的起始位置；
步骤S2044，在确定目标报文为除第一类型报文之外的其他类型报文的情况下，获取目标报文的第一信息值，其中，第一信息值用于指示第一信息的长度；基于第一信息值确定载荷的起始位置。
在本实施例中，第一类型报文可以是IPV6格式的报文，也可以是其它类型的报文；第一信息可以是目标报文中包含的BSL信息，对应的，第一信息值可以是BSL信息的L值。
例如，在目标报文为IPv6报文情况下，且封装如图3所示的情况下，其目的地址DA是为BIER分配的特定保留地址，此时可以通过对该地址进行识别操作即可确定BIER报文。
而在DA是本地接口地址情况下，且封装如图4所示的情况下，则读取IPv6报文中包含的NextHeader字段的字段值，在读取到该字段值指示为BIER类型的情况下，则通过该字段值进行识别操作，以确定BIER报文，并据此获得BIER头的开始位置。
而在目标报文为以太类型为0xAB37的报文，且封装如图5所示的情况下，则根据该类型报文中包含的类型值确定BIER报文，并据此获得BIER头的开始位置。
在目标报文为MPLS报文，且封装类似图6所示的情况下，则根据目标报文的前4字节所指示的标签值来对本地表项进行匹配查找，在命中的表项指示信息为BIER类型的情况下，确定BIER报文，此时该标签的起始位置即为BIER头的开始位置。
在一个可选的实施例中，获取目标报文的第一信息值包括以下至少之一：
基于目标报文的起始位置，对目标报文执行第一偏移计算，以得到目标报文包含的第一信息；基于第一信息执行第一匹配处理，以得到第一信息值；
基于目标报文的起始位置，对目标报文执行第一读取处理，以得到第一信息；基于第一信息执行第二匹配处理，以得到第一信息值。
在本实施例中，获取第一信息的方式可以根据需求或使用环境来进行不同的选择，从而适应多种使用情况。
例如，第一偏移计算可以(但不限于)是从BIER头开始的位置偏移40位，读取4位的BSL值，再根据该值找到对应的BSL长度值L；同理，第一读取处理可以(但不限于)是如果在BIFT(Bit Index Forwarding Table，位索引转发表)-ID的编码方式为<BSL，SD，SI>(SD：Sub-Domain，子域；SI：Set Identifier，集标识)三元组硬编码的情况下，其编码形式可以是前4位是BSL，紧接着8位是SD，最后8位是SI的方式硬编码，此时从BIER报文的开始位置读取4位即可确定BSL值，再根据该BSL值找到对应的BSL长度值L。
在一个可选的实施例中，基于目标报文的起始位置确定载荷的类型包括：
步骤S20646，在确定目标报文为第一类型报文的情况下，基于目标报文的起始位置确定目标报文中包含的目标头字段，基于目标头字段确定载荷的类型；
步骤S20648，在确定目标报文为除第一类型报文之外的其他类型报文的情况下，基于目标报文的起始位置，对目标报文执行第二偏移计算，以得到目标报文的属性值；基于属性值确定载荷的类型。
在本实施例中，目标头字段可以(但不限于)是IPv6的DOH扩展头中的Next Header字段，也可以是HBH扩展头中的Next Header字段或其它字段、SRH扩展头等其他扩展头中的Next Header字段或其他字段；属性值可以是报文头的Proto值，相应的第二偏移计算可以是从BIER头的开始位置偏移74位，以读取6位的Proto值。
在一个可选的实施例中，
在接收来自入口节点的目标报文之后，该方法还包括：
步骤S2022，在确定目标报文为第一类型报文的情况下，基于目标报文包含的源地址执行第一定位操作，以得到第一定位结果；
将载荷数据转发至接收端包括：
步骤S2082，在基于第一定位结果定位到目标节点的情况下，将载荷数据发送至目标节点，以指示目标节点将载荷数据发送至接收端。
在一个可选的实施例中，
在接收来自入口节点的目标报文之后，该方法还包括：
步骤S2024，在确定目标报文为除第一类型报文之外的其他类型报文的情况下，根据载荷的类型查找目标节点；
将载荷数据转发至接收端包括：
步骤S2084，在确定查找到目标节点的情况下，对载荷执行第三偏移操作，以得到目标载荷数据；将目标载荷数据发送至目标节点，以指示目标节点将载荷数据发送至接收端。
在本实施例中，在特殊业务的情况下，由于特殊业务的需求，需要对业务类型进行确认才能进行后续的数据转发。
其中，源地址可以是IPv6报文中的源地址SA(Source Address)，也可以是其它类型的 源地址。
例如，在进入BIER域的组播流量是基于MVPN(Multicast Virtual Private Network，组播虚拟专用网)，或者EVPN(Ethernet Virtual Private Network，以太虚拟专用网)等业务的情况下，因为边缘节点BFIR和BFER上会有多个MVPN或者EVPN实例，因此BFER在收到报文时，需要定位到具体的MVPN/EVPN实例才能进一步转发给接收者。
具体的，在使用IPv6的源地址SA进行业务实例定位后，需要确定是否可以定位到具体的业务，在确定了具体的业务之后(如VPN1)，再将确定的payload报文在相应的VPN(Virtual Private Network，虚拟专用网)中转发给接收者；对应的，在确定payload类型为MPLS或者IPv6地址等类型的情况下，读取payload的标签值或者IPv6地址，再根据取payload的标签值或者IPv6地址查找到对应的VPN；然后再将payload报文偏移4字节(payload是MPLS类型)或者16字节(payload是IPv6地址类型)后的报文内容，转发给对应VPN中的接收者；需要说明的是，因为目标报文中有一部分内容属于无需转发给接收者的内容，因而在使用过程中需要提出这部分的内容。
在一个可选的实施例中，
在确定目标报文中包含的载荷的类型以及载荷的起始位置之前，该方法还包括：
步骤S20402，在确定目标报文为第一类型报文的情况下，基于目标报文包含的源地址判断入口节点是否为与本地存储的第一入口节点标识对应的第一入口节点；
步骤S20404，在确定目标报文为除第一类型报文之外的其他类型报文的情况下，获取目标报文中包括的第二信息，基于第二信息以及目标报文的起始位置，对目标报文执行第四偏移计算，以确定第一入口节点的节点标识值；基于节点标识值以及第二信息判断入口节点是否为与本地存储的第一入口节点标识对应的第一入口节点；
确定目标报文中包含的载荷的类型以及载荷的起始位置包括：
步骤S2046，在确定入口节点为与本地存储的第一入口节点标识对应的第一入口节点的情况下，确定目标报文中包含的载荷的类型以及载荷的起始位置。
在本实施例中，第二信息可以是SD(Sub-Domain，子域)信息，也可以是其它信息。
为了提高部署的可靠性，对于同样的组播流，其入口节点BFIR可能有两个或者两个以上，此时两个入口节点BFIR都会封装和转发BIER流量到出口节点BFER上，此时，出口节点BFER需要选择一台BFIR的流量接收和转发给接收者，而对于其他BFIR转发过来的同样的组播流量则进行丢弃。
例如，在目标报文为IPv6的情况下，通过源地址SA来进行入口节点BFIR判断，即SA(Source Address，源地址)如果是BFIR1的地址，则进行处理并转发给接收者。
在一个可选的实施例中，该方法还包括：
步骤S20406，在确定入口节点为除第一入口节点之外的其他节点的情况下，丢弃目标报文。
在本实施例中，对于不需要的入口节点BFIR发来的报文，则直接丢弃。如图7所示，正常情况下，BFER1/BFER2只处理转发来自BFIR1的报文，丢弃来自BFIR2的报文；即，SA如果是BFIR2的地址，则直接丢弃该报文。
在一个可选的实施例中，该方法还包括：
步骤S20408，对目标入口节点执行故障检测处理；
步骤S204010，在确定目标入口节点处于故障状态的情况下，将本地存储的第一入口节点标识更新为第二入口节点标识，其中，第二入口节点标识用于标识除第一入口节点以外的其他入口节点。
在本实施例中，当BFIR1出现故障无法转发报文，BFER1/BFER2通过检测或者其他手段获知BFIR1的故障后，切换为接收和转发SA为BFIR2地址的流量。
在一个可选的实施例中，获取目标报文中包括的第二信息包括以下至少之一：
基于目标报文的起始位置，对目标报文执行第五偏移计算，以得到第二信息；
根据目标报文中包括的位索引表，对本地表项执行第三匹配处理，以得到第二信息。
在本实施例中，通过不同方式获取第二信息是为了适应不同的使用背景和使用方式，从而适应不同的使用环境。
例如，在BIFT(Bit Index Forwarding Table，位索引转发表)-ID的编码方式是<BSL，SD，SI>三元组硬编码的情况下，即采用前4位是BSL，紧接着8位是SD，最后8位是SI的方式进行硬编码的情况下，则从BIER报文的开始偏移4位，读取8位的SD值；而在BIFT-ID是采用OSPF/ISIS扩展通告的方式的情况下，则根据BIFT-ID查询本地表项，获取SD值。
具体的，在获取SD信息后，从BIER报文开始位置偏移10字节，读取2字节的BFIR-ID值，用<SD，BFIR-ID>来确定发送该报文的BFIR信息，如果来自不需要的BFIR，则丢弃；如图7所示，假设SD为0，BFIR1的BFIR-ID为10，BFIR2的BFIR-ID为20，则来自于<SD＝0，BFIR-ID＝10>的流量被接受并转发给接收者，来自于<SD＝0，BFIR-ID＝20>的流量则被丢弃；此时当BFIR1出现故障无法转发报文，BFER1/BFER2通过检测或者其他手段获知BFIR1的故障后，切换为接受和转发来自<SD＝0，BFIR-ID＝20>的流量。
在一个可选的实施例中，获取目标报文的第一信息值包括以下至少之一：
接收来自入口节点的第一信息值；
接收来自控制器的第一信息值；
获取预先设置的第一信息值。
在本实施例中，固定BSL值是为了减少报文解析过程所涉及的计算量，从而进一步简化BFER上的操作。
例如，BFIR在与BFER通过BIER Overlay技术进行通告时，BFIR通知BFER其固定使用的BSL长度，即BFIR对BIER头进行封装时采用固定的BSL长度，比如128位，或者256位等，此时，涉及到的BIER Overlay技术包括但不限于MLD(Multicast Listener Discovery)、PIM(Protocol Independent Multicast)、MVPN、EVPN等。
或者，采用控制器下发的方式，控制器通知BFIR固定采用某个固定BSL进行BIER头封装。控制器通知的方式包括但不限于BGP-LS、PCEP、NETCONF/RESTCONF加YANG模型等方式。
或者，在BFER上配置固定的BSL长度，对BIER头解析时全部采用该BSL长度。
同样对于payload处理，如果只部署一种业务，比如通过BIER域传输的只有IPv4组播流量业务。则也可以通过类似固定BSL值的方法固定payload处理方式，BFER与BFIR之间的BIER Overlay扩展，以及BFER与控制器之间的通告，也可以采用与固定BSL类似的方式。
在一个可选的实施例中，在基于载荷的类型以及载荷的起始位置，对目标报文执行载荷解析操作，以得到载荷的载荷数据之后，该方法还包括：
在确定不存在用于接收载荷数据的接收端的情况下，执行以下操作至少之一：
向入口节点发送第一反馈，其中，第一反馈用于指示拒绝接收待发送至接收端的报文；
向控制器发送第二反馈，以指示控制器向入口节点发送第三反馈，其中，第三反馈用于指示拒绝接收待发送至接收端的报文。
在本实施例中，在不存在接收端的情况下向反馈指示能够避免入口节点持续发送数据导致的数据冗余以及能量浪费。
例如，BFER进行payload处理时，如果发现本地没有相应的接收者，则说明报文传递有问题，此时BFER记录该问题，并通过以下方式之一告知BFIR：
方式1：
BFER通过BIER Overlay技术进行通告，通知BFIR其不接收该组播流量；
方式2：
BFER通过BGP-LS(Border Gateway Protocol-Link State，边界网关协议-链路状态)、PCEP、NETCONF/RESTCONF加YANG模型等方式告知控制器，控制器再通知BFIR不再发送该组播流量给该BFER；
BFIR获知该信息后，则不再发送该组播流量给BFER。
如图8所示，假设BFER2在处理转发BIER报文时，发现对于某组播流量，本地没有接收者，则BFER2在丢弃该报文之后，记录这个问题，并通过BIER Overlay技术或者控制器使BFIR获知该信息，BFIR在后续对该组播流量进行封装时，将在封装的BIER头目的Bit-String中删除BFER2节点，从而该报文将不会再发送到BFER2。
在一个可选的实施例中，该方法还包括：
步骤S2010，向入口节点或控制器发送第四反馈，其中，第四反馈用于指示以下信息至少之一：
出口节点为不支持预定技术的节点，出口节点支持预定技术的能力级别。
在本实施例中，向入口节点或控制器发送第四反馈以避免入口节点或控制器反复发送流量信息。
例如，BFER不能支持完整BIER技术时，可以通过向BFIR节点或者控制器发送反馈信息，使BFIR或控制器确定对应的BFER处于不能支持完整BIER技术的状态。
其中，BFER通知控制器时，可以通过BGP-LS协议扩展上报给控制器或者BFIR，上报方式包括(但不限于)：
方式1：在Node Attribute TLV(RFC7752定义)的Node Flag Bits中选择未使用的一位来表示非完整BIER技术支持。
方式2：在Node Attribute TLV中新定义一个类型表示非完整BIER技术支持。
方式3：在Prefix Attribute TLV中的BIER Information TLV中增加一个子TLV表示非完整BIER技术支持，其中，BIER Information TLV为draft-ietf-bier-bgp-ls-bier-ext中的定义。
当然，还可以采用其他形式的BGP-LS协议扩展，本公开不做限制。
例如，如果不使用BGP-LS协议扩展，还可以使用PCEP节点能力扩展等方式，或者NETCONF/RESTCONF加YANG模型的方式。
在一个可选的实施例中，在向入口节点或控制器发送第四反馈之前，该方法还包括：
步骤S20102，在目标协议信息中增加用于指示出口节点为不支持预定技术的节点的标识， 以得到第四反馈。
在本实施例中，通过对不支持预定技术的节点的标识进行识别，能够快速确定出口节点的状态，从而避免能量损耗和数据冗余。
其中，在目标协议信息中增加用于指示出口节点为不支持预定技术的节点的标识可以通过以下方式实现：
例如，
方式1：在部署MVPN/EVPN业务时，可以通过PMSI(Proyider Multicast Service Interface)Tunnel Attribute(PTA)中新增隧道类型为非完整BIER技术支持来实现；
方式2：BFER通知BFIR节点通过MLD/PIM/BGP等协议新增扩展BIER能力TLV的方式来实现，其中携带非完整BIER技术支持能力；
方式3：BFER在Underlay的OSPF/ISIS等路由协议扩展的BIER-info TLV/sub-TLV中(定义在RFC8401/RFC8444中)，新增BIER能力扩展子TLV，或者直接利用BIER-info TLV/sub-TLV中的预留字段的某位来表示非完整BIER技术支持。因为Underlay信息整个BIER域内的设备都会收到，包括BFIR，因此BFIR查询BFER所通告的该信息获知BFER节点的非完整BIER技术支持情况。
方式4：BFER将其能力上报控制器后，控制器再通过BGP-LS，PCEP(Path Computation Element Communication Protocol，路径计算通信协议)，NETCONF/RESTCONF加YANG模型等方式告知BFIR，告知内容为非完整支持能力sub-TLV或者sub-sub-TLV等。
BFIR通过上述方式可以获知不能完整支持BIER技术的BFER情况，同时在默认情况下不对该BFER做特殊处理，但可以通过策略进行精细化控制，假如对于某条组播流量只有一个BFER需要接收，且该BFER不能完整支持BIER技术，则BFIR可以略掉封装BIER头的操作，直接采用IPinIP或者其它的隧道封装形式就能将报文发送到BFER。
需要说明的是，在前述的非完整BIER技术能力通告中，还可以进一步的细化，以表示不同的非完整BIER技术能力支持情况：
例如，可以将非完整BIER技术能力进行分级，不同的级别表示不同的BIER技术支持能力，比如采用级别1表示仅支持固定BSL和固定payload类型处理，级别2表示支持固定payload处理但可支持BSL读取处理，级别3表示支持BSL读取及payload类型读取处理等；或者级别1表示支持BSL读取处理，级别2表示支持BSL和SD读取处理，级别3表示支持BSL、SD和BFIR-ID读取处理等。
还可以在上述的BGP-LS/PCEP/YANG模型等扩展中增加sub-TLV或者其他扩展，并携带具体的级别信息，这样可以让控制器或者BFIR节点获得更精确的BFER对BIER技术的支持情况，从而可以于策略结合，更好的适应不同BIER组网部署需求。比如BFIR获知BFER节点仅支持固定BSL处理，则BFIR将仅用该BSL进行BIER头封装，以便BFER处理。
通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到根据上述实施例的方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本公开的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，或者网络设备等)执行本公开各个实施例所述的方法。
在本实施例中还提供了一种报文处理装置，该装置用于实现上述实施例及优选实施方式，已经进行过说明的不再赘述。如以下所使用的，术语“模块”可以实现预定功能的软件和/或硬件的组合。尽管以下实施例所描述的装置较佳地以软件来实现，但是硬件，或者软件和硬件的组合的实现也是可能并被构想的。
图9是根据本公开实施例的一种报文处理装置的结构框图，如图9所示，该装置包括：
接收模块92，设置为接收来自入口节点的目标报文；
确定模块94，设置为确定目标报文中包含的载荷的类型以及载荷的起始位置；
解析模块96，设置为基于载荷的类型以及载荷的起始位置，对目标报文执行载荷解析操作，以得到载荷的载荷数据；
发送模块98，设置为将载荷数据转发至接收端。
在一个可选的实施例中，解析模块96包括：
位置确定单元962，设置为基于目标报文的类型确定目标报文的起始位置；
信息确定单元964，设置为基于目标报文的起始位置确定载荷的类型以及载荷的起始位置。
在一个可选的实施例中，信息确定单元964包括：
信息确定子单元9642，设置为基于目标报文的类型确定目标报文中包括的用于确定起始位置的目标信息；
第一位置确定子单元9644，设置为基于目标信息确定起始位置。
在一个可选的实施例中，确定模块94包括：
第一确定单元942，设置为在确定目标报文为第一类型报文的情况下，跳过目标报文的报文头，以确定载荷的起始位置；
第二确定单元944，设置为在确定目标报文为除所述第一类型报文之外的其他类型报文的情况下，获取标报文的第一信息值，其中，第一信息值用于指示第一信息的长度；基于第一信息值确定载荷的起始位置。
在一个可选的实施例中，第二确定单元844包括：
第一计算子单元9442，设置为基于所述目标报文的起始位置，对所述目标报文执行第一偏移计算，以得到所述目标报文包含的所述第一信息；基于所述第一信息执行第一匹配处理，以得到所述第一信息值；
第一读取子单元9444，设置为基于目标报文的起始位置，对目标报文执行第一读取处理，以得到第一信息；基于第一信息执行第二匹配处理，以得到第一信息值。
在一个可选的实施例中，信息确定单元964还包括：
第一确定子单元9646，设置为在确定目标报文为第一类型报文的情况下，基于目标报文的起始位置确定目标报文中包含的目标头字段，基于目标头字段确定载荷的类型；
第二确定子单元9648，设置为在确定目标报文为除第一类型报文之外的其他类型报文的情况下，基于目标报文的起始位置，对目标报文执行第二偏移计算，以得到目标报文的属性值；基于属性值确定所述载荷的类型。
在一个可选的实施例中，
该装置还包括：
定位单元922，设置为在接收来自入口节点的目标报文之后，在确定目标报文为第一类 型报文的情况下，基于目标报文包含的源地址执行第一定位操作，以得到第一定位结果；
发送模块98包括：
第一发送单元982，在基于第一定位结果定位到目标节点的情况下，将载荷数据发送至目标节点，以指示目标节点将载荷数据发送至接收端；
在一个可选的实施例中，
该装置还包括：
查找单元924，设置为在接收来自入口节点的目标报文之后，在确定目标报文为除第一类型报文之外的其他类型报文的情况下，根据载荷的类型查找目标节点；
发送模块98包括：
第二发送单元984，在确定查找到目标节点的情况下，对载荷执行第三偏移操作，以得到目标载荷数据；将目标载荷数据发送至目标节点，以指示目标节点将载荷数据发送至所述接收端。
在一个可选的实施例中，该装置还包括：
第一节点确定单元8402，设置为在确定目标报文中包含的载荷的类型以及载荷的起始位置之前，在确定目标报文为第一类型报文的情况下，基于目标报文包含的源地址判断入口节点是否为与本地存储的第一入口节点标识对应的第一入口节点；
第二节点确定单元8404，在确定目标报文为除所述第一类型报文之外的其他类型报文的情况下，获取目标报文中包括的第二信息，基于第二信息以及目标报文的起始位置，对目标报文执行第四偏移计算，以确定第一入口节点的节点标识值；基于节点标识值以及第二信息判断入口节点是否为与本地存储的第一入口节点标识对应的第一入口节点；
确定模块94还包括：
确定子单元946，在确定入口节点为与本地存储的第一入口节点标识对应的第一入口节点的情况下，确定目标报文中包含的载荷的类型以及载荷的起始位置。
在一个可选的实施例中，该装置还包括：
报文丢弃单元9406，在确定入口节点为除第一入口节点之外的其他节点的情况下，丢弃目标报文。
在一个可选的实施例中，该装置还包括：
故障检测单元9408，对目标入口节点执行故障检测处理；
节点更新单元94010，在确定目标入口节点处于故障状态的情况下，将本地存储的第一入口节点标识更新为第二入口节点标识，其中，第二入口节点标识用于标识除第一入口节点以外的其他入口节点。
在一个可选的实施例中，第二节点确定单元3404包括以下至少之一：
偏移计算子单元94042，设置为基于目标报文的起始位置，对目标报文执行第五偏移计算，以得到第二信息；
表项匹配子单元94044，设置为根据目标报文中包括的位索引表，对本地表项执行第三匹配处理，以得到第二信息。
在一个可选的实施例中，第二确定单元944还包括以下至少之一：
第一接收子单元9446，设置为接收来自入口节点的第一信息值；
第二接收子单元9448，设置为接收来自控制器的所述第一信息值；
采集子单元94410，设置为获取预先设置的第一信息值。
在一个可选的实施例中，该装置还包括：
操作执行单元968，设置为在基于载荷的类型以及载荷的起始位置，对目标报文执行载荷解析操作，以得到载荷的载荷数据之后，在确定不存在用于接收载荷数据的接收端的情况下，执行以下操作至少之一：
向入口节点发送第一反馈，其中，第一反馈用于指示拒绝接收待发送至接收端的报文；
向控制器发送第二反馈，以指示控制器向入口节点发送第三反馈，其中，第三反馈用于指示拒绝接收待发送至接收端的报文。
在一个可选的实施例中，该装置还包括：
反馈模块910，设置为向入口节点或控制器发送第四反馈，其中，第四反馈用于指示以下信息至少之一：
出口节点为不支持预定技术的节点，出口节点支持预定技术的能力级别。
在一个可选的实施例中，反馈模块910还包括：
指示单元9102，设置为在向入口节点或控制器发送第四反馈之前，在目标协议信息中增加用于指示出口节点为不支持预定技术的节点的标识，以得到第四反馈。
需要说明的是，上述各个模块是可以通过软件或硬件来实现的，对于后者，可以通过以下方式实现，但不限于此：上述模块均位于同一处理器中；或者，上述各个模块以任意组合的形式分别位于不同的处理器中。
下面结合具体实施例对本公开进行说明。
如图8及图10所示，本公开实施例提供的报文处理方法主要包括如下步骤：
步骤S101，BFER收到报文(对应前述步骤S202)；
步骤S102，识别出是BIER报文后，跳过BIER头的处理，或者仅处理BIER头中字段(包括以下至少一种：BSL，BFIR-ID，SD，BIFT-ID)，以确定BIER报文的payload的类型和起始位置(对应前述步骤S204)；
步骤S103，再根据payload的报文类型以及起始位置，进行payload报文解析(对应前述步骤S206)；
步骤S104，再将解析结果正常转发给接收者R1/R2/R3(对应前述步骤S208)。
其中，如图7所示，在MVPN或者EVPN等业务部署时，BFER获取所需的关键业务实例信息；且在部署双根保护功能时，BFER需要根据特定字段丢弃重复流量；
而当BFER为非完整BIER技术支持能力时，BFER通过BGP-LS协议，或者PCEP(协议，或者NETCONF、RESTCONF等携带YANG模型或者数据的形式，向控制器可选通告其非完整BIER技术支持能力；或者BFER通过BIER Overlay协议，向BFIR节点可选通告其非完整BIER技术支持能力。
其中，BFIR通过BIER Overlay协议，可选通告BFER其封装的BSL长度，或者payload的封装方式，或者两者均通告。
其中，BIER Overlay技术包括但不限于MLD(Multicast Listener Discovery，组播侦听发现)、PIM(Protocol Independent Multicast，协议无关组播)、MVPN、EVPN等。
当BFER在某组播流量本地没有接收者时，BFER记录该问题，并通过BIER Overlay技术反馈给BFIR，或者BFER告知控制器，再由控制器告知BFIR，BFIR对该组播流量后续报文封 装BIER头时删除该BFER节点。
具体的实施例如下所示，需要说明的是，以下实施例中的BIER头格式均以RFC8296中定义的为准，如图11所示，且以下所提到的TLV(Type，Length，Value)格式类似如图12所示：
具体实施例一
如图8所示，在BFER1、BFER2不能完整支持BIER技术，但在BFER1、BFER2软件信令进行BIERUnderlay交互时，仍表现为正常BFER节点的情况下，即，在BFER1、BFER2与BFRm等节点进行OSPF(Open Shortest Path First，开放式最短路径优先)/ISIS(Intermediate System-to-Intermediate System，中间系统到中间系统)等协议信令交互时，仍然采用正常BFER节点的通告内容的情况下，BFRm不会认为BFER1、BFER2是特殊的节点，不会对二者进行特殊记录，在报文转发时也不会进行特殊操作；同时，BFER1和BFER2在与BFIR之间进行BIER Overlay交互时，也不需要特殊的通告内容，BFIR也会将BFER1和BFER2视为正常的BIER节点；BFIR对组播流量进行正常BIER封装并转发到BIER域内，由此BFER1和BFER2将收到正常的BIER报文；其中，组播流量可以是IPv4、IPv6或者Ethernet等类型流量。
如图13所示，上述情况中的BFER的报文处理步骤如下：
步骤S1101：识别BIER报文；
步骤S1102：跳过BIER头；
步骤S1103：获取BIER头的payload报文类型；
步骤S1104：基于payload报文类型进行payload报文解析，并将解析结果正常转发给接收者R1/R2/R3。
其中，步骤1101具体包括：
分支步骤1101a，如果收到的报文是IPv6报文，封装类似图3所示，其目的地址是为BIER分配的特定保留地址，通过该地址识别出BIER报文。
分支步骤1101b，如果收到的报文是IPv6报文，封装类似图4所示，其DA是本地接口地址，读取IPv6的Next Header字段，如果该字段值指示为BIER类型，则通过该字段值识别出BIER报文；并据此获得BIER头的开始位置。
分支步骤1101c，如果收到的是以太类型为0xAB37的报文，封装类似图5所示，则根据该类型值识别出BIER报文；并据此获得BIER头的开始位置。
分支步骤1101d，如果收到的是MPLS报文，封装类似图6所示，根据报文的前4字节标签值查本地表项，命中的表项指示信息为BIER类型，由此识别出BIER报文；该标签的起始位置即BIER头的开始位置。
步骤1102具体包括：
分支步骤1102a，接步骤1101中的分支步骤1101a，剥除IPv6头及可能的扩展头，如DOH等，得到BIER报文的payload开始位置。
分支1102b，接步骤1101中的分支1101b，首先获取BSL信息，获取方法有两种：
从BIER头开始的位置偏移40位，读取4位的BSL值，根据该值找到对应的BSL长度值L(其对应定义在RFC8296中)；
如果BIFT-ID的编码方式是<BSL，SD，SI>(SD：Sub-Domain，子域；SI：Set Identifier，集标识)三元组硬编码，即可能采用前4位是BSL，紧接着8位是SD，最后8位是SI的方式 硬编码，则从BIER报文的开始位置读取4位的BSL值，并根据该值找到对应的BSL长度值L。
通过以上方法获得BSL长度值L后，再根据BSL获得payload报文的开始位置：即从BIER头开始偏移(12+L/8)字节，获取到其payload报文的开始位置。比如4位的BSL值为3，可获知对应的BSL长度值为256，则通过计算可知从BIER头开始偏移(12+256/8)44字节可以获取到payload报文的开始位置。
分支步骤1102c，接步骤1101中的分支1101c，处理方式同1102b。
分支步骤1102d，接步骤1101中的分支1101d，处理方式有两种，第一种同1102b；第二种BSL的值获取则是由分支1101d中得到的标签值查询本地表项，获得BSL值；然后用1102b的同样计算方式获得payload报文的开始位置。
步骤1103具体包括：
分支步骤1103a，接步骤1101中的分支1101a，BIER头封装在IPv6的DOH扩展头中时，根据IPv6头DOH扩展头中的NextHeader字段，获知payload的报文类型；BIER头也可封装在HBH，SRH等其他扩展头中，处理方式类似。
分支步骤1103b，接步骤1101中的分支1101b，从BIER头的开始位置偏移74位，读取6位的Proto值，根据该值确定payload报文的类型。
分支步骤1103c，接步骤1101中的分支1101c，处理方式同1103b。
分支步骤1103d，接步骤1101中的分支1101d，处理方式同1103b。
通过以上步骤，BFER2/BFER3可以跳过BIER报文头中的Bit-String等复杂处理流程，获取到BIER的payload的报文类型以及起始位置，从而可以进行payload报文解析，并正常转发给接收者R1/R2/R3。
具体实施例二
进入BIER域的组播流量可能基于MVPN，或者EVPN等业务，因为边缘节点BFIR和BFER上会有多个MVPN或者EVPN实例，因此BFER在收到报文时，需要定位到具体的MVPN/EVPN实例才能进一步转发给接收者。如图7所示，进入BIER域的组播流量是MVPN/EVPN流量，并分属VPN1和VPN2，BFER收到报文时，需要区分出报文应该转发给VPN1还是VPN2。
需要说明的是，BIER这种数据面转发技术因为没有组播树的建立问题，消除了组播树建立的时延，并且在网络出现链路或者节点问题时，收敛速度同OSPF或ISIS协议，比原来的组播树重建降低了巨大的时延。
上述情况的具体实施步骤包括：
步骤1201：
分支步骤1201a，接步骤1101中的分支1101a，使用其IPv6源地址SA(Source Address)进行业务实例定位，看是否可定位到某个VPN，如VPN1；然后在通过步骤1102a、1103a后，将payload报文在相应的VPN如VPN1中转发给接收者。
分支步骤1201b，在通过步骤1102b和1103b后，根据payload报文是MPLS或者IPv6地址等类型，读取payload的标签值或者IPv6地址，根据该值查找到对应的VPN；然后再将payload报文偏移4字节(payload是MPLS类型)或者16字节(payload是IPv6地址类型)后的报文内容，转发给对应VPN中的接收者；需要说明的是，因为目标报文中有一部分内容属于无需转发给接收者的内容，因而在使用过程中需要提出这部分的内容。
分支步骤1201c，在通过步骤1102c和1103c后，处理方式同1201b。
分支步骤1201d，在通过步骤1102d和1103d后，处理方式同1201b。
通过以上步骤，再结合步骤1102/1103，可以实现MVPN/EVPN的业务应用。
具体实施例三
为了提高部署的可靠性，对于同样的组播流，其入口节点BFIR可能部署有两个或者两个以上，其中，部署的BFIR都会封装和转发BIER流量到出口节点BFER上，BFER需要选择其中一个BFIR，并将来自该BFIR的流量接收和转发给接收者，而对于其他BFIR转发过来的同样的组播流量则进行丢弃。
如图7所示，为了避免BFIR的单点故障，对于同一条组播流量，BFIR1和BFIR2将都转发给BFER，BFER只选择来自BFIR1的流量转发给接收者，对来自BFIR2的重复流量则进行丢弃。
上述过程的具体步骤包括步骤1301，其中，步骤1301包括：
分支步骤1301a，接前述具体步骤1101中的分支1101a，使用其IPv6源地址SA来进行BFIR判断，对于不需要的BFIR发来的报文，则直接丢弃。如图7所示，正常情况下，BFER1/BFER2只处理转发来自BFIR1的报文，丢弃来自BFIR2的报文；即SA如果是BFIR1的地址，则进行处理并转发给接收者，SA如果是BFIR2的地址，则直接丢弃该报文；当BFIR1发生故障无法转发报文，BFER1/BFER2通过检测或者其他手段获知BFIR1的故障后，及流量的接收方向切换为接受和转发SA为BFIR2地址的流量。
分支步骤1301b，接步骤1101中的分支1101b，首先获取SD信息，再根据获取的SD信息，从BIER报文开始位置偏移10字节，以读取2字节的BFIR-ID值，在根据<SD，BFIR-ID>的报文格式来确定发送该报文的BFIR信息，如果来自不需要的BFIR，则丢弃。
具体如图7所示，假设SD为0，BFIR1的BFIR-ID为10，BFIR2的BFIR-ID为20，则来自于<SD＝0，BFIR-ID＝10>的流量被接收并转发给接收者，来自于<SD＝0，BFIR-ID＝20>的流量则被丢弃；当BFIR1出现故障无法转发报文，BFER1/BFER2通过检测或者其他手段获知BFIR1的故障后，切换为接受和转发来自<SD＝0，BFIR-ID＝20>的流量。
其中，获取SD信息的方式可以(但不限于)是以下两种方式：
如果BIFT-ID的编码方式是<BSL，SD，SI>三元组硬编码，即可能采用前4位是BSL，紧接着8位是SD，最后8位是SI的方式，则从BIER报文的开始偏移4位，读取8位的SD值；
如果BIFT-ID是采用OSPF/ISIS扩展通告的方式，则根据BIFT-ID查询本地表项，获取SD值。
分支步骤1301c，接前述步骤1101中的分支1101c，其中，获取SD的方法和处理方式均同前述分支步骤1301b。
分支步骤1301d，接前述步骤1101中的分支1101d，采用前述分支步骤1301b中的方法2获取SD信息，而确定BFIR信息的处理方式同前述分支步骤1301b。
通过以上步骤，结合步骤1102/1103，可以实现双根保护场景的应用。
具体实施例四：
为了进一步简化BFER上的操作，可以通过以下方式获取固定的BSL值，而无需通过报文解析。
方式1：
BFIR在与BFER通过BIER Overlay技术进行通告时，BFIR向BFER发送反馈信息，以将 BFIR固定使用的BSL长度告知BFER，即将BFIR只会使用某个固定的BSL长度进行BIER头封装的情况反馈至BFER；例如，BFIR固定使用128位，或者固定使用256位等。其中，涉及到的BIER Overlay技术包括(但不限于)MLD、PIM、MVPN、EVPN等。
方式2：
采用控制器下发的方式将BFIR固定使用的BSL长度告知BFER，具体方式为：控制器向BFER发送反馈信息，以将BFIR固定采用某个固定BSL进行BIER头封装的情况反馈至BFER。其中，控制器发送反馈的方式包括(但不限于)BGP-LS、PCEP、NETCONF/RESTCONF加YANG模型等方式。
方法3：
在BFER上配置固定的BSL长度，且在执行BIER头解析时全部采用该BSL长度。
这样在步骤1102的分支1102b、1102c、1102d中，不用在报文头中读取BSL值，而直接使用以上方式确定的固定BSL长度值进行计算得到BIER的payload开始位置。
同理，对于payload的处理，如果只部署一种业务，比如通过BIER域传输的只有IPv4组播流量业务，则也可以通过类似固定BSL值的方法固定payload处理方式；其中，BFER与BFIR之间的BIER Overlay扩展，以及BFER与控制器之间的消息反馈，也可以采用与固定BSL类似的方式，由此也无需通过步骤1103中的报文解析获取payload类型。
具体实施例五：
在步骤1103后，BFER进行payload处理时，如果发现本地没有相应的接收者，则说明报文传递有问题，此时BFER记录该问题，并通过以下方式之一告知BFIR：
方式1：
BFER通过BIER Overlay技术发送反馈信息，以将BFER不接收该组播流量的情况反馈至BFIR；
方式2：
BFER通过BGP-LS、PCEP、NETCONF/RESTCONF加YANG模型等方式向控制器发送反馈信息，控制器向BFIR发送指示，以BFIR指示不再发送该组播流量给该BFER；而BFIR获知该指示后，则不再发送该组播流量给BFER。
如图1所示，假设BFER2在处理转发BIER报文时，发现对于某组播流量，本地没有接收者，则BFER2在丢弃该报文之后，记录这个问题，并通过BIER Overlay技术向BFIR发送该信息，或者通过控制器向BFIR发送该信息以使BFIR获知该信息，从而使得BFIR在后续对该组播流量进行封装时，将在封装的BIER头目的Bit-String中删除BFER2节点，实现不再将该报文发送到BFER2的效果。
具体实施例六：
BFER不能支持完整BIER技术时，可以告知BFIR节点或者控制器，使BFIR或控制器知晓该信息。
BFER通知控制器时，可以通过BGP-LS协议扩展上报给控制器或者BFIR，可选方式如下：
在Node Attribute TLV(RFC7752定义)的Node Flag Bits中选择未使用的一位来表示非完整BIER技术支持，其中TLV格式如图13所示。
在Node Attribute TLV中新定义一个类型表示非完整BIER技术支持。
在Prefix Attribute TLV中的BIER Information TLV中增加一个子TLV表示非完整BIER 技术支持，其中，BIER Information TLV在draft-ietf-bier-bgp-ls-bier-ext中定义。
当然也可以采用其他形式的BGP-LS协议扩展，本实施例不做具体限制。
同理，如果不使用BGP-LS协议扩展，则还可以使用PCEP节点能力扩展等方式，或者NETCONF/RESTCONF加YANG模型的方式。
这样，控制器可以获知BFER对BIER技术支持的情况，进而使得BFER节点不会被规划为BFIR，避免因BIER转发能力的缺失引起问题。
其中，BFER可以通过BIER Overlay/Underlay技术扩展将BFER为非完整BIER技术支持通知BFIR节点，也可以通过控制器将BFER为非完整BIER技术支持通知BFIR节点，而具体可选通告方式如下：
方式1：
在部署MVPN/EVPN业务时，可以通过PMSI(Proyider Multicast Service Interface)Tunnel Attribute(PTA)中新增隧道类型为非完整BIER技术支持来实现；
方式2：
BFER通知BFIR节点通过MLD/PIM/BGP等协议新增扩展BIER能力TLV的方式来实现，其中携带非完整BIER技术支持能力；
方式3：
BFER在Underlay的OSPF/ISIS等路由协议扩展的BIER-info TLV/sub-TLV中(定义在RFC8401/RFC8444中)，新增BIER能力扩展子TLV，或者直接利用BIER-info TLV/sub-TLV中的预留字段的某位来表示非完整BIER技术支持。因为Underlay信息整个BIER域内的设备都会收到，包括BFIR，因此BFIR查询BFER所通告的该信息获知BFER节点的非完整BIER技术支持情况。
BFER将其能力上报控制器后，控制器再通过BGP-LS，PCEP，NETCONF/RESTCONF加YANG模型等方式告知BFIR，告知内容为非完整支持能力sub-TLV或者sub-sub-TLV等。
方式4：
由此BFIR可以获知不能完整支持BIER技术的BFER情况，默认情况下不对该BFER做特殊处理，但可以通过策略进行精细化控制，假如对于某条组播流量只有一个BFER需要接收，且该BFER不能完整支持BIER技术，则BFIR可以略掉封装BIER头的操作，直接采用IPinIP或者其它的隧道封装形式就能将报文发送到BFER。
在以上的非完整BIER技术能力通告中，还可以进一步的细化，表示不同的非完整BIER技术能力支持情况：
方式1：
可以将非完整BIER技术能力进行分级，不同的级别表示不同的BIER技术支持能力，比如采用级别1表示仅支持固定BSL和固定payload类型处理，级别2表示支持固定payload处理但可支持BSL读取处理，级别3表示支持BSL读取及payload类型读取处理等；或者级别1表示支持BSL读取处理，级别2表示支持BSL和SD读取处理，级别3表示支持BSL、SD和BFIR-ID读取处理等。
方式2：
在以上所述的BGP-LS/PCEP/YANG模型等扩展中增加sub-TLV或者其他扩展，携带具体的级别信息，这样可以让控制器或者BFIR节点获得更精确的BFER对BIER技术的支持情况，从 而可以跟策略结合，更好的适应不同BIER组网部署需求。比如BFIR获知BFER节点仅支持固定BSL处理，则BFIR将仅用该BSL进行BIER头封装，以便BFER处理。
本公开的实施例还提供了一种计算机可读存储介质，该计算机可读存储介质中存储有计算机程序，其中，该计算机程序被设置为运行时执行上述任一项方法实施例中的步骤。
在一个示例性实施例中，上述计算机可读存储介质可以包括但不限于：U盘、只读存储器(Read-Only Memory，简称为ROM)、随机存取存储器(Random Access Memory，简称为RAM)、移动硬盘、磁碟或者光盘等各种可以存储计算机程序的介质。
本公开的实施例还提供了一种电子装置，包括存储器和处理器，该存储器中存储有计算机程序，该处理器被设置为运行计算机程序以执行上述任一项方法实施例中的步骤。
在一个示例性实施例中，上述电子装置还可以包括传输设备以及输入输出设备，其中，该传输设备和上述处理器连接，该输入输出设备和上述处理器连接。
本实施例中的具体示例可以参考上述实施例及示例性实施方式中所描述的示例，本实施例在此不再赘述。
显然，本领域的技术人员应该明白，上述的本公开的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，并且在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本公开不限制于任何特定的硬件和软件结合。
以上所述仅为本公开的优选实施例而已，并不用于限制本公开，对于本领域的技术人员来说，本公开可以有各种更改和变化。凡在本公开的原则之内，所作的任何修改、等同替换、改进等，均应包含在本公开的保护范围之内。

Claims (12)

  1. 一种报文处理方法，包括：
    接收来自入口节点的目标报文；
    确定所述目标报文中包含的载荷的类型以及所述载荷的起始位置；
    基于所述载荷的类型以及所述载荷的起始位置，对所述目标报文执行载荷解析操作，以得到所述载荷的载荷数据；
    将所述载荷数据转发至接收端。
  2. 根据权利要求1所述的方法，其中，确定所述目标报文中包含的载荷的类型以及所述载荷的起始位置包括：
    基于所述目标报文的类型确定所述目标报文的起始位置；
    基于所述目标报文的起始位置确定所述载荷的类型以及所述载荷的起始位置。
  3. 根据权利要求2所述的方法，其中，所述基于所述起始位置确定所述载荷的起始位置包括：
    在确定所述目标报文为第一类型报文的情况下，跳过所述目标报文的报文头，以确定所述载荷的起始位置；
    在确定所述目标报文为除所述第一类型报文之外的其他类型报文的情况下，获取所述目标报文的第一信息值，其中，所述第一信息值用于指示第一信息的长度；基于所述第一信息值确定所述载荷的起始位置。
  4. 根据权利要求2所述的方法，其中，所述基于所述目标报文的起始位置确定所述载荷的类型包括：
    在确定所述目标报文为第一类型报文的情况下，基于所述目标报文的起始位置确定所述目标报文中包含的目标头字段，基于所述目标头字段确定所述载荷的类型；
    在确定所述目标报文为除所述第一类型报文之外的其他类型报文的情况下，基于所述目标报文的起始位置，对所述目标报文执行第二偏移计算，以得到所述目标报文的属性值；基于所述属性值确定所述载荷的类型。
  5. 根据权利要求1所述的方法，其中，
    在接收来自入口节点的目标报文之后，所述方法还包括：在确定所述目标报文为第一类型报文的情况下，基于所述目标报文包含的源地址执行第一定位操作，以得到第一定位结果；将所述载荷数据转发至接收端包括：在基于所述第一定位结果定位到目标节点的情况下，将所述载荷数据发送至所述目标节点，以指示所述目标节点将所述载荷数据发送至所述接收端；
    或者，
    在接收来自入口节点的目标报文之后，所述方法还包括：在确定所述目标报文为除所述第一类型报文之外的其他类型报文的情况下，根据所述载荷的类型查找所述目标节点；将所述载荷数据转发至接收端包括：在确定查找到所述目标节点的情况下，对所述载荷执行第三偏移操作，以得到目标载荷数据；将所述目标载荷数据发送至所述目标节点，以指示所述目标节点将所述载荷数据发送至所述接收端。
  6. 根据权利要求1所述的方法，其中，
    在确定所述目标报文中包含的载荷的类型以及所述载荷的起始位置之前，所述方法还包括：
    在确定所述目标报文为第一类型报文的情况下，基于所述目标报文包含的源地址判断所述入口节点是否为与本地存储的第一入口节点标识对应的第一入口节点；
    在确定所述目标报文为除所述第一类型报文之外的其他类型报文的情况下，获取所述目标报文中包括的第二信息，基于所述第二信息以及所述目标报文的起始位置，对所述目标报文执行第四偏移计算，以确定所述第一入口节点的节点标识值；基于所述节点标识值以及所述第二信息判断所述入口节点是否为与本地存储的第一入口节点标识对应的第一入口节点；
    确定所述目标报文中包含的载荷的类型以及所述载荷的起始位置包括：在确定所述入口节点为与本地存储的第一入口节点标识对应的所述第一入口节点的情况下，确定所述目标报文中包含的载荷的类型以及所述载荷的起始位置。
  7. 根据权利要求3所述的方法，其中，所述获取所述目标报文的第一信息值包括以下至少之一：
    接收来自所述入口节点的所述第一信息值；
    接收来自控制器的所述第一信息值；
    获取预先设置的第一信息值。
  8. 根据权利要求1所述的方法，其中，在基于所述载荷的类型以及所述载荷的起始位置，对所述目标报文执行载荷解析操作，以得到所述载荷的载荷数据之后，所述方法还包括：
    在确定不存在用于接收所述载荷数据的所述接收端的情况下，执行以下操作至少之一：
    向所述入口节点发送第一反馈，其中，所述第一反馈用于指示拒绝接收待发送至所述接收端的报文；
    向控制器发送第二反馈，以指示所述控制器向所述入口节点发送第三反馈，其中，所述第三反馈用于指示拒绝接收待发送至所述接收端的报文。
  9. 根据权利要求1所述的方法，其中，所述方法还包括：
    向所述入口节点或控制器发送第四反馈，其中，所述第四反馈用于指示以下信息至少之一：出口节点为不支持预定技术的节点，出口节点支持预定技术的能力级别。
  10. 一种报文处理装置，包括：
    接收模块，设置为接收来自入口节点的目标报文；
    确定模块，设置为确定所述目标报文中包含的载荷的类型以及所述载荷的起始位置；
    解析模块，设置为基于所述载荷的类型以及所述载荷的起始位置，对所述目标报文执行载荷解析操作，以得到所述载荷的载荷数据；
    发送模块，设置为将所述载荷数据转发至接收端。
  11. 一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机程序，其中，所述计算机程序被处理器执行时实现所述权利要求1至9任一项中所述的方法的步骤。
  12. 一种电子装置，包括存储器和处理器，所述存储器中存储有计算机程序，所述处理器被设置为运行所述计算机程序以执行所述权利要求1至9任一项中所述的方法。
PCT/CN2022/075883 2021-04-21 2022-02-10 一种报文处理方法、装置、存储介质及电子装置 WO2022222582A1 (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US18/282,592 US20240163208A1 (en) 2021-04-21 2022-02-10 Packet processing method and apparatus, and storage medium and electronic apparatus

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202110432551.5A CN115314150A (zh) 2021-04-21 2021-04-21 一种报文处理方法、装置、存储介质及电子装置
CN202110432551.5 2021-04-21

Publications (1)

Publication Number Publication Date
WO2022222582A1 true WO2022222582A1 (zh) 2022-10-27

Family

ID=83723573

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2022/075883 WO2022222582A1 (zh) 2021-04-21 2022-02-10 一种报文处理方法、装置、存储介质及电子装置

Country Status (3)

Country Link
US (1) US20240163208A1 (zh)
CN (1) CN115314150A (zh)
WO (1) WO2022222582A1 (zh)

Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106341327A (zh) * 2015-07-08 2017-01-18 中兴通讯股份有限公司 一种bier报文的传输方法及系统
CN107645446A (zh) * 2016-07-21 2018-01-30 中兴通讯股份有限公司 一种信息确定方法和装置
US20190296999A1 (en) * 2018-03-21 2019-09-26 Nokia Solutions And Networks Oy Hierarchical bit indexed replication of multicast packets
CN110620730A (zh) * 2018-06-20 2019-12-27 瞻博网络公司 比特索引显式复制（bier）倒数第二跳弹出
CN112054959A (zh) * 2019-06-06 2020-12-08 华为技术有限公司 一种bier报文的发送方法和装置
CN112491708A (zh) * 2020-10-15 2021-03-12 中兴通讯股份有限公司 IPv6报文的路由头封装方法及装置
CN112491729A (zh) * 2020-09-22 2021-03-12 中兴通讯股份有限公司 一种数据处理方法、装置、存储介质及电子装置
CN112491718A (zh) * 2020-08-31 2021-03-12 中兴通讯股份有限公司 报文头的处理方法及装置、存储介质、电子装置
CN112491706A (zh) * 2020-07-31 2021-03-12 中兴通讯股份有限公司 数据报文的处理方法及装置、存储介质、电子装置

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7724740B1 (en) * 2002-08-27 2010-05-25 3Com Corporation Computer system and network interface supporting class of service queues
WO2021073357A1 (zh) * 2019-10-14 2021-04-22 华为技术有限公司 报文处理方法、装置、系统、设备及存储介质

Patent Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106341327A (zh) * 2015-07-08 2017-01-18 中兴通讯股份有限公司 一种bier报文的传输方法及系统
CN107645446A (zh) * 2016-07-21 2018-01-30 中兴通讯股份有限公司 一种信息确定方法和装置
US20190296999A1 (en) * 2018-03-21 2019-09-26 Nokia Solutions And Networks Oy Hierarchical bit indexed replication of multicast packets
CN110620730A (zh) * 2018-06-20 2019-12-27 瞻博网络公司 比特索引显式复制（bier）倒数第二跳弹出
CN112054959A (zh) * 2019-06-06 2020-12-08 华为技术有限公司 一种bier报文的发送方法和装置
CN112491706A (zh) * 2020-07-31 2021-03-12 中兴通讯股份有限公司 数据报文的处理方法及装置、存储介质、电子装置
CN112491718A (zh) * 2020-08-31 2021-03-12 中兴通讯股份有限公司 报文头的处理方法及装置、存储介质、电子装置
CN112491729A (zh) * 2020-09-22 2021-03-12 中兴通讯股份有限公司 一种数据处理方法、装置、存储介质及电子装置
CN112491708A (zh) * 2020-10-15 2021-03-12 中兴通讯股份有限公司 IPv6报文的路由头封装方法及装置

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
12 January 2018 (2018-01-12), IJ. WIJNANDS, ED. CISCO SYSTEMS, INC. E. ROSEN, ED. JUNIPER NETWORKS, INC. A. DOLGANOW NOKIA J. TANTSURA INDIVIDUAL S. ALDRIN GOOG: "Encapsulation for Bit Index Explicit Replication (BIER) in MPLS and Non-MPLS Networks; rfc8296.txt", XP015122285, Database accession no. 8296 *
20 November 2017 (2017-11-20), IJ. WIJNANDS, ED. CISCO SYSTEMS, INC. E. ROSEN, ED. JUNIPER NETWORKS, INC. A. DOLGANOW NOKIA T. PRZYGIENDA JUNIPER NETWORKS, INC. : "Multicast Using Bit Index Explicit Replication (BIER); rfc8279.txt", XP015122259, Database accession no. 8279 *
Z. ZHANG JUNIPER NETWORKS: "BIER Penultimate Hop Popping; draft-zzhang-bier-php-01.txt", BIER PENULTIMATE HOP POPPING; DRAFT-ZZHANG-BIER-PHP-01.TXT; INTERNET-DRAFT: BIER, INTERNET ENGINEERING TASK FORCE, IETF; STANDARDWORKINGDRAFT, INTERNET SOCIETY (ISOC) 4, RUE DES FALAISES CH- 1205 GENEVA, SWITZERLAND, no. 01, 3 August 2018 (2018-08-03), Internet Society (ISOC) 4, rue des Falaises CH- 1205 Geneva, Switzerland , pages 1 - 7, XP015127985 *
Z. ZHANG ZTE CORPORATION Z. ZHANG, ED. JUNIPER NETWORKS I. WIJNANDS INDIVIDUAL M. MISHRA CISCO SYSTEMS H. BIDGOLI NOKIA G. MISHRA,: "Supporting BIER in IPv6 Networks (BIERin6) draft-zhang-bier-bierin6-09; draft-zhang-bier-bierin6-09.txt", SUPPORTING BIER IN IPV6 NETWORKS (BIERIN6) DRAFT-ZHANG-BIER-BIERIN6-09; DRAFT-ZHANG-BIER-BIERIN6-09.TXT; INTERNET-DRAFT: BIER, INTERNET ENGINEERING TASK FORCE, IETF; STANDARDWORKINGDRAFT, INTERNET SOCIETY (ISOC) 4, RUE DES FALAISES CH- 1205 GENEVA, S, no. 09, 22 February 2021 (2021-02-22), Internet Society (ISOC) 4, rue des Falaises CH- 1205 Geneva, Switzerland , pages 1 - 11, XP015144775 *

Also Published As

Publication number Publication date
US20240163208A1 (en) 2024-05-16
CN115314150A (zh) 2022-11-08

Similar Documents

Publication Publication Date Title
US9948574B2 (en) Bit indexed explicit replication packet encapsulation
CN107968750B (zh) 报文传输方法、装置及节点
EP3958521A1 (en) Method and apparatus for providing service for service flow
US8665887B2 (en) Number automatic routing method, updating method, withdrawing method, router and device
EP3490201B1 (en) Method, device and system for information synchronization
CN103685022B (zh) 报文转发方法及服务提供商网络边缘设备
CN110324226A (zh) 改进以太虚拟专用网网络中多宿主站点流量的混叠行为
CN108964940B (zh) 消息发送方法及装置、存储介质
CN107040469A (zh) 网络设备及方法
US20210160182A1 (en) Communication method, communications device, and communications system
US20130259050A1 (en) Systems and methods for multi-level switching of data frames
CN112491706B (zh) 数据报文的处理方法及装置、存储介质、电子装置
US11394578B2 (en) Supporting multicast over a network domain
US11362954B2 (en) Tunneling inter-domain stateless internet protocol multicast packets
CN113259239A (zh) 一种在混合网络中转发报文的方法、设备和系统
WO2022184169A1 (zh) 报文转发方法、系统、存储介质及电子装置
CN112491718A (zh) 报文头的处理方法及装置、存储介质、电子装置
CN107294859B (zh) 一种信息传递方法、装置及系统
US20230006917A1 (en) Route Determining Method and Apparatus and Network Device
EP2981036B1 (en) Multicast communication method and aggregation switch
WO2022222582A1 (zh) 一种报文处理方法、装置、存储介质及电子装置
US20200304405A1 (en) Seamless multipoint label distribution protocol (mldp) transport over a bit index explicit replication (bier) core
CN113014495A (zh) 用于改进的多播的源主动社区
US20240305565A1 (en) Traffic Handling for EVPN E-Tree
CN114079629B (zh) 最大传输单元mtu确定方法、装置、设备以及存储介质

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22790692

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 18282592

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205A DATED 27/02/2024)