WO2023207147A1 - IPv6报文处理方法、节点、存储介质和程序产品 - Google Patents

IPv6报文处理方法、节点、存储介质和程序产品 Download PDF

Info

Publication number
WO2023207147A1
WO2023207147A1 PCT/CN2022/140322 CN2022140322W WO2023207147A1 WO 2023207147 A1 WO2023207147 A1 WO 2023207147A1 CN 2022140322 W CN2022140322 W CN 2022140322W WO 2023207147 A1 WO2023207147 A1 WO 2023207147A1
Authority
WO
WIPO (PCT)
Prior art keywords
target
ipv6
ipv6 message
control word
header
Prior art date
Application number
PCT/CN2022/140322
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 中兴通讯股份有限公司
Publication of WO2023207147A1 publication Critical patent/WO2023207147A1/zh

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/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
    • H04L49/00—Packet switching elements
    • H04L49/90—Buffering arrangements
    • H04L49/9057—Arrangements for supporting packet reassembly or resequencing

Definitions

  • This application relates to the field of communication technology, especially an IPv6 message processing method, node, storage medium and program product.
  • IPv6 Internet Protocol Version 6, Internet Protocol Version 6
  • SLA Service Level Agreement
  • Embodiments of the present application provide an IPv6 message processing method, node, storage medium and program product, which can extend the IPv6 specification to support user data message sequence numbers, thereby enabling packet sorting and processing.
  • embodiments of the present application provide an IPv6 message processing method, which is applied to a sending node.
  • the method includes: obtaining a target IPv6 message to be sent; and determining a target sequence number according to the sending order of the target IPv6 message. , and add the target sequence number to the target IPv6 message; send the target IPv6 message carrying the target sequence number to the target node, so that the target node determines the target sequence number according to the target sequence number. Process the target IPv6 message.
  • embodiments of the present application also provide an IPv6 message processing method, applied to a target node.
  • the method includes: receiving a target IPv6 message from a sending node, wherein the target IPv6 message carries a target Sequence number, the target sequence number is determined by the sending node according to the sending order of the target IPv6 message; read the target sequence number, compare the target sequence number with the expected sequence number, and calculate the sequence number based on the comparison.
  • the sorting situation of the target IPv6 message is determined; and the target IPv6 message is processed according to the sorting situation.
  • embodiments of the present application also provide a sending node, including: a memory, a processor, and a computer program stored on the memory and executable on the processor.
  • the processor executes the computer program.
  • the program implements the message processing method applied to the sending node as described previously.
  • embodiments of the present application also provide a target node, including: a memory, a processor, and a computer program stored on the memory and executable on the processor.
  • the processor executes the computer program.
  • the program implements the message processing method applied to the target node as described earlier.
  • embodiments of the present application also provide a computer-readable storage medium that stores computer-executable instructions, and the computer-executable instructions are used to execute the message processing method as described above.
  • embodiments of the present application also provide a computer program product, including a computer program or computer instructions.
  • the computer program or computer instructions are stored in a computer-readable storage medium, and the processor of the computer device obtains the information from the computer program or computer instructions.
  • the computer readable storage medium reads the computer program or the computer instructions, and the processor executes the computer program or the computer instructions, so that the computer device performs the message processing method as described above.
  • the sending node can determine the target sequence number according to the sending order of the target IPv6 messages, and add the target sequence number to the target IPv6 message, and carry the The target IPv6 message with the target sequence number is sent to the target node, so that the target node can sort the target IPv6 message according to the target sequence number carried in the target IPv6 message, and the IPv6 specification can be extended to support user datagrams.
  • the document serial number is in line with the future trend of pure IPv6 networks.
  • Figure 1 is a schematic diagram of an implementation environment for executing an IPv6 message processing method provided by an embodiment of the present application
  • FIG. 2 is a flow chart of an IPv6 message processing method applied to the sending node side provided by an embodiment of the present application
  • FIG. 3 is a flow chart of an embodiment of step S200 in Figure 2;
  • Figure 4 is a schematic diagram of the encapsulation format of Fragment Header provided by an embodiment of this application.
  • FIG. 5 is a flow chart of another embodiment of step S200 in Figure 2;
  • Figure 6 is a schematic diagram of the encapsulation format of the Destination Options Header provided by an embodiment of the present application.
  • FIG. 7 is a flow chart of another embodiment of step S200 in Figure 2;
  • FIG 8 is a flow chart of another embodiment of step S200 in Figure 2;
  • Figure 9 is a schematic diagram of the packaging format of the Control Word Extension Header provided by an embodiment of the present application.
  • FIG 10 is a flow chart of another embodiment of step S200 in Figure 2;
  • Figure 11 is a schematic diagram of the packaging format of the Control Word Header provided by an embodiment of the present application.
  • Figure 12 is a flow chart of an embodiment of step S300 in Figure 2;
  • FIG 13 is a flow chart of another embodiment of step S300 in Figure 2;
  • Figure 14 is a flow chart of an embodiment of step S320 in Figure 12;
  • Figure 15 is a flow chart of an embodiment of step S330 in Figure 13;
  • Figure 16 is a flow chart of an IPv6 message processing method on the target node side provided by an embodiment of the present application.
  • Figure 17 is a flow chart of an embodiment of reading the target serial number in step S500 in Figure 16;
  • Figure 18 is a flow chart of another embodiment of reading the target serial number in step S500 in Figure 16;
  • Figure 19 is a flow chart of another embodiment of reading the target serial number in step S500 in Figure 16;
  • Figure 20 is a flow chart of another embodiment of reading the target serial number in step S500 in Figure 16;
  • Figure 21 is a flow chart of another embodiment of reading the target serial number in step S500 in Figure 16;
  • Figure 22 is a flow chart of an embodiment of step S400 in Figure 16;
  • FIG 23 is a flow chart of another embodiment of step S400 in Figure 16;
  • Figure 24 is a flow chart of an embodiment of determining the sorting of target IPv6 packets according to the comparison results in step S500 in Figure 16;
  • Figure 25 is a flow chart of another embodiment of determining the sorting of target IPv6 packets according to the comparison results in step S500 in Figure 16;
  • Figure 26 is a flow chart of another embodiment of determining the sorting of target IPv6 packets according to the comparison results in step S500 in Figure 16;
  • Figure 27 is a flow chart of an embodiment of processing the target IPv6 message according to the sorting situation in step S600 in Figure 16;
  • Figure 28 is a flow chart of another embodiment of processing the target IPv6 message according to the sorting situation in step S600 in Figure 16;
  • Figure 29 is a schematic diagram of the SRv6 transmission path of a typical VPWS PW carried on PSN;
  • Figure 30 is an example diagram of redundant replication and elimination of typical DetNet business flows.
  • MPLS packets refer to packets encapsulated by the MPLS label stack.
  • the classic approach is to assume that the payload following the label stack is an IP packet, and based on this assumption, check if the first 4 bits of the payload are 4 or 6, then treat the payload as an IPv4 packet or IPv6 packet.
  • non-IP loads such as Layer 2 loads (such as Ethernet, PPP, Frame Relay, TDM, etc.) carried on MPLS PW (Pseudo Wire).
  • control plane protocol to explicitly specify the payload type encapsulated by the label when negotiating the service label (such as the PW label), and maintain the encapsulated payload in the corresponding label forwarding entry created.
  • Load type information When a node receives an MPLS message and matches the corresponding label forwarding entry, it can parse the message based on the payload type information maintained in the entry.
  • the payload type information maintained in the label forwarding entry can be a Layer 2 payload type or a control word type. It should be noted that this method can only be used on the network egress node that maintains service label forwarding entries.
  • the intermediate nodes of the network do not and do not need to maintain related service label forwarding entries, so the intermediate nodes can only rely on reports. Use the information of the document itself to infer the payload type after the label stack.
  • intermediate nodes do parse MPLS packets and implement ECMP (Equal Cost Multi-path, Equal Cost Multi-path) processing according to their payload types. Therefore, the intermediate node may mistake a Layer 2 payload for an IP payload, and then perform ECMP hashing based on the incorrectly obtained IP quintuple. As a result, multiple packets of the same service may have different hash results and be processed along different paths. forwarding along the path, eventually causing packets to be out of order. In order to avoid this situation, RFC4385 defines MPLS control words, including PWMCW (PW MPLS Control Word, pseudo wire control word) and PWACH (PW Associated Channel Header, pseudo wire pipe header).
  • PWMCW PW MPLS Control Word, pseudo wire control word
  • PWACH PW Associated Channel Header, pseudo wire pipe header
  • the former is used to encapsulate user data packets, and the latter It is used to encapsulate OAM (Operations, Administration and Maintenance) messages.
  • OAM Operations, Administration and Maintenance
  • the purpose of introducing the control word is very simple, which is to clearly distinguish it from the IP payload and prevent intermediate nodes from mistakenly treating non-IP payloads as IP payloads when implementing ECMP. Therefore, the value of the first 4 bits of the control word cannot be It's 4 or 6.
  • RFC5586 further renames PWACH to G-Ach (Generic Associated Channel), broadening the scope of application from MPLS PW to all types of MPLS LSP.
  • PWMCW In addition to being able to distinguish it from the IP payload, PWMCW also contains message sequence number (Sequence Number) information, which can be used for out-of-order inspection and reorganization of user data packets, and is suitable for services that are sensitive to packet out-of-order, such as TDM simulation business.
  • RFC8964 also introduces d-CW (DetNet Control Word, deterministic network control word) in the MPLS encapsulation scheme of DetNet (Deterministic Network) defined, which contains sequence number information and is used for DetNet services
  • the packet sorting function of the sub-layer provides certainty of out-of-order indicators.
  • IPv6 As more and more networks upgrade from MPLS bearers to IPv6 (especially SRv6), user data flows will be uniformly encapsulated in IPv6. For the business, only the carrying method has changed, but the SLA (Service Level Agreement) of the business still needs to be met, for example, the out-of-order guarantee of user data packets.
  • SLA Service Level Agreement
  • the current IPv6 specification lacks support for user data packet sequence numbers and relies on other methods, such as inserting MPLS labels and MPLS control words into IPv6 encapsulation. However, this method is not in line with the future of pure IPv6 networks. trend.
  • embodiments of the present application provide an IPv6 message processing method, a sending node, a target node, a computer-readable storage medium, and a computer program product.
  • the sending node can report according to the target IPv6 message. Determine the target sequence number in the sending order of the message, add the target sequence number to the target IPv6 message, and send the target IPv6 message carrying the target sequence number to the target node, so that the target node can determine the target IPv6 message according to the target sequence number.
  • the target sequence number carried sorts the target IPv6 packets and can extend the IPv6 specification to support user data packet sequence numbers, which is in line with the future trend of pure IPv6 networks.
  • Figure 1 is a schematic diagram of an implementation environment for executing an IPv6 message processing method provided by an embodiment of the present application.
  • the implementation environment is provided with a sending node 100 and a target node 200 , where the sending node 100 and the target node 200 are communicatively connected.
  • the sending node 100 and the target node 200 are both equipped with a processor and a memory, where the processor and the memory can be connected through a bus or other means.
  • memory can be used to store non-transitory software programs and non-transitory computer executable programs.
  • the memory may include high-speed random access memory and may also include non-transitory memory, such as at least one magnetic disk storage device, flash memory device, or other non-transitory solid-state storage device.
  • the memory may optionally include memory located remotely from the processor, and these remote memories may be connected to the implementation environment via a network. Examples of the above-mentioned networks include but are not limited to the Internet, intranets, local area networks, mobile communication networks and combinations thereof.
  • an intermediate node may also be provided between the sending node 100 and the target node 200, where the sending node 100 and the target node 200 are respectively communicatively connected with the intermediate node.
  • the processor in the sending node 100 or the target node 200 can call the IPv6 message processing program stored in the memory, thereby executing the IPv6 message processing method.
  • Figure 2 is a flow chart of an IPv6 message processing method on the sending node side provided by an embodiment of the present application. The method is applied to the sending node and includes but is not limited to step S100, step S200 and step S300.
  • Step S100 Obtain the target IPv6 message to be sent
  • Step S200 Determine the target sequence number according to the sending order of the target IPv6 message, and add the target sequence number to the target IPv6 message;
  • Step S300 Send the target IPv6 message carrying the target sequence number to the target node, so that the target node processes the target IPv6 message according to the target sequence number.
  • the sending node can determine the target sequence number according to the sending order of the target IPv6 messages, add the target sequence number to the target IPv6 message, and then send the target sequence number carrying the target IPv6 message.
  • the IPv6 message is sent to the target node, so that the target node can sort the target IPv6 message according to the target sequence number carried in the target IPv6 message. Therefore, the embodiment of the present application can extend the IPv6 specification to support user data
  • the packet sequence number is in line with the future trend of pure IPv6 networks.
  • the above target IPv6 message specifically refers to the unfragmented original packet; therefore, correspondingly, the above sending order refers to the sending order of the original packet for the same data flow.
  • the target sequence number in the embodiment of the present application is determined according to the sending order of the target IPv6 message. Specifically, when the sending order of the target IPv6 message is earlier, the value of the corresponding target sequence number is higher. Small; on the contrary, when the target IPv6 message is sent later in the sequence, the corresponding target sequence number is larger.
  • target IPv6 messages that is, for different original packets, the target sequence numbers carried by them are inconsistent; for multiple fragmented messages obtained by fragmenting the same target IPv6 message , the target sequence numbers they each carry are consistent.
  • Figure 3 is a flow chart of an embodiment of step S200 in Figure 2; specifically, when the target IPv6 message contains the IPv6 extension header Fragment Header, regarding the target sequence in the above step S200 number is added to the target IPv6 message, including but not limited to step S210.
  • Step S210 Add the target serial number to the Identification field of the Fragment Header.
  • the current IPv6 specification defines a Fragment Header, which can be used by IPv6source to fragment the message when the size of the message exceeds the MTU (Maximum Transmission Unit) of the transmission path.
  • the Fragment Header Contains identification information, but its role is limited to identifying multiple fragments belonging to the same original package.
  • the embodiment of the present application reuses the Fragment Header, in which the encapsulation format of the Fragment Header can be shown in Figure 4.
  • the embodiment of the present application extends the IPv6 specification by adding the target sequence number to the Identification field of the Fragment Header. To support user data packet sequence numbers, it is in line with the future trend of pure IPv6 networks.
  • Figure 5 is a flow chart of another embodiment of step S200 in Figure 2; specifically, when the target IPv6 message contains the IPv6 extension header Destination Options Header, regarding the steps in step S200 above,
  • the target sequence number is added to the target IPv6 message, including but not limited to step S221 and step S222.
  • Step S221 Add control word options in the Destination Options Header
  • Step S222 Add the target serial number to the control word field in the control word option.
  • the encapsulation format of the Destination Options Header can be as shown in Figure 6.
  • the embodiment of the present application adds a control word option in the Destination Options Header and adds the target serial number to the control word field in the control word option, thereby implementing
  • the IPv6 specification has been extended to support user data packet sequence numbers, in line with the future trend of pure IPv6 networks.
  • Figure 7 is a flow chart of another embodiment of step S200 in Figure 2; specifically, in the case where the target IPv6 message contains the IPv6 extension header Hop-by-Hop Options Header, regarding the above steps Adding the target sequence number to the target IPv6 message in S200 includes but is not limited to step S231 and step S232.
  • Step S231 Add control word options to the Hop-by-Hop Options Header
  • Step S232 Add the target serial number to the control word field in the control word option.
  • the encapsulation format of the Hop-by-Hop Options Header can also be shown in Figure 6.
  • a control word option is added to the Hop-by-Hop Options Header and the target serial number is added to the control word option. in the control word field, thereby extending the IPv6 specification to support user data packet sequence numbers, in line with the trend of future pure IPv6 networks.
  • Figure 8 is a flow chart of another embodiment of step S200 in Figure 2; specifically, in the case where the target IPv6 message contains the IPv6 extension header Control Word Extension Header, regarding the above step S200 Add the target sequence number to the target IPv6 message, including but not limited to step S240.
  • Step S240 Add the target serial number to the control word field in the Control Word Extension Header.
  • Control Word Extension Header the encapsulation format of the Control Word Extension Header can be as shown in Figure 9.
  • the embodiment of this application defines a new IPv6 extension header, called Control Word Extension Header, and adds the target serial number to the Control Word Extension Header. in the control word field, thereby extending the IPv6 specification to support user data packet sequence numbers, in line with the future trend of pure IPv6 networks.
  • Figure 10 is a flow chart of another embodiment of step S200 in Figure 2; specifically, in the case where the target IPv6 message contains the Upper-layer payload header Control Word Header, regarding the above step S200 Add the target sequence number to the target IPv6 message, including but not limited to step S250.
  • Step S250 Add the target serial number to the control word field in the Control Word Header.
  • Control Word Header can be as shown in Figure 11.
  • This embodiment of the application defines a new Upper-layer payload type, called Control Word Header, and adds the target serial number to the Control Word Header.
  • the IPv6 specification is extended to support user data packet sequence numbers, which is in line with the trend of future pure IPv6 networks.
  • Figure 12 is a flow chart of an embodiment of step S300 in Figure 2; specifically, regarding sending the target IPv6 message carrying the target sequence number to the target node in the above step S300, including but not It is limited to step S310 and step S320.
  • Step S310 Obtain the data volume of the target IPv6 message
  • Step S320 When the data amount is less than or equal to the maximum transmission amount of the transmission path between the sending node and the target node, set the offset and the last bit identifier in the complete target IPv6 message according to the preset specifications, and set the The complete target IPv6 message is sent to the target node.
  • the embodiment of the present application can follow the preset specifications. Set the offset and last bit identifier in the target IPv6 packet as the original packet.
  • Figure 13 is a flow chart of another embodiment of step S300 in Figure 2; specifically, regarding sending the target IPv6 message carrying the target sequence number to the target node in the above step S300, including but It is not limited to step S310 and step S330.
  • Step S310 When the amount of data is greater than the maximum transmission amount of the transmission path between the sending node and the target node, the target IPv6 message is divided into multiple fragmented messages;
  • Step S330 Set the offset and the last bit identifier in the fragmented message according to the preset specification, and send the set multiple fragmented messages to the target node.
  • the embodiment of this application will Divide the target IPv6 packet into multiple fragmented packets, and then set the offset and last bit identifier in the multiple fragmented packets according to the preset specifications.
  • the offset of the first fragmented message corresponds to 0, and the offset of the second fragmented message corresponds to 0.
  • the offset Fragment Offset of the fragment message corresponds to the length of the first fragment
  • the offset Fragment Offset of the third fragment message corresponds to the sum of the lengths of the first fragment and the second fragment.
  • the last flag M-flag of the last fragmented message corresponds to 0, and the last flag M-flag of the non-last fragmented message corresponds to 1.
  • Figure 14 is a flow chart of an embodiment of step S320 in Figure 12; specifically, with regard to sending the set complete target IPv6 message to the target node in the above step S320, including but It is not limited to step S321.
  • Step S321 Send the set complete target IPv6 message to the intermediate node, so that the intermediate node reads the source address, destination address and original packet identifier carried in the target IPv6 message, and filters duplicate packets carrying the IPv6 message through the intermediate node.
  • the destination IPv6 message with the same source address, destination address and original packet identifier is forwarded to the destination node through the intermediate node.
  • the intermediate node implements the DetNet elimination function
  • multiple copies of the original packets with the same source address, destination address, and original packet ID will be eliminated and only one copy will be retained.
  • the embodiment of the present application can compare the source address, destination address and original packet identifier of multiple original packets at the same time. If the three are consistent, it indicates that they are the same original packet; if there is at least one of the three, If they are inconsistent, it means they are different original packages.
  • Figure 15 is a flow chart of an embodiment of step S330 in Figure 13; specifically, regarding sending the set multiple fragmented messages to the target node in the above step S330, including but It is not limited to step S331.
  • Step S331 Send the set multiple fragmented messages to the intermediate node, so that the intermediate node can read the source address, destination address, original packet identifier and offset carried in the fragmented messages, and filter them through the intermediate node. Repeat fragmented packets carrying the same source address, destination address, original packet identifier and offset, and forward the retained fragmented packets to the target node through the intermediate node.
  • the intermediate node implements the DetNet elimination function
  • multiple fragmented packets with the same source address, destination address, original packet identifier and offset will be eliminated and only one will be retained.
  • the embodiment of the present application can compare the source address, destination address, original packet identifier and offset of multiple fragmented packets at the same time. If the four are consistent, it indicates that they are the same fragmented packet; if If at least one of the four is inconsistent, it indicates that they are different fragmented packages.
  • Figure 16 is a flow chart of an IPv6 packet processing method on the target node side provided by an embodiment of the present application. The method is applied to the target node and includes but is not limited to step S400, step S500 and step S600.
  • Step S400 Receive the target IPv6 message from the sending node, where the target IPv6 message carries a target sequence number, and the target sequence number is determined by the sending node according to the sending order of the target IPv6 message;
  • Step S500 Read the target sequence number, compare the target sequence number with the expected sequence number, and determine the sorting of the target IPv6 messages based on the comparison result;
  • Step S600 Process the target IPv6 packet according to the sorting situation.
  • the sending node can determine the target sequence number according to the sending order of the target IPv6 messages, add the target sequence number to the target IPv6 message, and then send the target sequence number carrying the target IPv6 message.
  • the IPv6 packet is sent to the target node.
  • the target node compares the target sequence number with the expected sequence number, determines the sorting of the target IPv6 packet based on the comparison result, and then processes the target IPv6 packet based on the sorting. Therefore, the embodiments of the present application can extend the IPv6 specification to support user data packet sequence numbers, which is in line with the future trend of pure IPv6 networks.
  • the above target IPv6 message specifically refers to the unfragmented original packet; therefore, correspondingly, the above sending order refers to the sending order of the original packet for the same data flow.
  • the target sequence number in the embodiment of the present application is determined based on the sending order of the target IPv6 message. Specifically, when the target IPv6 message is sent earlier in the sending order, the corresponding target sequence number is smaller; On the contrary, when the target IPv6 message is sent later in the sequence, the corresponding target sequence number is larger.
  • target IPv6 messages that is, for different original packets, the target sequence numbers carried by them are inconsistent; for multiple fragmented messages obtained by fragmenting the same target IPv6 message , the target sequence numbers they each carry are consistent.
  • the above expected sequence number is obtained by continuous accumulation and updating. Specifically, the next expected sequence number is determined by the target node based on the comparison result between the currently received target sequence number and the current expected sequence number. It is understandable that the initial expected sequence number may be set manually.
  • Figure 17 is a flow chart of an embodiment of reading the target sequence number in step S500 in Figure 16; specifically, the target IPv6 message contains an IPv6 extension header Fragment Header, and the IPv6 extension header Fragment Header
  • the reading of the target serial number in the above step S500 includes but is not limited to step S510.
  • Step S510 Read the Identification field to obtain the target serial number.
  • the current IPv6 specification defines a Fragment Header, which can be used by the IPv6 source to fragment the message when the size of the message exceeds the MTU of the transmission path.
  • the Fragment Header contains identification information, its function is only Limited to identifying multiple fragments belonging to the same original package.
  • the embodiment of the present application reuses the Fragment Header, in which the encapsulation format of the Fragment Header can be shown in Figure 4.
  • the embodiment of the present application adds the target sequence number to the Identification field of the Fragment Header, so that the target node reads the The target sequence number can be obtained from the Identification field, thereby extending the IPv6 specification to support user data packet sequence numbers, in line with the future trend of pure IPv6 networks.
  • Figure 18 is a flow chart of another embodiment of reading the target sequence number in step S500 in Figure 16; specifically, the target IPv6 message contains the IPv6 extension header Destination Options Header, and the Destination Options Header carries the control word option, and the control word field of the control word option carries the target serial number, the reading of the target serial number in the above step S500 includes but is not limited to step S520.
  • Step S520 Read the control word field of the control word option to obtain the target serial number.
  • the encapsulation format of the Destination Options Header can be shown in Figure 6.
  • This embodiment of the present application adds a control word option in the Destination Options Header and adds the target serial number to the control word field in the control word option, so that the target The node can obtain the target sequence number by reading the control word field of this control word option, thereby extending the IPv6 specification to support user data packet sequence numbers, in line with the future trend of pure IPv6 networks.
  • Figure 19 is a flow chart of another embodiment of reading the target sequence number in step S500 in Figure 16; specifically, the target IPv6 message contains the IPv6 extension header Hop-by-Hop Options Header, And when the Hop-by-Hop Options Header carries a control word option, and the control word field of the control word option carries a target serial number, the reading of the target serial number in the above step S500 includes but is not limited to steps S530.
  • Step S530 Read the control word field of the control word option to obtain the target serial number.
  • the encapsulation format of the Hop-by-Hop Options Header can also be shown in Figure 6.
  • a control word option is added to the Hop-by-Hop Options Header and the target serial number is added to the control word option.
  • the target node can obtain the target sequence number by reading the control word field of the control word option, thus extending the IPv6 specification to support user data packet sequence numbers, which is in line with the future trend of pure IPv6 networks.
  • Figure 20 is a flow chart of another embodiment of reading the target sequence number in step S500 in Figure 16; specifically, the target IPv6 message contains the IPv6 extension header Control Word Extension Header, and Control Word When the Extension Header carries a control word field, and the control word field carries a target serial number, reading the target serial number in the above step S500 includes but is not limited to step S540.
  • Step S540 Read the control word field carried in the Control Word Extension Header to obtain the target serial number.
  • the encapsulation format of the Control Word Extension Header can be as shown in Figure 9.
  • the embodiment of this application defines a new IPv6 extension header, called Control Word Extension Header, and adds the target serial number to the Control Word Extension Header.
  • the target node can obtain the target sequence number by reading the control word field of the Control Word Extension Header, thus extending the IPv6 specification to support the user data packet sequence number, which is in line with the future trend of pure IPv6 networks.
  • Figure 21 is a flow chart of another embodiment of reading the target sequence number in step S500 in Figure 16; specifically, the target IPv6 message contains the Upper-layer payload header Control Word Header, and Control When the Word Header carries a control word field, and the control word field carries a target serial number, reading the target serial number in the above step S500 includes but is not limited to step S550.
  • Step S550 Read the control word field carried in the Control Word Header to obtain the target serial number.
  • Control Word Header can be as shown in Figure 11.
  • This embodiment of the application defines a new Upper-layer payload type, called Control Word Header, and adds the target serial number to the Control Word Header.
  • the target node can obtain the target sequence number by reading the control word field of the Control Word Header, thus extending the IPv6 specification to support user data packet sequence numbers, which is in line with the future trend of pure IPv6 networks.
  • Figure 22 is a flow chart of an embodiment of step S400 in Figure 16; specifically, regarding receiving the target IPv6 message from the sending node in the above step S400, including but not limited to step S411 and step S412.
  • Step S411 Receive the data message, in which the data message is set with a Fragment Offset field and an M-flag field.
  • the Fragment Offset field carries an offset
  • the M-flag field carries a last bit identifier
  • Step S412 When the offset and the last bit identifier are both zero, determine that the data packet is the original packet and regard the data packet as the target IPv6 packet.
  • the offset in the Fragment Offset field and the last bit in the M-flag field in the data message received by the target node are both zero, it indicates that the data message is an unfragmented original packet. Then the original packages are sorted later.
  • Figure 23 is a flow chart of another embodiment of step S400 in Figure 16; specifically, regarding the receiving of the target IPv6 message from the sending node in the above step S400, including but not limited to steps S421, Step S422 and step S423.
  • Step S421 Receive the data message, in which the data message is set with a Fragment Offset field and an M-flag field.
  • the Fragment Offset field carries an offset
  • the M-flag field carries a last bit identifier
  • Step S422 When the offset or the last bit identifier is non-zero, determine that the data packet is a fragmented packet
  • Step S423 Obtain the original packet identifier carried by the fragmented message, and reassemble the multiple fragmented messages carrying the same original packet identifier to obtain the target IPv6 message, where the target IPv6 message is the original packet.
  • the target node when at least one of the offset in the Fragment Offset field and the last bit identifier in the M-flag field in the data message received by the target node is non-zero, it indicates that the data message is fragmented.
  • the corresponding original packet that is, the target IPv6 message, is first reassembled according to the specifications of RFC8200, and then the original packet is sorted.
  • Figure 24 is a flow chart of an embodiment of determining the sorting of target IPv6 messages according to the comparison results in step S500 in Figure 16; specifically, regarding the determination of the target IPv6 according to the comparison results in the above step S500
  • the sorting of messages includes but is not limited to step S560.
  • Step S560 When the target sequence number is equal to the expected sequence number, determine that the target IPv6 message is in order, and add one to the expected sequence number.
  • the expected sequence number is 1. If the target sequence number is equal to the expected sequence number later, the expected sequence number will increase by 1.
  • Figure 25 is a flow chart of another embodiment of determining the sorting of target IPv6 messages according to the comparison results in step S500 in Figure 16; specifically, regarding the determination of the target according to the comparison results in the above step S500
  • the sorting of IPv6 packets includes but is not limited to step S571, step S572 and step S573.
  • Step S571 When the target serial number is greater than the expected serial number, calculate the first difference between the target serial number and the expected serial number;
  • Step S572 When the first difference value is less than or equal to the first preset value, determine that the target IPv6 message is in order;
  • Step S573 When the first difference value is greater than the first preset value, it is determined that the target IPv6 packet is out of sequence.
  • first preset value may be preset manually.
  • Figure 26 is a flow chart of another embodiment of determining the sorting of target IPv6 messages according to the comparison results in step S500 in Figure 16; specifically, regarding the determination of the target according to the comparison results in the above step S500
  • the sorting of IPv6 packets includes but is not limited to step S581, step S582 and step S583.
  • Step S581 When the target serial number is smaller than the expected serial number, calculate the second difference between the expected serial number and the target serial number;
  • Step S582 When the second difference value is greater than or equal to the second preset value, determine that the target IPv6 message is in order;
  • Step S583 When the second difference value is less than the second preset value, it is determined that the target IPv6 packet is out of order.
  • the above-mentioned second preset value may be preset manually.
  • Figure 27 is a flow chart of an embodiment of processing the target IPv6 packet according to the sorting situation in step S600 in Figure 16; specifically, regarding the processing of the target IPv6 packet according to the sorting situation in the above step S600
  • the text is processed, including but not limited to step S610.
  • Step S610 If the sorting situation is in order, retain the target IPv6 message.
  • Figure 28 is a flow chart of another embodiment of processing the target IPv6 message according to the sorting situation in step S600 in Figure 16; specifically, regarding the processing of the target IPv6 message according to the sorting situation in the above step S600 The message is processed, including but not limited to step S620.
  • Step S620 If the sorting situation is out of order, discard the target IPv6 packet or reorder the target IPv6 packet.
  • the target IPv6 messages are retained; when the sorting situation is out of order, the target IPv6 messages are discarded or the target IPv6 messages are reordered.
  • IPv6 message processing method on the sending node side Based on the various embodiments of the IPv6 message processing method on the sending node side and the various embodiments of the IPv6 message processing method on the target node side, correspondingly, the IPv6 message processing method of the present application will be described in detail below with respect to various encapsulation methods. various embodiments.
  • RFC8200 defines the Fragment Header, which is used by the IPv6 sending node to fragment the message when the size of the message exceeds the MTU of the transmission path.
  • the Fragment Header contains Identification information, which is used to identify multiple fragments belonging to the same original package. That is, fragments belonging to the same original package should have the same source address (Source Address) and Destination Address (destination address). and Identification. If there are different original packets between the same source and destination that need to be fragmented, RFC8200 only requires that the Identification of these original packets must be different, and does not consider the ordering requirements between different original packets.
  • the following is an explanation of the fields in the Fragment Header encapsulation format defined by RFC8200 in Figure 4:
  • Next Header Prompts the type of lower header following the Fragment Header.
  • Fragment Offset The offset of the fragment relative to the starting position of the fragmentable part of the original package. For example, the offset of the first fragment is 0, the offset of the second fragment is the length of the first fragment, and the offset of the third fragment is the length of the first fragment and the second fragment. The sum of the lengths, and so on.
  • M-flag 0 indicates the last fragment, 1 indicates the non-last fragment.
  • the Fragment Header can be specified through control plane signaling negotiation or configuration to carry the corresponding sequence.
  • Number information that is, the Identification field in the Fragment Header is used to represent the serial number, which is an unsigned integer value.
  • the Identification of the Fragment Header encapsulated in the first data packet sent by the IPv6 sending node must be set to 1, and the Identification of the subsequent data packets sent successively increases by 1 in sequence.
  • the maximum Identification value is 4294967295, which then flips to 1. It is worth noting that the above data packets refer to the original unfragmented packets.
  • the Fragment Offset and M-flag in the Fragment Header are both set to 0 to indicate that the packet is an independent and complete packet.
  • the Fragment Offset, M-flag and Identification in the Fragment Header contained in each fragment are set according to the specifications of RFC8200.
  • an IPv6 node such as a network intermediate node implements DetNet's copy or elimination function
  • the original packet and the fragmented packet can be distinguished. If it is an original packet, the Identification in the Fragment Header contained in the original packet is used to distinguish different original packets. Package, if it is a fragmented package, the Identification in the Fragment Header contained in the fragmented package is used together with the Fragment Offset to distinguish different fragmented packages.
  • an IPv6 node such as an IPv6 target node
  • receives a packet it sorts the packets based on Identification, as follows:
  • the IPv6Destination node maintains the Expected Sequence Number variable. Initially, the Expected Sequence Number is 1.
  • the difference between the Identification and the Expected Sequence Number is calculated: if the difference is less than the first preset value, the message is also considered to be in order; if If the difference is greater than the first preset value, the packet is considered to be out of order, and the packet will be discarded or reordered locally.
  • the difference between the Expected Sequence Number and the Identification is calculated: if the difference is greater than the second preset value, the message is also considered to be in order ( Corresponding to the situation of sequence number reversal); if the difference is less than the second preset value, the packet is considered to be out of order, and the packet will be discarded or reordered locally.
  • RFC8200 defines Destination Options Header and Hop-by-Hop Options header to carry optional information.
  • the Destination Options Header is used by the destination node of the message, and its usage rules comply with the requirements of the control word;
  • the Hop-by-Hop Options header is used by the intermediate nodes in the message forwarding path, and it is not clear whether it meets the requirements of the control word.
  • a new Control Word Option is added to the Destination Options Header or Hop-by-Hop Options header.
  • the encapsulation format of the entire Destination Options Header or Hop-by-Hop Options header is as shown in Figure 6, in which each field The explanation is as follows:
  • Next Header Prompts the type of lower header following the Destination Options Header or Hop-by-Hop Options header.
  • Hdr Ext Len Prompts how many 8 bytes the entire Destination Options Header or Hop-by-Hop Options header occupies, not counting the first 8 bytes.
  • Option Type Prompts that the option type is a control word type, and its value is to be assigned by IANA.
  • Opt Data Len Prompts the number of bytes of the entire control word, set to 4.
  • Control word which can be all defined MPLS control words, such as Preferred PW MPLS Control Word and PW Associated Channel Header defined in RFC4385, or DetNet Control Word defined in RFC8964, or g-Ach (Generic Associated Channel) defined in RFC5586 , Universal Pipe) and so on. Please refer to the corresponding standards for the specific packaging formats of various control words. Among them, control words containing the Sequence Number field generally use a 16-bit sequence number.
  • the above Option Type can be assigned only one value to identify this option as a general Control Word, and then use the first 4 bits of the value of the Control Word to distinguish which specific control word it is. This is what is currently used in MPLS. way to take it. However, this method is not accurate. For example, currently in MPLS, both PWMCW and d-CW set the first 4 bits to 0, and additional service labels are required to distinguish whether it is PWMCW or d-CW.
  • the embodiment of this application recommends allocating multiple Option Types to distinguish different control words, such as:
  • Option Type-1 Preferred PW MPLS Control Word defined by RFC4385
  • Option Type-2 DetNet Control Word defined by RFC8964
  • Option Type-3 g-Ach defined by RFC5586
  • Control Word field does not need to copy the specific MPLS control words defined in the above standards, because the existing MPLS control words may have some MPLS-related fields. Like the first 4 bits, in IPv6, they can be optimized.
  • the following method can be used based on the control word information contained in the above-mentioned Destination Options Header or Hop-by-Hop Options header:
  • the Destination Options Header or Hop-by can be specified through signaling negotiation on the control plane or configuration.
  • -Hop Options header carries the corresponding control word, which contains the corresponding Sequence Number information.
  • the sequence number of the Destination Options Header or Hop-by-Hop Options header encapsulated in the first data packet sent by IPv6Source must be set to 1, and the Sequence Number of subsequent data packets sent successively increases by 1. .
  • the maximum serial number value is 65535, which then flips to 1. Note that the data packets referred to here refer to the original unfragmented packets.
  • a Fragment Header can be further inserted into the message according to RFC8200 specifications. At this time, the Idenfitication in the Fragment Header can only distinguish different original packages, and there is no requirement whether to increment in sequence.
  • an IPv6 node such as an intermediate node implements the replication or elimination function of DetNet
  • the original packet and the fragmented packet can be distinguished. If it is an original packet, the Destination Options Header or Hop-by-Hop Options header contained in the original packet
  • the control word is used to distinguish different original packages. If it is a fragmented package, in addition to the above control words, it is also necessary to combine the Identification and Fragment Offset in the Fragment Header contained in the fragmented package to distinguish different fragmented packages.
  • an IPv6 node such as the destination node receives a packet, it processes the packet based on the sequence number as follows:
  • the IPv6Destination node maintains the Expected Sequence Number variable. Initially, Expected Identification is 1.
  • the difference between the Sequence Number and the Expected Sequence Number is calculated: if the difference is less than the first preset value, the message is also considered to be in order. ; If the difference is greater than the first preset value, the packet is considered to be out of order, and the packet will be discarded or reordered locally.
  • the difference between the Expected Sequence Number and the Sequence Number is calculated: if the difference is greater than the second preset value, the message is also considered to be in order. (Corresponding to the situation of sequence number flipping); if the difference is less than the second preset value, the packet is considered to be out of order, and the packet will be discarded or reordered locally.
  • Control Word Extension Header the corresponding Header type is to be allocated by IANA.
  • IANA IPv6 extension header
  • Next Header Prompts the type of lower header following the Control Word Extension Header.
  • CW Type Prompt control word type, its value is to be assigned by IANA, as follows:
  • CW Type-1 Preferred PW MPLS Control Word defined by RFC4385
  • CW Type-2 DetNet Control Word defined by RFC8964
  • CW Type-3 g-Ach defined by RFC5586
  • Control word depending on CW Type, can be all defined MPLS control words, such as Preferred PW MPLS Control Word and PW Associated Channel Header defined in RFC4385, or DetNet Control Word defined in RFC8964, or g- defined in RFC5586 Ach, wait. Please refer to the corresponding standards for the specific packaging formats of various control words. Among them, control words containing the Sequence Number field generally use a 16-bit sequence number.
  • Control Word Extension Header For user data packets that need to be sorted, such as packets forwarded along the PW, or DetNet packets that are redundantly copied along multiple paths, the Control Word Extension Header can be specified through signaling negotiation on the control plane or configuration to carry the corresponding The processing of the control word is similar to the solution corresponding to the Destination Options Header shown in Figure 6 above, and will not be described again here.
  • control word is introduced in the IPv6 extension header.
  • the idea is to treat the control word as information provided by PSN (Packet Switched Network) itself.
  • PSN Packet Switched Network
  • a new Upper-Layer load type can also be defined, called Control Word Header, and the corresponding Header type is to be allocated by IANA.
  • CW Type Prompt control word type, its value is to be assigned by IANA. for example:
  • CW Type-1 Preferred PW MPLS Control Word defined by RFC4385
  • CW Type-2 DetNet Control Word defined by RFC8964
  • CW Type-3 g-Ach defined by RFC5586
  • Protocol Type Prompts the type of lower protocol header following the Control Word Header.
  • Control Word which can be all defined MPLS control words, such as Preferred PW MPLS Control Word and PW Associated Channel Header defined by RFC4385, or DetNet Control Word defined by RFC8964, or g-Ach defined by RFC5586, etc. Please refer to the corresponding standards for the specific packaging formats of various control words. Among them, control words containing the Sequence Number field generally use a 16-bit sequence number.
  • Control Word Header For user data packets that need to be sorted, such as packets forwarded along the PW, or DetNet packets that are redundantly copied along multiple paths, the Control Word Header can be specified through signaling negotiation on the control plane or configuration to carry the corresponding The processing of the control word is similar to the solution corresponding to the Destination Options Header shown in Figure 6 above, and will not be described again here.
  • Figure 29 is a schematic diagram of the SRv6 transmission path of a typical VPWS PW carried on the PSN.
  • the TDM service flow is transmitted on the PW, and the order of service packets needs to be guaranteed. Therefore, PE1 and PE2 negotiate the SRv6servcie SID of the PW (usually END.DX2, refer to draft-ietf-bess-srv6-services-15). , can explicitly negotiate the control word that needs to encapsulate any of the above encapsulation methods defined in this patent.
  • the encapsulation of the user data packet sent by PE1 along the PW may be:
  • TDM payload where DOH refers to the Destination Options Header.
  • PE2 When PE2 receives the message, it parses the control word, obtains the sequence number information, and implements message sorting.
  • Figure 30 is an example diagram of redundant copying and elimination of typical DetNet business flows.
  • src and dst are the source and destination nodes of the deterministic business flow respectively
  • all R nodes are nodes that implement the replication function (replication function)
  • all E nodes are nodes that implement the elimination function (elimination function)
  • all O The node is the node that implements the ordering function. Assume that the entire network is a pure IPv6 network.
  • control word of any of the above encapsulation methods defined in the embodiments of this application is encapsulated on the src node for the deterministic service flow.
  • control word information contained in the copied flow is the same as the received flow; all E nodes eliminate duplicate messages based on the control word information contained in the received redundant flow; All O nodes sort the messages according to the control word information contained in the original packet received.
  • the sending node includes a memory, a processor, and a computer program stored in the memory and executable on the processor.
  • the processor executes the computer program, it implements the above-mentioned application in sending. IPv6 packet processing method on the node side.
  • sending node in this embodiment can correspond to the sending node in the implementation environment in the embodiment as shown in Figure 1.
  • the two belong to the same application concept, so they have the same implementation principles and benefits. The effect will not be detailed here.
  • the non-transient software programs and instructions required to implement the IPv6 message processing method of the above embodiment are stored in the memory.
  • the IPv6 message processing method of the above embodiment is executed.
  • the above-described figure is executed. Method steps 2, 3, 5, 7, 8, 10, 12 to 15.
  • an embodiment of the present application provides a target node, which includes a memory, a processor, and a computer program stored in the memory and executable on the processor.
  • the processor executes the computer program, the above-mentioned application is implemented. IPv6 packet processing method on the target node side.
  • target node in this embodiment can correspond to the target node in the implementation environment in the embodiment as shown in Figure 1.
  • the two belong to the same application concept, so they have the same implementation principles and benefits. The effect will not be detailed here.
  • the non-transient software programs and instructions required to implement the IPv6 message processing method of the above embodiment are stored in the memory.
  • the IPv6 message processing method of the above embodiment is executed.
  • the above-described figure is executed. 16 to the method steps in Figure 28.
  • an embodiment of the present application also provides a computer-readable storage medium that stores computer-executable instructions.
  • the computer-executable instructions are used to execute the above-mentioned IPv6 message processing method, for example, The method steps described above in Figures 2, 3, 5, 7, 8, 10, 12 to 28 are carried out.
  • an embodiment of the present application also discloses a computer program product, which includes a computer program or computer instructions.
  • the computer program or computer instructions are stored in a computer-readable storage medium.
  • the processor of the computer device reads the computer program from the computer-readable storage medium.
  • the computer program or computer instructions are obtained, and the processor executes the computer program or computer instructions, so that the computer device performs the IPv6 message processing method as in any of the previous embodiments.
  • Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, Digital Versatile Disk (DVD) or other optical disk storage, magnetic cassettes, tapes, disk storage or other magnetic storage devices, or may Any other medium used to store the desired information and that can be accessed by a computer.
  • communication media typically includes computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism, and may include any information delivery media .

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本申请实施例提供了一种IPv6报文处理方法、节点、存储介质和程序产品，包括：发送节点获取待发送的目标IPv6报文，根据目标IPv6报文的发送顺序确定目标序列号，并将目标序列号添加至目标IPv6报文中，以及将携带有目标序列号的目标IPv6报文发送至目标节点，然后目标节点将目标序列号和期望序列号进行比较，并根据比较结果确定目标IPv6报文的排序情况，以及根据排序情况对目标IPv6报文进行处理。本申请实施例中，对于需要排序的目标IPv6报文，发送节点可以按照发送顺序在目标IPv6报文中添加目标序列号。

Description

IPv6报文处理方法、节点、存储介质和程序产品
相关申请的交叉引用
本申请基于申请号为202210438583.0、申请日为2022年04月25日的中国专利申请提出，并要求该中国专利申请的优先权，该中国专利申请的全部内容在此引入本申请作为参考。
技术领域
本申请涉及通信技术领域，尤其是一种IPv6报文处理方法、节点、存储介质和程序产品。
背景技术
随着越来越多的网络从MPLS(Multiprotocol Label Switching，多协议标签交换)承载向IPv6(I nternet Protocol Version 6，互联网协议第6版)升级，用户数据流将统一采用IPv6封装。对业务而言，只是承载方式发生了改变，而业务的SLA(Service Level Agreement，服务等级协定)如用户数据报文的乱序保证仍然需要得到满足。然而对于当前的IPv6规范，由于自身缺乏对用户数据报文序列号的支持，因此需要依赖于其它方式，例如在IPv6封装中插入MPLS标签和MPLS控制字，但是这种方式不符合未来纯IPv6网络的趋势。
发明内容
以下是对本文详细描述的主题的概述。本概述并非是为了限制权利要求的保护范围。
本申请实施例提供了一种IPv6报文处理方法、节点、存储介质和程序产品，能够对IPv6规范进行扩展以支持用户数据报文序列号，从而能够实现报文的排序处理。
一方面，本申请实施例提供了一种IPv6报文处理方法，应用于发送节点，所述方法包括：获取待发送的目标IPv6报文；根据所述目标IPv6报文的发送顺序确定目标序列号，并将所述目标序列号添加至所述目标IPv6报文中；将携带有所述目标序列号的所述目标IPv6报文发送至目标节点，以使所述目标节点根据所述目标序列号对所述目标IPv6报文进行处理。
另一方面，本申请实施例还提供了一种IPv6报文处理方法，应用于目标节点，所述方法包括：接收来自发送节点的目标IPv6报文，其中，所述目标IPv6报文携带有目标序列号，所述目标序列号由所述发送节点根据所述目标IPv6报文的发送顺序确定得到；读取所述目标序列号，将所述目标序列号和期望序列号进行比较，并根据比较结果确定所述目标IPv6报文的排序情况；根据所述排序情况对所述目标IPv6报文进行处理。
另一方面，本申请实施例还提供了一种发送节点，包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现如前面所述的应用于发送节点的报文处理方法。
另一方面，本申请实施例还提供了一种目标节点，包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现如前面所述的应用于目标节点的报文处理方法。
另一方面，本申请实施例还提供了一种计算机可读存储介质，存储有计算机可执行指令，所述计算机可执行指令用于执行如前面所述的报文处理方法。
另一方面，本申请实施例还提供了一种计算机程序产品，包括计算机程序或计算机指令，所述计算机程序或所述计算机指令存储在计算机可读存储介质中，计算机设备的处理器从所述计算机可读存储介质读取所述计算机程序或所述计算机指令，所述处理器执行所述计算机程序或所述计算机指令，使得所述计算机设备执行如前面所述的报文处理方法。
本申请实施例中，对于需要排序的目标IPv6报文，发送节点可以按照目标IPv6报文的发送顺序确定目标序列号，并将目标序列号添加至所述目标IPv6报文中，并将携带有目标序列号的目标IPv6报文发送至目标节点，从而可以使得目标节点能够根据目标IPv6报文所携带的目标序列号对目标IPv6报文进行排序处理，能够对IPv6规范进行扩展以支持用户数据报文序列号，符合未来纯IPv6网络的趋势。
本申请的其它特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变得显而易见，或者通过实施本申请而了解。本申请的目的和其他优点可通过在说明书、权利要求书以及附图中所特别指出的结构来实现和获得。
附图说明
附图用来提供对本申请技术方案的进一步理解，并且构成说明书的一部分，与本申请的实施例一起用于解释本申请的技术方案，并不构成对本申请技术方案的限制。
图1是本申请一个实施例提供的用于执行IPv6报文处理方法的实施环境的示意图；
图2是本申请一个实施例提供的应用于发送节点侧的IPv6报文处理方法的流程图；
图3是图2中步骤S200的一个实施例的流程图；
图4是本申请一个实施例提供的Fragment Header的封装格式示意图；
图5是图2中步骤S200的另一个实施例的流程图；
图6是本申请一个实施例提供的Destination Options Header的封装格式示意图；
图7是图2中步骤S200的另一个实施例的流程图；
图8是图2中步骤S200的另一个实施例的流程图；
图9是本申请一个实施例提供的Control Word Extension Header的封装格式示意图；
图10是图2中步骤S200的另一个实施例的流程图；
图11是本申请一个实施例提供的Control Word Header的封装格式示意图；
图12是图2中步骤S300的一个实施例的流程图；
图13是图2中步骤S300的另一个实施例的流程图；
图14是图12中步骤S320的一个实施例的流程图；
图15是图13中步骤S330的一个实施例的流程图；
图16是本申请一个实施例提供的目标节点侧的IPv6报文处理方法的流程图；
图17是图16中步骤S500中读取目标序列号的一个实施例的流程图；
图18是图16中步骤S500中读取目标序列号的另一个实施例的流程图；
图19是图16中步骤S500中读取目标序列号的另一个实施例的流程图；
图20是图16中步骤S500中读取目标序列号的另一个实施例的流程图；
图21是图16中步骤S500中读取目标序列号的另一个实施例的流程图；
图22是图16中步骤S400的一个实施例的流程图；
图23是图16中步骤S400的另一个实施例的流程图；
图24是图16中步骤S500中的根据比较结果确定目标IPv6报文的排序情况的一个实施例的流程图；
图25是图16中步骤S500中的根据比较结果确定目标IPv6报文的排序情况的另一个实施例的流程图；
图26是图16中步骤S500中的根据比较结果确定目标IPv6报文的排序情况的另一个实施例的流程图；
图27是图16中步骤S600中的根据排序情况对目标IPv6报文进行处理的一个实施例的流程图；
图28是图16中步骤S600中的根据排序情况对目标IPv6报文进行处理的另一个实施例的流程图；
图29是典型的VPWS PW承载在PSN的SRv6传输路径的示意图；
图30是典型的DetNet业务流的冗余复制与消除示例图。
具体实施方式
为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处所描述的具体实施例仅用以解释本申请，并不用于限定本申请。
需要说明的是，虽然在装置示意图中进行了功能模块划分，在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于装置中的模块划分，或流程图中的顺序执行所示出或描述的步骤。说明书、权利要求书或上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。
在相关技术中，MPLS报文是指由MPLS标签栈所封装的报文，对于紧随标签栈底之后的载荷类型，一般没有足够的信息去严格的识别。经典的做法是假设跟随在标签栈之后的载荷是IP报文，并基于此假设，检查载荷的前4比特如果是数值4或6，就将载荷当成IPv4报文或IPv6报文。然而这样的判断显然无法涵盖non-IP的载荷，比如承载在MPLS PW(Pseudo Wire，伪线)上二层载荷(如Ethernet,PPP,Frame Relay,TDM等)。为此，进一步的补救方式是控制面的协议在协商业务标签(如PW标签)时，就显式的指定该标签所封装的载荷类型，并在创建的相应标签转发表项中维护所封装的载荷类型信息。那么，当一个节点收到MPLS报文并匹配到相应的标签转发表项时，可结合表项中维护的载荷类型信息去解析报文。对于标签转发表项中维护的载荷类型信息，可以是二层载荷类型，或控制字类型。需要注意的是，这种方法只能用于维护业务标签转发表项的网络出口节点上，而网络中间节点上没有也不需要维护相关的业务标签转发表项，所以中间节点上只能依赖报文自身的信息去推测标签栈之后的载荷类型。
然而，现有网络中，中间节点上的确会解析MPLS报文并根据其载荷类型实施ECMP(Equal Cost  Multi-path，等价多路径)的处理。因此，中间节点有可能会把一个二层载荷误当成IP载荷，然后根据错误获取到的IP五元组实施ECMP哈希，导致同一业务的多个报文可能有不同的哈希结果并沿不同的路径进行转发，最终导致报文乱序。为了避免这种情况，RFC4385定义了MPLS控制字，包括PWMCW(PW MPLS Control Word，伪线控制字)和PWACH(PW Associated Channel Header，伪线管道头)，前者用于封装用户数据报文，后者用于封装OAM(Operations，Administration and Maintenance，操作、管理和维护)报文。控制字引入的目的是很简单，就是为了显式的与IP载荷区分开来，阻止中间节点在实施ECMP时去错误的将non-IP载荷当成IP载荷，因此控制字的前4比特的值不能是4或6。RFC5586进一步将PWACH更名为G-Ach(Generic Associated Channel，通用关联信道)，将适用范围从MPLS PW拓宽到所有类型的MPLS LSP。
其中，PWMCW除了能够与IP载荷进行区分以外，还包含有报文序列号(Sequence Number)信息，可用于用户数据报文的乱序检查和重组，适用于对报文乱序敏感的业务，如TDM仿真业务。类似的，RFC8964也在定义的DetNet(Deterministic Network，确定性网络)的MPLS封装方案中，引入了d-CW(DetNet Control Word，确定性网络控制字)，其中包含序列号信息，用于DetNet业务子层的报文排序功能，以提供乱序指标的确定性。
随着越来越多的网络从MPLS承载向IPv6(特别是SRv6)升级，用户数据流将统一采用IPv6封装。对业务而言，只是承载方式发生了改变，而业务的SLA(Service Level Agreement，服务等级协定)仍然需要得到满足，比如，用户数据报文的乱序保证。然而，当前的IPv6规范中，自身缺乏对用户数据报文序列号的支持，而依赖于其它方式，比如在IPv6封装中插入MPLS标签和MPLS控制字，但这种方式不符合未来纯IPv6网络的趋势。
基于上述情况，本申请实施例提供了一种IPv6报文处理方法、发送节点、目标节点、计算机可读存储介质和计算机程序产品，对于需要排序的目标IPv6报文，发送节点可以按照目标IPv6报文的发送顺序确定目标序列号，并将目标序列号添加至目标IPv6报文中，并将携带有目标序列号的目标IPv6报文发送至目标节点，从而可以使得目标节点能够根据目标IPv6报文所携带的目标序列号对目标IPv6报文进行排序处理，能够对IPv6规范进行扩展以支持用户数据报文序列号，符合未来纯IPv6网络的趋势。
下面结合附图，对本申请实施例作进一步阐述。
如图1所示，图1是本申请一个实施例提供的用于执行IPv6报文处理方法的实施环境的示意图。
在图1的示例中，该实施环境设置有发送节点100和目标节点200，其中，发送节点100和目标节点200之间通信连接。
其中，有发送节点100和目标节点200中均设置有处理器和存储器，其中，处理器和存储器可以通过总线或者其他方式连接。
存储器作为一种非暂态计算机可读存储介质，可用于存储非暂态软件程序以及非暂态性计算机可执行程序。此外，存储器可以包括高速随机存取存储器，还可以包括非暂态存储器，例如至少一个磁盘存储器件、闪存器件、或其他非暂态固态存储器件。在一些实施方式中，存储器可选包括相对于处理器远程设置的存储器，这些远程存储器可以通过网络连接至该实施环境。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。
另外，需要说明的是，在该实施环境中，发送节点100和目标节点200之间还可以设置有中间节点，其中，发送节点100和目标节点200分别与中间节点通信连接。
本领域技术人员可以理解的是，该实施环境可以应用于当前的通信网络系统以及后续演进的移动通信网络系统等，本实施例对此并不作具体限定。
本领域技术人员可以理解的是，图1中示出的实施环境并不构成对本申请实施例的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。
在图1所示的实施环境中，发送节点100或者目标节点200中的处理器可以调用储存在存储器中的IPv6报文处理程序，从而执行IPv6报文处理方法。
基于上述实施环境，下面提出本申请的发送节点侧的IPv6报文处理方法的各个实施例。
如图2所示，图2是本申请一个实施例提供的发送节点侧的IPv6报文处理方法的流程图，该方法应用于发送节点，包括但不限于有步骤S100、步骤S200和步骤S300。
步骤S100、获取待发送的目标IPv6报文；
步骤S200、根据目标IPv6报文的发送顺序确定目标序列号，并将目标序列号添加至目标IPv6报文中；
步骤S300、将携带有目标序列号的目标IPv6报文发送至目标节点，以使目标节点根据目标序列号对目标IPv6报文进行处理。
具体地，对于需要排序的目标IPv6报文，发送节点可以按照目标IPv6报文的发送顺序确定目标序列号，并将目标序列号添加至目标IPv6报文中，然后将携带有目标序列号的目标IPv6报文发送至目标节点，从而可以使得目标节点能够根据目标IPv6报文所携带的目标序列号对目标IPv6报文进行排序处理，因此， 本申请实施例能够对IPv6规范进行扩展以支持用户数据报文序列号，符合未来纯IPv6网络的趋势。
需要说明的是，关于上述的目标IPv6报文，具体是指未分片的原包；因此对应地，上述的发送顺序是指针对同样的数据流的情况下原包的发送顺序。
另外，需要说明的是，本申请实施例的目标序列号是根据目标IPv6报文的发送顺序确定的，具体地，当目标IPv6报文的发送顺序越靠前，对应的目标序列号的数值越小；相反地，当目标IPv6报文的发送顺序越靠后，对应的目标序列号的数值越大。
另外，需要说明的是，对于不同的目标IPv6报文，即对于不同的原包，其各自携带的目标序列号均不一致；对于由同一个目标IPv6报文分片得到的多个分片报文，其各自携带的目标序列号均一致。
值得注意的是，关于目标序列号在目标IPv6报文中的添加位置，具体参见下图3至图11所示，分别如下：
如图3所示，图3是图2中步骤S200的一个实施例的流程图；具体地，在目标IPv6报文包含有IPv6扩展头Fragment Header的情况下，关于上述步骤S200中的将目标序列号添加至目标IPv6报文中，包括但不限于有步骤S210。
步骤S210、将目标序列号添加至Fragment Header的Identification字段中。
需要说明的是，当前的IPv6规范定义了Fragment Header，可用于当报文的大小超过了传输路径的MTU(Maximum Transmission Unit，最大传输单元)时，IPv6source对报文进行分片，虽然Fragment Header中包含有标识信息，但其作用仅限于识别属于相同原包的多个分片。
对此，本申请实施例复用Fragment Header，其中，Fragment Header的封装格式可以如图4所示，本申请实施例通过将目标序列号添加至Fragment Header的Identification字段中，从而对IPv6规范进行扩展以支持用户数据报文序列号，符合未来纯IPv6网络的趋势。
如图5所示，图5是图2中步骤S200的另一个实施例的流程图；具体地，在目标IPv6报文包含有IPv6扩展头Destination Options Header的情况下，关于上述步骤S200中的将目标序列号添加至目标IPv6报文中，包括但不限于有步骤S221和步骤S222。
步骤S221、在Destination Options Header中增加控制字选项；
步骤S222、将目标序列号添加至控制字选项中的控制字字段中。
具体地，Destination Options Header的封装格式可以如图6所示，本申请实施例通过在Destination Options Header中新增控制字选项并且将目标序列号添加至控制字选项中的控制字字段中，从而对IPv6规范进行扩展以支持用户数据报文序列号，符合未来纯IPv6网络的趋势。
如图7所示，图7是图2中步骤S200的另一个实施例的流程图；具体地，在目标IPv6报文包含有IPv6扩展头Hop-by-Hop Options Header的情况下，关于上述步骤S200中的将目标序列号添加至目标IPv6报文中，包括但不限于有步骤S231和步骤S232。
步骤S231、在Hop-by-Hop Options Header中增加控制字选项；
步骤S232、将目标序列号添加至控制字选项中的控制字字段中。
具体地，Hop-by-Hop Options Header的封装格式同样可以如图6所示，本申请实施例通过在Hop-by-Hop Options Header中新增控制字选项并且将目标序列号添加至控制字选项中的控制字字段中，从而对IPv6规范进行扩展以支持用户数据报文序列号，符合未来纯IPv6网络的趋势。
如图8所示，图8是图2中步骤S200的另一个实施例的流程图；具体地，在目标IPv6报文包含有IPv6扩展头Control Word Extension Header的情况下，关于上述步骤S200中的将目标序列号添加至目标IPv6报文中，包括但不限于有步骤S240。
步骤S240、将目标序列号添加至Control Word Extension Header中的控制字字段中。
具体地，Control Word Extension Header的封装格式可以如图9所示，本申请实施例通过定义一种新的IPv6扩展头，称为Control Word Extension Header，并通过将目标序列号添加至Control Word Extension Header的控制字字段中，从而对IPv6规范进行扩展以支持用户数据报文序列号，符合未来纯IPv6网络的趋势。
如图10所示，图10是图2中步骤S200的另一个实施例的流程图；具体地，在目标IPv6报文包含有Upper-layer载荷头Control Word Header的情况下，关于上述步骤S200中的将目标序列号添加至目标IPv6报文中，包括但不限于有步骤S250。
步骤S250、将目标序列号添加至Control Word Header中的控制字字段中。
具体地，Control Word Header的封装格式可以如图11所示，本申请实施例通过定义一种新的Upper-layer载荷类型，称为Control Word Header，并通过将目标序列号添加至Control Word Header的控制字字段中，从而对IPv6规范进行扩展以支持用户数据报文序列号，符合未来纯IPv6网络的趋势。
值得注意的是，关于上述步骤S300中的发送目标IPv6报文至目标节点的过程，具体参见下图12至图15所示，分别如下：
如图12所示，图12是图2中步骤S300的一个实施例的流程图；具体地，关于上述步骤S300中的将携带有目标序列号的目标IPv6报文发送至目标节点，包括但不限于有步骤S310和步骤S320。
步骤S310、获取目标IPv6报文的数据量；
步骤S320、当数据量小于或等于发送节点和目标节点之间的传输路径的最大传输量，按照预设规范对完整的目标IPv6报文中的偏移量和末位标识进行设置，并将设置后的完整的目标IPv6报文发送至目标节点。
具体地，如果发送节点和目标节点之间的传输路径的最大传输量大于目标IPv6报文的数据量，则表明无需对目标IPv6报文进行分片，因此，本申请实施例可以按照预设规范对作为原包的目标IPv6报文中的偏移量和末位标识进行设置。
需要说明的是，在预设规范中，当目标IPv6报文作为原包发送时，其偏移量Fragment Offset对应为0，其末位标识M-flag也对应为0。
如图13所示，图13是图2中步骤S300的另一个实施例的流程图；具体地，关于上述步骤S300中的将携带有目标序列号的目标IPv6报文发送至目标节点，包括但不限于有步骤S310和步骤S330。
步骤S310、当数据量大于发送节点和目标节点之间的传输路径的最大传输量，将目标IPv6报文切分为多个分片报文；
步骤S330、按照预设规范对分片报文中的偏移量和末位标识均进行设置，并将设置后的多个分片报文发送至目标节点。
具体地，如果发送节点和目标节点之间的传输路径的最大传输量小于目标IPv6报文的数据量，则表明需要对目标IPv6报文进行分片后才可以正常传输，因此，本申请实施例会将目标IPv6报文切分为多个分片报文，然后再按照预设规范对多个分片报文中的偏移量和末位标识进行设置。
需要说明的是，在预设规范中，当目标IPv6报文切分为多个分片报文进行发送时，第一个分片报文的偏移量Fragment Offset对应为0，第二个分片报文的偏移量Fragment Offset对应为第一个分片的长度，第三个分片报文的偏移量Fragment Offset对应为第一个分片和第二个分片的长度之和，如此类推。另外，最后一个分片报文的末位标识M-flag对应为0，非最后一个分片报文的末位标识M-flag对应为1。
另外，如图14所示，图14是图12中步骤S320的一个实施例的流程图；具体地，关于上述步骤S320中的将设置后的完整的目标IPv6报文发送至目标节点，包括但不限于有步骤S321。
步骤S321、将设置后的完整的目标IPv6报文发送至中间节点，以使中间节点读取目标IPv6报文所携带的源地址、目的地址和原包标识，并通过中间节点过滤重复的携带有相同的源地址、目的地址和原包标识的目标IPv6报文，以及通过中间节点将保留的目标IPv6报文转发至目标节点。
具体地，当中间节点实施DetNet消除功能时，多份具有相同的源地址、目的地址和原包标识的原包，将被消除只保留一份。
需要说明的是，本申请实施例可以通过同时对比多个原包的源地址、目的地址和原包标识，若三者均为一致，则表明为相同的原包；若三者中存在至少一者不一致，则表明为不同的原包。
另外，如图15所示，图15是图13中步骤S330的一个实施例的流程图；具体地，关于上述步骤S330中的将设置后的多个分片报文发送至目标节点，包括但不限于有步骤S331。
步骤S331、将设置后的多个分片报文发送至中间节点，以使中间节点读取分片报文所携带的源地址、目的地址、原包标识和偏移量，并通过中间节点过滤重复的携带有相同的源地址、目的地址、原包标识和偏移量的分片报文，以及通过中间节点将保留的分片报文转发至目标节点。
具体地，当中间节点实施DetNet消除功能时，多份具有相同的源地址、目的地址、原包标识和偏移量的分片包，将被消除只保留一份。
需要说明的是，本申请实施例可以通过同时对比多个分片包的源地址、目的地址、原包标识和偏移量，若四者均为一致，则表明为相同的分片包；若四者中存在至少一者不一致，则表明为不同的分片包。
基于上述图2至图15中的发送节点侧的IPv6报文处理方法的各个实施例，对应地，下面提出本申请的目标节点侧的IPv6报文处理方法的各个实施例。
如图16所示，图16是本申请一个实施例提供的目标节点侧的IPv6报文处理方法的流程图，该方法应用于目标节点，包括但不限于有步骤S400、步骤S500和步骤S600。
步骤S400、接收来自发送节点的目标IPv6报文，其中，目标IPv6报文携带有目标序列号，目标序列号由发送节点根据目标IPv6报文的发送顺序确定得到；
步骤S500、读取目标序列号，将目标序列号和期望序列号进行比较，并根据比较结果确定目标IPv6报文的排序情况；
步骤S600、根据排序情况对目标IPv6报文进行处理。
具体地，对于需要排序的目标IPv6报文，发送节点可以按照目标IPv6报文的发送顺序确定目标序列号，并将目标序列号添加至目标IPv6报文中，然后将携带有目标序列号的目标IPv6报文发送至目标节点， 接着，目标节点会将目标序列号和期望序列号进行比较，并根据比较结果确定目标IPv6报文的排序情况，再根据排序情况对目标IPv6报文进行处理。因此，本申请实施例能够对IPv6规范进行扩展以支持用户数据报文序列号，符合未来纯IPv6网络的趋势。
需要说明的是，关于上述的目标IPv6报文，具体是指未分片的原包；因此对应地，上述的发送顺序是指针对同样的数据流的情况下原包的发送顺序。
可以理解的是，本申请实施例的目标序列号是根据目标IPv6报文的发送顺序确定的，具体地，当目标IPv6报文的发送顺序越靠前，对应的目标序列号的数值越小；相反地，当目标IPv6报文的发送顺序越靠后，对应的目标序列号的数值越大。
另外，需要说明的是，对于不同的目标IPv6报文，即对于不同的原包，其各自携带的目标序列号均不一致；对于由同一个目标IPv6报文分片得到的多个分片报文，其各自携带的目标序列号均一致。
另外，需要说明的是，关于上述的期望序列号，为不断累加更新得到的。具体地，下一个期望序列号是由目标节点根据当前接收到的目标序列号和当前的期望序列号的比较结果确定得到。可以理解的是，最初始的期望序列号可以是人为设置的。
另外，需要说明的是，关于本申请实施例的目标节点侧的IPv6报文处理方法的具体实施方式和技术效果，可以参照上述实施例的发送节点侧的IPv6报文处理方法的具体实施方式和技术效果。
值得注意的是，关于步骤S500中目标序列号的读取位置，具体参见下图17至图21所示，分别如下：
如图17所示，图17是图16中步骤S500中读取目标序列号的一个实施例的流程图；具体地，在目标IPv6报文包含有IPv6扩展头Fragment Header，并且IPv6扩展头Fragment Header的Identification字段携带有目标序列号的情况下，关于上述步骤S500中的读取目标序列号，包括但不限于有步骤S510。
步骤S510、读取Identification字段，得到目标序列号。
需要说明的是，当前的IPv6规范定义了Fragment Header，可用于当报文的大小超过了传输路径的MTU时，IPv6source对报文进行分片，虽然Fragment Header中包含有标识信息，但其作用仅限于识别属于相同原包的多个分片。
对此，本申请实施例复用Fragment Header，其中，Fragment Header的封装格式可以如图4所示，本申请实施例通过将目标序列号添加至Fragment Header的Identification字段中，使得目标节点读取该Identification字段即可得到目标序列号，从而对IPv6规范进行扩展以支持用户数据报文序列号，符合未来纯IPv6网络的趋势。
如图18所示，图18是图16中步骤S500中读取目标序列号的另一个实施例的流程图；具体地，在目标IPv6报文包含有IPv6扩展头Destination Options Header，并且Destination Options Header中携带有控制字选项，以及控制字选项的控制字字段携带有目标序列号的情况下，关于上述步骤S500中的读取目标序列号，包括但不限于有步骤S520。
步骤S520、读取控制字选项的控制字字段，得到目标序列号。
具体地，Destination Options Header的封装格式可以如图6所示，本申请实施例通过在Destination Options Header中新增控制字选项并且将目标序列号添加至控制字选项中的控制字字段中，使得目标节点读取该控制字选项的控制字字段即可得到目标序列号，从而对IPv6规范进行扩展以支持用户数据报文序列号，符合未来纯IPv6网络的趋势。
如图19所示，图19是图16中步骤S500中读取目标序列号的另一个实施例的流程图；具体地，在目标IPv6报文包含有IPv6扩展头Hop-by-Hop Options Header，并且Hop-by-Hop Options Header中携带有控制字选项，以及控制字选项的控制字字段携带有目标序列号的情况下，关于上述步骤S500中的读取目标序列号，包括但不限于有步骤S530。
步骤S530、读取控制字选项的控制字字段，得到目标序列号。
具体地，Hop-by-Hop Options Header的封装格式同样可以如图6所示，本申请实施例通过在Hop-by-Hop Options Header中新增控制字选项并且将目标序列号添加至控制字选项中的控制字字段中，使得目标节点读取该控制字选项的控制字字段即可得到目标序列号，从而对IPv6规范进行扩展以支持用户数据报文序列号，符合未来纯IPv6网络的趋势。
如图20所示，图20是图16中步骤S500中读取目标序列号的另一个实施例的流程图；具体地，在目标IPv6报文包含有IPv6扩展头Control Word Extension Header，并且Control Word Extension Header中携带有控制字字段，以及控制字字段携带有目标序列号的情况下，关于上述步骤S500中的读取目标序列号，包括但不限于有步骤S540。
步骤S540、读取Control Word Extension Header中携带的控制字字段，得到目标序列号。
具体地，Control Word Extension Header的封装格式可以如图9所示，本申请实施例通过定义一种新的IPv6扩展头，称为Control Word Extension Header，并通过将目标序列号添加至Control Word Extension Header的控制字字段中，使得目标节点读取该Control Word Extension Header的控制字字段 即可得到目标序列号，从而对IPv6规范进行扩展以支持用户数据报文序列号，符合未来纯IPv6网络的趋势。
如图21所示，图21是图16中步骤S500中读取目标序列号的另一个实施例的流程图；具体地，在目标IPv6报文包含有Upper-layer载荷头Control Word Header，并且Control Word Header中携带有控制字字段，以及控制字字段携带有目标序列号的情况下，关于上述步骤S500中的读取目标序列号，包括但不限于有步骤S550。
步骤S550、读取Control Word Header中携带的控制字字段，得到目标序列号。
具体地，Control Word Header的封装格式可以如图11所示，本申请实施例通过定义一种新的Upper-layer载荷类型，称为Control Word Header，并通过将目标序列号添加至Control Word Header的控制字字段中，使得目标节点读取该Control Word Header的控制字字段即可得到目标序列号，从而对IPv6规范进行扩展以支持用户数据报文序列号，符合未来纯IPv6网络的趋势。
值得注意的是，关于上述步骤S400中的接收来自发送节点的目标IPv6报文的过程，具体参见下图22至图23所示，分别如下：
如图22所示，图22是图16中步骤S400的一个实施例的流程图；具体地，关于上述步骤S400中的接收来自发送节点的目标IPv6报文，包括但不限于有步骤S411和步骤S412。
步骤S411、接收数据报文，其中，数据报文设置有Fragment Offset字段和M-flag字段，Fragment Offset字段携带有偏移量，M-flag字段携带有末位标识；
步骤S412、当偏移量和末位标识均为零，确定数据报文为原包并将数据报文作为目标IPv6报文。
具体地，当目标节点所接收的数据报文中的Fragment Offset字段中的偏移量以及M-flag字段中的末位标识均为零，则表明该数据报文为未分片的原包，接着后续再对原包进行排序处理。
如图23所示，图23是图16中步骤S400的另一个实施例的流程图；具体地，关于上述步骤S400中的接收来自发送节点的目标IPv6报文，包括但不限于有步骤S421、步骤S422和步骤S423。
步骤S421、接收数据报文，其中，数据报文设置有Fragment Offset字段和M-flag字段，Fragment Offset字段携带有偏移量，M-flag字段携带有末位标识；
步骤S422、当偏移量或末位标识为非零，确定数据报文为分片报文；
步骤S423、获取分片报文所携带的原包标识，并对携带有相同原包标识的多个分片报文进行重组，得到目标IPv6报文，其中，目标IPv6报文为原包。
具体地，当目标节点所接收的数据报文中的Fragment Offset字段中的偏移量以及M-flag字段中的末位标识中的至少一者为非零，则表明该数据报文为分片报文，则先按照RFC8200的规范重组出相应的原包，即目标IPv6报文，接着后续再对原包进行排序处理。
值得注意的是，关于上述步骤S500中的根据比较结果确定目标IPv6报文的排序情况的流程过程，具体参见下图24至图26所示，分别如下：
如图24所示，图24是图16中步骤S500中的根据比较结果确定目标IPv6报文的排序情况的一个实施例的流程图；具体地，关于上述步骤S500中的根据比较结果确定目标IPv6报文的排序情况，包括但不限于有步骤S560。
步骤S560、在目标序列号等于期望序列号的情况下，确定目标IPv6报文为有序，并对期望序列号进行加一处理。
需要说明的是，初始时，期望序列号为1，若后续出现目标序列号等于期望序列号的情况时，期望序列号会自增1。
如图25所示，图25是图16中步骤S500中的根据比较结果确定目标IPv6报文的排序情况的另一个实施例的流程图；具体地，关于上述步骤S500中的根据比较结果确定目标IPv6报文的排序情况，包括但不限于有步骤S571、步骤S572和步骤S573。
步骤S571、在目标序列号大于期望序列号的情况下，计算得到目标序列号和期望序列号之间的第一差值；
步骤S572、当第一差值小于或等于第一预设值，确定目标IPv6报文为有序；
步骤S573、当第一差值大于第一预设值，确定目标IPv6报文为失序。
需要说明的是，关于上述的第一预设值，可以是人为预先设定的。
如图26所示，图26是图16中步骤S500中的根据比较结果确定目标IPv6报文的排序情况的另一个实施例的流程图；具体地，关于上述步骤S500中的根据比较结果确定目标IPv6报文的排序情况，包括但不限于有步骤S581、步骤S582和步骤S583。
步骤S581、在目标序列号小于期望序列号的情况下，计算得到期望序列号和目标序列号之间的第二差值；
步骤S582、当第二差值大于或等于第二预设值，确定目标IPv6报文为有序；
步骤S583、当第二差值小于第二预设值，确定目标IPv6报文为失序。
需要说明的是，关于上述的第二预设值，可以是人为预先设定的。
值得注意的是，关于上述步骤S600中的根据排序情况对目标IPv6报文进行处理的具体过程，具体参见下图27至图28所示，分别如下：
如图27所示，图27是图16中步骤S600中的根据排序情况对目标IPv6报文进行处理的一个实施例的流程图；具体地，关于上述步骤S600中的根据排序情况对目标IPv6报文进行处理，包括但不限于有步骤S610。
步骤S610、在排序情况为有序的情况下，保留目标IPv6报文。
如图28所示，图28是图16中步骤S600中的根据排序情况对目标IPv6报文进行处理的另一个实施例的流程图；具体地，关于上述步骤S600中的根据排序情况对目标IPv6报文进行处理，包括但不限于有步骤S620。
步骤S620、在排序情况为失序的情况下，丢弃目标IPv6报文或对目标IPv6报文进行重新排序。
具体地，当排序情况为有序的情况下，保留目标IPv6报文；当排序情况为失序的情况下，丢弃目标IPv6报文或对目标IPv6报文进行重新排序。
基于上述发送节点侧的IPv6报文处理方法的各个实施例以及目标节点侧的IPv6报文处理方法的各个实施例，对应地，下面针对各种封装方式来详细说明本申请的IPv6报文处理方法的各个实施例。
对于图4所示的Fragment Header的封装格式的具体实施方式，具体如下：
RFC8200定义了Fragment Header，用于当报文的大小超过了传输路径的MTU时，IPv6发送节点对报文进行分片。Fragment Header中包含有Identification(标识)信息，用于识别属于相同原包的多个分片，即，属于相同原包的分片应该具有相同的源地址(Source Address)、Destination Address(目的地址)和Identification。如果在相同的源、目的之间有不同的原包需要分片，RFC8200仅要求这些原包的Identification必须不同，并未考虑不同原包之间的排序要求。如下是图4中RFC8200已定义的Fragment Header封装格式中的字段的解释：
Next Header：提示跟随在Fragment Header之后的下层Header的类型。
Fragment Offset：分片相对于原包可分片部分的起始位置的偏移量。示例性地，第一个分片的Offset为0，第二个分片的Offset为第一个分片的长度，第三个分片的Offset为第一个分片和第二个分片的长度之和，如此类推。
M-flag：0表示最后一个分片，1表示非最后一个分片。
Identification：被分片的原包的标识。
基于上述Fragment Header封装格式，为了满足用户数据报文的排序需求，本申请实施例复用Fragment Header，并补充如下的使用方法：
对于需要排序的用户数据报文，例如沿PW转发的报文，或者沿多条路径进行冗余复制的DetNet报文，可通过控制面的信令协商或者配置指定使用Fragment Header去携带相应的序列号信息，即，Fragment Header中的Identification字段用于表示序列号，它是一个无符号整型值。
针对同样的数据流，IPv6发送节点发送的第一个数据报文所封装的Fragment Header的Identification必须设置为1，之后陆续发送的数据报文的Identification依次递增1。最大的Identification值为4294967295，之后又翻转为1。值得注意的是，上述的数据报文均是指未分片的原包。
对于某个原包，如果不需要分片，则Fragment Header中的Fragment Offset和M-flag均设置为0，以表明报文是独立的完整报文。
对于某个原包，如果需要分片，则每个分片中包含的Fragment Header中的Fragment Offset、M-flag和Identification按照RFC8200的规范进行设置。
另外，如果某个IPv6节点如网络中间节点实施DetNet的复制或消除功能，可区分原包和分片包，如果是原包，则原包中包含的Fragment Header中的Identfication用于区分不同的原包，如果是分片包，则分片包中包含的Fragment Header中的Identification与Fragment Offset一起用于区分不同的分片包。其中，在实施DetNet消除功能的节点上，多份具有相同的Source Address、Destination Address和Identification的原包，将被消除只保留一份；多份具有相同的Source Address、Destination Address、Identification和Fragment Offset的分片包，将被消除只保留一份。通过实施此步骤后将会使得后续的分片重组更加简单，当然，如果不实施此步骤的话，根据RFC8200的规范，后续的分片重组流程也能过滤重复的分片包。
另外，某个IPv6节点如IPv6目标节点接收报文时根据Identification对报文进行排序的处理，具体如下：
首先检查是否是分片报文，如果是分片报文，则先按照RFC8200的规范重组出相应的原包。对同一原包内的多个分片报文进行排序的意义不大，因为分片重组时天然会根据各分片的Fragment Offset进行从 小到大的排序。以下处理流程均是指原包的处理，分片报文不涉及。
针对同样的数据流，IPv6Destination节点维护了Expected Sequence Number(期望序列号)变量，初始时，Expected Sequence Number为1。
如果收到的数据报文中包含的Identification等于Expected Sequence Number，则该报文是有序的。此时Expected Sequence Number自增1。
如果收到的数据报文中包含的Identification大于Expected Sequence Number，则计算Identification与Expected Sequence Number的差值：如果差值小于第一预设值，则该报文也被认为是有序的；如果差值大于第一预设值，则该报文被认为是失序的，报文将被丢弃或者本地重新排序。
如果收到的数据报文中包含的Identification小于Expected Sequence Number，则计算Expected Sequence Number与Identifi cation的差值：如果差值大于第二预设值，则该报文也被认为是有序的(对应于序列号翻转的情况)；如果差值小于第二预设值，则该报文被认为是失序的，报文将被丢弃或者本地重新排序。
对于图6所示的Destination Options Header的封装格式的具体实施方式，具体如下：
RFC8200定义了Destination Options Header和Hop-by-Hop Options header，以携带可选的信息。其中Destination Options Header供报文的目标节点使用，其使用规则符合控制字的需求；Hop-by-Hop Options header供报文转发路径的中间节点使用，暂不明确其是否符合控制字的需求。本申请实施例在Destination Options Header或Hop-by-Hop Options header中新增Control Word Option，此时整个Destination Options Header或Hop-by-Hop Options header的封装格式如图6所示，其中各字段的解释如下：
Next Header：提示跟随在Destination Options Header或Hop-by-Hop Options header之后的下层Header的类型。
Hdr Ext Len：提示整个Destination Options Header或Hop-by-Hop Options header占多少个8字节，不计入前8字节。
Option Type：提示选项类型为控制字类型，其取值待IANA分配。
Opt Data Len：提示整个控制字的字节数，设置为4。
Control Word：控制字，可以是所有已定义的MPLS控制字，如RFC4385定义的Preferred PW MPLS Control Word和PW Associated Channel Header，或RFC8964定义的DetNet Control Word，或RFC5586定义的g-Ach(Generic Associated Channel,通用管道)等等。各种控制字的具体封装格式请参考相应的标准，其中，含有Sequence Number(序列号)字段的控制字，一般采用16比特的序列号。
上述Option Type可以仅分配一个取值，用于标识本选项为一般的Control Word，然后再根据Control Word的前4比特的取值去区分到底是哪种具体的控制字，这正是目前MPLS中采取的方式。不过这种方式其实不精确，比如目前在MPLS中，PWMCW与d-CW都设置前4比特为0，需额外通过业务标签去区分到底是PWMCW或d-CW。
因此，除上述方式，本申请实施例建议分配多个Option Type去区分不同的控制字，如：
Option Type-1：RFC4385定义的Preferred PW MPLS Control Word
Option Type-2：RFC8964定义的DetNet Control Word
Option Type-3：RFC5586定义的g-Ach
需要注意的是，如果采取多种Option Type，则Control Word字段中也可以不照搬上述各标准中已定义的具体MPLS控制字，因为已有的MPLS控制字中可能有一些和MPLS相关的字段，如前4比特，在IPv6中，它们是可以优化的。
为了满足用户数据报文的排序需求，可基于上述Destination Options Header或Hop-by-Hop Options header中包含的控制字信息，使用如下的方法：
对于需要排序的用户数据报文，比如沿PW转发的报文，或者沿多条路径进行冗余复制的DetNet报文，可通过控制面的信令协商或者配置指定使用Destination Options Header或Hop-by-Hop Options header去携带相应的控制字，在控制字中包含有相应的Sequence Number信息。
针对同样的数据流，IPv6Source发送的第一个数据报文所封装的Destination Options Header或Hop-by-Hop Options header的序列号必须设置为1，之后陆续发送的数据报文的Sequence Number依次递增1。最大的序列号值为65535，之后又翻转为1。注意这里所指的数据报文均是指未分片的原包。
对于某个原包，如果需要分片，则可进一步按照RFC8200的规范在报文中插入Fragment Header。此时Fragment Header中的Idenfitication仅能区分不同的原包即可，是否依序自增不作要求。
另外，如果某个IPv6节点如中间节点实施DetNet的复制或消除功能，可区分原包和分片包，如果是原包，则原包中包含的Destination Options Header或Hop-by-Hop Options header中的控制字用于区分不同的原包，如果是分片包，则除了上述控制字以外还需结合分片包中包含的Fragment Header中的 Identification与Fragment Offset一起用于区分不同的分片包。其中，在实施DetNet消除功能的节点上，多份具有相同的Source Address、Destination Address和控制字的原包，将被消除只保留一份；多份具有相同的Source Address、Destination Address、控制字、Identification和Fragment Offset的分片包，将被消除只保留一份。实施此步骤后将使得后续的分片重组更加简单，当然，如果不实施，根据RFC8200的规范，后续的分片重组流程也应该能过滤重复的分片包。
另外，某个IPv6节点如目的节点接收报文时根据序列号对报文的处理如下：
首先检查是否是Fragment Header封装的分片报文，如果是分片报文，则先按照RFC8200的规范重组出相应的原包。对同一原包内的多个分片报文进行排序的意义不大，因为分片重组时天然会根据各分片的Fragment Offset进行从小到大的排序。以下处理流程均是指原包的处理，分片报文不涉及。
针对同样的数据流，IPv6Destination节点维护了Expected Sequence Number(期望序列号)变量，初始时，Expected Identification为1。
如果收到的数据报文中包含的Sequence Number等于Expected Sequence Number，则该报文是有序的。此时Expected Sequence Number自增1。
如果收到的数据报文中包含的Sequence Number大于Expected Sequence Number，则计算Sequence Number与Expected Sequence Number的差值：如果差值小于第一预设值，则该报文也被认为是有序的；如果差值大于第一预设值，则该报文被认为是失序的，报文将被丢弃或者本地重新排序。
如果收到的数据报文中包含的Sequence Number小于Expected Sequence Number，则计算Expected Sequence Number与Sequence Number的差值：如果差值大于第二预设值，则该报文也被认为是有序的(对应于序列号翻转的情况)；如果差值小于第二预设值，则该报文被认为是失序的，报文将被丢弃或者本地重新排序。
对于图9所示的Control Word Extension Header的封装格式的具体实施方式，具体如下：
考虑到上述Fragment Header的初衷是用于分片，以及Destination Options Header和Hop-by-Hop Options header的使用存在不少的限制，则本申请实施例可以定义一种新的IPv6扩展头，称为Control Word Extension Header，相应的Header type待IANA分配。其中，对于图9所示的Control Word Extension Header的封装格式，各字段解释如下：
Next Header：提示跟随在Control Word Extension Header之后的下层Header的类型。
Hdr Ext Len：提示整个Control Word Extension Header占多少个8字节，不计入前8字节。
CW Type：提示控制字类型，其取值待IANA分配,如下：
CW Type-1：RFC4385定义的Preferred PW MPLS Control Word
CW Type-2：RFC8964定义的DetNet Control Word
CW Type-3：RFC5586定义的g-Ach
Reserved：保留字段。
Control Word：控制字，取决于CW Type，可以是所有已定义的MPLS控制字，如RFC4385定义的Preferred PW MPLS Control Word和PW Associated Channel Header，或RFC8964定义的DetNet Control Word，或RFC5586定义的g-Ach，等等。各种控制字的具体封装格式请参考相应的标准，其中，含有Sequence Number字段的控制字，一般采用16比特的序列号。
对于需要排序的用户数据报文，比如沿PW转发的报文，或者沿多条路径进行冗余复制的DetNet报文，可通过控制面的信令协商或者配置指定使用Control Word Extension Header去携带相应的控制字，其处理与上述图6所示的Destination Options Header对应的方案类似，此处不再赘述。
对于图11所示的Control Word Header的封装格式的具体实施方式，具体如下：
关于图4、图6和图9中的方案都是在IPv6扩展头中引入控制字，其思路是将控制字当成PSN(Packet Switched Network,分组交换网络)自身提供的信息。如果将控制字当成业务载荷的一部分，则也可以新定义一种Upper-Layer载荷类型，称为Control Word Header，相应的Header type待IANA分配。其中，对于图11所示的Control Word Header的封装格式，各字段解释如下：
CW Type：提示控制字类型，其取值待IANA分配。比如：
CW Type-1：RFC4385定义的Preferred PW MPLS Control Word
CW Type-2：RFC8964定义的DetNet Control Word
CW Type-3：RFC5586定义的g-Ach
Protocol Type：提示跟随在Control Word Header之后的下层协议头的类型。
Reserved：保留字段。
Control Word：控制字，可以是所有已定义的MPLS控制字，如RFC4385定义的Preferred PW MPLS Control Word和PW Associated Channel Header，或RFC8964定义的DetNet Control Word，或RFC5586定义的g-Ach，等等。各种控制字的具体封装格式请参考相应的标准，其中，含有Sequence Number字段 的控制字，一般采用16比特的序列号。
对于需要排序的用户数据报文，比如沿PW转发的报文，或者沿多条路径进行冗余复制的DetNet报文，可通过控制面的信令协商或者配置指定使用Control Word Header去携带相应的控制字，其处理与上述图6所示的Destination Options Header对应的方案类似，此处不再赘述。
基于上述图4、图6、图9和图11中的封装方式，对应地，下面针对各种具体实施环境中来说明上述图4、图6、图9和图11中各种封装方式的各个实施例。
如图29所示，图29是典型的VPWS PW承载在PSN的SRv6传输路径的示意图。在ingress PE1和egress PE2之间建立VPWS PW，并建立从PE1至PE2的SRv6policy。在PW上传输的是TDM业务流，需要保证业务报文的顺序，因此，PE1和PE2在协商PW的SRv6servcie SID(一般为END.DX2，参考draft-ietf-bess-srv6-services-15)时，可显式协商需要封装本专利定义的上述任一封装方式的控制字。
最终，PE1沿PW发送的用户数据报文的封装可能为：
当为图4中的Fragment Header封装格式，对应封装为：IPv6 Header|SRH|FH|TDM payload，其中，FH指Fragment Header。
当为图6中的Destination Options Header封装格式，对应封装为：IPv6 Header|SRH|DOH(CW option)|TDM payload，其中，DOH指Destination Options Header。
当为图9中的Control Word Extension Header封装格式，对应封装为：IPv6 Header|SRH|CWEH|TDM payload，其中，CWEH指Control Word Extension Header。
当为图11中的Control WordHeader封装格式，对应封装为：IPv6 Header|SRH|CWH|TDM payload，其中，CWH指Control Word Header。
PE2收到报文时，解析出控制字，从中获取序列号信息，实施报文排序处理。
另外，如图30所示，图30是典型的DetNet业务流的冗余复制与消除示例图。其中，src与dst分别为确定性业务流的源和目的节点，所有的R节点为实施复制功能(replication function)的节点，所有的E节点为实施消除功能(elimination function)的节点，所有的O节点为实施排序功能(order ing function)的节点。假设整个网络为纯IPv6网络。
可通过配置，使得在src节点上为确定性业务流封装本申请实施例所定义的上述任一封装方式的控制字。
最终，src发送的用户数据报文的封装可能为：
当为图4中的Fragment Header封装格式，对应封装为：IPv6 Header|FH|DetNet App-Flow，其中，FH指Fragment Header。
当为图6中的Destination Options Header封装格式，对应封装为：IPv6 Header|DOH(CW option)|DetNet App-Flow，其中，DOH指Destination Options Header。
当为图9中的Control Word Extension Header封装格式，对应封装为：IPv6 Header|CWEH|DetNet App-Flow，其中，CWEH指Control Word Extension Header。
当为图11中的Control Word Header封装格式，对应封装为：IPv6 Header|CWH|DetNet App-Flow，其中，CWH指Control Word Header。
所有的R节点在实施流量冗余复制时，复制流中包含的控制字信息与接收到的流相同；所有的E节点根据接收到的冗余流中包含的控制字信息，消除重复报文；所有的O节点根据接收到的原包中包含的控制字信息，对报文排序。
基于上述的IPv6报文处理方法，下面提出本申请的发送节点、目标节点、计算机可读存储介质和计算机程序产品的各个实施例。
本申请的一个实施例提供了一种发送节点，该发送节点包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，处理器执行计算机程序时实现如上述的应用于发送节点侧的IPv6报文处理方法。
需要说明的是，本实施例中的发送节点，可以对应为如图1所示实施例中的实施环境中的发送节点，两者属于相同的申请构思，因此两者具有相同的实现原理以及有益效果，此处不再详述。
实现上述实施例的IPv6报文处理方法所需的非暂态软件程序以及指令存储在存储器中，当被处理器执行时，执行上述实施例的IPv6报文处理方法，例如，执行以上描述的图2、3、5、7、8、10、12至15中的方法步骤。
值得注意的是，本申请实施例的发送节点的具体实施方式和技术效果，可对应参照上述IPv6报文处理方法的具体实施方式和技术效果。
另外，本申请的一个实施例提供了一种目标节点，该目标节点包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，处理器执行计算机程序时实现如上述的应用于目标节点侧的IPv6报文处理方法。
需要说明的是，本实施例中的目标节点，可以对应为如图1所示实施例中的实施环境中的目标节点，两者属于相同的申请构思，因此两者具有相同的实现原理以及有益效果，此处不再详述。
实现上述实施例的IPv6报文处理方法所需的非暂态软件程序以及指令存储在存储器中，当被处理器执行时，执行上述实施例的IPv6报文处理方法，例如，执行以上描述的图16至图28中的方法步骤。
值得注意的是，本申请实施例的目标节点的具体实施方式和技术效果，可对应参照上述IPv6报文处理方法的具体实施方式和技术效果。
此外，本申请的一个实施例还提供了一种计算机可读存储介质，该计算机可读存储介质存储有计算机可执行指令，当计算机可执行指令用于执行上述的IPv6报文处理方法，例如，执行以上描述的图2、3、5、7、8、10、12至28中的方法步骤。
此外，本申请的一个实施例还公开了一种计算机程序产品，包括计算机程序或计算机指令，计算机程序或计算机指令存储在计算机可读存储介质中，计算机设备的处理器从计算机可读存储介质读取计算机程序或计算机指令，处理器执行计算机程序或计算机指令，使得计算机设备执行如前面任意实施例中的IPv6报文处理方法。
本领域普通技术人员可以理解，上文中所公开方法中的全部或某些步骤、系统可以被实施为软件、固件、硬件及其适当的组合。某些物理组件或所有物理组件可以被实施为由处理器，如中央处理器、数字信号处理器或微处理器执行的软件，或者被实施为硬件，或者被实施为集成电路，如专用集成电路。这样的软件可以分布在计算机可读介质上，计算机可读介质可以包括计算机存储介质(或非暂时性介质)和通信介质(或暂时性介质)。如本领域普通技术人员公知的，术语计算机存储介质包括在用于存储信息(诸如计算机可读指令、数据结构、程序模块或其他数据)的任何方法或技术中实施的易失性和非易失性、可移除和不可移除介质。计算机存储介质包括但不限于RAM、ROM、EEPROM、闪存或其他存储器技术、CD-ROM、数字多功能盘(DVD)或其他光盘存储、磁盒、磁带、磁盘存储或其他磁存储装置、或者可以用于存储期望的信息并且可以被计算机访问的任何其他的介质。此外，本领域普通技术人员公知的是，通信介质通常包括计算机可读指令、数据结构、程序模块或者诸如载波或其他传输机制之类的调制数据信号中的其他数据，并且可包括任何信息递送介质。
以上是对本申请的较佳实施进行了具体说明，但本申请并不局限于上述实施方式，熟悉本领域的技术人员在不违背本申请范围的共享条件下还可作出种种等同的变形或替换，这些等同的变形或替换均包括在本申请权利要求所限定的范围内。

Claims (28)

  1. 一种IPv6报文处理方法，应用于发送节点，所述方法包括：
    获取待发送的目标IPv6报文；
    根据所述目标IPv6报文的发送顺序确定目标序列号，并将所述目标序列号添加至所述目标IPv6报文中；
    将携带有所述目标序列号的所述目标IPv6报文发送至目标节点，以使所述目标节点根据所述目标序列号对所述目标IPv6报文进行处理。
  2. 根据权利要求1所述的IPv6报文处理方法，其中，所述目标IPv6报文包含有IPv6扩展头FragmentHeader；所述将所述目标序列号添加至所述目标IPv6报文中，包括：
    将所述目标序列号添加至所述Fragment Header的Identification字段中。
  3. 根据权利要求1所述的IPv6报文处理方法，其中，所述目标IPv6报文包含有IPv6扩展头Destination Options Header；所述将所述目标序列号添加至所述目标IPv6报文中，包括：
    在所述Destination Options Header中增加控制字选项；
    将所述目标序列号添加至所述控制字选项中的控制字字段中。
  4. 根据权利要求1所述的IPv6报文处理方法，其中，所述目标IPv6报文包含有IPv6扩展头Hop-by-Hop Options Header；所述将所述目标序列号添加至所述目标IPv6报文中，包括：
    在所述Hop-by-Hop Options Header中增加控制字选项；
    将所述目标序列号添加至所述控制字选项中的控制字字段中。
  5. 根据权利要求1所述的IPv6报文处理方法，其中，所述目标IPv6报文包含有IPv6扩展头Control Word Extension Header；所述将所述目标序列号添加至所述目标IPv6报文中，包括：
    将所述目标序列号添加至所述Control Word Extension Header中的控制字字段中。
  6. 根据权利要求1所述的IPv6报文处理方法，其中，所述目标IPv6报文包含有Upper-layer载荷头Control Word Header；所述将所述目标序列号添加至所述目标IPv6报文中，包括：
    将所述目标序列号添加至所述Control Word Header中的控制字字段中。
  7. 根据权利要求1所述的IPv6报文处理方法，其中，所述将携带有所述目标序列号的所述目标IPv6报文发送至目标节点，包括：
    获取所述目标IPv6报文的数据量；
    当所述数据量小于或等于所述发送节点和所述目标节点之间的传输路径的最大传输量，按照预设规范对完整的所述目标IPv6报文中的偏移量和末位标识进行设置，并将设置后的完整的所述目标IPv6报文发送至目标节点。
  8. 根据权利要求7所述的IPv6报文处理方法，其中，所述将携带有所述目标序列号的所述目标IPv6报文发送至目标节点，还包括：
    当所述数据量大于所述发送节点和所述目标节点之间的传输路径的最大传输量，将所述目标IPv6报文切分为多个分片报文；
    按照预设规范对所述分片报文中的偏移量和末位标识均进行设置，并将设置后的多个所述分片报文发送至目标节点。
  9. 根据权利要求7所述的IPv6报文处理方法，其中，所述将设置后的完整的所述目标IPv6报文发送至目标节点，包括：
    将设置后的完整的所述目标IPv6报文发送至中间节点，以使所述中间节点读取所述目标IPv6报文所携带的源地址、目的地址和原包标识，并通过所述中间节点过滤重复的携带有相同的所述源地址、所述目的地址和所述原包标识的所述目标IPv6报文，以及通过所述中间节点将保留的所述目标IPv6报文转发至所述目标节点。
  10. 根据权利要求8所述的IPv6报文处理方法，其中，所述将设置后的多个所述分片报文发送至目标节点，包括：
    将设置后的多个所述分片报文发送至中间节点，以使所述中间节点读取所述分片报文所携带的源地址、目的地址、原包标识和偏移量，并通过所述中间节点过滤重复的携带有相同的所述源地址、所述目的地址、所述原包标识和所述偏移量的所述分片报文，以及通过所述中间节点将保留的所述分片报文转发至所述目标节点。
  11. 一种IPv6报文处理方法，应用于目标节点，所述方法包括：
    接收来自发送节点的目标IPv6报文，其中，所述目标IPv6报文携带有目标序列号，所述目标序列号由所述发送节点根据所述目标IPv6报文的发送顺序确定得到；
    读取所述目标序列号，将所述目标序列号和期望序列号进行比较，并根据比较结果确定所述目标IPv6报文的排序情况；
    根据所述排序情况对所述目标IPv6报文进行处理。
  12. 根据权利要求11所述的IPv6报文处理方法，其中：所述目标IPv6报文包含有IPv6扩展头Fragment Header，所述IPv6扩展头Fragment Header的Identification字段携带有所述目标序列号；所述读取所述目标序列号，包括：
    读取所述Identification字段，得到所述目标序列号。
  13. 根据权利要求11所述的IPv6报文处理方法，其中：所述目标IPv6报文包含有IPv6扩展头Destination Options Header，所述Destination Options Header中携带有控制字选项，所述控制字选项的控制字字段携带有所述目标序列号；所述读取所述目标序列号，包括：
    读取所述控制字选项的所述控制字字段，得到所述目标序列号。
  14. 根据权利要求11所述的IPv6报文处理方法，其中：所述目标IPv6报文包含有IPv6扩展头Hop-by-Hop Options Header，所述Hop-by-Hop Options Header中携带有控制字选项，所述控制字选项的控制字字段携带有所述目标序列号；所述读取所述目标序列号，包括：
    读取所述控制字选项的所述控制字字段，得到所述目标序列号。
  15. 根据权利要求11所述的IPv6报文处理方法，其中：所述目标IPv6报文包含有IPv6扩展头Control Word Extension Header，所述Control Word Extension Header中携带有控制字字段，所述控制字字段携带有所述目标序列号；所述读取所述目标序列号，包括：
    读取所述Control Word Extension Header中携带的所述控制字字段，得到所述目标序列号。
  16. 根据权利要求11所述的IPv6报文处理方法，其中：所述目标IPv6报文包含有Upper-layer载荷头Control Word Header，所述Control Word Header中携带有控制字字段，所述控制字字段携带有所述目标序列号；所述读取所述目标序列号，包括：
    读取所述Control Word Header中携带的所述控制字字段，得到所述目标序列号。
  17. 根据权利要求11所述的IPv6报文处理方法，其中，所述接收来自发送节点的目标IPv6报文，包括：
    接收数据报文，其中，所述数据报文设置有Fragment Offset字段和M-flag字段，所述Fragment Offset字段携带有偏移量，所述M-flag字段携带有末位标识；
    当所述偏移量和所述末位标识均为零，确定所述数据报文为原包并将所述数据报文作为目标IPv6报文。
  18. 根据权利要求11所述的IPv6报文处理方法，其中，所述接收来自发送节点的目标IPv6报文，包括：
    接收数据报文，其中，所述数据报文设置有Fragment Offset字段和M-flag字段，所述Fragment Offset字段携带有偏移量，所述M-flag字段携带有末位标识；
    当所述偏移量或所述末位标识为非零，确定所述数据报文为分片报文；
    获取所述分片报文所携带的原包标识，并对携带有相同所述原包标识的多个所述分片报文进行重组，得到目标IPv6报文，其中，所述目标IPv6报文为原包。
  19. 根据权利要求11所述的IPv6报文处理方法，其中，所述根据比较结果确定所述目标IPv6报文的排序情况，包括：
    在所述目标序列号等于期望序列号的情况下，确定所述目标IPv6报文为有序，并对所述期望序列号进行加一处理。
  20. 根据权利要求11所述的IPv6报文处理方法，其中，所述根据比较结果确定所述目标IPv6报文的排序情况，包括：
    在所述目标序列号大于期望序列号的情况下，计算得到所述目标序列号和所述期望序列号之间的第一差值；
    当所述第一差值小于或等于第一预设值，确定所述目标IPv6报文为有序；
    当所述第一差值大于所述第一预设值，确定所述目标IPv6报文为失序。
  21. 根据权利要求11所述的IPv6报文处理方法，其中，所述根据比较结果确定所述目标IPv6报文的排序情况，包括：
    在所述目标序列号小于期望序列号的情况下，计算得到所述期望序列号和所述目标序列号之间的第二差值；
    当所述第二差值大于或等于第二预设值，确定所述目标IPv6报文为有序；
    当所述第二差值小于所述第二预设值，确定所述目标IPv6报文为失序。
  22. 根据权利要求11所述的IPv6报文处理方法，其中，所述根据所述排序情况对所述目标IPv6报 文进行处理，包括：
    在所述排序情况为有序的情况下，保留所述目标IPv6报文。
  23. 根据权利要求11所述的IPv6报文处理方法，其中，所述根据所述排序情况对所述目标IPv6报文进行处理，包括：
    在所述排序情况为失序的情况下，丢弃所述目标IPv6报文或对所述目标IPv6报文进行重新排序。
  24. 根据权利要求11至23中任意一项所述的IPv6报文处理方法，其中，当前的所述期望序列号由所述目标节点根据所述目标序列号和历史的所述期望序列号的比较结果确定得到。
  25. 一种发送节点，包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现如权利要求1至10中任意一项所述的IPv6报文处理方法。
  26. 一种目标节点，包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现如权利要求11至24中任意一项所述的IPv6报文处理方法。
  27. 一种计算机可读存储介质，存储有计算机可执行指令，所述计算机可执行指令用于执行权利要求1至24中任意一项所述的IPv6报文处理方法。
  28. 一种计算机程序产品，包括计算机程序或计算机指令，所述计算机程序或所述计算机指令存储在计算机可读存储介质中，计算机设备的处理器从所述计算机可读存储介质读取所述计算机程序或所述计算机指令，所述处理器执行所述计算机程序或所述计算机指令，使得所述计算机设备执行如权利要求1至24中任意一项所述的IPv6报文处理方法。
PCT/CN2022/140322 2022-04-25 2022-12-20 IPv6报文处理方法、节点、存储介质和程序产品 WO2023207147A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202210438583.0A CN116996461A (zh) 2022-04-25 2022-04-25 IPv6报文处理方法、节点、存储介质和程序产品
CN202210438583.0 2022-04-25

Publications (1)

Publication Number Publication Date
WO2023207147A1 true WO2023207147A1 (zh) 2023-11-02

Family

ID=88517211

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2022/140322 WO2023207147A1 (zh) 2022-04-25 2022-12-20 IPv6报文处理方法、节点、存储介质和程序产品

Country Status (2)

Country Link
CN (1) CN116996461A (zh)
WO (1) WO2023207147A1 (zh)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1937541A (zh) * 2005-09-20 2007-03-28 华为技术有限公司 一种网络性能测试方法
CN110932934A (zh) * 2019-11-21 2020-03-27 中国联合网络通信集团有限公司 一种网络丢包的检测方法和装置
WO2021174958A1 (zh) * 2020-03-06 2021-09-10 中兴通讯股份有限公司 报文转发方法、设备、系统、网络设备和存储介质
WO2022078509A1 (zh) * 2020-10-15 2022-04-21 中兴通讯股份有限公司 IPv6报文的扩展头封装方法及装置

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1937541A (zh) * 2005-09-20 2007-03-28 华为技术有限公司 一种网络性能测试方法
CN110932934A (zh) * 2019-11-21 2020-03-27 中国联合网络通信集团有限公司 一种网络丢包的检测方法和装置
WO2021174958A1 (zh) * 2020-03-06 2021-09-10 中兴通讯股份有限公司 报文转发方法、设备、系统、网络设备和存储介质
WO2022078509A1 (zh) * 2020-10-15 2022-04-21 中兴通讯股份有限公司 IPv6报文的扩展头封装方法及装置

Also Published As

Publication number Publication date
CN116996461A (zh) 2023-11-03

Similar Documents

Publication Publication Date Title
US11336574B2 (en) Segment routing extension headers
US10164838B2 (en) Seamless segment routing
US8743691B2 (en) Priority aware MAC flow control
EP3742683B1 (en) Method and device for processing packet by using unified sr label stack
CN105282024A (zh) 通过IP封装的CCNx消息分段的切入转发
US8811171B2 (en) Flow control for multi-hop networks
US7929531B2 (en) Communications system for delivering multimedia internet protocol packets across network boundaries
US20060182105A1 (en) Apparatus and method for transmitting multi protocol label switching (MPLS) multicast packets over Ethernet
WO2021088629A1 (zh) DetNet数据包处理方法及装置
WO2021088813A1 (zh) 报文封装方法及装置、报文解封装方法及装置
US20090210770A1 (en) Method, system and computer program product for end to end error checking in ethernet
WO2023207147A1 (zh) IPv6报文处理方法、节点、存储介质和程序产品
US8085777B2 (en) Packet-processing apparatus and method
CN115442286A (zh) 用于sr路径入口保护的方法和网络节点
CN111865795A (zh) 控制方法及装置
US8149832B2 (en) Methods, systems, and computer program products for pushing and/or popping multiple multiprotocol label switching (MPLS) labels/shim headers at a single node
US20050053071A1 (en) Method and apparatus for label switching data packets
CN112929193B (zh) 用于配置介质访问控制地址老化时间的方法和装置
JP2001007835A (ja) データ送信装置及び方法、データ中継装置及び方法、データ受信装置及び方法、並びにデータ通信システム、データ通信方法
CN113055268A (zh) 隧道流量负载均衡的方法、装置、设备及介质
US20060221929A1 (en) Description of packet in a packet communication network
JP2005101690A (ja) 中継装置及び中継方法
WO2024045537A1 (zh) 报文传输的方法和网络设备
WO2022257798A1 (zh) 转发方法、转发系统、电子设备和计算机可读存储介质
CN116074395A (zh) 一种报文发送方法及装置

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: 22939956

Country of ref document: EP

Kind code of ref document: A1