WO2011072442A1

WO2011072442A1 - Method and system for communication between master clock and slave clock

Info

Publication number: WO2011072442A1
Application number: PCT/CN2009/075639
Authority: WO
Inventors: 曹海萍; 陈伟
Original assignee: 中兴通讯股份有限公司
Priority date: 2009-12-16
Filing date: 2009-12-16
Publication date: 2011-06-23

Abstract

A method and system for communication between a master clock and a slave clock are disclosed in the present invention. The method includes the following steps: A server authenticates the slave clock and determines the master clock for the slave clock after judging that the slave clock is legal; The slave clock performs time synchronization with the master clock. The invention introduces the server to authenticate the slave clock and to determine the master clock for the slave clock after judging that the slave clock is legal and then enables the slave clock to perform time synchronization with the master clock, so as to save the network resources, prevent the slave clock from frequently changing the master clock, and solve the problem that the master clock provides a clock message to an unexpected slave clock simultaneously. In the process of synchronizing the slave clock with the master clock, the master clock accomplishes the unicast request of the announce message, the sync message and the delay measurement response message in by a unicast negotiation, thus the effectiveness of the unicast negotiation can be further improved.

Description

Method and system for master-slave clock communication

Technical field

The present invention relates to the field of network time synchronization technologies, and in particular, to a method and system for master-slave clock communication. Background technique

At present, the IEEE1588 PTP (Precision Time Protocol) protocol gives the master-slave clock to establish a link and synchronize the mechanism. From the clock side, it can be divided into two phases. The first is to select the master clock to establish the link phase, and then the selected During the synchronization phase of the master clock, all messages in the protocol can be collectively referred to as PTP messages. The following description will be made with reference to Fig. 1.

After the main clock is powered on, the announcement (Announce) message, the synchronization message (Sync), the follow-up message (FollowUp), and the sending time of the synchronization message in the follow-up message are periodically sent in a multicast manner.

Select the master clock to establish the link phase: After the slave clock in the same network is powered on, the notification message is always monitored. After receiving the notification message, determine the clock quality indicator carried in the message. If the clock quality is better than the clock quality, select the clock. For your own master clock.

Synchronization with the selected master clock: After the master clock is selected from the clock, the synchronization message sent by the selected master clock in multicast mode is received, the message is followed, and the selected master clock is received immediately after receiving the synchronization message. Sending a delay measurement message (Delay-Req), recording the transmission time, the main clock must reply to the delay response message (Delay-Resp) after receiving the delay measurement message, and the message carries the time of receiving the delay measurement message, so that A synchronization message interaction is completed. The slave clock can know four timestamps at this time, tl: Sync message transmission time, t2: Sync message reception time, t3: Delay-Req message transmission time, t4: Delay-Req message reception time. . These time stamps are used to determine the time offset between this slave clock and the master clock, and local clock correction is performed to synchronize with the master clock.

Existing methods have the following problems:

First, after the main clock is powered on, the Announce message is periodically sent in multicast mode. After the slave clock in the same network is powered on, the notification message is always monitored. When received, if the master clock is received. The clock quality is better than its own clock quality, and the clock is chosen as its own master clock. This method leads to wasted bandwidth. Especially when there is no online slave clock in the network and there are multiple master clocks in the network, the slave clock is likely to frequently change its master clock and find a master clock that the user cannot recognize. Synchronization that causes master-slave cannot be effectively managed.

Second, the communication mechanism given by the current protocol is that as long as the notification message and the synchronization message of the master clock can be received, the delay measurement message can be sent to the master clock, and the master clock receives the delay request from the slave clock (Delay-Req). For the message, the delay response (Delay-Resp) must be replied. When the slave clock is not within the master clock authorization range, the delay response message sent by the master clock is sent at a relatively high frequency, so the wasted bandwidth and network resources cannot be ignored. In addition, the security of the primary clock is a potential serious problem. For example, multiple slave clocks in the network maliciously send many delay measurement request messages, and the master clock must respond to all these messages, causing the master clock to bear. Summary of the invention

The technical problem to be solved by the present invention is to provide a method and system for master-slave clock communication, which realizes discriminating the validity of the slave clock, saves bandwidth resources, and improves manageability and security of the master clock and the slave clock.

In order to solve the above problem, the present invention provides a method for master-slave clock communication, which includes: a server authenticating a slave clock, determining that the slave clock is legal, and determining a master clock for the slave clock, the master The clock is time synchronized with the slave clock.

Further, the above method has the following features:

The slave clock sends a request message for querying the master clock to the server, and after the server receives the request message, the slave server authenticates the slave clock, determines that the slave clock is legal, and determines the master clock for the slave clock, The request message is forwarded to the master clock, and the master clock sends an inquiry master clock request response message to the slave clock, and the slave clock performs unicast negotiation with the master clock. After the negotiation succeeds, the master clock and the master clock The slave clock is time synchronized.

Further, the above method has the following features:

The request message for querying the master clock sent from the clock to the server includes a query for whether the master clock supports multiple types of message unicast negotiation; the master clock supports multiple types of message lists. During the broadcast negotiation, the Query Master Clock Request Response message sent to the slave clock carries an indication that supports multiple types of message unicast negotiation, and the master clock sends the notification message in a unicast manner after the negotiation succeeds. Synchronize messages and follow up messages.

Further, the above method has the following features:

The process of performing unicast negotiation between the slave clock and the master clock is: sending, by the slave clock, a unified unicast negotiation request message to the master clock, requesting the master clock to send the notification message, the synchronization message, and the follow-up in a unicast manner The primary clock sends a unified unicast negotiation grant message to indicate that the negotiation is successful, and notifies the period in which the message is sent in unicast mode. Further, the above method has the following features:

The server selects one of the master clocks including the slave clock as the master clock of the slave clock in the service range.

Further, the above method has the following features:

The server determines whether the slave clock is legal according to the IP address of the slave clock.

Further, the above method has the following features:

After the server authenticates the slave clock, the slave clock is notified that the master clock fails to be queried.

In order to solve the above problems, the present invention further provides a system for master-slave clock communication, including: a master clock, a slave clock, and a server, wherein the server is configured to authenticate a slave clock, and determine that the slave clock is legal. A master clock is determined for the slave clock; the master clock is used for time synchronization with the slave clock.

Further, the above system also has the following features:

The slave clock is configured to send a request message for querying a master clock to the server, where the request message includes a query that the master clock supports multiple types of message unicast negotiation; the master clock is used to The slave clock sends an inquiry master clock request response message, and carries an indication of whether to support multiple types of message unicast negotiation; and after the negotiation with the slave clock succeeds, the notification message and the synchronization message are sent in a unicast manner. And the following information: the server is further configured to: after receiving the request message, authenticating the slave clock, determining that the slave clock is legal, and determining the master clock for the slave clock, forwarding the request message to The master clock. Further, the above system also has the following features:

The server is further configured to: select, as a master clock of the slave clock, one of the master clocks including the slave clock as a master clock of the slave clock; and further, determine, according to the IP address of the slave clock, the Whether the slave clock is legal.

The invention introduces the server as the slave clock authentication, determines that the slave clock is legal, and determines a master clock for the slave clock, and the slave clock synchronizes time with the master clock, thereby saving network resources and preventing the slave clock from frequently changing the master clock. Addresses the problem of the master clock providing a clock message to an undesired slave clock. During the time synchronization between the clock and the master clock, the master clock completes the notification message, the synchronization message, and the unicast request of the delay measurement response message by one unicast negotiation, which can further improve the effectiveness of the unicast negotiation. The server selects one of the master clocks that are the best clock quality from the master clocks of the clock as the master clock of the slave clock to solve the problem that the master clock sends synchronous messages to the slave clocks that are not within the authorized range, thereby wasting bandwidth resources. BRIEF abstract

FIG. 1 is a schematic diagram of a master-slave clock establishing link process in an existing protocol;

2 is a flow chart of a method of master-slave clock communication in an embodiment. Preferred embodiment of the invention

The system of master-slave clock communication includes: master clock, slave clock, and server.

The master clock is used for time synchronization with the slave clock. It is also used to carry multiple types of message unicast in the query sending master clock request response message to the slave clock when supporting multiple types of message unicast negotiation. An indication of negotiation; and after successfully negotiating with the slave clock, sending a notification message, a synchronization message, and a follow-up message in a unicast manner.

The slave clock is configured to send a request message for querying the master clock to the server, where the request message includes a query for whether the master clock supports multiple types of message unicast negotiation, and is further configured to: after receiving the notification message, determine that the master clock is Its own master clock, and the time synchronization with the master clock is completed according to the synchronization message and the follow-up message. a server, after receiving the request message, authenticating the slave clock, determining that the slave clock is legal, determining a master clock for the slave clock, and forwarding the request message to the master clock; And selecting, as the master clock of the slave clock, one of the master clocks including the slave clock in the service range; and determining whether the slave clock is legal according to the IP address of the slave clock.

The method for master-slave clock communication includes: the server authenticates the slave clock, determines that the slave clock is legal, and determines a master clock for the slave clock, and the master clock is time-synchronized with the slave clock.

As shown in FIG. 2, the method for master-slave clock communication specifically includes:

Step 201: After the clock is powered on (Power On), send a request message (Req_Master) for querying the master clock to the server and start timing. The request message may include: query of the master clock information, whether the master clock supports unicast negotiation. The query can be one of the following parameters: Whether the primary clock supports a single type of message unicast negotiation (that is, unicast negotiation for each type of message, after the primary clock receives a unicast negotiation request for a certain type of message, The type of the message is sent by the unicast message. The master clock supports multiple types of message unicast negotiation. After receiving the unicast negotiation message, the master clock sends unicast messages to multiple types of messages. Two or three messages in the synchronization message and the follow-up message are unicast).

This request message may also include a query of whether the master clock is locked with the grandmother's clock (the grandmother's clock is generally a global positioning clock, and the final purpose of synchronizing the clock from the master clock is to achieve synchronization with the global positioning clock. The master clock is not synchronized with the grandmother's clock. When the clock it provides is unstable, it affects the accuracy of the slave clock).

The message body format of the request message (Req_Master) for querying the master clock is as shown in Table 1:

messageType Externd-messageType 1 4 unicastNegotiationEnable 1 5 unicastNegotiationUniform 1 6 The meaning of each field is:

The tlvType field may use the reserved value of the TLV TYPE in the current protocol, and is used to indicate that the current TLV is a message for querying the master clock during access;

The lengthField field indicates the total length of the message body, ie MessageType, Externd-messageType, and Reserved fields, in Bytes.

The messageType field indicates that the current message is a query master clock message.

The Externd-messageType field is only used for extended messages and can generally not be used.

The unicastNegotiationEnable field indicates whether the traditional unicast negotiation is supported, that is, the negotiation mode given by IEEE1588. If a certain type of message is desired to be unicast, the message is unicast once. If there is a type N message that wants to be unicast, the unicast negotiation is performed. N times.

The unicastNegotiationUniform field indicates whether a unicast request for unicast negotiation is completed to complete the unicast request for the Annouce, Sync, and Delay-Resp messages.

In addition, it should be noted that when the message is sent, the general PTP message header specified by the IEEE1588 protocol needs to be added in front of the message body described in Table 1. The format of the message header is specified in the protocol, as shown in Table 2. :

correctionField 8 8

Reserved 4 16 sourcePortldentity 10 20

Sequenceld 2 30 controlField 1 32 logMessagelnterval 1 33 The meanings of the fields in Table 2 are as follows:

The transportSpecific field indicates the transport protocol number used by the IEEE1588 PTP message. For example, if the PTP message transmission uses UDP, this field is the number of the UDP protocol.

The messageType field indicates the specific type of the PTP message. For example, if a notification message is sent, this field specifies that the message types in the VTP version of the PTP protocol are: a synchronization message, a delay measurement request message, a delay measurement response message, a notification message, Follow-up messages, signaling messages, management messages, peer-to-peer delay measurement request messages, peer-to-peer delay measurement messages, peer-to-peer follow-up messages. In addition to signaling messages and management messages, these messages refer to a single message, and signaling messages and management messages are collectively referred to as two types of messages. For example, when the message type in the message header is a signaling message, the sub-message type of the signaling message needs to be specified, and the management message is similar. But when the message type in the message header is a notification message, it is the notification message.

The versionPTP field indicates the PTP protocol version number.

The messageLength field indicates the length of the entire PTP message, starting from the first byte of the PTP header to the end of the last byte of the message body.

The domainNumber field indicates the domain number of the clock that sent the message.

The flagField field indicates whether the message is sent in unicast or multicast mode. The master-slave synchronization mode is one-step or two-step.

The correctionField field indicates the dwell time of the message in the transparent clock, and only the field used for synchronization needs to fill in this field.

The sourcePortldentity field indicates the clock Id that sent the message.

The sequenceld field indicates the sequence number of the message in the same type of message sent by one clock. Take the synchronous message as an example. For each synchronization message, this field is incremented by 1. Another representation of the controlField field message type.

The logMessagelnterval field indicates the logarithm of the message transmission period.

When the primary clock message is queried as described in step 201, the message type field shall indicate a signaling message, i.e., the field is set to (3).

Step 202: The server authenticates the slave clock to determine whether the slave clock is legal. If the server determines that the slave clock is illegal, step 203 is performed, and the server determines that the slave clock is legal, step 204 is performed. Specifically, the server may be based on the IP address of the slave clock. Judging whether it is legal or not can also be judged based on other parameters of the slave clock. It can be determined whether the IP address of the slave clock indicates the slave clock authorization range of all the master clocks managed by the server, and the setting of the authorization range can be set by the user according to requirements, for example, the domain where the master clock is located is set as the slave clock authorization. range.

Step 203: The server notifies the slave clock that the master clock fails to be queried;

The message body format for notifying the slave clock to query the master clock can be as shown in Table 3:

table 3:

The meaning of each field:

The tlvType field can use the reserved value of the TLV TYPE in the current protocol, which is the same as the message usage value of the query master clock message.

The messageType field indicates that the current message is the query master clock failure message, the accesstReq field Indicates whether it is allowed to synchronize with the master clock managed by this server.

The Externd-messageType field is only used for extended messages and can generally not be used. The accesstReq field indicates whether the requesting master clock failed or succeeded.

When the inquiry main clock failure message is sent, the PTP general message header described in Table 2 should be added in front of the message body described in Table 3.

Step 204: The server determines a master clock for the slave clock, and forwards the received request message to the j3⁄4 master clock.

The server selects one of the master clocks of the slave clock to be the master clock of the slave clock in the service range.

Step 205: The master clock establishes a query master clock request response message, and in the request response message, it can indicate whether the unicast negotiation is supported, whether multiple types of message unicast are supported, and whether the message body format of the ancestor request response message can be As shown in Table 4:

Table 4:

The meaning of each field is:

The lengthField field indicates that the message body is also messageType, Externd-messageType, The total length of the unicastNegotiationEnable, unicastNegotiationUniform, and Reserved fields, in Bytes.

The messageType field indicates that the current message is a response to the query master clock message.

The unicastNegotiationEnable field indicates whether unicast negotiation is supported.

Whether unicastNegotiationUniform supports a unicast negotiation to complete unicast requests for all messages.

Step 206: When the slave clock learns that the master clock supports multiple types of message unicast negotiation (that is, the unicastNegotiationUniform is 1), the slave clock initiates a multi-type message unicast negotiation to the master clock, that is, sends a unified unicast negotiation request message. The request master clock sends notification messages, synchronization messages, and follow-up messages in unicast mode.

The message body format of the unified unicast negotiation request message is shown in Table 5:

table 5:

The meaning of each field is:

The lengthField field represents the message body, which is the total length of the messageType, reseved, loglnterAnnounceMessagePeriod, loglnterSyncMessagePeriod, loglnterDelayRespMessagePeriod, and durationField fields. Bit.

The message Type field indicates that the currently requested unicast message is Announce, Sync, and Delay-Res messages. The value of the reserved value of the message field in the current IEEE1588 protocol can be used. That is to say, F is used to announce unicast for Announce, Sync, Delay-Res.

The loglnterAnnounceMessagePeriod field indicates the current negotiation request master clock to

2 ^A logInterAnnounceMessagePeriod (where eight represents an exponential operation) sends a notification message for the period.

The loglnterSyncMessagePeriod field indicates that the current negotiation request master clock sends a synchronization message with a period of 2 ^A logInterSyncMessagePeriod.

The loglnterDelay espMessagePeriod field indicates that the current negotiation request master clock sends a delayed request response message with a period of 2 ^A logInterDelay espMessagePenod.

The durationField field indicates the expected duration of the request for the main clock cycle to send three types of messages, and the field is filled with 0 to indicate an infinite time.

It should be noted that the PTP general message header shown in Table 2 should be added when sending the message, and the message type in the message header is < .

Step 207: After receiving the unified unicast negotiation request message described in step 206, the master clock sends a unified unicast negotiation grant message to indicate that the negotiation is successful, and notifies the period in which the message is sent in a unicast manner, and the message body format of the message is as follows: Table 6 shows:

Table 6:

The meaning of each field of the message is as follows: The tlvType field corresponds to the field in Table 5.

The lengthField field corresponds to the field in Table 5.

The messageType field is the same as the field in Table 5.

The loglnterAnnounceMessagePeriod field indicates that the actual approved unicast notification message period is 2 ^A logInterAmounceMessagePeriod. That is, in the future, the Announce message is actually sent in this cycle;

The loglnterSyncMessagePeriod field indicates that the actual approved unicast synchronization message period is 2 ^A logInterSyncMessagePeriod. That is, the Sync message is actually sent in this cycle in the future;

The loglnterDelay espMessagePenod field indicates that the period of the actually approved unicast delay measurement response message is 2 ^A logInterSyncMessagePenod. That is, the Delay-Resp message is actually sent in this cycle;

The durationField field corresponds to the field in Table 5.

Step 208: When the primary clock supports the unicast mode, the notification message, the synchronization message, and the follow-up message are sent to the slave clock in the unicast mode in the period of step 207;

Step 209: After receiving the notification message from the clock, determine that the master clock is its own master clock, and complete synchronization with the master clock according to the synchronization message and the follow-up message.

Specifically, the synchronization message is received from the clock, and the delay request message is set up and sent to the master clock in the unicast mode; the master clock receives the delay request message, immediately sends the delay response message, and puts the time of receiving the delay request message into the delayed response. In a certain field of the message; the slave clock uses the synchronization message reception time, the synchronization message transmission time and the delay request transmission time carried in the follow-up message, the delay measurement reception time carried in the delay response message, the calculation time deviation, and the local clock Correction, complete synchronization with the master clock.

The invention introduces the server as the slave clock authentication, determines that the slave clock is legal, and determines a master clock for the slave clock, and the slave clock synchronizes time with the master clock, thereby saving network resources and preventing the slave clock from frequently changing the master clock. Addresses the issue of the master clock providing messages to the undesired slave clock. During the time synchronization of the clock from the master clock, the master clock sends the message in unicast mode. One step to save network resources. The server selects the best one of the clocks from the master clocks of the clock as the master clock of the slave clock, which can solve the problem that the slave clock cannot be selected to the user's desired master clock in the prior art, and the master clock pair is not authorized. The issue of synchronous message transmission from the slave clock in the range wastes bandwidth resources.

Of course, there are many other embodiments of the present invention, and various changes and modifications can be made by those skilled in the art without departing from the spirit and scope of the invention. All should fall within the scope of protection of the appended claims.

Industrial applicability

The invention can realize the discrimination of the slave clock legality, save bandwidth resources, and improve the manageability and security of the master clock and the slave clock.

Claims

Claim

A method for master-slave clock communication, wherein:

The server authenticates the slave clock, determines that the slave clock is legal, and determines a master clock for the slave clock, and the master clock synchronizes with the slave clock.

2. The method of claim 1 wherein

3. The method of claim 2, wherein

The request message for querying the master clock sent from the clock to the server includes a query for whether the master clock supports multiple types of message unicast negotiation; when the master clock supports multiple types of message unicast negotiation, The querying the master clock request response message sent by the slave clock carries an indication that supports multiple types of message unicast negotiation, and the master clock sends the notification message, the synchronization message, and the follow-up message in a unicast manner after the negotiation succeeds. .

4. The method of claim 3, wherein

The process of performing unicast negotiation between the slave clock and the master clock is: sending, by the slave clock, a unified unicast negotiation request message to the master clock, requesting the master clock to send the notification message, the synchronization message, and the follow-up in a unicast manner The primary clock sends a unified unicast negotiation grant message to indicate that the negotiation is successful, and notifies the period in which the message is sent in unicast mode.

5. The method of claim 1, 2, 3 or 4, wherein

6. The method of claim 1, 2, 3 or 4, wherein

7. The method of claim 1, 2, 3 or 4, wherein After the server authenticates the slave clock, the slave clock is notified that the master clock fails to be queried.

A master-slave clock communication system, comprising: a master clock, a slave clock, and a server, wherein the server is configured to authenticate a slave clock, determine that the slave clock is legal, and determine the slave clock Master clock

The master clock is used for time synchronization with the slave clock.

9. The system of claim 8 wherein

The slave clock is configured to send, to the server, a request message for querying a master clock, where the request message includes a query for whether the master clock supports multiple types of message unicast negotiation;

The master clock is configured to send an inquiry master clock request response message to the slave clock, and carry an indication of whether to support multiple types of message unicast negotiation in the message; and after successfully negotiating with the slave clock, Send notification messages, synchronization messages, and follow-up messages in unicast mode;

The server is further configured to: after receiving the request message, authenticating a slave clock, determining that the slave clock is legal, and determining a master clock for the slave clock, forwarding the request message to the master clock .

10. The system of claim 8 or 9, wherein