WO2017132911A1 - Appareil et procédé de transmission de données - Google Patents

Appareil et procédé de transmission de données Download PDF

Info

Publication number
WO2017132911A1
WO2017132911A1 PCT/CN2016/073381 CN2016073381W WO2017132911A1 WO 2017132911 A1 WO2017132911 A1 WO 2017132911A1 CN 2016073381 W CN2016073381 W CN 2016073381W WO 2017132911 A1 WO2017132911 A1 WO 2017132911A1
Authority
WO
WIPO (PCT)
Prior art keywords
bit
header
data
ipv4
option
Prior art date
Application number
PCT/CN2016/073381
Other languages
English (en)
Chinese (zh)
Inventor
贺恩华
Original Assignee
华为技术有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 华为技术有限公司 filed Critical 华为技术有限公司
Priority to PCT/CN2016/073381 priority Critical patent/WO2017132911A1/fr
Priority to CN201680048976.3A priority patent/CN107925516A/zh
Publication of WO2017132911A1 publication Critical patent/WO2017132911A1/fr

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received

Definitions

  • Embodiments of the present invention relate to communication technologies, and in particular, to a data transmission method and apparatus.
  • LTE Long Term Evolution
  • LTE-A Long Term Evolution-Advance
  • IP Internet Protocol
  • IPv4 Internet Protocol Version 4
  • each intermediate device (such as a base station, a core network, a router, etc.) has a Maximum Transmission Unit (MTU) limit. If the size of the transmitted data packet exceeds the MTU, The data packet is divided into a plurality of fragmented packets that do not exceed the MTU size. The value of the identifier Flg of each fragmented packet is 1, indicating that the packet is a fragmented packet.
  • a 16-bit Internet Protocol Identity (IPID) field is defined in the header of each IPv4 data packet. The decimal value corresponding to the IPID is 0 to 65535. .
  • the packet is considered to be the fragmented packet of the same data packet. If the IPIDs are different, It is considered not to be the same data message.
  • the receiver When using IPv4 for high-speed data transmission, in the certain period, the receiver often has two or more data packets that are not the same data packet.
  • the IPID of the fragmented packet is the same, and the packets with the same IPID are erroneously reorganized, resulting in errors in data transmission and even service interruption.
  • the present invention provides a data transmission method and apparatus, which avoids that two or more fragmented packets that are not the same IPv4 data packet have the same IPID in a certain period, and thus The case of incorrect combination of IPv4 data messages satisfies the business needs of high-speed transmission of wired or wireless data in the future.
  • an embodiment of the present invention provides a data transmission method, including: adding an option Option field at a tail of an IPv4 data header of a fourth Internet Protocol version 4 to generate a second IPv4 data header; the Option field includes an identifier bit, a length bit and a data bit, the Internet Protocol Identity IPID of the second IPv4 data message is a sum of an IPID of the first IPv4 data header and a bit number of data bits of the Option field; according to the second IPv4 data The header and the transmission data generate an IPv4 data message; and the IPv4 data message is sent.
  • the IP address of the second IPv4 data packet is the sum of the IPID of the first IPv4 data header and the number of bits of the data bit of the Option field, because the Option field is added in the header of the standard IPv4 data packet. That is, the maximum value of the IPID in the finally generated IPv4 data packet exceeds 65535.
  • the IPID of the IPv4 data packet exceeds 65535, the IPID can continue to increase, and the update will not start from 0, so that the receiver will appear in a certain period. Two or more fragmented packets that are not the same IPv4 data packet have the same IPID, so that the IPv4 data packets are incorrectly combined, which satisfies the future high-speed transmission of wired or wireless data.
  • the option Option field is added after the end of the first IPv4 data header.
  • the method further includes adding a padding field after the data bit of the Option field, such that the sum of the data bits of the Option field and the number of bits of the padding field is 16.
  • the padding field is added after the data bit of the Option field, so that the sum of the data bits of the Option field and the number of bits of the padding field is 16, not only making IPv4
  • the maximum IPID of the data packet exceeds 65535, which avoids the situation where the IPID of two or more fragmented packets that are not the same data packet is the same at the receiving end, meeting the needs of future wired and wireless network services.
  • the problem of inaccurate calculation caused by the fact that the Option field does not occupy 4 bytes is calculated when calculating the header checksum, and the operation is simple and the efficiency is high.
  • the method further includes: updating a length of the second IPv4 data header, corresponding IPv4 data The total length of the message and the header checksum.
  • the value of other fields is adaptively updated to ensure the accuracy and reliability of the IPv4 data packet.
  • the identifier bit of the Option field includes a copy bit, a function option bit, and an option number.
  • the sending the IPv4 data packet includes:
  • the header checksum of the two IPv4 data headers includes: 16-bit aligning the values of the fields of the second IPv4 data header, and setting the header checksum to 0; the aligned fields Summing the value, obtaining a first header checksum; re-aligning the first header checksum with 16 values of other fields to obtain a second header checksum; The partial checksum performs a bit flip to obtain an updated header checksum.
  • an embodiment of the present invention provides a data transmission method, including: receiving an IPv4 data packet of an Internet Protocol version 4.
  • the header of the IPv4 data packet includes an Option field, and the Option field includes an identifier bit and a length bit. And a data bit; parsing the IPv4 data packet according to a sum of an IPID of the IPv4 data header and a bit number of data bits of the Option field.
  • the Option field is added to the header of the IPv4 data packet, so that the maximum value of the IPID exceeds 65535, that is, when the IPID of the IPv4 data packet exceeds 65535, the value can continue to increase, and the update does not start from 0. The situation that two or more fragmented packets that are not the same data packet have the same IPID at the receiving end is avoided, which satisfies the business requirement of high-speed transmission of wired or wireless data in the future.
  • the identifier bit of the Option field includes a copy bit, a function option bit, and an option number.
  • an embodiment of the present invention provides a data transmission apparatus, including:
  • the Internet Protocol Identity IPID is the sum of the IPID of the first IPv4 data header and the number of bits of the data bits of the Option field;
  • a generating module configured to generate an IPv4 data packet according to the second IPv4 data header and the transmission data
  • a sending module configured to send the IPv4 data packet.
  • the adding module is further configured to add a padding field after the data bit of the Option field, so that the data bit of the Option field and the number of bits of the padding field are Is 16.
  • the device further includes:
  • an update module configured to update a length of the second IPv4 data header, a total length of the corresponding IPv4 data packet, and a header checksum.
  • the identifier bit of the Option field includes a copy bit, a function option bit, and an option number.
  • the adding module updates a header checksum of the second IPv4 data header ,include:
  • the adding module performs 16-bit alignment on the values of the fields of the second IPv4 data header, and sets the header checksum to 0; sums the values of the aligned fields to obtain the first header. a checksum; re-aligning the first header checksum with 16 values of other fields to obtain a second header checksum; and performing bit flipping on the second header checksum to obtain Updated header checksum.
  • the apparatus provided by the third aspect is used to perform the data transmission method provided by the first aspect, and the implementation principle and the beneficial effects are similar, and details are not described herein again.
  • an embodiment of the present invention provides a data transmission apparatus, including:
  • a receiving module configured to receive an IPv4 data packet of the Internet Protocol version 4; the header of the IPv4 data packet includes an Option field, where the Option field includes an identifier bit, a length bit, and a data bit;
  • a parsing module configured to parse the IPv4 data packet according to a sum of an IPID of the IPv4 data header and a bit number of data bits of the Option field.
  • the identifier bit of the Option field includes a copy bit, a function option bit, and an option number.
  • the apparatus provided in the fourth aspect is used to perform the data transmission method provided by the second aspect, and the implementation principle and the beneficial effects are similar, and details are not described herein again.
  • FIG. 1 is a schematic diagram of an application scenario of a data transmission method provided by the present invention
  • FIG. 2 is a flowchart of a data transmission method according to Embodiment 1 of the present invention.
  • FIG. 3 is a flowchart of a data transmission method according to Embodiment 2 of the present invention.
  • FIG. 4 is a flowchart of a method for calculating a header checksum of an IPv4 data packet according to an embodiment of the present invention
  • FIG. 5 is a schematic structural diagram of a data transmission apparatus according to Embodiment 3 of the present invention.
  • FIG. 6 is a schematic structural diagram of a data transmission apparatus according to Embodiment 4 of the present invention.
  • FIG. 7 is a schematic structural diagram of a data transmission apparatus according to Embodiment 5 of the present invention.
  • FIG. 8 is a schematic structural diagram of a device according to Embodiment 6 of the present invention.
  • FIG. 1 is a schematic diagram of an application scenario of a data transmission method provided by the present invention.
  • the data transmission method is applicable to all networks using IPv4 technologies, such as a mobile network, a fixed network, and an Internet of Things.
  • the scenario includes a transmitting end 1, an intermediate device 2, an intermediate device 3, an intermediate device 4, and a receiving end 5.
  • the sending end 1 is configured to generate an IPv4 data packet according to the agreed protocol, and send the IPv4 data packet to the receiving end 5.
  • the receiving end 5 parses the packet according to the agreed protocol.
  • the sender 1 and the receiver 5 can be devices such as a server and a terminal.
  • the intermediate device is configured to forward the IPv4 data packet according to the agreed protocol.
  • the intermediate device may be a base station, a core network, a router, etc.
  • the intermediate device in the scenario is not required, and may include multiple or multiple intermediate devices.
  • the intermediate device may not be included, and only three intermediate devices are schematically illustrated in FIG.
  • FIG. 2 is a flowchart of a data transmission method according to Embodiment 1 of the present invention. As shown in FIG. 2, the method in this embodiment may include:
  • Step 101 Add an Option field at the end of the first IPv4 data header to generate a second IPv4 data header.
  • the Option field includes an identifier bit, a length bit, and a data bit.
  • the IPID of the second IPv4 data packet is the first IPv4 data.
  • the IPID of the header and the bits of the data bits of the Option field The sum of the numbers.
  • the IP address of the first Pv4 data header is a 16-bit IPID in a standard IPv4 packet, that is, an Identification field in a header of a standard IPv4 packet, and the Option field is used in a standard IPv4 packet.
  • the 16-bit IPID is extended, wherein the identifier field of the Option field indicates that the Option field is used to extend the IPID, the length bit indicates the length of the entire Option field, and the data bit indicates the length of the extended IPID.
  • the length of the IPID field of the standard IPv4 packet is 16 bits, that is, the maximum value of the IPID is 65535.
  • the sender adds an Option field to the end of the header of the IPv4 data packet to extend the IPID, that is, the 16-bit original.
  • the sum of the number of bits of the data bits of the IPID and the Option field is the IPID of the generated IPv4 data packet, so that the length of the IPID of the IPv4 data packet is greater than 16 bits, that is, the maximum value of the IPID exceeds 65535.
  • the data bit of the Option field can be set to 16 bits, and the IPID can be extended from 16 bits in the standard to 32 bits.
  • the identification range supported by the IPv4 protocol is extended from 65535 to 4294836225, which is equivalent to extending the IPID of the IPv4 data packet to The same range of IPv6 Identification.
  • Table 1 shows the format of an IPv4 data packet according to an embodiment of the present invention.
  • the length of the data bit of the Option field in Table 1 is 16 bits.
  • the second IPv4 data header includes the IPv4 protocol version (Ver) and the header length (Internet Header Length, Referred to as IHL), service type (Tos), total message length (total length), IP identification (Identification), fragmented message flag (Flg), fragmented packet offset (Fragment offset), lifetime (Time), protocol type (Protocol), Header Checksum, source address, destination address, Option field (Opt.code), length of the Option field (Opt.len), the Option field of the Option field, where the Identification is the 16-bit IPID defined in the standard IPv4 protocol.
  • Table 2 shows the format of a standard IPv4 data message. As shown in Table 2, the first IPv4 data header starts from the Ver field and ends at the destination address field.
  • the Identification field in the standard IPv4 data header is only 16 bits, the header length is 20 bytes, the total length of the IPv4 data packet is 1500 bytes, and the value of the Header Checksum is 0xc7a4.
  • the IPv4 data header in this embodiment includes not only the Identification field but also the Option field.
  • the second IPv4 data header starts from Ver and ends with the option value.
  • the header length is increased by 4 bytes, that is, 24 bytes, IPv4.
  • the total length of the data packet is 1504 Byte, and the value of the Header Checksum is 0x3c9c.
  • Step 102 Generate an IPv4 data packet according to the second IPv4 data header and the transmission data.
  • the transmission data is added in the data field. It can generate IPv4 data packets.
  • Step 103 Send an IPv4 data packet.
  • the sending end directly sends the IPv4 data packet to the receiving end, and the intermediate device forwards the IPv4 data packet to the receiving end, for example, forwarding the IPv4 data packet to the next hop in the forwarding path.
  • the router forwards the IPv4 data packet to other intermediate devices, and finally sends the packet to the receiving end after being forwarded multiple times.
  • the above steps 101-103 are performed by the transmitting end.
  • the receiving end specifically performs the following steps: receiving the Internet Protocol version 4 IPv4 data message; according to the sum of the IPID of the IPv4 data header and the number of bits of the data field of the Option field to the IPv4
  • the data packet is parsed; the header of the IPv4 data packet includes an Option field, and the Option field includes an identifier bit, a length bit, and a data bit.
  • the receiving end parses the data IPv4 data packet according to the Identification+Option value shown in Table 1, for example, if the receiving end identifies multiple IPv4 data. If the packets are all fragmented and the value of the Identification+Option value is the same, the IPv4 data packets are combined into one IPv4 data packet.
  • the data transmission method provided in this embodiment adds an Option field to the end of the first IPv4 data header, generates a second IPv4 data header, generates an IPv4 data packet according to the second IPv4 data header and the transmission data, and sends the IPv4 data packet.
  • the receiving end is configured to enable the receiving end to parse the IPv4 data packet according to the sum of the IPID of the IPv4 data header and the number of bits of the data bit of the Option field, because the Option field added in the header of the standard IPv4 data packet makes
  • the IP address of the second IPv4 data packet is the sum of the IPID of the first IPv4 data header and the number of bits of the data bit of the Option field, that is, the maximum value of the IPID in the finally generated IPv4 data packet exceeds 65535, when the IPv4 data packet If the IPID exceeds 65535, the IPID of the fragmented packet that is not the same IPv4 data packet will be the same, so that the IP address of the fragmented packet that is not the same IPv4 data packet will be the same.
  • the case of incorrectly combining IPv4 data packets satisfies the business needs of high-speed transmission of wired or wireless data in the future.
  • the method further includes: after the option Option field is added to the end of the first IPv4 data header, the method further includes: The padding field is added after the bit so that the sum of the data bits of the Option field and the number of bits of the padding field is 16.
  • Table 3 shows the format of an IPv4 data packet provided by another embodiment of the present invention. As shown in Table 3, When the data bit of the Option field is 8 bits, the Option field does not occupy 4 bytes. Therefore, an 8-bit padding field is added after the Option field of the Option field.
  • the Padding field is used for 16-bit alignment in order to calculate the Header Checksum. There is no practical meaning.
  • the number of bits of the data bit of the Option field may be set longer. For example, if the data bit of the Option field is set to 24 bits, the Padding field needs to be set after the Option field, if the Option is If the data bit of the field is set to 32bit, you do not need to add the Padding field.
  • FIG. 3 is a flowchart of a data transmission method according to Embodiment 2 of the present invention. As shown in FIG. 3, the method includes the following steps:
  • Step 201 Add an Option field at the end of the first IPv4 data header to generate a second IPv4 data header.
  • the Option field includes an identifier bit, a length bit, and a data bit.
  • the IPID of the second IPv4 data packet is an IPID of the first IPv4 data header. The sum of the number of bits of the data bits with the Option field.
  • the identifier bits of the Option field include a copy bit, a function option bit, and an option number.
  • the identifier bit Opt.code of the Option field contains 8 bits, where 1 bit is used to set a copy flag, and when the copied flag is 0, it means non-copy (not copied); when the copied flag is 1 When it is said, it is copied.
  • 2bits is used to set function option bits (option) Class), when the option class is 0, it indicates that the Option field is a control command (control); when the option class is 1 or 3, it indicates that the Option field is reserved for future use; when the option class is 1. , indicating that the Option field is debugging and measurement.
  • 5bits is used to set the option number (option number). The option number is used to indicate the type of the Option field. Different option numbers indicate Option fields for different purposes.
  • Table 4 shows the format of the Option field. As shown in Table 4, eight Option fields of other uses have been defined in the protocol, and the eight Option fields are clearly defined in the protocol. Let me repeat. This embodiment adds a ninth Option field for extending the IPID.
  • the copied flag of the ninth Option field provided in this embodiment is 1, indicating that the option is 0, indicating that the Option field is control, the option number is 10, and 10 indicates that the Option field is used for expansion.
  • IPID Preferably, any value of 11 to 32 that is not used in the current RFC791 protocol may be used as the option number value in this embodiment.
  • Step 202 Update the length of the second IPv4 data header, the total length of the corresponding IPv4 data packet, and the header checksum.
  • FIG. 4 is a flowchart of a method for calculating a header checksum of an IPv4 data packet according to an embodiment of the present invention.
  • the execution body of the method is a sender.
  • Table 5 shows the result of each step of calculating the Header Checksum in the standard IPv4 data message.
  • Table 6 shows the result of each step of calculating the Header Checksum in the IPv4 data message provided by the embodiment of the present invention.
  • the method includes the following steps:
  • Step 301 Perform 16-bit alignment on the values of the fields of the second IPv4 data header, and set the header checksum to 0.
  • the fields in the header of the IPv4 data packet are aligned 16 bits. Since the Header Checksum needs to be calculated, the Header Checksum is first set to 0.
  • opt.Value 16 bits is shown in Table 6. If the opt.Value is 8 bits, and the padding field is included, the value of opt.Value is the number of bits of opt.Value and padding. Sum.
  • Step 302 Summing the values of the aligned fields to obtain a first header checksum.
  • the standard IPv4 data message is summed and the hexadecimal first head is obtained.
  • the sum of the checksums is "23859”.
  • the hexadecimal first header checksum obtained by the summation is "2C361".
  • Step 303 Re-align the first header checksum with the values of other fields by 16 bits to obtain a second header checksum.
  • the 16 bits of each field in the header of the IPv4 data packet are aligned again. If the value of the first header checksum field exceeds 16 bits, the portion exceeding 16 bits and the lower 4 bits are If the bit is added, the value corresponding to the second header checksum of the standard IPv4 data packet is "385B", and the value corresponding to the second header checksum of the IPv4 data packet in this embodiment is "C363". ".
  • Step 304 Perform bit flipping on the second header checksum to obtain an updated header checksum.
  • Step 203 Generate an IPv4 data packet according to the second IPv4 data header and the transmission data.
  • Step 204 Send an IPv4 data packet.
  • the data transmission method provided in this embodiment adds an Option field to the end of the first IPv4 data header, generates a second IPv4 data header, and calculates and updates the length of the second IPv4 data header, the total length of the corresponding IPv4 data packet, and
  • the header checksum generates an IPv4 data packet according to the second IPv4 data header and the transmission data, and sends the IPv4 data packet to the receiving end, so that the receiving end compares the number of bits of the identification and the Option value to the IPv4 data packet. Performing an analysis to determine whether multiple IPv4 data packets are fragmented packets of the same IPv4 data packet.
  • the maximum value of the IPID exceeds 65535, that is, when When the IPID of an IPv4 data packet exceeds 65535, the IPID of the packet can continue to increase. It does not start from 0. This prevents the IPID of two or more fragmented packets that are not the same data packet from being the same at the receiving end. Meet the business needs of high-speed data transmission.
  • FIG. 5 is a schematic structural diagram of a data transmission apparatus according to Embodiment 3 of the present invention.
  • the apparatus includes an adding module 11, a generating module 12, and a sending module 13.
  • the adding module 11 adds an option Option field at the end of the first Internet Protocol version 4 IPv4 data header to generate a second IPv4 data header; the Option field includes an identifier bit, a length bit, and a data bit, and the second IPv4 data packet is in the Internet.
  • the protocol identifier IPID is the sum of the IPID of the first IPv4 data header and the number of bits of the data bits of the Option field.
  • the generating module 12 is configured to generate an IPv4 data packet according to the second IPv4 data header and the transmission data.
  • the sending module 13 is configured to send an IPv4 data message.
  • the device in this embodiment may be used to implement the technical solution of the method embodiment shown in FIG. 2, and the implementation principle and technical effects are similar, and details are not described herein again.
  • the adding module 11 is further configured to add a padding field after the data bit of the Option field, so that the sum of the data bit of the Option field and the number of bits of the padding field is 16.
  • FIG. 6 is a schematic structural diagram of a data transmission apparatus according to Embodiment 4 of the present invention. As shown in FIG. 6, the apparatus further includes an update module 14.
  • the update module 14 is configured to update the length of the second IPv4 data header, the total length of the corresponding IPv4 data message, and the header checksum.
  • the identifier bits of the Option field include a copy bit, a function option bit, and an option number.
  • the device in this embodiment may be used to implement the technical solution of the method embodiment shown in FIG. 2, and the implementation principle and technical effects are similar, and details are not described herein again.
  • the adding module 11 updates the header checksum of the second IPv4 data header, including: the adding module 11 performs 16-bit alignment on the values of the fields of the second IPv4 data header, and sets the header checksum to 0: summing the values of the aligned fields to obtain a first header checksum; re-aligning the first header checksum with the values of other fields by 16 bits to obtain a second header checksum; The second header checksum is bit flipped to obtain an updated header checksum.
  • the device in this embodiment may be used to implement the technical solution of the method embodiment shown in FIG. 3, and the implementation principle and technical effects are similar, and details are not described herein again.
  • FIG. 7 is a schematic structural diagram of a data transmission apparatus according to Embodiment 5 of the present invention.
  • the apparatus includes a receiving module 21 and a parsing module 22.
  • the receiving module 21 is configured to receive an IPv4 data packet of the Internet Protocol version 4.
  • the header of the IPv4 data packet includes an Option field, and the Option field includes an identifier bit, a length bit, and a data bit.
  • the parsing module 22 is configured to parse the IPv4 data packet according to the sum of the IPID of the IPv4 data header and the number of bits of the data bit of the Option field.
  • the identifier bits of the Option field include a copy bit, a function option bit, and an option number.
  • the device in this embodiment is a device at the receiving end corresponding to FIG. 5 and FIG. 6 , and the implementation principle and technical effects thereof are similar to the technical solutions in the method embodiment shown in FIG. 2 or FIG. 3 , and details are not described herein again.
  • the device includes a processor 31 and a sending interface 32.
  • the device may further include a receiving interface 33 and a memory 34, a sending interface 32, and a receiving interface. 33 is coupled to processor 31, respectively.
  • the sending interface 32 and the receiving interface 33 may be wired connection ports or wireless transceivers.
  • the sending interface 32 is a wireless transmitter
  • the receiving interface 33 is a wireless receiver.
  • Processor 31 may include one or more multi-core processors and/or memory 34.
  • the processor 31 can be a general purpose processor, an application specific integrated circuit (ASIC), or a digital signal processor (DSP).
  • ASIC application specific integrated circuit
  • DSP digital signal processor
  • Memory 34 can be a non-transitory storage medium coupled to processor 31 for storing different types of data.
  • the memory 34 may comprise a read only memory (ROM), a random access memory (RAM) or other type of dynamic storage device that can store information and instructions, or may be a disk storage.
  • ROM read only memory
  • RAM random access memory
  • Memory 34 can be used to store instructions that implement the related methods described in FIG. 2 or FIG.
  • the processor 31 adds an option Option field at the end of the first Internet Protocol version 4 IPv4 data header to generate a second IPv4 data header;
  • the Option field includes an identifier bit, a length bit, and a data bit, and an Internet Protocol identifier of the second IPv4 data packet.
  • the IPID is the sum of the IPID of the first IPv4 data header and the number of bits of the data bits of the Option field; and generates an IPv4 data packet according to the second IPv4 data header and the transmission data.
  • the sending interface 32 is configured to send an IPv4 data message.
  • the processor 31 is further configured to add a padding field after the data bit of the Option field, so that the sum of the data bit of the Option field and the number of bits of the padding field is 16.
  • the processor 31 is further configured to update a length of the second IPv4 data header, a total length of the corresponding IPv4 data message, and a header checksum.
  • the identifier bits of the Option field include a copy bit, a function option bit, and an option number.
  • the processor 31 updates the header checksum of the second IPv4 data header, including: the processor 31 performs 16-bit alignment on the values of the fields of the second IPv4 data header, and sets the header checksum to 0: summing the values of the aligned fields to obtain a first header checksum; re-aligning the first header checksum with the values of other fields by 16 bits to obtain a second header checksum; Will be second The header checksum performs a bit flip to obtain an updated header checksum.
  • the device in this embodiment may be used to implement the technical solution of the method embodiment shown in FIG. 2 or 3.
  • the implementation principle and technical effects are similar, and details are not described herein again.
  • the embodiment of the present invention further provides a device.
  • the structure of the device is the same as that of the device shown in FIG. 8.
  • the receiving interface is configured to receive the IPv4 data packet of the Internet Protocol version 4; and the IPv4 data packet.
  • the header includes an Option field, and the Option field includes an identifier bit, a length bit, and a data bit.
  • the processor parses the IPv4 data packet according to the sum of the IPID of the IPv4 data header and the number of bits of the data bit of the Option field.
  • the identifier bits of the Option field include a copy bit, a function option bit, and an option number.
  • the device in this embodiment may be used to implement the technical solution of the method embodiment shown in FIG. 2 or FIG. 3, and the implementation principle and technical effects are similar, and details are not described herein again.
  • the aforementioned program can be stored in a computer readable storage medium.
  • the steps of the foregoing method embodiments are performed; and the foregoing storage medium includes: Read-Only Memory (ROM), Random Access Memory (RAM), and Magnetic A variety of media that can store program code, such as a disc or a disc.

Landscapes

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

Abstract

La présente invention concerne un procédé et un appareil de transmission de données. Le procédé consiste : à ajouter un champ d'option dans une partie terminale d'un premier en-tête de paquet de données de protocole Internet version 4 (IPv4) et à générer un second en-tête de paquet de données IPv4, le champ d'option comprenant un bit de balise, un bit de longueur et un bit de données, un identifiant de protocole Internet (IPID) d'un second paquet de données IPv4 étant une somme entre un IPID du premier en-tête de paquet de données IPv4 et le nombre de bits des bits de données du champ d'option ; à générer un paquet de données IPv4 en fonction du second en-tête de paquet de données IPv4 et des données transmises ; à envoyer le paquet de données IPv4. La situation d'une combinaison erronée de paquets de données IPv4 due au fait que des IPID d'au moins deux paquets segmentés, qui ne sont pas un paquet de données IPv4 identique, sont identiques sur une extrémité de réception dans une période est évitée, ce qui permet de satisfaire des exigences de service d'une future transmission de données à grande vitesse filaire ou sans fil.
PCT/CN2016/073381 2016-02-03 2016-02-03 Appareil et procédé de transmission de données WO2017132911A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
PCT/CN2016/073381 WO2017132911A1 (fr) 2016-02-03 2016-02-03 Appareil et procédé de transmission de données
CN201680048976.3A CN107925516A (zh) 2016-02-03 2016-02-03 数据传输方法和装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2016/073381 WO2017132911A1 (fr) 2016-02-03 2016-02-03 Appareil et procédé de transmission de données

Publications (1)

Publication Number Publication Date
WO2017132911A1 true WO2017132911A1 (fr) 2017-08-10

Family

ID=59500331

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2016/073381 WO2017132911A1 (fr) 2016-02-03 2016-02-03 Appareil et procédé de transmission de données

Country Status (2)

Country Link
CN (1) CN107925516A (fr)
WO (1) WO2017132911A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114205425A (zh) * 2020-09-02 2022-03-18 中国移动通信有限公司研究院 一种报文传输方法、装置、设备及可读存储介质

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115150476B (zh) * 2022-06-20 2024-04-12 浪潮思科网络科技有限公司 一种eigrp协议报文压缩方法、系统、设备及介质
CN115174702B (zh) * 2022-09-08 2022-11-22 深圳华锐分布式技术股份有限公司 基于rdma协议的数据传输方法、装置、设备及介质

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101567852A (zh) * 2009-05-20 2009-10-28 中兴通讯股份有限公司 Ip报文网络地址转换的方法及装置
US20100265932A1 (en) * 2009-04-20 2010-10-21 Sony Corporation Wireless transmitter, wireless transmission method, wireless receiver and wireless reception method
WO2011120470A2 (fr) * 2011-05-09 2011-10-06 华为技术有限公司 Procédé et dispositif de surveillance des performances de flux média
CN103532672A (zh) * 2013-10-22 2014-01-22 芮雄丽 一种sdn网络中分片报文乱序的处理方法及应用

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100265932A1 (en) * 2009-04-20 2010-10-21 Sony Corporation Wireless transmitter, wireless transmission method, wireless receiver and wireless reception method
CN101567852A (zh) * 2009-05-20 2009-10-28 中兴通讯股份有限公司 Ip报文网络地址转换的方法及装置
WO2011120470A2 (fr) * 2011-05-09 2011-10-06 华为技术有限公司 Procédé et dispositif de surveillance des performances de flux média
CN103532672A (zh) * 2013-10-22 2014-01-22 芮雄丽 一种sdn网络中分片报文乱序的处理方法及应用

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114205425A (zh) * 2020-09-02 2022-03-18 中国移动通信有限公司研究院 一种报文传输方法、装置、设备及可读存储介质

Also Published As

Publication number Publication date
CN107925516A (zh) 2018-04-17

Similar Documents

Publication Publication Date Title
US10880817B2 (en) Wi-fi configuration method, Wi-Fi mobile terminal, and Wi-Fi device
WO2021000827A1 (fr) Procédé et appareil d'établissement de liaison de transmission de données, et support de stockage lisible par ordinateur
US10462065B2 (en) Path maximum transmission unit discovery
US11824959B2 (en) ROHC header compression for MPTCP
US11637771B2 (en) Technologies for managing network traffic through heterogeneous networks
US11153207B2 (en) Data link layer-based communication method, device, and system
WO2016000513A1 (fr) Procédé et dispositif pour mettre à jour une manière de traitement d'un paquet de flux de services
US20220174477A1 (en) Method and apparatus for realizing network capability opening, electronic device and storage medium
CN112534779A (zh) 更新用于应用的pfd规则和相关网络节点的方法
WO2020078324A1 (fr) Procédé et appareil de mesure de retard
WO2008040203A1 (fr) Procédé, système et routeur pour calcul de l'unité de transmission maximale de l'interface de sortie du routeur
WO2017132911A1 (fr) Appareil et procédé de transmission de données
US20230379244A1 (en) Ultra reliable segment routing
Klauck et al. Enhanced DNS message compression-Optimizing mDNS/DNS-SD for the use in 6LoWPANs
WO2015192705A1 (fr) Dispositif d'accès et procédé implémenté par un dispositif d'accès pour connecter un équipement d'utilisateur dans un réseau
WO2022142390A1 (fr) Procédé et dispositif d'encapsulation et de désencapsulation de paquet, support de stockage, et dispositif électronique
WO2017041534A1 (fr) Procédé et dispositif de communication par courants porteurs en ligne, et support de stockage informatique
JP2018518869A (ja) マルチプルシーケンス化フローのためのバンドルされた前方誤り訂正（ｆｅｃ）
WO2015096734A1 (fr) Procédé de transmission en liaison descendante pour des données de service, et passerelle de données de paquet
US11470502B2 (en) Congestion notification by data packet from intermediate node
WO2018045521A1 (fr) Procédé et dispositif de transmission de signalisation dans un réseau sans fil
EP3345411A1 (fr) Programme informatique, support de stockage lisible sur ordinateur, dispositif d'émission, dispositif de réception et procédés mis en uvre dans celui-ci pour transférer des données d'utilisateur d'arrière-plan
WO2009109128A1 (fr) Procédé et dispositif de configuration de messages d'information à en-tête pleine
WO2017143538A1 (fr) Procédé et appareil de transmission de données vocales
US8774202B2 (en) Methods, systems, and computer readable media for generating general packet radio service tunneling protocol (GTP) encapsulated real-time transport protocol (RTP) packets in a long term evolution (LTE) node simulator

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

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 16888736

Country of ref document: EP

Kind code of ref document: A1