Skip to content

W
White Rabbit Standardization
Commit 5d85fdcd authored by Maciej Lipinski's avatar Maciej Lipinski
Browse files
Options

wrspec: with Javier's and Tom's corrections, v1.1

parent 916c4fd8
Hide whitespace changes
Inline Side-by-side
Showing with 278351 additions and 27345 deletions
src/deleted
View file @ 5d85fdcd
......@@ -119,4 +119,15 @@ standard is used (see Appendix~\ref{ptpFSM}, Figure~\ref{fig:ptpFSMslaveOnly}).
=============================
=============================
\ No newline at end of file
This pattern is defined by the IEEE 802.3 standard \cite{} as \textit{Low-frequency text pattern}
(Appendix~36A.2). It can be generated by the repeated transmission of K28.7 code-group.
=============================
Implementation of the method to obtain fixed delays for non-deterministic Gigabit
Ethernet PHY
is described in Appendix~\ref{sec:calibForGigbitE}. This fixed delay measurement is optional and in
principle needed only once, while the WR link is being set up.
==============================
\ No newline at end of file
src/fig/ptpMSGs.ps
View file @ 5d85fdcd
This source diff could not be displayed because it is too large. You can view the blob instead.
src/fig/wrFSM.ps
View file @ 5d85fdcd
This source diff could not be displayed because it is too large. You can view the blob instead.
src/fig/wrptpMSGs.ps
View file @ 5d85fdcd
This source diff could not be displayed because it is too large. You can view the blob instead.
src/wrspec.tex
View file @ 5d85fdcd
......@@ -27,6 +27,10 @@
\usepackage{times,mathptmx}
\usepackage{chngcntr}
%\usepackage{amsfonts}
%\usepackage{amssymb}
%\usepackage{graphicx}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% creating subsubsubsection notation
% src: http://www.latex-community.org/forum/viewtopic.php?f=5&t=791
......@@ -72,6 +76,17 @@
\label{fig:wr_logo}
\end{figure}
\vspace{2cm}
\begin{center}
\large \textbf{Acknowledgements:}
\end{center}
%\vspace{1.3cm}
\begin{center}
Many thanks to John Eidson and the White Rabbit Community\\ for the feedback and comments.
\end{center}
\newpage
\setcounter{page}{1}
......@@ -100,17 +115,21 @@
& & & 3.~Fixed some typos. \\
\hline
1.0 & 26/04/2011 & M.L. & 1.~Including feedback from comments. \\
& & & 2.~Creating WR PTP Profile. \\
& & & 3.~Adding modification to BMC. \\
& & & 4.~Enabling WR Switch to be "real" Boundary Clock. \\
& & & 5.~Adding figure clarifying WRPTP vs. PTP FSMs operation from
& & & 2.~Created WR PTP Profile. \\
& & & 3.~Added modification to BMC. \\
& & & 4.~Enabled WR Switch to be "real" Boundary Clock. \\
& & & 5.~Added figure clarifying WRPTP vs. PTP FSMs operation from
Power On. \\
& & & 6.~Mentioning (missed) modification to PTP FSM. \\
& & & 6.~Mentioned (missing) modification to PTP FSM. \\
\hline
1.1 & 2/05/2011 & J.S.\& T.W. & Clarity and typos. \\
\hline
\end{tabular}
\label{tab:revHist}
\end{table}
\newpage
\tableofcontents
......@@ -131,11 +150,12 @@ node uses a traceable clock to encode data over the physical layer, while the sl
recovers this clock (syntonization) and bases its timekeeping on it. Absolute time
synchronisation between master and slave is achieved by adjusting
the clock phase and offset of the slave to that of the master.
The \textit{offset} refers to the clock (e.g. time defined in Coordinated Universal Time standard),
The \textit{offset} refers to the clock (e.g. time defined in Coordinated Universal Time or
International Atomic Time standards),
while the \textit{phase} refers to the clock signal (e.g. 125 MHz clock signal).
The phase and offset adjustment is done through the two-way exchange of PTP sync messages, which
are corrected
to achieve sub-ns accuracy due to the precise knowledge of the link delay.
to achieve sub-ns accuracy thanks to the precise knowledge of the link delay.
\begin{figure}[ht!]
\centering
......@@ -159,7 +179,7 @@ over the physical layer, resulting in a \textit{cascade} of master
and slave nodes. As a result of this topology, a WR~network consists of two kinds of WR network
devices:
\textit{WR boundary clocks} (WR Switches) and \textit{WR ordinary clocks}
(WR Nodes), see section~\ref{sec:wrptpOverview}.
(WR Nodes), see section~\ref{sec:definitions}.
\begin{figure}[ht!]
\centering
......@@ -169,7 +189,7 @@ devices:
\label{fig:wrNetwork}
\end{figure}
Applications need WR and IEEE1588-2008 nodes to coexist. Examples
Some applications need WR and IEEE1588-2008 nodes to coexist. Examples
of this are networks where the need for highly accurate time synchronisation is concentrated on a
certain group of nodes. For this purpose the WR protocol enables WR nodes to defer to IEEE1588
behaviour when not connected to another WR node.
......@@ -227,8 +247,11 @@ the offset and the delay between the nodes exchanging the messages. \textit{Foll
and \textit{Delay\_Resp Messages} are used to send timestamps between Master
and Slave (in the case of a two-step clock).
\textit{Signaling Messages} are used only for configuration and
administrative purposes. They are not essential for PTP synchronization.
\textit{Management Messages} are used only for configuration and
administrative purposes. \textit{Signaling Messages} are used for communication between clocks
for optional or experimental features of the PTP standard as well as implementation-specific
mechanisms. Both, Management and Signaling messages, are not essential for PTP synchronization.
The flow of events in the PTP delay request-response (two-step clock) mechanism is the following
(simplified overview):
......@@ -239,8 +262,8 @@ The flow of events in the PTP delay request-response (two-step clock) mechanism
\item The master periodically sends a Sync message (timestamped on transmission, $t_1$) followed by
a Follow\_UP message which carries $t_1$.
\item The slave receives the Sync message sent by the master (timestamped on reception, $t_2$).
\item The slave receives the Follow\_Up message (which carries timestamp of Sync transmission time)
sent by the master .
\item The slave receives the Follow\_Up message (which carries timestamp of Sync transmission time,
$t_1$) sent by the master .
\item The slave sends a Delay\_Req message (timestamped on transmission, $t_3$).
\item The master receives the Delay\_Req message sent by the slave (timestamped on reception,
$t_4$).
......@@ -284,7 +307,7 @@ relate the two variable delays $\delta_{ms}$ and $\delta_{sm}$.
% on in this document we refer to this missing equation as the \textit{physical
% medium correlation}.
Describing a procedure to obtain this equation is out of the scope of this document. However,
section~\ref{sec:physcorr} provides such equation obtained empirically for one scenario.
section~\ref{sec:physcorr} provides such an equation obtained empirically for one scenario.
\begin{figure}[ht!]
\centering
......@@ -306,7 +329,7 @@ this document by the \textit{relative delay coefficient} ($\alpha$).
Its origin is highly implementation-dependent. Thus this document just assumes that it exists
and is known.
\subsubsection{Ethernet over a Single-mode Optical Fibre}
\subsubsection{1000base-X over a Single-mode Optical Fibre}
\label{sec:singlefiber}
When a single-mode fibre is used as bi-directional communication medium,
it can be shown that both variable delays are related by an equation of
......@@ -351,9 +374,6 @@ notation by using equations \eqref{eq:delayms},
\eqdelay{sm} = \mu - \eqasymm
\end{align}
The delay asymmetry cannot be calculated unless we use the physical medium
correlation.
\subsection{Solution for Ethernet over a Single-mode Optical Fiber}
Combining equations \eqref{eq:singlefiber} and \eqref{eq:mu} we obtain:
......@@ -374,7 +394,7 @@ The delay asymmetry can then be derived from equations \eqref{eq:delayms}, \eqre
\\
\newpage
\section{Fixed delays}
......@@ -388,12 +408,14 @@ establishing the WR link, which is called \textit{WR Link Setup} in this documen
A WR~node participates in the measurement of another
WR node's reception fixed delay ($\Delta_{\{rx_m, rx_s\}}$) upon request, e.g. by sending
a calibration pattern in Gigabit Ethernet. Measurement of fixed delays during WR Link Setup
is optional. It is only required if non-deterministic reception/transmission elements are used.
is optional and in principle needed only once, while the WR link is being set up.
It is only required if non-deterministic reception/transmission elements are used
The calibration pattern sent by WR nodes to measure fixed delays for non-deterministic Gigabit
Ethernet PHY shall be generated by repeated transmission of RD+ K28.7 code-group as described
in Appendix~\ref{sec:calibForGigbitE}.
An example implementation of the method to obtain fixed delays for non-deterministic Gigabit
Ethernet PHY
is described in Appendix~\ref{sec:calibForGigbitE}. This fixed delay measurement is optional and in
principle needed only once, while the WR link is being set up.
\newpage
......@@ -404,15 +426,15 @@ White Rabbit extends the IEEE1588-2008 (PTP) standard to achieve sub-ns accuracy
benefiting from PTP's synchronization, management and messaging mechanisms. From now on in this
document, the White Rabbit extension to the PTP standard will be referred to as \textit{WRPTP}.
WRPTP takes advantage of PTP's customization facilities, i.e. \textit{PTP profile} and
\textit{Type-Length-Value} (TLV), and makes a few extensions to PTP standard which are out of the
scope of mentioned facilities. It also defines \textit{implementation specific} functionalities
(e.g. WR-specific fields of Data Sets, hardware support) which are in line with the
PTP standard.
For the simplicity and clarity sake, this section explains all the mechanism of WRPTP without
classifying them into PTP-profile, PTP-extension, implementation-specific. The distinction is
made in the last two subchapters where \textit{White Rabbit PTP profile} is defined and
extensions to PTP listed.
WRPTP takes advantage of PTP's customization facilities, i.e. \textit{PTP profiles} and
\textit{Type-Length-Value} (TLV), and makes an extension to the
PTP standard which is out of the scope of these facilities. It also defines
\textit{implementation specific} functionalities (e.g. WR-specific fields of Data Sets,
hardware support) which are compatible with the PTP standard.
For the sake of simplicity and clarity, this section explains all the mechanisms of WRPTP without
classifying them into PTP-profile, PTP-extension and implementation-specific. The distinction is
made in the last subsections, where the \textit{White Rabbit PTP profile} is defined and the
extensions to PTP are listed.
\subsection{Overview}
\label{sec:wrptpOverview}
......@@ -421,15 +443,14 @@ extensions to PTP listed.
WRPTP introduces \textit{the White Rabbit Link Setup} (WR Link Setup), which is a process for
establishing the WR link (Figure~\ref{fig:wrptpMSGs}). It includes syntonization of the local clock
over the physical layer, measurement of fixed delays (calibration) and distribution of the
information about fixed delays over the link. The WRPTP takes advantage of the Link Delay
information about fixed delays over the link. WRPTP uses the Link Delay
Model to obtain an accurate delay estimation, e.g. it uses the delay asymmetry equation
\eqref{eq:aqasymm} for Gigabit Ethernet over Fiber Optic. The additional communication between
\eqref{eq:aqasymm} for Gigabit Ethernet over optical fiber. The additional communication between
a master and a slave needed to exchange parameters and state information is done through extended
PTP messaging facilities.
WRPTP is compliant with standard PTP. Figure~\ref{fig:hybrid-network} depicts the tree topology
of a \emph{hybrid} WR/IEEE1588 network with grandmaster as a root. The optimal synchronization
is achieved by connecting WR-nodes directly to the grandmaster and non-WR nodes to WR nodes.
of a \emph{hybrid} WR/IEEE1588 network with a grandmaster as a root.
\begin{figure}[ht!]
......@@ -447,22 +468,27 @@ is achieved by connecting WR-nodes directly to the grandmaster and non-WR nodes
\begin{figure}[ht!]
\centering
% \vspace{-1.3cm}
\includegraphics[width=0.80\textwidth]{fig/wrptpMSGs.ps}
\includegraphics[width=0.6\textwidth]{fig/wrptpMSGs.ps}
\caption{Simplified overview of the message flow in WRPTP.}
\label{fig:wrptpMSGs}
\end{figure}
The flow of events for standard PTP which is presented in section~\ref{sec:ptp} is extended
as depicted in Figure~\ref{fig:wrptpMSGs} and described below (simplified overview):
as depicted in Figure~\ref{fig:wrptpMSGs} and described below:
\newpage
\begin{enumerate}
\item The WR Master periodically sends WR Announce messages with a custom suffix.
\item The WR Slave receives several Announce message(s), recognizes the WR Announce message and uses
the modified BMC algorithm to establish its place in the WR network hierarchy.
\item The WR Slave starts the WR Link Setup by sending the SLAVE\_PRESENT WR Signaling message.
\item The WR Master sends the LOCK WR Signaling message to request the WR Slave to start
syntonization.
\item The \textbf{WR Node A} which is in PTP\_MASTER state periodically sends WR Announce messages with
a custom suffix.
\item The \textbf{WR Node B} receives Announce message(s), recognizes the WR Announce message and
uses the modified BMC algorithm (section~\ref{sec:wrBMC}) to establish its place in the WR
network hierarchy.
\item The \textbf{WR Node B} enters WR Slave mode (based on the conditions in
\ref{sec:wrSlaveFSMstart}) and starts the WR Link Setup by sending the SLAVE\_PRESENT
WR Signaling message.
\item The \textbf{WR Node A} enters WR Master mode (based on the conditions in
\ref{sec:wrMasterFSMstart}) and sends the LOCK WR Signaling message to request the WR Slave
to start syntonization.
\item The WR Slave sends the LOCKED WR Signaling message as soon as the syntonization process is
finished (notification from the hardware).
\item The WR Master sends the CALIBRATE WR Signaling message to request calibration of its
......@@ -490,6 +516,7 @@ It results in the Slave's synchronization with the Master clock with sub-ns accu
\end{enumerate}
\subsection{Definitions}
\label{sec:definitions}
The following definitions used in this document are introduced in Clause 3.1 of PTP:\\
......@@ -503,34 +530,36 @@ and maintains the timescale used in the domain. It may serve as a source of time
clock, or may synchronize to another clock, i.e., be a slave clock.\\
\\
This document introduces the following definitions:\\
\textbf{White Rabbit Port (WR Port)}: a WRPTP-enabled port of a boundary clock
or an ordinary clock.\\
\textbf{White Rabbit Master (WR Master)}: a WRPTP-enabled port of a boundary clock or an
ordinary clock which acts as a source of timing information for another White Rabbit enabled port of
a boundary clock or an ordinary.\\
a boundary or an ordinary clock.\\
\textbf{White Rabbit Slave (WR Slave)}: a WRPTP-enabled port of a boundary clock or an
ordinary clock in which retrieves timing information send over a link by WR Master\\
ordinary clock which retrieves timing information sent over a link by a WR Master.\\
\textbf{White Rabbit Switch (WR Switch)}: a boundary clock implementing WRPTP, compatible with
standard PTP. \\
\textbf{White Rabbit Node (WR Node)}: an ordinary clock implementing WRPTP.
\textbf{White Rabbit Node (WR Node)}: an ordinary clock implementing WRPTP, compatible with
standard PTP. \\
\subsection{WRPTP Data Sets Fields}
\subsection{WRPTP Data Set Fields}
\label{sec:wrDS}
The PTP standard defines data sets (DS) to store the static and dynamic variables needed for the
operation of the protocol (section 8, PTP). WRPTP:
\begin{itemize}
\item adds fields to DSs defined in PTP standard to store the WR-specific parameters,
\item adds fields to the DSs defined in the PTP standard to store the WR-specific parameters,
\item defines a new DS: backupParentDS.
\end{itemize}
\subsubsection{New fields of PTP Data Sets}
Table~\ref{tab:wrDS} defines the additional DS fields required by WRPTP that are not part of
the PTP standard, a description follows.
the PTP standard, described below.
\begin{table}[ph!]
......@@ -555,9 +584,9 @@ calibrated & portDS & TRUE, FALSE &D \\ \hline
deltaTx & portDS & 64 bit value &D \\ \hline
deltaRx & portDS & 64 bit value &D \\ \hline
calPeriod & portDS & 32 bit value &S \\ \hline
calPattern & portDS & 32 bit value &S \\ \hline
calPatternLen & portDS & 16 bit value &S \\ \hline
wrAlpha & portDS & 32 bit value &S \\ \hline \hline
%calPattern & portDS & 32 bit value &S \\ \hline
%calPatternLen & portDS & 16 bit value &S \\ \hline
%wrAlpha & portDS & 32 bit value &S \\ \hline \hline
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
parentWrConfig & portDS & NON\_WR,
WR\_S\_ONLY,
......@@ -570,8 +599,8 @@ parentWrModeON & portDS & TRUE, FALSE &D \\ \hline
parentDeltaTx & portDS & 64 bit value &D \\ \hline
parentDeltaRx & portDS & 64 bit value &D\\ \hline
parentCalPeriod & portDS & 32 bit value &S \\ \hline
parentCalPattern & portDS & 32 bit value &S \\ \hline
parentCalPatternLen & portDS & 16 bit value &S \\ \hline \hline
%parentCalPattern & portDS & 32 bit value &S \\ \hline
%parentCalPatternLen & portDS & 16 bit value &S \\ \hline \hline
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
primarySlavePortNumber & currentDS & 16 bits value &D \\ \hline
......@@ -580,16 +609,18 @@ primarySlavePortNumber & currentDS & 16 bits value &D \\ \hline
\end{table}
\paragraph{wrConfig} Determines predefined function of a WR port.
\paragraph{wrConfig} Determines the predefined function of a WR port.
\paragraph{wrMode} Determines current WR-role of a WR port which is determined by BMC.
\paragraph{wrMode} Contains the current WR-role of a WR port which is determined using the modified
BMC algorithm (section~\ref{sec:wrBMC}) by the conditions described in
the sections~\ref{sec:wrSlaveFSMstart}~and~\ref{sec:wrMasterFSMstart}.
\paragraph{wrModeON} If TRUE, it indicates that WR Link Setup has been performed successfully
and WR Port is synchronized using WRPTP. TRUE value validates the role defined in wrMode as active.
\paragraph{wrModeON} If true, it indicates that the WR Link Setup has been performed successfully
and the WR port is synchronized using WRPTP, and that the role defined in wrMode is active.
\paragraph{wrPortState} Stores current state of WRPTP state machine (see chapter~\ref{wrFSM}).
\paragraph{wrPortState} Stores the current state of the WRPTP state machine (see chapter~\ref{wrFSM}).
\paragraph{calibrated} If true, it indicates that fixed delays of the given port are known.
\paragraph{calibrated} If true, it indicates that the fixed delays of the given port are known.
\paragraph{deltaTx} Port's $\Delta_{tx}$ measured in picoseconds and multiplied by ${2^{16}}$.
......@@ -597,17 +628,17 @@ and WR Port is synchronized using WRPTP. TRUE value validates the role defined i
\paragraph{calPeriod} Calibration period in microseconds.
\paragraph{calPattern} Medium specific calibration pattern.
%\paragraph{calPattern} Medium specific calibration pattern.
\paragraph{calPatternLen} Number of bits of calPattern to be repeated.
%\paragraph{calPatternLen} Number of bits of calPattern to be repeated.
\paragraph{wrAlpha} \textit{Relative delay coefficient} described in
section~\ref{sec:singlefiber}.
%\paragraph{wrAlpha} \textit{Relative delay coefficient} described in
% section~\ref{sec:singlefiber}.
\paragraph{primarySlavePortNumber} If 0, no primary Slave is selected. 1, 2 ,...N --value of the
portNumber (clause 7.5.2.3 PTP) selected as the primary Slave, see chapter~\ref{sec:wrBMC}.
\paragraph{primarySlavePortNumber} If 0, no Primary Slave is selected. 1, 2 ,...N --value of the
portNumber (clause 7.5.2.3 PTP) selected as the Primary Slave, see section~\ref{sec:wrBMC}.
\paragraph{parentWrConfig} Stores the value of wrConfig parameter of the parent port.
\paragraph{parentWrConfig} Stores the value of wrConfig of the parent port.
\paragraph{parentWrMode} Stores the value of wrMode of the parent port.
......@@ -621,9 +652,9 @@ portNumber (clause 7.5.2.3 PTP) selected as the primary Slave, see chapter~\ref{
\paragraph{parentCalPeriod} Stores the value of calPeriod parameter of the parent port.
\paragraph{parentCalPattern} Stores the value of calPattern parameter of the parent port.
%\paragraph{parentCalPattern} Stores the value of calPattern parameter of the parent port.
\paragraph{parentCalPatternLen} Stores the value of calPatternLen parameter of the parent port.
%\paragraph{parentCalPatternLen} Stores the value of calPatternLen parameter of the parent port.
\subsubsection{backupParentDS data set specifications}
......@@ -638,15 +669,18 @@ Each entry of the data set contains:
\begin{itemize}
\item backupParentDS.secondarySlavePortNumber - the number of the port on which the Announce
message from backup Parent has been received,
message from backup parent has been received (Secondary Slave port),
\item backupParentDS.backupParentSourcePortIdentity - the portIdentity of the port on the backup
master.
\end{itemize}
The implementation-specific backupParentDS set shall have a minimum capacity of three backup parent
records. The order of the records is established using Data Set Comparison Algorithm on $E_{rbest}$
which are qualified as backup Masters by modified State Decision Algorithm, record number 0 being the
best (described in the chapter~\ref{StadeDecisionAlg}).
records. The order of the records is established using Data Set Comparison Algorithm as described
in the section~\ref{StadeDecisionAlg}.
%on $E_{rbest}$
%which are qualified as backup Masters by modified State Decision Algorithm, record number 0 being the
%best (described in the chapter~\ref{StadeDecisionAlg}).
......@@ -656,43 +690,49 @@ best (described in the chapter~\ref{StadeDecisionAlg}).
\subsubsection{Overview}
The Best Master Clock (BMC) algorithm is used in PTP to compare clocks (determine which
clock is the \textit{best}) and to recommend the next state of the PTP state machine (Clause 9.3
of PTP). The BMC is used to prune the physical network topology to obtain logical tree(s) with
\textit{best} clock, grandmaster (preferably the one synchronized to a primary reference time
of PTP). The BMC is used to prune the physical network topology to obtain logical tree(s) with the
\textit{best} clock, the grandmaster (preferably the one synchronized to a primary reference time
source), as a root. In the case when more then one clock in a network is synchronized to a primary
reference time source, the BMC produces disjoint logic trees. Each tree has a signel grandmaster.
reference time source, the BMC produces disjoint logic trees. Each tree has a single grandmaster.
As a result of BMC, a no more then one port of a Boundary Clock can be in the PTP\_SLAVE state. Such a
solution allows for redundancy of the time source and topology but is not optimal for continuity
of the synchronization. In example, in the case of a failure of one of the \textit{best} clocks
As a result of BMC, no more than one port of a Boundary Clock can be in the PTP\_SLAVE state. Such a
solution allows for redundancy of the time source and topology but is not optimal for the continuity
of the synchronization. For example, in case of a failure of one of the \textit{best} clocks
(reference-synchronized grandmasters), all the slave nodes in its logic tree need to switch
synchronization to the alternate grandmaster. This requires restart of the estimation of the
clock draft, mean path delay and offset which might cause fluctuation of time notion.
synchronization to the alternate grandmaster. This requires the restart of the estimation of the
clock drift, mean path delay and offset which might cause fluctuations in the notion of time.
The modified BMC allows for more then one \textit{best} clock in a single domain, enabling to create
logic topology with multiple roots. A Boundary Clock running modified BMC can have more then one
port in the PTP\_SLAVE state. This means that timing information is exchanged between Boundary Clock
and more then one source of time (Ordinary Clock or Boundary Clock). At any time any of these
information can be used to perform synchronization, including weighted average from all SLAVE ports
as mentioned in \cite{Takahide}.
The modified BMC allows for more than one \textit{best} clock in a single domain, enabling the
creation of a logic topology with multiple roots. A Boundary Clock running the modified BMC can have
more than one port in the PTP\_SLAVE state. This means that timing information is exchanged between
the Boundary Clock and more than one source of time (Ordinary Clock or Boundary Clock). At any time
any of these links can be used to perform synchronization, including a weighted average from all
SLAVE ports as mentioned in \cite{Takahide}.
The Best Master Clock algorithm comprises of State Decision Algorithm (SDA), Data Set Comparison
The BMC algorithm includes the State Decision Algorithm (SDA) and the Data Set Comparison
Algorithm (DCA) and defines which fields of Data Sets should be updated depending on the outcome of
SDA. The modifications to BMC are detailed below. DCA is not modified, therefore it is not
the SDA. The modifications to the BMC are detailed below. the DCA is not modified, therefore it is not
mentioned.
\subsubsection{State Decision Algorithm}
\subsubsection{State Decision Algorithm (SDA)}
\label{StadeDecisionAlg}
The original SDA is depicted in Figure~26 of the PTP standard. The modified SDA, depicted in
Figure~\ref{fig:modifiedSDA}, enforces SLAVE state instead of PASSIVE state. A port being in a
$PTP\_SLAVE$ state as a result of SDA modification (block-8 and block-13 of
Figure~\ref{fig:modifiedSDA}) is considered secondary SLAVE port. The port which enters
$PTP\_SLAVE$ state based on the decision at block-11, is considered Primary SLAVE port.
It means that a Secondary SLAVE port (if present) is connected to the grandmaster clock equally good
or worse by path compared to the one connected to Primary SLAVE port.
Figure~\ref{fig:modifiedSDA}, enforces $BMC\_SLAVE$ state instead of $BMC\_PASSIVE$ state. A port being
in a $PTP\_SLAVE$ state as a result of SDA modification (block-8 and block-13 of
Figure~\ref{fig:modifiedSDA}) is considered a Secondary SLAVE port. The port which enters
the $PTP\_SLAVE$ state based on the decision at block-11, is considered the Primary SLAVE port.
It means that:
\begin{itemize}
\item the Primary SLAVE port and the Secondary SLAVE port(s) are synchronized to the same
grandmaster clock but the connection of the Primary SLAVE port is possibly better by path, or
\item the Primary SLAVE port and the Secondary SLAVE port(s) are synchronized to different
grandmaster clocks of the same clockClass range (1-127 or 128-255,see Table~5 of PTP)
but the connection of the Primary SLAVE port is possibly better by path.
\end{itemize}
The best qualified Announce messages ($E_{rbest}$, see Clause 9.3.2.3 of PTP) from all Secondary
SLAVE ports shall be compared with DCA to determine the "second best master" and the lower order
SLAVE ports shall be compared with the DCA to determine the "second best master" and the lower order
masters. The sequence of events is as follows (the idea originated from \cite{Takahide}):
\begin{itemize}
\item The best master is computed with the BMC -- the Primary SLAVE port established (block-11 of
......@@ -702,10 +742,10 @@ masters. The sequence of events is as follows (the idea originated from \cite{Ta
a second best master and its data is stored in $E_{srbest}$.
\item The BMC algorithm is executed on all the $E_{srbest}$.
\item The best master selected is considered second best master.
\item The BMC is repeated excluding $E_{srbest}$ of the second best masters.
\item repeat till the set of $E_{srbest}$ is empty.
\item The BMC is repeated excluding $E_{srbest}$ of the best master until the set of $E_{srbest}$
is empty.
\end{itemize}
The order of second and lower level best masters determined in this way is used to update
The order of second and lower level best masters determined in this way is used to update the
backupParentDS data set.
......@@ -720,19 +760,20 @@ backupParentDS data set.
\subsubsection{Update of Data Sets}
The modifications to the rules governing update of data sets are twofold:
The modifications to the rules governing the update of the data sets are twofold:
\begin{itemize}
\item Modifications to already existing "update tables" (Table~13 and Table~16, clause 9.3 of
PTP) to accommodate new DS fields.
\item Addition of new "update table" to accommodate new backupParentDS data set and
modifications in SDA.
PTP) to accommodate the new DS fields.
\item Addition of a new "update table" to accommodate the new backupParentDS data set and
the modifications in the SDA.
\end{itemize}
\begin{table}[ht!]
\caption{Modification to Table~13 of IEEE1588-2008: Update for state decision code M1 and M2.}
\centering
\begin{tabular}{| c | c |} \hline
\textbf{Update this field} & \textbf{From the indicated source} \\
\begin{tabular}{| c | p{8cm} |} \hline
\textbf{Update this field} &
\textbf{From the indicated field of the defaultDS data set of the clock unless otherwise stated} \\
& \\ \hline
currentDS & \\ \hline
currentDS.primarySlavePortNumber & set to 0 \\ \hline
......@@ -773,22 +814,24 @@ backupParentDS.backupParentSourcePortIdentity & sourcePortIdentity of $E_{rbest
\subsection{WRPTP Messages}
\label{sec:wrMSG}
White Rabbit benefits from PTP's messaging facilities. It defines \textit{WR Type-Length-Value}
(WR TLV) to exchange WR-specific information and uses two-step clock delay request-response
mechanism for synchronization. In particular, it adds a suffix to the Announce message to enable
recognition of WR nodes and uses Signaling Messages to exchange WR-specific information
(Figure~\ref{fig:wrptpMSGs}).
White Rabbit benefits from PTP's messaging facilities. It defines a \textit{WR Type-Length-Value}
(WR TLV) extension to exchange WR-specific information and uses the two-step clock delay
request-response mechanism for synchronization. In particular, it adds a suffix to the Announce
message to enable recognition of WR nodes and uses Signaling Messages to exchange WR-specific
information (Figure~\ref{fig:wrptpMSGs}).
A WR Master announces its presence by adding a suffix to the Announce message.
A WR port in the $PTP\_MASTER$ state announces its presence by adding a suffix to the Announce message.
The suffix is defined by the PTP standard as a set of TLV entities (section 13.4, PTP).
Unrecognised TLVs are ignored by standard PTP nodes (section 14.1, PTP), but read and interpreted by
White Rabbit nodes.
The information provided in the WRPTP Announce message is sufficient for another WR port to decide
whether the WR link can be established and maintained. The WR port receiving
WRPTP Announce message enters (if conditions are fulfilled) WR Slave mode and starts Link Setup process (performed in the
$PTP\_UNCALIBRATED$ state, see Appendix~\ref{ap:ptpAndWrFSMS}) requesting the WR Master to do
the same. During the WR Link Setup, communication between the WR Master and the WR Slave is
performed using the PTP Signaling Messages carrying WR TLVs. Once the WR link has been established,
whether the WR link can be established and maintained. A WR port receiving a
WRPTP Announce message enters (if conditions in \ref{sec:wrSlaveFSMstart} are fulfilled)
the WR Slave mode and starts the Link Setup process (performed during $PTP\_UNCALIBRATED$ state.
see Appendix~\ref{ap:ptpAndWrFSMS}) It requests the sender of the WRPTP announce message to enter
the WR Master mode (see section \ref{sec:wrMasterFSMstart}) and start the Link Setup process.
During the WR Link Setup, communication between the WR Master and the WR Slave is performed using
PTP Signaling Messages carrying WR TLVs. Once the WR link has been established,
the WR nodes use a PTP delay request-response mechanism (section 11.3, PTP).
......@@ -796,10 +839,11 @@ the WR nodes use a PTP delay request-response mechanism (section 11.3, PTP).
\label{sec:wrTLVtype}
All PTP messages can be extended by means of a standard \textit{type, length, value} (TLV)
extension mechanism. White Rabbit uses \textit{ORGANIZATION\_EXTENSION} TLV type (tlvType=0x0003)
which is defined in clause 14.3 of PTP. TLVs represented by this type are designated for vendors
and standard organizations to extend the protocol for specific needs. The organization specific
TLV fields for WR extension are defined and described in Table~\ref{tab:wrTLVtype}.
extension mechanism. White Rabbit uses the \textit{ORGANIZATION\_EXTENSION} TLV type \\
(tlvType=0x0003) which is defined in clause 14.3 of PTP. TLVs represented by this type
are designated for vendors and standard organizations to extend the protocol for specific needs.
The organization-specific TLV fields for WR extension are defined and described in
Table~\ref{tab:wrTLVtype}.
\begin{table}[h!]
\caption{Organization specific TLV fields for WR (see Table~35, PTP).}
......@@ -817,7 +861,7 @@ TLV fields for WR extension are defined and described in Table~\ref{tab:wrTLVtyp
octets. \\ \hline
\multicolumn{8}{|c|}{OrganizatinId } & 3 & 4 & 0x080030 & OUI owned by CERN. \\
\hline
\multicolumn{8}{|c|}{organizationSubType} & 2 & 7 & magicNumber & e.g.: 0xDEAD - identifies WRPTP
\multicolumn{8}{|c|}{organizationSubType} & 2 & 7 & magicNumber & e.g.: 0xABCD - identifies WRPTP
within protocols identified by CERN's OUI. \\
\cline{9-12} %\hline
\multicolumn{8}{|c|}{} & 1 & 9 & versionNumber& 0x01 - WRPTP version.\\
......@@ -831,8 +875,8 @@ TLV fields for WR extension are defined and described in Table~\ref{tab:wrTLVtyp
\label{tab:wrTLVtype}
\end{table}
The WR-specific TLVs are identified by wrMessageID which is defined in
Table~\ref{tab:wrMessageId}, the different types of WR messages are described in subsequent
chapters.
Table~\ref{tab:wrMessageId}. The different types of WR messages are described in subsequent
sections.
\begin{table}[ht!]
\caption{White Rabbit Message ID values}
......@@ -855,12 +899,12 @@ ANN\_SUFIX & 0x2000 & Announce \\ \hline
\label{sec:wrAnnounceMSG}
The standard PTP Announce Message is suffixed by one entity of WR TLV.
The standard PTP Announce Message is suffixed by one WR TLV entity.
The WRPTP Announce message has the structure defined in Table~\ref{tab:wrAnnounce}. The $dataField$
of the suffix WR TLV stores the $wrFlags$ which are defined in Table~\ref{tab:wrFlags}.
of the suffix WR TLV stores the $wrFlags$ defined in Table~\ref{tab:wrFlags}.
\begin{table}[h!]
\caption{White Rabbit Announce Message}
\caption{White Rabbit Announce Message.}
\centering
\begin{tabular}{| c | c | c | c | c | c | c | c | c | c | p{4.5cm} |}
\hline
......@@ -874,7 +918,7 @@ of the suffix WR TLV stores the $wrFlags$ which are defined in Table~\ref{tab:wr
\multicolumn{8}{|c|}{tlvType } & 2 & 64 & 0x0003, see \ref{sec:wrTLVtype}. \\ \hline
\multicolumn{8}{|c|}{lengthField } & 2 & 66 & 0xA. \\ \hline
\multicolumn{8}{|c|}{OrganizationId} & 3 & 68 & 0x080030. \\ \hline
\multicolumn{8}{|c|}{magicNumber } & 2 & 71 & 0xDEAD. \\ \hline
\multicolumn{8}{|c|}{magicNumber } & 2 & 71 & 0xABCD. \\ \hline
\multicolumn{8}{|c|}{versionNumber } & 1 & 73 & 0x01. \\ \hline
\multicolumn{8}{|c|}{wrMessageId } & 2 & 74 & 0x0010. \\ \hline
\multicolumn{8}{|c|}{wrFlags } & 2 & 76 & see Table~\ref{tab:wrFlags}. \\ \hline
......@@ -884,7 +928,7 @@ of the suffix WR TLV stores the $wrFlags$ which are defined in Table~\ref{tab:wr
\begin{table}[ht!]
\caption{White Rabbit flags (unused flags are reserved and shall be written to 0, ignored when read)}
\caption{White Rabbit flags.}
\centering
\begin{tabular}{| c | c | c | c | p{5.3cm} |} \hline
......@@ -910,17 +954,17 @@ of the suffix WR TLV stores the $wrFlags$ which are defined in Table~\ref{tab:wr
\label{wrSignalingMSG}
White Rabbit uses Signaling Messages (defined in clause 13.12 of PTP) to exchange WR-specific
information, except for the flags transported in the suffix to Announce message.
information, except for the flags transported in the suffix of the Announce message.
The Signaling Messages conforms to the format presented in Table~\ref{tab:wrSignalingMSG}. Each WR
Signaling Message transports single WR TLV structured as defined in Section~\ref{sec:wrTLVtype}.
The targetPortIdentity shall be always set to clockIdentity of the port on the other side of the
link (conveyed in the Announce Message).
The Signaling Messages conform to the format presented in Table~\ref{tab:wrSignalingMSG}. Each WR
Signaling Message transports a single WR TLV structure as defined in Section~\ref{sec:wrTLVtype}.
The \textit{targetPortIdentity} shall be always set to the \textit{clockIdentity} of the port
on the other side of the link (conveyed in the Announce Message).
Signaling Message are used in WRPTP to trigger transitions in WR state machines and exchange
Signaling Messages are used in WRPTP to trigger transitions in the WR state machine and exchange
WR-specific parameters. They are distinguished by the \textit{wrMessageId} field of \textit{WR TLV},
defined in Table~\ref{tab:wrMessageId}. Signaling Messages are exchanged only within single
link connection (no forwarding) which is ensured by setting targetPortId appropriately.
defined in Table~\ref{tab:wrMessageId}. Signaling Messages are exchanged only within a single
link connection (no forwarding) which is ensured by setting the targetPortId appropriately.
The rest of this subsection describes the WRPTP Signaling Messages in details.
\begin{table}[h!]
......@@ -941,11 +985,11 @@ The rest of this subsection describes the WRPTP Signaling Messages in details.
\end{table}
\paragraph{SLAVE\_PRESENT} Message sent by the WR Slave to the WR Master. It initiates the WR Link
Setup process in the WR Master. The message shall have the form specified in
Table~\ref{tab:wrOtherTLV}.
\paragraph{SLAVE\_PRESENT} Message sent by the WR Node which entered WR Slave mode to the WR Node
to become the WR Master. It initiates the WR Master mode and starts WR Link Setup process in
the WR Master. The message shall have the form specified in Table~\ref{tab:wrOtherTLV}.
\paragraph{LOCK} Message sent by the WR Master to the WR Slave to request the start of frequency
\paragraph{LOCK} Message sent by the WR Master to the WR Slave to request the start of frequency
locking. The message shall have the form specified in Table~\ref{tab:wrOtherTLV}.
\paragraph{LOCKED} Message sent by the WR Slave to the WR Master. It indicates successful
......@@ -966,7 +1010,7 @@ Table~\ref{tab:wrOtherTLV}.
\multicolumn{8}{|c|}{tlvType } & 2 & 0 & 0x0003, see \ref{sec:wrTLVtype}. \\ \hline
\multicolumn{8}{|c|}{lengthField } & 2 & 2 & 0x8. \\ \hline
\multicolumn{8}{|c|}{OrganizationId} & 3 & 4 & 0x080030. \\ \hline
\multicolumn{8}{|c|}{magicNumber } & 2 & 7 & 0xDEAD. \\ \hline
\multicolumn{8}{|c|}{magicNumber } & 2 & 7 & 0xABCD. \\ \hline
\multicolumn{8}{|c|}{versionNumber } & 1 & 9 & 0x01. \\ \hline
\multicolumn{8}{|c|}{wrMessageId } & 2 & 10 & Defined in Table~\ref{tab:wrMessageId}.\\ \hline
\end{tabular}
......@@ -975,12 +1019,11 @@ Table~\ref{tab:wrOtherTLV}.
\paragraph{CALIBRATE} Message sent by the WR node entering the REQ\_CALIBRATION state (see
section~\ref{wrFSM}). It informs the other node
whether sending a calibration pattern (see section~\ref{sec:fixedDelays}) is required (defined by
the value of \textit{calibrationSendPattern} flag).
If calibration is required, it carries a set of parameters describing
the calibration pattern to be sent. The message format and parameters are described in
\paragraph{CALIBRATE} Message sent by the WR port entering the REQ\_CALIBRATION state (see
section~\ref{wrFSM}). It informs the other port
whether sending a calibration pattern (see section~\ref{sec:fixedDelays}) is required (defined by
the value of \textit{calibrationSendPattern} flag). If calibration is required, it carries
the calibration period. The message format and parameters are described in
Table~\ref{tab:wrCalibrateTLV}.
......@@ -997,7 +1040,7 @@ Table~\ref{tab:wrCalibrateTLV}.
\multicolumn{8}{|c|}{tlvType } & 2 & 0 & 0x0003, see \ref{sec:wrTLVtype}. \\ \hline
\multicolumn{8}{|c|}{lengthField } & 2 & 2 & 0x14. \\ \hline
\multicolumn{8}{|c|}{OrganizationId } & 3 & 4 & 0x080030. \\ \hline
\multicolumn{8}{|c|}{magicNumber } & 2 & 7 & 0xDEAD. \\ \hline
\multicolumn{8}{|c|}{magicNumber } & 2 & 7 & 0xABCD. \\ \hline
\multicolumn{8}{|c|}{versionNumber } & 1 & 9 & 0x01. \\ \hline
\multicolumn{8}{|c|}{wrMessageId } & 2 & 10 & CALIBRATE. \\ \hline
\multicolumn{8}{|c|}{calibrationSendPattern} & 2 & 12 & The value determines whether calibration
......@@ -1008,13 +1051,13 @@ Table~\ref{tab:wrCalibrateTLV}.
\multicolumn{8}{|c|}{calibrationPeriod} & 4 & 14 & The value defines the time (in microseconds)
for which the calibration pattern should be
sent by the receiving node.\\ \hline
\multicolumn{8}{|c|}{calibrationPattern} & 4 & 18 & The value defines the calibration pattern
which should be sent by the receiving
node.\\ \hline
\multicolumn{8}{|c|}{calibrationPatternLen} & 2 & 22 & The value defines the number of bits of
\textit{calibrationPattern} field which
should be used as repeated pattern (starting
with the LSB). \\\hline
% \multicolumn{8}{|c|}{calibrationPattern} & 4 & 18 & The value defines the calibration pattern
% which should be sent by the receiving
% node.\\ \hline
% \multicolumn{8}{|c|}{calibrationPatternLen} & 2 & 22 & The value defines the number of bits of
% \textit{calibrationPattern} field which
% should be used as repeated pattern (starting
% with the LSB). \\\hline
\end{tabular}
\label{tab:wrCalibrateTLV}
\end{table}
......@@ -1024,7 +1067,7 @@ Table~\ref{tab:wrCalibrateTLV}.
\paragraph{CALIBRATED} Message sent by a WR node entering the \textit{CALIBRATED} state.
\paragraph{CALIBRATED} Message sent by a WR port entering the \textit{CALIBRATED} state.
If preceded by the \textit{CALIBRATE} message with \textit{calibrationSendPattern} set to TRUE,
it indicates successful completion of the calibration. The message provides the other node with the
values of its fixed delays ($\Delta_{tx}$ and $\Delta_{rx}$).
......@@ -1043,7 +1086,7 @@ The message shall have the format specified in Table~\ref{tab:wrCalibratedTLV}.
\multicolumn{8}{|c|}{tlvType } & 2 & 0 & 0x0003, see \ref{sec:wrTLVtype}. \\ \hline
\multicolumn{8}{|c|}{lengthField } & 2 & 2 & 0x28. \\ \hline
\multicolumn{8}{|c|}{OrganizationId } & 3 & 4 & 0x080030. \\ \hline
\multicolumn{8}{|c|}{magicNumber } & 2 & 7 & 0xDEAD. \\ \hline
\multicolumn{8}{|c|}{magicNumber } & 2 & 7 & 0xABCD. \\ \hline
\multicolumn{8}{|c|}{versionNumber } & 1 & 9 & 0x01. \\ \hline
\multicolumn{8}{|c|}{wrMessageId } & 2 & 10 & CALIBRATED. \\ \hline
\multicolumn{8}{|c|}{deltaTx } & 16 & 12 & The value of $\Delta_{tx_m}$ measured in
......@@ -1060,36 +1103,37 @@ The message shall have the format specified in Table~\ref{tab:wrCalibratedTLV}.
\paragraph{WR\_MODE\_ON} Message sent by WR Master to WR Slave. It indicates successful completion
of
the WR Link Setup process and requests the WR~Slave to enter WR~mode. The message shall have the
format specified in Table~\ref{tab:wrOtherTLV}.
of the WR Link Setup process and requests the WR~Slave to validate its WR~mode (by setting wrModeON
to true). The message shall have the format specified in Table~\ref{tab:wrOtherTLV}.
\newpage
\subsection{PTP State Machine}
\label{ptpStateMachine}
The WR Link Setup (WR state machine) is performed in the PTP\_UNCALIBRATED state of PTP state
The WR Link Setup (WR state machine) is performed in the PTP\_UNCALIBRATED state of the PTP state
machine (see Appendix~\ref{ap:ptpAndWrFSMS}). Therefore it is essential for a WR port to implement
this state as specified in the PTP state machine (\textcolor{blue}{2} in
Figure~\ref{fig:modifiedPtpFSM}): a transition state
between the LISTENING or PRE\_MASTER or MASTER or PASSIVE state and the SLAVE state.
WRPTP specifies implementation-specific SYNCHRONIZATION\_FAULT PTP state transition event (defined in
Clause 9.2.6.12). It shell be implemented as evaluation of two WR-specific parameters: $wrModeON$
and $parentWrModeON$ by the port being in WR\_SLAVE mode and PTP\_SLAVE state. If the value of at least
on of the parameters is FALSE, the SYNCHRONIZATION\_FAULT even shell occur and PTP\_UNCALIBRATED
entered. Consequently the WR Link Setup is performed. Such implementation enables forced
re-calibration of WR nodes which can be triggered by both, WR Master and WR Slave.
WRPTP specifies an implementation-specific SYNCHRONIZATION\_FAULT PTP state transition event
(defined in Clause 9.2.6.12). The port being in WR\_Slave mode and PTP\_SLAVE state shall
evaluate values of two WR-specific parameters: $wrModeON$ and $parentWrModeON$. If the value
of at least one of the parameters is FALSE, the SYNCHRONIZATION\_FAULT event shall occur
and PTP\_UNCALIBRATED shall be entered. Consequently the WR Link Setup is performed.
Such implementation enables forced re-calibration of WR ports which can be triggered by both,
WR Master and WR Slave.
WRPTP introduces new state transition event to the original PTP state machine:
\textit{CALIBRATION\_FORCED\_BY\_SLAVE}. It is depicted in red (number 2)
WRPTP introduces a new state transition event to the original PTP state machine:
\textit{CALIBRATION\_FORCED\_BY\_SLAVE}. It is depicted in red (number \textcolor{blue}{2})
in Figure~\ref{fig:modifiedPtpFSM}. The event shall be instantiated by the reception of
$SLAVE\_PRESENT$ Signaling Message on WR-Master-enabled port (the value of portDS.wrConfig's
is WR\_M\_AND\_S or WR\_M\_ONLY) in $PTP_MASTER$ state. Such state transition enables WR Slave
to initiate WR Link Setup on WR Master.
the $SLAVE\_PRESENT$ Signaling Message on a WR-Master-enabled port (the value of portDS.wrConfig
is WR\_M\_AND\_S or WR\_M\_ONLY) in $PTP\_MASTER$ state.
This transition allows a WR Slave to start WR Master mode and trigger a WR Link Setup process in
another WR port.
\begin{figure}[ht!]
......@@ -1107,46 +1151,57 @@ WRPTP introduces new state transition event to the original PTP state machine:
\label{wrFSM}
The White Rabbit finite state machine (WR FSM) controls the process of establishing a White Rabbit
link between a WR Master and a WR Slave (WR Link Setup). It involves recognition of two compatible
WR nodes, syntonization over the physical layer, measurement of fixed delays and exchange of
their values across the link. The procedure differs between WR Master and WR Slave, therefore
three states are Slave-only (entered only if the node is in WR Slave mode) and one state is
Master-only (entered only if the node is in WR Master mode). The WR FSM shall be
link between a WR Master and a WR Slave (WR Link Setup). It involves the recognition of two
compatible WR nodes, syntonization over the physical layer, measurement of fixed delays and
exchange of their values across the link. The procedure differs between WR Master and WR Slave,
therefore three states are Slave-only (entered only if the node is in WR Slave mode) and one
state is Master-only (entered only if the node is in WR Master mode). The WR FSM shall be
executed in the PTP UNCALIBRATED state, it is depicted in Figure~\ref{fig:wrFSM} and described in
the rest of
this section.
the rest of this section.
A typical flow of a complete WR Signalin Message exchange between a WR Slave and a WR Master
A typical flow of a complete WR Signaling Message exchange between a WR Slave and a WR Master
during WR Link Setup is presented in Appendix~\ref{ap:wr_lsu_flow}. For clarity, the cooperation of
PTP and WR state machines from the power up is presented in Appendix~\ref{ap:ptpAndWrFSMS}.
PTP and WR state machines from power up is presented in Appendix~\ref{ap:ptpAndWrFSMS}.
\subsubsection{Condition to start the WR FSM by WR Slave}
\subsubsection{Conditions to enter WR Slave mode and start the WR FSM}
\label{sec:wrSlaveFSMstart}
The WR FSM in a WR Slave-enabled port (portDS.wrConfig equals \textit{WR\_M\_ONLY} OR
\textit{WR\_M\_AND\_S}) exits the IDLE state and starts execution by entering the \textit{PRESENT}
state, only when the PTP state machine enters the PTP UNCALIBRATED state
as a result of STATE\_DECISION\_EVENT: Recommended State == BMC\_SLAVE (\textcolor{blue}{1} in
Figure~\ref{fig:modifiedPtpFSM}) and the following conditions
are met:
%The WR FSM in
A WRPTP-enabled port becomes a WR Slave (portDS.wrMode = WR\_SLAVE) and starts execution
of WR FSM by entering the \textit{PRESENT} state, only when the following conditions are met:
\begin{itemize}
\item the port is WR Slave-enabled: \\
\textit{portDS.portWrConfig = ($WR\_S\_ONLY$ \textbf{OR} $WR\_M\_AND\_S$)} \textbf{AND}
\item the PTP state machine enters the PTP UNCALIBRATED state as a result of \\
STATE\_DECISION\_EVENT:
Recommended State == BMC\_SLAVE (\textcolor{blue}{1} in Figure~\ref{fig:modifiedPtpFSM})
\textbf{AND}
\item the parent port is WR Master-enabled: \\
\textit{portDS.parentPortWrConfig = ($WR\_M\_ONLY$ \textbf{OR} $WR\_M\_AND\_S$)} \textbf{AND}
\item at least one of the ports on the link is not in WR Mode: \\
\textit{portDS.portWrMode = FALSE \textbf{OR} portDS.ParentPortWrMode = FALSE}.
\end{itemize}
\subsubsection{Condition to start the WR FSM by WR Master}
\subsubsection{Conditions to enter WR Master mode and start the WR FSM}
\label{sec:wrMasterFSMstart}
A WRPTP-enabled port becomes a WR Master (portDS.wrMode = WR\_Master) and starts execution of WR FSM
by entering the \textit{M\_LOCK} state only when the following conditions are met:
\begin{itemize}
\item the port is WR Master-enabled:\\
\textit{portDS.portWrConfig = $WR\_M\_ONLY$ \textbf{OR} $WR\_M\_AND\_S$} \textbf{AND}
\item the PTP state machine enters the a PTP\_UNCALIBRATED state as a result of
CALIBRATION\_FORCED\_BY\_SLAVE transition event (\textcolor{blue}{2} in
Figure~\ref{fig:modifiedPtpFSM})
\end{itemize}
The WR FSM in a WR Master-enabled port (\textit{$WR\_M\_ONLY$ \textbf{OR} $WR\_M\_AND\_S$})
exits the IDLE state and starts execution by entering the \textit{M\_LOCK} state only when
PTP state machine enters the PTP\_UNCALIBRATED state as a result of
CALIBRATION\_FORCED\_BY\_SLAVE transition event (\textcolor{blue}{2} in
Figure~\ref{fig:modifiedPtpFSM}).
%The WR FSM in a WR Master-enabled port (\textit{$WR\_M\_ONLY$ \textbf{OR} $WR\_M\_AND\_S$})
%exits the IDLE state and starts execution by entering the \textit{M\_LOCK} state only when
%PTP state machine enters the PTP\_UNCALIBRATED state as a result of
%CALIBRATION\_FORCED\_BY\_SLAVE transition event (\textcolor{blue}{2} in
%igure~\ref{fig:modifiedPtpFSM}).
\newpage
......@@ -1275,7 +1330,7 @@ WR\_LINK\_ON & The value of \textit{wrMode} is set to TRUE and the \texti
\centering
\begin{tabular}{| c | c |} \hline
\multicolumn{2}{|c|}{\textbf{PTP Profile}} \\ \hline
prifleName & White Rabbit \\ \hline
profleName & White Rabbit \\ \hline
profileVersion & 1.0 \\ \hline
profileIdentifier & 08-00-03-00-01-00 \\ \hline
organizationName & European Organization for Nuclear Research (CERN) \\ \hline
......@@ -1294,36 +1349,35 @@ the attributes as follows:
\item defaultDS.priority1: The default initialization value shall be 64.
\end{itemize}
\subsubsection{PTP Optins}
\subsubsection{PTP Options}
All options of 15.5.4.1.7 and clause 17 of PTP are permitted (??). By default, these options shall be
All options of 15.5.4.1.7 and clause 17 of PTP are permitted. By default, these options shall be
inactive unless specifically activated by a management procedure.
\\
Node management shall implement the management message mechanism of IEEE1588-2008 standard.
The node management shall implement the management message mechanism of the IEEE1588-2008 standard.
\\
The best master algorithm shall be the algorithm specified in Chapter~\ref{sec:wrBMC} of this
document (Modified BMC).
\\
The delay request-response mechanism shall be the default and only path delay measurement mechanism.
The delay request-response mechanism shall be the only path delay measurement mechanism.
\\
The TLV mechanism described in Chapter~\ref{sec:wrMSG} shall be supported.
\subsection{WRPTP Extensions to PTP}
\subsection{WRPTP Extension to PTP}
WRPTP extends PTP by adding state transition event defined in subchapter~\ref{ptpStateMachine}.
WRPTP extends PTP by adding the state transition event defined in section~\ref{ptpStateMachine}.
\subsection{Implementation-specific additions to PTP required by WRPTP}
WRPTP shell implement implementation-specific features:
WRPTP shall implement the following implementation-specific features:
\begin{itemize}
\item issuing PTP messages with WR TLV (i.e.suffixed Announce and Signaling messages),
as described in subchapter~\ref{sec:wrAnnounceMSG},
\item proper handling of PTP message with WR TLV (i.e. Signaling and suffixed Announce messages)
as described in subchapter~\ref{sec:wrAnnounceMSG},
\item WR state machine as defined in subchapter~\ref{wrFSM},
\item issuing PTP messages with a WR TLV (i.e. suffixed Announce and Signaling messages),
as described in section~\ref{sec:wrAnnounceMSG},
\item proper handling of these messages as described in \ref{sec:wrAnnounceMSG},
\item WR state machine as defined in \ref{wrFSM},
\item WR data set and additional WR-specific fields to PTP data sets as defined in
subchapter~\ref{sec:wrDS},
\item SYNCHRONIZATION\_FAULT state transition as defined in subchapter~\ref{ptpStateMachine}.
\ref{sec:wrDS},
\item SYNCHRONIZATION\_FAULT state transition as defined in \ref{ptpStateMachine}.
\end{itemize}
......@@ -1420,17 +1474,17 @@ SLAVE & \small The port is synchronizing to the selected master po
The variation of $\Delta_{\{tx_m, rx_s, tx_s, rx_m\}}$ delays is often caused by
the PHY's serializer / deserializer (SerDes), phase locked loop (PLL) or clock and
data recovery circuitry (CDR). The delay on the PHY can be measured by detecting
the phase shift between SerDes I/O and Tx/Rx clock. This can be done, for example, by sending
a repeated pattern of five "0" and five "1" (0000011111) over Gigabit Ethernet.
the phase shift between SerDes I/O and Tx/Rx clock. This be done in WR by sending
a repeated pattern of five "0" and five "1" (0000011111) over Gigabit Ethernet.
Such signal creates a 125~MHz clock on the SerDes I/O. Since the Tx/Rx clock
frequency is 125~MHz, the phase shift between the SerDes I/O and the Tx/Rx
clocks is equal to the fixed delay of the PHY (see Figure~\ref{fig:wrCalibration}).
The repeated pattern of five "0" and five "1" is an example of
\textit{calibration pattern} which is defined by the node requesting a calibration.
The calibration pattern used to describe the methods is not compliant with the 8b/10b encoding
standard.
For real-life implementation, a 8b/10b compliant pattern is needed.
The repeated pattern of five "0" and five "1" is defined by the IEEE 802.3 standard \cite{IEEE802.3}
as \textit{Low-frequency test pattern} (Appendix~36A.2). It shall be generated in WR nodes
by a repeated transmission of RD+ K28.7 code-group.
\begin{figure}[ht!]
\centering
......@@ -1484,6 +1538,14 @@ Control Systems}.
2008,
http://ieee1588.nist.gov/.
\bibitem{IEEE802.3}
IEEE Std 802.3-2008
\emph{IEEE Standard for Information technology -- Telecommunications and information exchange
between systems -- Local and Metropolitan area networks -- Specific requirements}.
IEEE Computer Society, New York,
2008.
\bibitem{Peek2010}
P.P.M. Jansweijer, H.Z. Peek,
\emph{Measuring propagation delay over a 1.25 Gbps bidirectional data link}.
......
wrspec_v1.1.pdf 0 → 100644
View file @ 5d85fdcd
File added
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment