CN114337893A - Precise time synchronization method based on programmable data plane - Google Patents

Precise time synchronization method based on programmable data plane Download PDF

Info

Publication number
CN114337893A
CN114337893A CN202111631275.1A CN202111631275A CN114337893A CN 114337893 A CN114337893 A CN 114337893A CN 202111631275 A CN202111631275 A CN 202111631275A CN 114337893 A CN114337893 A CN 114337893A
Authority
CN
China
Prior art keywords
time
switch
packet
synchronization
delay
Prior art date
Legal status (The legal status 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 status listed.)
Pending
Application number
CN202111631275.1A
Other languages
Chinese (zh)
Inventor
颜金尧
殷天航
王驰朝
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Communication University of China
Original Assignee
Communication University of China
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 Communication University of China filed Critical Communication University of China
Priority to CN202111631275.1A priority Critical patent/CN114337893A/en
Publication of CN114337893A publication Critical patent/CN114337893A/en
Pending legal-status Critical Current

Links

Images

Landscapes

  • Synchronisation In Digital Transmission Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

An accurate time synchronization method based on a programmable data plane relates to the technical field of time synchronization. The invention appears because the invention is very sensitive to the time synchronization precision in the network in the application scenes of industrial automation, a distributed multipoint synchronization system, an ultra-high definition video and audio production and broadcasting network and the like, and the corresponding technology is required to enable the network to support higher time synchronization precision. The invention provides a time synchronization combination technology of a network card and a P4 switch based on a programmable data plane technology, realizes nanosecond-level time synchronization, and optimizes synchronization precision under different link conditions. In addition, the invention provides a brand new framework: the method combines the original network card packet receiving acceleration technology with the data plane-based time synchronization technology, adopts a machine learning method, and optimizes the obtained synchronization error parameters, thereby reducing synchronization errors, optimizing a synchronization mode, and selecting the most appropriate accurate time synchronization mode in different scenes.

Description

Precise time synchronization method based on programmable data plane
Technical Field
The invention relates to the technical field of time synchronization, in particular to a precise time synchronization method and a precise time synchronization system based on a programmable data plane. The invention appears because the invention is very sensitive to the time synchronization precision in the network in the application scenes of industrial automation, a distributed multipoint synchronization system, an ultra-high definition video and audio production and broadcasting network and the like, and the corresponding technology is required to enable the network to support higher time synchronization precision. The traditional synchronization method cannot meet the requirements of high-precision synchronization scenes due to high actual deployment cost, low synchronization precision and the like. Meanwhile, the traditional network architecture is difficult to adapt to the requirement of the current rapidly-developed upper-layer application on time synchronization due to the characteristics of poor closure and openness. The software defined network and the programmable technology provide a new idea for the service scenes such as the ultra-high definition audio and video production and broadcasting network and the like which need the high-precision synchronization technology.
Background
DPTP data plane time synchronization protocol is used for synchronization between switches and supports nanosecond synchronization precision. For the current development, the time synchronization protocol is usually applied to industrial switches, for example, TSN (time sensitive network) switches are implemented based on IEEE 1588, and such industrial switches process clock information at the control layer.
PTP adopts master-slave clock synchronization mode, and the master-slave clocks realize time or frequency synchronization through messages such as interactive synchronization, state and time delay measurement. The PTP adopts the hardware timestamp, so the precision and the accuracy of the timestamp are higher, the synchronization precision of nanosecond level or even higher can be generally realized, and the PTP is widely applied to high-precision time synchronization solutions of systems such as a communication transmission network, a mobile return network, a smart grid, a high-speed railway and the like.
SDN software defined networking technologies monitor and manage multiple network facilities through the OpenFlow protocol using a centralized controller through decoupling of the network facility control plane and the data plane. In the software defined network architecture, the control plane is logically controlled in a unified manner, the whole network link is monitored, the southbound OpenFlow protocol is used for sending a control plane command to the data layer of each device in the network, and the unified management of the network devices is enhanced through the separation of control and forwarding, so that the deployment steps on each device are simplified.
Disclosure of Invention
The invention provides a network card and programmable data plane time synchronization combination technology based on a programmable data plane technology, realizes nanosecond-level time synchronization, and optimizes synchronization precision under different network conditions. In addition, the invention provides a brand new framework: the original network card packet receiving acceleration technology is combined with the data plane time synchronization technology, and the obtained synchronization error parameters are optimized by adopting a machine learning method, so that the synchronization errors are reduced, the synchronization mode is optimized, and the most appropriate accurate synchronization time is selected in cooperation with different network scenes, so that a better synchronization effect is achieved.
A method for precise time synchronization based on a programmable data plane is characterized by comprising the steps of processing data packets on the programmable data plane; accelerating the network card transceiving data packet by adopting a DPDK + Lua script language framework; predicting the synchronization delay and the link delay by adopting a machine learning method, and optimizing the whole synchronization system;
when a slave network switch generates a request data packet, a request response time axis starts, and when a master switch receives a corresponding response data packet, the request response time axis ends, two master-slave P4 switches are designed, the slave switch sends a synchronous request data packet to the master switch, the master switch writes the timestamp information of a data plane into the synchronous request data packet after receiving the data packet, and then generates a response data packet and sends the response data packet to the slave switch; after receiving the response data packet from the switch, extracting timestamp information carried in the data packet, wherein the timestamp information comprises various delay components involved in a request-response data packet model; in the data plane, the programmable data plane provides four timestamp components of TRx, TIg, TEx and TTx, wherein TRx represents the time when the data packet enters the parser; TIg denotes the time at which the packet enters the ingress pipeline; TEg denotes the time at which the packet enters the egress port pipeline; TTx represents the time that the packet came out of the inverse parser;
the processing of data packets in the programmable data plane pair comprises the following steps:
step 201, two switches are deployed, wherein SW1 is a slave switch and is used for calibrating a clock, and SW2 is a master switch and is used for determining reference time;
step 202, the master switch SW2 obtains a timestamp value TExt from an external clock source, and the timestamp value TExt is used as a reference clock TRefsw of the slave switch SW1 of the current data plane, and simultaneously stores a timestamp trespid entering an ingress port pipeline obtained inside the data plane SW2 into a register, and records that the current timestamp is Toffset (Toffset is trespid);
step 203, the x bit counter is kept not to be cleared within the time period of 2^ x-1 seconds, a register is required to be added in order to ensure that longer time is obtained to avoid the clearing of the counter, when the counter is about to be cleared, the register can record the time before the clearing, and the time information is recorded as Tera;
step 204, when the master switch SW2 receives a synchronization request packet, it reads the clock source timestamp value TRefsw obtained from the outside, the timestamp Tera of the register corresponding to the time slot where it is located, and the time offset variable Toffset of the pipeline at the ingress port;
step 205, when the master switch SW2 is exiting the port pipeline, the current egress port timestamp TRespEg is read;
step 206, calculating the current timestamp TNowsw after adding the reference time TRefsw by using the following formula, where the current timestamp TNowsw is calculated from the timestamp T _ offset of the input port pipeline, and the current timestamp value is:
Figure BDA0003440071790000021
step 207, since the variable TNowsw avoids the delay generated by the egress port queue, the time value calculation is inaccurate by using the egress port pipeline TRespEg, so that the step 206 is repeated to calculate the value of the TNowsw variable by using TRespEg whenever the switch receives a request packet from another switch;
step 208, the slave switch SW1 sends a request packet at the time of treeqtx; when the request packet is received by the master switch SW2 at the time of TReqRx, the master switch SW2 calculates the current reference TRefsw2 time value according to the formula 206;
step 209, in the data plane, the master switch SW2 matches the flow table by executing the action matching table, embeds the TRefsw2, the treqrrx, and the TRespEg time variable into the request packet, and the request packet is sent out by the master switch as a response packet at this time and is retransmitted back to the slave switch SW 1;
step 210, the slave switch SW1 receives the response packet at the TRespRx moment, and repeats step 206 to calculate the current time TNowsw2 of the master switch SW 2;
step 211, the slave switch SW1 starts processing the response packet at the trespid moment, and at this time, trespid is written into a register through a data plane register, which is marked as Toffset;
step 212, calculating the reference clock of the current slave switch, wherein the slave switch SW1 further needs to receive the accurate sending time of the data packet at the master switch, so that the master switch SW2 subsequently sends a Follow _ up packet, which includes the timestamp of the required accurate sending response data packet by the master switch and is recorded as TRespTx;
step 213, after obtaining the TRespTx variable value from switch SW2, calculates the total delay as RespD using the formula:
Figure BDA0003440071790000031
in step 214, the current time TNowsw2 of the master switch SW2, and the total delay RespD, can accurately calculate the synchronization time of the slave switch SW1 by the following formula:
Figure BDA0003440071790000032
in step 215, step 201 to step 214 are repeatedly executed.
Further, accelerating the network card transceiving data packet by adopting a DPDK + Lua script language framework, accelerating the network card transceiving data packet on hardware by adopting the DPDK, and simultaneously initializing and sending a synchronous request packet on software by adopting a Lua script language;
the method for accelerating the network card transceiving data packet by adopting the DPDK + Lua script language framework comprises the following steps:
step 301, installing a DPDK on a host, configuring a large-page memory Hugepages, and loading a kernel module;
step 302, defining a synchronous request packet by adopting a Lua script language, and defining a data packet sending rule;
step 303, in an initialization stage, when no cross traffic exists in a link, the host sends a DPTP probe packet to the programmable switch first, and the switch replies each timestamp TNowsw, TRespRx, trestx, tresqrrx, TRespTx to the host; TNowsw is the current slave switch time, TResprx is the time when the response packet reaches the network card, TReqTx is the time when the host sends the detection packet, TReqRx is the time when the switch receives the detection packet, and TRespTx is the time when the output port sends the response packet;
in step 304, in the initialization phase, when the link rate R is 0%, the link delay nicowiredelay at this time is calculated according to the following formula:
NicWireDelay=(TRespRx-TReqTx)-(TRespTx-TReqRx
step 305, in the synchronization stage, calculating the reference time RespD of the host according to the following formula, where TRespTx is the time for the switch to issue a response packet, and TRespEg is the time for the response packet to come out from the output port pipeline of the switch:
RespD=OWD+(TRespTx-TRespEg)
step 306, determining the uncomputed delay OWD, if in the synchronization stage, the link rate R is equal to about 0%, at this time, OWD is nicwired delay/2, and once R is not 0%, the nicwired delay at this time is linearly increased, and in order to ensure the accuracy of synchronization and the synchronization of the clock on the host with the switch, it is necessary to use the nicwired delay calculated in the idle link in the initialization stage of step 303, which is referred to as avgnicwired delay, to calculate OWD; OWD was calculated according to the following formula:
Figure BDA0003440071790000041
step 307, calculating the reference time RespD of the host by using the formulas of the step 305 and the step 306, and achieving the synchronization between the host and the programmable switch;
step 308, repeat steps 301 to 307.
Further, a machine learning method is adopted to predict and compensate synchronous delay and link delay, the whole synchronous system is optimized, the total delay and the one-way link delay between the switches under different network states under the condition of load and no load are counted, the total delay and the one-way link delay between the switches are predicted and compensated by adopting a recurrent neural network (LSTM), the delay at the moment is counted and used as an input layer when the synchronization starts, so that the current output delay is predicted, and the value at the moment is used as the input layer for iteration;
the method for predicting and compensating the synchronization delay and the link delay by adopting a machine learning method and optimizing the whole synchronous network system specifically comprises the following steps:
step 401, according to step 213, calculating the total delay RespD between the master and slave switches;
step 402, according to step 306, calculating the uncalculated delay OWD between the host and the switch;
step 403, counting the total delay and the one-way link delay between the switches in different network states;
step 404, after the whole network is synchronized, due to the fact that the network has cross flow, various congestion and packet loss phenomena, RespD and OWD can generate changes with different amplitudes, the RespD and OWD are used as input x and are placed into a recurrent neural network (LSTM), and new RespD and OWD are predicted to serve as output h;
step 405, predicting a new RespD, and repeating step 214 to calculate the synchronization time of the slave switch SW 1;
step 406, repeating step 305 to calculate the reference time of the host by using the predicted new OWD;
and step 407, repeating the steps 401 to 405, and continuously updating the synchronization time of the slave switch and the master.
The invention realizes that the timestamp variable values of all the components are embedded into the synchronous data packet in the data plane, and also realizes that the measured synchronization precision is within 25 nanoseconds under a no-load link compared with the traditional time synchronization method, and simultaneously simulates the situation of a complex link, and the measured synchronization precision is within 35 nanoseconds. When an actual physical topology is built, a p4c compiler is used for compiling the actual physical topology into json files to be configured in the programmable network equipment, and a DPDK operating environment is installed on a network card at a server side, so that the network card and the switch can be synchronized.
Description of the drawings:
FIG. 1: network card (server) and switch time synchronization technology architecture
FIG. 2: lua function call procedure
FIG. 3: p4 code correspondence analysis chart
FIG. 4: switch part table matching rule
FIG. 5: RNN network structure
FIG. 6: LSTM network structure
FIG. 7: synchronous system logic topology map
FIG. 8: synchronization information for 2P 4 switches
FIG. 9: lua code file result of executing host
FIG. 10: lua code file result executed on network card end
Detailed Description
The invention provides a test scheme of a network card (server) and switch time synchronization technology and provides a complete technical architecture diagram.
Network topology design
The invention designs a simple data center network topology to verify and test the proposed network card (server) and time synchronization technology, the test comprises 4 host computers (2 servers, two ports of each server network card are respectively regarded as 1 host computer), 2P 4 switches (1 physical P4 switch is virtualized into 2 switches), and a specific network topology diagram is shown in FIG. 7.
The test experiment of the whole synchronization technology comprises a Barefoot Tofino switch which is connected with 2 servers, wherein the servers adopt Intel X520-DA2 network cards (supporting 10G/25G). The P4 physical switch uses the 132 ports and 168 ports of the 10G fabric connection switch to form a loopback link for virtualizing one physical switch as 2 switches. In the server network card part, the X520-DA2 supports obtaining of a hardware timestamp of the network card, a port 0 of the network card is connected with a port 154 of a P4 switch, and a port 1 of the network card is connected with a port 136 of a P4 switch, so that a synchronous data packet sending and receiving link of the network card 1-P4 switch-network card 2 is realized. The Software Environment comprises an SDE (Software Development Environment) version bf-SDE-8.9.1 of a P4 switch, an Ubuntu-16.04-server-amd64 version of a server operating system and a DPDK version 20.08.
Second, build network topology
(1) Programmable data plane terminal
In this section, P4 code was written to implement virtualization of the P4 physical switch and synchronization between two P4 switches. Firstly, a P4 compiling command is used for compiling P4 codes corresponding to service logic, and data plane forwarding logic of a data packet is loaded into a P4 switch. The master switch sends a synchronous data packet to the master switch based on the time information of the reference clock source, and simultaneously calculates a synchronous error between the master switch and the slave switch according to the received response data packet to correct the clock of the master switch. The P4 code is then compiled in the P4 switch with P4c and the compiled code is loaded into the switch. After the code is compiled, corresponding data packet processing logic is realized only in a data layer, and then a flow table is downloaded to the switch through a control plane, wherein the logic comprises logic of sending and receiving data packets from which port to enter and exit.
As shown in fig. 8, the respective delay values after 2P 4 switches are synchronized and the synchronization error of 2 switches can be seen. As can be seen from the figure, after a sync packet arrives at the master switch, a packet parsing process takes 62 ns, a pipeline processing and queue waiting at an ingress port of the master switch takes 350 ns, a pipeline processing and packet reverse parsing process at an egress port takes 320 ns, and a round trip RTT from the transmission of a sync request packet to the reception of a response packet from the switch is 905 ns. Meanwhile, the absolute synchronization precision between the master P4 switch and the slave P4 switch can be obtained to be 6 nanoseconds.
(2) Server network card terminal
After the P4 switches are synchronized, the network card sends a synchronization request packet to the switches in the same header format as that of the switch synchronization, and the result of executing the host. As can be seen from the figure, EAL (Environment Abstraction Layer) in DPDK detects and initializes the server and the network card device. 2 ports of the Intel X520-DA2 network card are taken over by the EAL, so that when sending and receiving synchronous request data packets, the Linux kernel can be bypassed for data packet processing. Meanwhile, 2 ports of the Intel X520-DA2 network card are configured to be independent 2 hosts, namely Device 0 and Device 1, the corresponding mac is 90: E2: BA:27: A7:34 and 90: E2: BA:27: A7:35, and the link rate of the network port is 10000 Mbit/s. The part mainly realizes the configuration of the network card, the sending and receiving of data packets and the acceleration of the processing of the data packets. Firstly, a DPDK technology is started and configured in a Linux system, and the configuration comprises the steps of inserting an IGB _ UIO module, distributing a large-page memory for a server, and binding a network card to a driver compatible with the DPDK. Lua code is then executed to enable the network card to send to the synchronized P4 switch at a rate of 2000 packets per second. The network card supports hardware time stamps, and the time stamps sent by the network card can be embedded in the sent data packets by a method of reading the physical time stamps through the network card driving API, and finally the server network card and the switch start synchronous testing.
Lua code is executed at the network card end, and as a result, as shown in fig. 10, the value of each time variable used by the network card for the time synchronization formula can be obtained. Host2(Dev 1) sends a timesync packet, command is set as a response packet command (0x3), and after receiving the response packet, the value of each time variable defined in the header of the synchronization packet can be obtained, and when the command is a timestamp command (0x6) for capturing the sent packet, the value of each time variable can also be calculated. From the figure, it can be derived that the response packet information returned by the switch, for example, the time for the switch to process the network card request packet is 53 ns, and in the patent, the absolute synchronization error between Host1 and the P4 switch (single hop) is 7 ns.
Invention integrated frame
The integral framework of the invention mainly comprises three parts: the programmable data plane processes data packets, a DPDK + Lua script language framework is adopted to accelerate the network card to receive and transmit the data packets, a machine learning method is adopted to predict synchronous delay and link delay, and the whole synchronous system is optimized.
In the part of processing the data packets in the programmable data plane, according to the principle of master-slave synchronization of the programmable data plane, the header format of a self-defined synchronous data packet, a data plane acquisition time stamp, logic codes embedded in the synchronous data packet and a corresponding flow table under a switch by utilizing a control plane are realized by writing P4 codes, so that the synchronization between two or more P4 switches is realized. After the two P4 switches complete synchronization, at this time, a data packet module, which is implemented by the server side network card based on DPDK and Lua scripting languages, continuously sends a synchronization request data packet to the switches, and after the P4 switch receives the data packet with the same format, the data packet is processed on the data plane through an action-matching pipeline, including writing in the own master clock of the synchronized switches and a timestamp component of the data plane. When all time information of the P4 switch is written into the data packet, the switch sends out the response data packet through the matching-action pipeline and then forwards the response data packet back to the server side. After receiving the response data packet, the server side directly delivers the synchronous request data packet to an upper application by bypassing the kernel by using a DPDK data packet acceleration technology, and analyzes and calculates the time information. Based on the above scheme, a request response model and an overall experimental framework diagram of a network card (server) and a switch are provided, as shown in fig. 1.
The accelerating part of the network card transceiving data packet by adopting a DPDK + Lua script language framework is divided into two steps: accelerating the network card receiving packet and realizing the receiving and sending packets by software. In the acceleration of the network card receiving packet, the problem of inaccurate delay measurement is caused by considering that the traditional data packet processing mode is a mode of CPU interruption, memory copy, context switch, memory management and the like. Therefore, the DPDK technology for accelerating data packet processing is adopted, the Linux kernel protocol stack can be bypassed, extra time overhead caused by memory copying, management and the like is reduced, and the synchronization precision is improved. The software implementation of the receiving and sending package is realized by adopting Lua script language. A high-rate packet generator MoonGen developed based on a DPDK data packet acceleration technology is adopted at the bottom layer. On one hand, as a 'decorator' of the DPDK, the Moonnen can fully utilize the characteristic advantages of the DPDK technology and support the acceleration of data packet processing; on the other hand, the whole MoonGen is completely controlled by the Lua script language, a user can develop a corresponding Lua script according to the service logic of the user to realize receiving and sending of the data packet, and the Lua language is used as a light-weight embedded script language and has the characteristics of high efficiency, portability, simplicity and lightness. In the module, according to the requirement of sending a synchronization request packet in a Host-Switch system, a packet header definition and receiving and sending module realized based on a Lua script language is deployed in a network card.
The method comprises the steps of predicting synchronization delay and link delay by adopting a machine learning method, optimizing the whole synchronization system part, predicting and compensating total delay and one-way link delay between switches by adopting a recurrent neural network (LSTM), counting the delay at the moment when synchronization starts, taking the delay as an input layer, predicting current output delay, taking the value at the moment as the input layer, iterating, predicting new total delay RespD and uncomputed delay OWD of a link, recalculating synchronization time between the switches and between a host and the switches, avoiding factors influencing the synchronization time, such as congestion and packet loss in a network after network synchronization, further improving synchronization precision, and further matching with different network scenes, selecting the most appropriate precise synchronization time to achieve better synchronization effect.
Various operation principles and implementation method of the invention
Programmable data plane processing data packet
The programmable data plane is in the P4 language. The P4 program mainly includes Header, Parser, Match-Action Table and Control Flow. P4 was programmed in three parts, header.p4, parser.p4 and main.p 4. P4 declares the data packet head needed to be supported; the method comprises the steps of instantiating a data packet header in a Parser.p4 and analyzing the data packet according to a sequence and a command in the data packet; and (4) writing the nanosecond-level time stamp of the data plane of the switch into a data packet in the main.p4, simultaneously executing corresponding forwarding logic and defining a control flow program of the execution sequence of each matching action table.
(1)Head.p4
P4, the packet header that the network device may process is declared, and in this experiment, the Ethernet protocol, the UDP protocol, the IPV4 protocol, and the timesync protocol are processed.
The packet format statement in the Timesync protocol is the same as the timestamp in lua, so as to ensure that the packet is normally communicated between the network card and the switch. Such as UDP protocol, IPV4 protocol, etc. no longer described, after declaring the timeout protocol, Parser needs to be defined to parse the packet, and the extracted related information is written into the instance of each protocol packet header for the following action-matching table.
(2)Parser.p4
The Parser usually starts at Parser start and ends at return addresses, and extracts the header information of the packet in sequence. The header needs to be instantiated before parsing, which is shown in FIG. 3.
Firstly instantiating Ethernet and extracting Ethernet field in data packet, storing the correspondent information in the instantiated object, judging the Ethernet field of the extracted Ethernet packet head and deciding the next Parser flow direction, in this patent, respectively flowing to the timesync header and IPv4 protocol support. IPv4 and the timesync are instantiated, and information of each field of the timesync in the data packet is extracted.
(3)Main.p4
In the main.p4 file, the include other two p4 files are needed first, then to implement the writing of time stamps into the data packets in the data plane, a plurality of action-matching tables are defined, including the action-matching tables implementing the three-layer routing forwarding function, and a register data structure is used to temporarily store the time stamp values in the data packets for switch internal time synchronization. Only three consecutive actions are chosen here-matching tables mac _ forward, copy _ packet and timesync _ info _ cp to introduce the code flow, as shown in FIG. 4.
As can be seen in the figure, first, a matching operation is performed on the table mac _ forward, the destination mac address in the data packet is matched with the flow table entry in the table, and if the matching is successful (hit), a set _ egr action is performed. In the set _ egr action, the output port of the metadata and the output port of the metadata inherent in the P4 switch ASIC are modified according to the matched entry information. The purpose of this action is to modify the output port of the data plane packet by dropping the flow table, controlling the forwarding of the packet from the designated port at the control plane.
And then matching table copy _ packet, matching the value of mdata.command with the entry in the table, if the matching is successful, executing a modify _ packet action, in the modify _ packet action, only copying each field information in the timeout data packet into metadata mdata without modifying the operation of the data packet according to a flow table, and then writing the updated data in the metadata into the timeout data packet.
The third matching is the table timesync _ info _ cp, namely, the value of mdata.command is matched with the entry in the table, and if the matching is successful (hit), the timesync _ flag _ cp _ spare action is executed. There is no need to modify the packet contents according to the flow table in this action, as shown in fig. 3, to inform the control plane to send Follow _ up packets.
Accelerating network card transceiving data packet by adopting DPDK + Lua script language framework
The DPDK module is mainly used for accelerating the sending and receiving of data packets, and a Hugepages (large page memory) and a loading kernel module are required to be configured in a command line mode by installing a corresponding DPDK version on a server. The DPDK application program runs in a user space and receives and transmits data packets by using a data plane library provided by the DPDK application program, and the processing process of the data packets by a Linux kernel protocol stack is bypassed. The Linux kernel treats a DPDK application (including its compilation, connection, and loading) as a common user-mode process. And after the DPDK program is started, only one main thread is needed, and then some sub-threads are created and bound to a specified CPU core to run.
The Lua script language framework is mainly used for realizing the initialization and the sending of the synchronous request packet. Mainly containing 2 files, timesync. Lua, declaring a header format and a protocol command constant of a request packet; and transmitting the data packet, extracting the time stamp variable value in the data packet and finishing the calculation of the time delay in the host.
(1) Lua defines synchronization request packet timesync
Declaring a packet header protocol to be processed by the network device in the timesync.
Table 1: lua header is declared in the main field
Figure BDA0003440071790000111
Meanwhile, a command flag needs to be set for the data packet, so that when the switch or the network card receives the data packet, the type of the data packet can be known, and different code strategies can be executed. In this patent, 7 kinds of packet command flags are set, TYPE _ REQ, TYPE _ RES, TYPE _ DELAY _ REQ, TYPE _ DELAY _ RES, TYPE _ CAPTURE _ TX, TYPE _ gendate _ REQ, and TYPE _ GENREQ, respectively. The TYPE _ REQ represents that the current data packet is a request data packet, the TYPE _ RES represents that the current data packet is a response data packet, the TYPE _ DELAY _ REQ represents that the current data packet is a request data packet carrying time DELAY, the TYPE _ DELAY _ RES represents that the current data packet is a response data packet carrying time DELAY, the TYPE _ CAPTURE _ TX represents that the current data packet is a data packet carrying a CAPTURE sending timestamp, the TYPE _ CAPTURE _ REQ is a request data packet generating time DELAY, and the TYPE _ GENREQ is a generated request data packet. Lua files, when a P4 switch receives a synchronization request packet, the switch adopts a different packet handling strategy.
Corresponding to defining the format of the data packet header and the command for executing the data packet, a method of acquiring time information in the data packet and a method of adding a command to the data packet are also defined, as shown in table 2. The protocol packet header required to be processed for the synchronization request data packet is declared to be completed, and then the data packet is sent to a P4 switch through a bottom-layer DPDK technology, and meanwhile, time field information is extracted from the received response data packet, and a synchronization error is calculated and used for correcting the clock synchronization of the network card at the server side.
Table 2: method for acquiring time information in data packet and method for adding command to data packet
Method for adding data packet command Method for obtaining variable value of timestamp of data packet
setCommand(int) getMagic()
getCommand() setMagic(int)
getReference_ts_lo()
getReference_ts_hi()
getEraTs()
getMacTs()
getIgTs()
getDelta()
getEgTs()
Corresponding to defining the format of the data packet head and the command for executing the data packet, a method for acquiring the time information in the data packet and a method for adding the command to the data packet are also defined. At this time, the protocol packet header required to be processed by the synchronization request data packet is declared to be completed, and then the data packet is sent to a P4 switch through a bottom-layer DPDK technology, and meanwhile, time field information is extracted from the received response data packet, and a synchronization error is calculated for correcting the clock synchronization of the network card at the server side. (2) Lua is a data packet sending file host
The time synchronization process of the server network card and the P4 switch comprises the following steps: designing and initializing a synchronous request data packet at a network card end of a server, then sending the request data packet and recording a timestamp value TReqTx at the moment; then, the synchronous request data packet arrives at a P4 switch, and the current timestamp TReqTx is recorded; the synchronized P4 switch will calculate the current TNowsw according to the formula and write the timestamp variable value into the packet at the data plane of the P4 switch: the response packet is then sent out of the egress port pipeline of the P4 switch, and the timestamp treeqtx at that time is recorded. Meanwhile, in order to reduce the influence of waiting delay of the response data packet in the queue, a Follow _ up data packet is additionally sent, and a timestamp actually sent by a TReqTx response data packet stored in the data packet is saved; when the response data packet reaches the network card, the timestamp TReqRx at this time is recorded, so that the network card device can calculate the synchronization error between the network card device and the switch, and the synchronization error is used for correcting the clock of the network card of the server. In addition to the individual timestamps mentioned above, the switch also calculates the link packet rate R.
In the host.lua file, calling an API of a bottom device module to configure the number of sending queues and the number of receiving queues in the network card, calling an Enablestamps () method to start a timestamp for the two queues, and reading a physical timestamp from the network card. The initialization and the data packet sending are realized in an InitiateServer () function, the time delay between the network card and the switch is calculated in a StartTimesync () function, and the function is used for correcting the time stamp of the network card and realizing the synchronization of the network card and the switch network.
Thirdly, the machine learning method is used for predicting the synchronization delay and the link delay and optimizing the whole synchronization system
Time series model
Time series prediction analysis is to use the characteristics of an event time in the past period of time to predict the characteristics of the event in the future period of time. The method is a relatively complex prediction modeling problem, different from the prediction of a regression analysis model, a time sequence model is dependent on the sequence of events, the result generated by inputting the time sequence model after the sequence is changed by values of the same magnitude is different, the characteristics of the time sequence model are utilized to optimize synchronous error data, and the most appropriate accurate time synchronization mode under different scenes is selected.
(II) RNN and LSTM models
The most common most powerful tool for time series models is the Recurrent Neural Network (RNN). Compared with the characteristic that the calculation results of the common neural network are independent, the calculation result of each hidden layer of the RNN is related to the current input and the previous hidden layer result. By the method, the calculation result of the RNN has the characteristic of memorizing the results for several times.
(1) RNN model
A typical RNN network structure is shown in FIG. 5, with the structure on the right created for ease of memory understanding during computation. In brief, x is the input layer, o is the output layer, s is the hidden layer, and t refers to the calculation of the number of times; and V, W and U are weights, wherein St is f (U is Xt + W is St-1) when the t-th hidden layer state is calculated, and the purpose of hooking the current input result with the previous calculation is realized.
(a) And (3) predicting and compensating the single link time delay by using RNN:
when the synchronization starts, the synchronization error of the single link at the moment is calculated and used as an input layer, so that the synchronization error of the currently output single link is predicted, the numerical value at the moment is used as the input layer to iterate, the synchronization error adapting to the whole network structure is calculated, the synchronization error is used for carrying out time synchronization on the whole network again, and the accurate synchronization effect is improved under different scenes.
(b) Limitation of RNN:
the RNN model is generally used directly to perform long-term memory calculations because it needs to hook the current implicit state calculation with the previous n calculations if long-term memory is to be implemented, i.e., St ═ f (U × Xt + W1 × St-1+ W2 × St-2+. + Wn St-n), where the amount of calculation increases exponentially, resulting in a significant increase in the time for model training.
(2) LSTM model
The LSTM (Long Short-Term Memory) model is a variation of RNN, and the LSTM is characterized in that valve nodes of each layer are added outside an RNN structure. The valves are of type 3: forgetting the valve, the input valve and the output valve. These valves can be opened or closed to add a determination of whether the memory state of the model network (the state of the previous network) at the layer output reaches a threshold value to the current layer calculation.
The valve node calculates the memory state of the network as input by using a sigmoid function; if the output result reaches the threshold value, multiplying the valve output by the calculation result of the current layer to be used as the input of the next layer; and if the threshold value is not reached, forgetting the output result. The weights at each level, including the valve nodes, are updated during each model backpropagation training, as shown in FIG. 6.
(a) Memory function of LSTM model:
the memory function of the LSTM model is implemented by these valve nodes. The training results of the previous model are correlated to the current model calculation when the valve is open, and the previous calculation results no longer affect the current calculation when the valve is closed. Therefore, by adjusting the opening and closing of the valve, we can achieve the effect of the early sequence on the final result.
(b) The synchronization time error is optimized by using an LSTM model:
the method comprises the steps of respectively measuring the time delay conditions (loaded condition and unloaded condition) of each part under different network states, taking the error as the input of the previous layer, calculating the time delay of the next layer, carrying out iteration for many times, calculating the time synchronization error under the current network state, and calibrating the time synchronization of the current network by using the error, thereby achieving the purpose of improving the accurate synchronization effect under different scenes.
Thus, the basic design description of the present invention is completed.

Claims (3)

1. A method for precise time synchronization based on a programmable data plane is characterized by comprising the steps of processing data packets on the programmable data plane; accelerating the network card transceiving data packet by adopting a DPDK + Lua script language framework; predicting the synchronization delay and the link delay by adopting a machine learning method, and optimizing the whole synchronization system;
when a slave network switch generates a request data packet, a request response time axis starts, and when a master switch receives a corresponding response data packet, the request response time axis ends, two master-slave P4 switches are designed, the slave switch sends a synchronous request data packet to the master switch, the master switch writes the timestamp information of a data plane into the synchronous request data packet after receiving the data packet, and then generates a response data packet and sends the response data packet to the slave switch; after receiving the response data packet from the switch, extracting timestamp information carried in the data packet, wherein the timestamp information comprises various delay components involved in a request-response data packet model; in the data plane, the programmable data plane provides four timestamp components of TRx, TIg, TEx and TTx, wherein TRx represents the time when the data packet enters the parser; TIg denotes the time at which the packet enters the ingress pipeline; TEg denotes the time at which the packet enters the egress port pipeline; TTx represents the time that the packet came out of the inverse parser;
the processing of data packets in the programmable data plane pair comprises the following steps:
step 201, two switches are deployed, wherein SW1 is a slave switch and is used for calibrating a clock, and SW2 is a master switch and is used for determining reference time;
step 202, the master switch SW2 obtains a timestamp value TExt from an external clock source, and the timestamp value TExt is used as a reference clock TRefsw of the slave switch SW1 of the current data plane, and simultaneously stores a timestamp trespid entering an ingress port pipeline obtained inside the data plane SW2 into a register, and records that the current timestamp is Toffset (Toffset is trespid);
step 203, the x bit counter is kept not to be cleared within the time period of 2^ x-1 seconds, a register is required to be added in order to ensure that longer time is obtained to avoid the clearing of the counter, when the counter is about to be cleared, the register can record the time before the clearing, and the time information is recorded as Tera;
step 204, when the master switch SW2 receives a synchronization request packet, it reads the clock source timestamp value TRefsw obtained from the outside, the timestamp Tera of the register corresponding to the time slot where it is located, and the time offset variable Toffset of the pipeline at the ingress port;
step 205, when the master switch SW2 is exiting the port pipeline, the current egress port timestamp TRespEg is read;
step 206, calculating the current timestamp TNowsw after adding the reference time TRefsw by using the following formula, where the current timestamp TNowsw is calculated from the timestamp T _ offset of the input port pipeline, and the current timestamp value is:
Figure FDA0003440071780000022
step 207, since the variable TNowsw avoids the delay generated by the egress port queue, the time value calculation is inaccurate by using the egress port pipeline TRespEg, so that the step 206 is repeated to calculate the value of the TNowsw variable by using TRespEg whenever the switch receives a request packet from another switch;
step 208, the slave switch SW1 sends a request packet at the time of treeqtx; when the request packet is received by the master switch SW2 at the time of TReqRx, the master switch SW2 calculates the current reference TRefsw2 time value according to the formula 206;
step 209, in the data plane, the master switch SW2 matches the flow table by executing the action matching table, embeds the TRefsw2, the treqrrx, and the TRespEg time variable into the request packet, and the request packet is sent out by the master switch as a response packet at this time and is retransmitted back to the slave switch SW 1;
step 210, the slave switch SW1 receives the response packet at the TRespRx moment, and repeats step 206 to calculate the current time TNowsw2 of the master switch SW 2;
step 211, the slave switch SW1 starts processing the response packet at the trespid moment, and at this time, trespid is written into a register through a data plane register, which is marked as Toffset;
step 212, calculating the reference clock of the current slave switch, wherein the slave switch SW1 further needs to receive the accurate sending time of the data packet at the master switch, so that the master switch SW2 subsequently sends a Follow _ up packet, which includes the timestamp of the required accurate sending response data packet by the master switch and is recorded as TRespTx;
step 213, after obtaining the TRespTx variable value from switch SW2, calculates the total delay as RespD using the formula:
Figure FDA0003440071780000021
in step 214, the current time TNowsw2 of the master switch SW2, and the total delay RespD, can accurately calculate the synchronization time of the slave switch SW1 by the following formula:
Figure FDA0003440071780000023
in step 215, step 201 to step 214 are repeatedly executed.
2. The method of claim 1, wherein: accelerating the network card transceiving data packet by adopting a DPDK + Lua script language framework, accelerating the network card transceiving data packet on hardware by adopting the DPDK, and simultaneously realizing the initialization and the sending of a synchronous request packet on software by adopting a Lua script language;
the method for accelerating the network card transceiving data packet by adopting the DPDK + Lua script language framework comprises the following steps:
step 301, installing a DPDK on a host, configuring a large-page memory Hugepages, and loading a kernel module;
step 302, defining a synchronous request packet by adopting a Lua script language, and defining a data packet sending rule;
step 303, in an initialization stage, when no cross traffic exists in a link, the host sends a DPTP probe packet to the programmable switch first, and the switch replies each timestamp TNowsw, TRespRx, trestx, tresqrrx, TRespTx to the host; TNowsw is the current slave switch time, TResprx is the time when the response packet reaches the network card, TReqTx is the time when the host sends the detection packet, TReqRx is the time when the switch receives the detection packet, and TRespTx is the time when the output port sends the response packet;
in step 304, in the initialization phase, when the link rate R is 0%, the link delay nicowiredelay at this time is calculated according to the following formula:
NicWireDelay=(TRespRx-TReqTx)-(TRespTx-TReqRx)
step 305, in the synchronization stage, calculating the reference time RespD of the host according to the following formula, where TRespTx is the time for the switch to issue a response packet, and TRespEg is the time for the response packet to come out from the output port pipeline of the switch:
RespD=OWD+(TRespTx-TRespEg)
step 306, determining the uncomputed delay OWD, if in the synchronization stage, the link rate R is equal to about 0%, at this time, OWD is nicwired delay/2, and once R is not 0%, the nicwired delay at this time is linearly increased, and in order to ensure the accuracy of synchronization and the synchronization of the clock on the host with the switch, it is necessary to use the nicwired delay calculated in the idle link in the initialization stage of step 303, which is referred to as avgnicwired delay, to calculate OWD; OWD was calculated according to the following formula:
Figure FDA0003440071780000031
step 307, calculating the reference time RespD of the host by using the formulas of the step 305 and the step 306, and achieving the synchronization between the host and the programmable switch;
step 308, repeat steps 301 to 307.
3. The method of claim 1, wherein: predicting and compensating synchronous delay and link delay by adopting a machine learning method, optimizing a whole synchronous system, counting total delay and one-way link delay between switches under different network states under the conditions of load and no load, predicting and compensating the total delay and the one-way link delay between the switches by adopting a recurrent neural network (LSTM), counting the delay at the moment when synchronization starts, and using the delay as an input layer, thereby predicting the current output delay, and using the value at the moment as the input layer for iteration;
the method for predicting and compensating the synchronization delay and the link delay by adopting a machine learning method and optimizing the whole synchronous network system specifically comprises the following steps:
step 401, according to step 213, calculating the total delay RespD between the master and slave switches;
step 402, according to step 306, calculating the uncalculated delay OWD between the host and the switch;
step 403, counting the total delay and the one-way link delay between the switches in different network states;
step 404, after the whole network is synchronized, due to the fact that the network has cross flow, various congestion and packet loss phenomena, RespD and OWD can generate changes with different amplitudes, the RespD and OWD are used as input x and are placed into a recurrent neural network (LSTM), and new RespD and OWD are predicted to serve as output h;
step 405, predicting a new RespD, and repeating step 214 to calculate the synchronization time of the slave switch SW 1;
step 406, repeating step 305 to calculate the reference time of the host by using the predicted new OWD;
and step 407, repeating the steps 401 to 405, and continuously updating the synchronization time of the slave switch and the master.
CN202111631275.1A 2021-12-28 2021-12-28 Precise time synchronization method based on programmable data plane Pending CN114337893A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202111631275.1A CN114337893A (en) 2021-12-28 2021-12-28 Precise time synchronization method based on programmable data plane

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202111631275.1A CN114337893A (en) 2021-12-28 2021-12-28 Precise time synchronization method based on programmable data plane

Publications (1)

Publication Number Publication Date
CN114337893A true CN114337893A (en) 2022-04-12

Family

ID=81015725

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202111631275.1A Pending CN114337893A (en) 2021-12-28 2021-12-28 Precise time synchronization method based on programmable data plane

Country Status (1)

Country Link
CN (1) CN114337893A (en)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115174711A (en) * 2022-07-07 2022-10-11 中国人民解放军战略支援部队信息工程大学 Data processing method, device and medium based on full-stack programmable network
CN116303791A (en) * 2023-03-22 2023-06-23 合肥申威睿思信息科技有限公司 Data synchronization method and device based on acceleration system

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170078176A1 (en) * 2015-09-11 2017-03-16 Telefonaktiebolaget L M Ericsson (Publ) Method and system for delay measurement of a traffic flow in a software-defined networking (sdn) system
US20210211214A1 (en) * 2021-03-18 2021-07-08 Intel Corporation Method and apparatus for data plane control of network time sync protocol in multi-host systems

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170078176A1 (en) * 2015-09-11 2017-03-16 Telefonaktiebolaget L M Ericsson (Publ) Method and system for delay measurement of a traffic flow in a software-defined networking (sdn) system
US20210211214A1 (en) * 2021-03-18 2021-07-08 Intel Corporation Method and apparatus for data plane control of network time sync protocol in multi-host systems

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
王驰朝,颜金尧: "基于可编程数据平面的南向协议研究" *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115174711A (en) * 2022-07-07 2022-10-11 中国人民解放军战略支援部队信息工程大学 Data processing method, device and medium based on full-stack programmable network
CN116303791A (en) * 2023-03-22 2023-06-23 合肥申威睿思信息科技有限公司 Data synchronization method and device based on acceleration system

Similar Documents

Publication Publication Date Title
US11012365B2 (en) Changing a time sensitive networking schedule implemented by a softswitch
US8233399B2 (en) Generic packet generator and method
CN108170590B (en) Test system and method of block chain system
CN114337893A (en) Precise time synchronization method based on programmable data plane
CN112422498A (en) In-band network remote measuring method, system and computer readable storage medium
CN101626383B (en) Route test method of aeronautical telecommunication network and router virtual machine
CN103178996B (en) Distributed packet-switching chip model verification system and method
Wu et al. Performance evaluation of industrial Ethernet protocols for networked control application
US5081601A (en) System for combining independently clocked simulators
JPH08163132A (en) Modeling method of data traffic of network,and simulation method thereof
CN104852828B (en) A kind of network delay detection method, apparatus and system
WO2009032281A2 (en) Methods and apparatus for generating simulated network traffic
CN110838954A (en) Lightweight large-scale autonomous network protocol function test method
CN109951494A (en) Emulate data processing method, device, emulator and storage medium
CN113114580A (en) User mode transport protocol development framework and method for 5G network congestion control
Geng et al. Model-based cosimulation for industrial wireless networks
CN104734900B (en) A kind of sending control method of communication protocol test
Lauer et al. Analyzing end-to-end functional delays on an IMA platform
JP6654733B2 (en) Data processing device, network system, packet order control circuit, and data processing method
CN114629830B (en) Method and system for automatically controlling test center instrument test
CN112019491B (en) Message processing method and system
Navaridas et al. On synthesizing workloads emulating MPI applications
JP2001251302A (en) Method and system for simulating network
US7702764B1 (en) System and method for testing network protocols
Herms et al. Unified development and deployment of network protocols

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination