Skip to content

W
White Rabbit Standardization
Commit 323a9c76 authored by Maciej Lipinski's avatar Maciej Lipinski
Browse files
Options

wrspec: first draft of V2

parent 4e0d9f47
Hide whitespace changes
Inline Side-by-side
Showing with 706219 additions and 6357 deletions
src/Makefile
View file @ 323a9c76
......@@ -7,6 +7,7 @@ wrspec.pdf : wrspec.tex figs
latex $^
dvips wrspec
ps2pdf wrspec.ps
cp wrspec.pdf ../
figs:
$(MAKE) -C fig
......
src/deleted 0 → 100644
View file @ 323a9c76
where the parentDS with index 0 is used as
parentDS defined in
the standard, the parentDS with index 1 and greater are used to store information about
backup sources of timing information, updated as defined by modified BMC, used by
platform-specific hardware support for topology redundancy.
==============================
It can be noted that if $\Delta << \mu$, the above equation can be simplified:
\begin{equation}
\label{eq:aqasymmSympl}
\eqasymm = \Delta_{tx_m} + \Delta_{rx_s} - \frac{\Delta - \alpha \mu}{2 + \alpha}
\end{equation}.
=============================
IEEE1588 standard allows its custamisation by the means of PTP profile which specifies set of
required and prohibited options as well as ranges and defaults of configurations. WRPTP takes a
full advantage of PTP profile defining WR TLVs, modification to Best Master Clock algorithm and
default attribut values.
=============================
\begin{table}[ph!]
\caption{WRPTP Data Sets fields}
\centering
\begin{tabular}{| c | p{2.0cm} | p{2.5cm} | p{1.5cm} | p{4cm}
|} \hline
\textbf{DS member} & \textbf{DS name}&\textbf{Values}& \textbf{D}ynamic or \textbf{S}tatic &
\textbf{Description}
\\
& & & &
\\ \hline
portWrConfig & portDS & NON\_WR,
WR\_S\_ONLY,
WR\_M\_ONLY
WR\_M\_AND\_S &S & Determines predefined
function of WR port
(static).\\ \hline
portCalibrated & portDS & TRUE, FALSE &D & Indicates whether fixed
delays of the given port
are known.\\ \hline
deltaTx & portDS & 64 bit value &D & Port's $\Delta_{tx}$
measured in picoseconds
and multiplied by
${2^{16}}$.\\ \hline
deltaRx & portDS & 64 bit value &D & Port's $\Delta_{rx}$
measured in picoseconds
and multiplied by
${2^{16}}$.\\ \hline
calPeriod & portDS & 32 bit value &S & Calibration period in
microseconds. \\ \hline
calPattern & portDS & 32 bit value &S & Medium specific
calibration pattern.
\\ \hline
calPatternLen & portDS & 16 bit value &S & Number of bits of
calPattern to be
repeated.\\ \hline
portWrMode & portDS & TRUE, FALSE &D & If TRUE, the port is
working in WR mode.
\\ \hline
wrAlpha & portDS & 32 bit value &S & \textit{Medium
correlation parameter} as
described in
section~\ref{sec:singlefiber}.
\\ \hline
parentPortWrConfig & portDS & NON\_WR,
WR\_S\_ONLY,
WR\_M\_ONLY
WR\_M\_AND\_S &D & Determines predefined
function of the PTP
parent.\\ \hline
parentPortDeltaTx & portDS & 64 bit value &D & Parent's
$\Delta_{tx}$ measured
in picoseconds and
multiplied by
${2^{16}}$. \\ \hline
parentPortDeltaRx & portDS & 64 bit value &D & Parent's
$\Delta_{rx}$ measured in
picoseconds and multiplied
by ${2^{16}}$. \\ \hline
parentPortWrMode & portDS & TRUE, FALSE &D & If TRUE, the parent port
is working in WR mode.
\\ \hline
primarySlavePortNumber & currentDS & 16 bits value &D & If 0, no
primary Slave is
selected. 1, 2 ,...N-value
of portNumber (clause
7.5.2.3 PTP), selected as
primary Slave.
\\ \hline
\end{tabular}
\label{tab:wrDS}
\end{table}
=============================
Hardware implementation of WR-Slave-enable port is much more complex then the implementation of
WR-Master-enabled port, while the usual number of ports acting as slaves in a WR Boundary
Clock is foreseen to be two or one (out of around 18 total). Therefore, it is justified to introduce
MasterOnly PTP state machine. Such solution enables to develop WR Boundary Clocks which implement
hardware support for Slave only on chose ports\footnote{This is the case of V2 of WR Switch. V3
WR Switch will enable all ports to act as Slaves}. A port running in MasterOnly mode can act only as
a source of timing information (so-called downlink). The MasterOnly PTP state machine is presented
in Figure~\ref{fig:ptpFSMmasterOnly}.
In case when SlaveOnly port is needed, the SlaveOnly PTP state machine defined in Figure~24 in PTP
standard is used (see Appendix~\ref{ptpFSM}, Figure~\ref{fig:ptpFSMslaveOnly}).
\begin{figure}[ht!]
\centering
\includegraphics[width=0.85\textwidth]{fig/ptpFSMmasterOnly.ps}
\caption{MasterOnly PTP state machine.}
\label{fig:ptpFSMmasterOnly}
\end{figure}
=============================
=============================
\ No newline at end of file
src/fig/SDA.ps 0 → 100644
View file @ 323a9c76
This source diff could not be displayed because it is too large. You can view the blob instead.
src/fig/modifiedPtpFSM.ps 0 → 100644
View file @ 323a9c76
This source diff could not be displayed because it is too large. You can view the blob instead.
src/fig/ptpAndWrFSMs.ps 0 → 100644
View file @ 323a9c76
This source diff could not be displayed because it is too large. You can view the blob instead.
src/fig/ptpFSM.ps
View file @ 323a9c76
This source diff could not be displayed because it is too large. You can view the blob instead.
src/fig/ptpFSMmasterOnly.ps 0 → 100644
View file @ 323a9c76
This source diff could not be displayed because it is too large. You can view the blob instead.
src/fig/ptpFSMslaveOnly.ps 0 → 100644
View file @ 323a9c76
This source diff could not be displayed because it is too large. You can view the blob instead.
src/wrspec.tex
View file @ 323a9c76
......@@ -19,8 +19,8 @@
\usepackage{pgf}
\usepackage{tikz}
\usetikzlibrary{arrows,automata,shapes}
\usepackage{multirow}
\usepackage{color}
\usepackage[latin1]{inputenc}
\usepackage{verbatim}
\usepackage{amsmath}
......@@ -83,20 +83,30 @@
\begin{table}[ht]
%\caption{White Rabbit Specification Revision History Table }
\centering
\begin{tabular}{| c | c | c | p{6cm} |} \hline
\begin{tabular}{| c | c | c | p{8cm} |} \hline
\textbf{Version} & \textbf{Date} & \textbf{Authors} & \textbf{Description} \\
& & &\\ \hline
0.1 & 10/09/2010 & E.G., M.L. & First draft for comments. \\ \hline
0.2 & 7/09/2010 & T.W., M.L. & Added introduction about PTP. \\ \hline
0.3 & 8/09/2010 & J.S., M.L. & Language\&Style-related corrections, reference to Peter's paper. \\ \hline
0.4 & 14/09/2010 & E.V.D.B., M.L.& 1.~Merged the FSM of the Slave and the FSM of the Master into single and linear FSM,\\
0.3 & 8/09/2010 & J.S., M.L. & Language\&Style-related corrections, reference to Peter's paper.
\\ \hline
0.4 & 14/09/2010 & E.V.D.B., M.L.& 1.~Merged the FSM of the Slave and the FSM of the Master into
single and linear FSM,\\
& & & 2.~Changed WR managementIDs,\\
& & & 3.~Added authors, this rev. table, explanatory figures and descriptions.
\\ \hline
& & & 3.~Added authors, this rev. table, explanatory figures and
descriptions. \\ \hline
0.5 & 17/09/2010 & E.V.D.B., J.S.& 1.~Added Table of Contents. \\
& & & 2.~Re-ordered appendixes. \\
& & & 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
Power On. \\
& & & 6.~Mentioning (missed) modification to PTP FSM. \\
\hline
\end{tabular}
\label{tab:revHist}
\end{table}
......@@ -113,7 +123,8 @@ White Rabbit (WR) is a protocol developed to synchronize nodes in
a packet-based network with sub-ns accuracy. The protocol results
from the combination of IEEE1588-2008 (PTP)\cite{IEEE1588} with two further
requirements: precise knowledge of the link delay and clock
syntonization\footnote{The adjustment of two electronic circuits or devices in terms of frequency.} over the physical layer.
syntonization\footnote{The adjustment of two electronic circuits or devices in terms of frequency.}
over the physical layer.
A WR link is formed by a pair of nodes, master and slave (Figure~\ref{fig:wrNodes}). The master
node uses a traceable clock to encode data over the physical layer, while the slave
......@@ -122,7 +133,8 @@ 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),
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
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.
\begin{figure}[ht!]
......@@ -144,10 +156,10 @@ Multi-link WR networks are obtained by chaining WR links forming a
hierarchical topology. This hierarchy is imposed by the fact that
a frequency traceable to a common grandmaster must be distributed
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:
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 Timing Receivers), see section~\ref{sec:wrptpOverview}. It should be noted that the problem of non-linear
error accumulation of chained boundary clocks is greatly diminished by the clock recovery mechanism.
(WR Nodes), see section~\ref{sec:wrptpOverview}.
\begin{figure}[ht!]
\centering
......@@ -157,12 +169,10 @@ error accumulation of chained boundary clocks is greatly diminished by the clock
\label{fig:wrNetwork}
\end{figure}
Some applications need WR and IEEE1588-2008 nodes to coexist. Examples
of this are existing IEEE1588 installations which are to be migrated
progressively to White Rabbit and 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.
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.
......@@ -172,7 +182,7 @@ IEEE1588 behaviour when not connected to another WR node.
\section{Precision Time Protocol}
\label{sec:ptp}
The IEEE1588-2008 standard, known as Precise Time Protocol (PTP),
The IEEE1588-2008 standard, known as Precision Time Protocol (PTP),
is repeatedly referenced in this document. Knowledge of basic PTP concepts is
required to read this specification, therefore they are explained in this section.
......@@ -224,16 +234,21 @@ The flow of events in the PTP delay request-response (two-step clock) mechanism
(simplified overview):
\begin{enumerate}
\item The master sends Announce messages periodically.
\item The slave receives the Announce message and uses the BMC algorithm to establish its place in the network hierarchy.
\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 Announce message and uses the BMC algorithm to establish its place in
the network hierarchy.
\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 sent by the master.
\item The slave receives the Follow\_Up message (which carries timestamp of Sync transmission time)
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 master (timestamped on reception, $t_4$).
\item The master receives the Delay\_Req message sent by the slave (timestamped on reception,
$t_4$).
\item The master sends the Delay\_Resp message which carries $t_4$.
\item The slave receives the Delay\_Resp.
\item The slave adjusts its clock using the offset and the delay calculated with timestamps
($t_{1}$, $t_{2}$, $t_{3}$, $t_{4}$). It results in the Slave's synchronization with the Master clock.
($t_{1}$, $t_{2}$, $t_{3}$, $t_{4}$). It results in the Slave's synchronization with the
Master clock.
\item Repeat 1-10.
\end{enumerate}
......@@ -264,11 +279,12 @@ master can be decomposed as
\end{equation}
The characterization of the link is completed with an equation to
relate the two variable delays $\delta_{ms}$ and $\delta_{sm}$. From now
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 correlations obtained empirically for one scenario.
relate the two variable delays $\delta_{ms}$ and $\delta_{sm}$.
% From now
% 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.
\begin{figure}[ht!]
\centering
......@@ -280,15 +296,15 @@ provides correlations obtained empirically for one scenario.
\label{fig:delaymodel}
\end{figure}
\subsection{Physical Medium Correlation}
\subsection{Relative Delay Coefficient}
\label{sec:physcorr}
An accurate correlation between both variable delays on the transmission line
An accurate relation between both variable delays on the transmission line
is essential for obtaining an acceptable estimate of the delay asymmetry on a
WR link. The origin of this correlation is highly implementation-dependent.
Thus this document just assumes that such correlation exists and is known.
The correlation between $\delta_{ms}$ and $\delta_{sm}$ is represented in
this document by the \textit{medium correlation parameter} ($\alpha$).
WR link. The relation between $\delta_{ms}$ and $\delta_{sm}$ is represented in
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}
\label{sec:singlefiber}
......@@ -326,7 +342,8 @@ i.e.
\Delta = \Delta_{tx_m} + \Delta_{rx_s} + \Delta_{tx_s} + \Delta_{rx_m}
\end{equation}
The delay asymmetry as specified in section 7.4.2 of the PTP standard is expressed in our own notation by using equations \eqref{eq:delayms},
The delay asymmetry as specified in section 7.4.2 of the PTP standard is expressed in our own
notation by using equations \eqref{eq:delayms},
\eqref{eq:delaysm} and \eqref{eq:mu} as follows:
\begin{align}
\eqdelay{ms} = \mu + \eqasymm
......@@ -347,18 +364,15 @@ Combining equations \eqref{eq:singlefiber} and \eqref{eq:mu} we obtain:
\label{eq:deltasm}
\end{gather}
\\
The delay asymmetry can then be derived from equations \eqref{eq:delayms}, \eqref{eq:asymm}, \eqref{eq:deltams} and
The delay asymmetry can then be derived from equations \eqref{eq:delayms}, \eqref{eq:asymm},
\eqref{eq:deltams} and
\eqref{eq:deltasm}:
\begin{equation}
\label{eq:aqasymm}
\eqasymm = \Delta_{tx_m} + \Delta_{rx_s} - \frac{\Delta - \alpha \mu + \alpha \Delta}{2 + \alpha}
\end{equation}
\\
It can be noted that if $\Delta << \mu$, the above equation can be simplified:
\begin{equation}
\label{eq:aqasymmSympl}
\eqasymm = \Delta_{tx_m} + \Delta_{rx_s} - \frac{\Delta - \alpha \mu}{2 + \alpha}
\end{equation}.
......@@ -376,25 +390,58 @@ WR node's reception fixed delay ($\Delta_{\{rx_m, rx_s\}}$) upon request, e.g. b
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.
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.
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
\section{White Rabbit PTP Extension}
\section{White Rabbit PTP }
White Rabbit extends the IEEE1588-2008 (PTP) standard to achieve sub-ns accuracy while still
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.
\subsection{Overview}
\label{sec:wrptpOverview}
White Rabbit extends the IEEE1588-2008 (PTP) standard to achieve sub-ns accuracy while still benefiting
from PTP's synchronization and management mechanisms. From now on in this document,
the White Rabbit extension to the PTP standard will be referred to as \textit{WRPTP}. 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 WR extension takes advantage of 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. WRPTP extends the PTP messages and Data Sets (DS) to communicate parameters and state information between a master and a slave.
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
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
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.
\begin{figure}[ht!]
\centering
% \vspace{-1.3cm}
\includegraphics[width=0.80\textwidth]{fig/hybrid.ps}
\caption{Hybrid WR/IEEE1588 network. White Rabbit nodes work
transparently with PTP nodes. WR ordinary clock 3 is more accurately
synchronised to the grandmaster than WR ordinary clock 2, which
is below a PTP boundary clock.}
\label{fig:hybrid-network}
\end{figure}
\begin{figure}[ht!]
......@@ -411,16 +458,25 @@ as depicted in Figure~\ref{fig:wrptpMSGs} and described below (simplified overvi
\newpage
\begin{enumerate}
\item The WR Master periodically sends WR Announce messages with a custom suffix.
\item The WR Slave receives an Announce message, recognizes it as the WR Announce message and uses the modified BMC algorithm to establish its place in the WR network hierarchy.
\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 Management message.
\item The WR Master sends the LOCK WR Management message to request the WR Slave to start syntonization.
\item The WR Slave sends the LOCKED WR Management message as soon as the syntonization process is finished (notification from the hardware).
\item The WR Master sends the CALIBRATE WR Management message to request calibration of its reception fixed delay.
\item The WR Master sends the CALIBRATED WR Management message as soon as the calibration is finished (notification from hardware).
\item The WR Slave sends the CALIBRATE WR Management message to request calibration of its reception fixed delay.
\item The WR Slave sends the CALIBRATED WR Management message as soon as the calibration is finished (notification from hardware).
\item The WR Master sends the WR\_MODE\_ON WR Management message to indicate completion of the WR Link Setup process.
\item The WR Master periodically sends a Sync message (timestamped on transmission, $t_1$) followed by a Follow\_UP message which carries $t_1$.
\item The WR Master sends the LOCK WR Management message to request the WR Slave to start
syntonization.
\item The WR Slave sends the LOCKED WR Management message as soon as the syntonization process is
finished (notification from the hardware).
\item The WR Master sends the CALIBRATE WR Management message to request calibration of its
reception fixed delay.
\item The WR Master sends the CALIBRATED WR Management message as soon as the calibration is
finished (notification from hardware).
\item The WR Slave sends the CALIBRATE WR Management message to request calibration of its
reception fixed delay.
\item The WR Slave sends the CALIBRATED WR Management message as soon as the calibration is
finished (notification from hardware).
\item The WR Master sends the WR\_MODE\_ON WR Management message to indicate completion of the WR
Link Setup process.
\item The WR Master periodically sends a Sync message (timestamped on transmission, $t_1$) followed
by a Follow\_UP message which carries $t_1$.
\item The WR Slave receives the Sync message sent by the master (timestamped on reception, $t_2$).
\item The WR Slave receives the Follow\_Up message sent by the master.
\item The WR Slave sends a Delay\_Req message (timestamped on transmission, $t_3$).
......@@ -433,134 +489,375 @@ It results in the Slave's synchronization with the Master clock with sub-ns accu
\item Repeat 1, 11-18.
\end{enumerate}
The WR Link Setup is performed in the PTP UNCALIBRATED state, so it is essential for a
WR node to implement this state as specified in the PTP state machine (Appendix~\ref{ptpFSM}):
a transition state between the LISTENING or PRE\_MASTER or MASTER or PASSIVE state and the SLAVE state.
\subsection{Definitions}
In this document, the term \textit{node}
is used interchangeably with \textit{port}. A WR Master node/port is an ordinary clock with predefined
Master functionality, working as a Master on the link. A WR Slave node/port is an ordinary clock with
predefined Slave functionality, working as a Slave on the link.
A \textit{White Rabbit Switch} (WRSW) is not a PTP-compliant boundary clock. It is considered a set of
ordinary clocks with predefined functionality (WR Master or WR Slave) rather than a clock with multiple
PTP ports. As a consequence, WRPTP messages are never forwarded. A \textit{White Rabbit Timing Receiver}
is an ordinary clock with predefined WR Slave functionality (slave node). Proper performance of a WR network
is ensured by connecting a WR Slave port to a WR Master port.
The following definitions used in this document are introduced in Clause 3.1 of PTP:\\
\textbf{node}: A device that can issue or receive Precision Time Protocol (PTP) communications on a
network.\\
\textbf{boundary clock}: A clock that has multiple Precision Time Protocol (PTP) ports in a domain
and maintains the timescale used in the domain. It may serve as the source of time, i.e., be a
master clock, and may synchronize to another clock, i.e., be a slave clock.\\
\textbf{ordinary clock}: A clock that has a single Precision Time Protocol (PTP) port in a domain
and maintains the timescale used in the domain. It may serve as a source of time, i.e., be a master
clock, or may synchronize to another clock, i.e., be a slave clock.\\
\\
This document introduces the following definitions:\\
\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.\\
\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\\
\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.
Figure~\ref{fig:hybrid-network} depicts the topology of a \emph{hybrid} WR/IEEE1588
network where optimal synchronization with a grandmaster is
achieved by connecting non-WR Slaves to WR Masters.
\begin{figure}[ht!]
\centering
% \vspace{-1.3cm}
\includegraphics[width=0.80\textwidth]{fig/hybrid.ps}
\caption{Hybrid WR/IEEE1588 network. White Rabbit nodes work
transparently with PTP nodes. WR ordinary clock 3 is more accurately
synchronised to the grandmaster than WR ordinary clock 2, which
is below a PTP boundary clock.}
\label{fig:hybrid-network}
\end{figure}
\subsection{WRPTP Data Sets 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 requires additional DS fields to store the WR-specific
parameters. Table~\ref{tab:wrDS} defines and describes the additional required DS fields that are not part of the PTP standard.
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 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.
\begin{table}[ph!]
\caption{WRPTP Data Sets fields}
\centering
\begin{tabular}{| c | c | p{2.5cm} | p{4cm} |} \hline
\begin{tabular}{| c | c | p{2.5cm} | c | } \hline
\textbf{DS member} & \textbf{DS name}&\textbf{Values} & \textbf{Description} \\
& & & \\ \hline
wrPortMode & portDS & NON\_WR, WR\_SLAVE, WR\_MASTER & Determines predefined function of WR port (static). \\ \hline
calibrated & portDS & TRUE, FALSE & Indicates whether fixed delays of the given port are known. \\ \hline
deltaTx & portDS & 64 bit value & Port's $\Delta_{tx}$ measured in picoseconds and multiplied by ${2^{16}}$. \\ \hline
deltaRx & portDS & 64 bit value & Port's $\Delta_{rx}$ measured in picoseconds and multiplied by ${2^{16}}$. \\ \hline
calPeriod & portDS & 32 bit value & Calibration period in microseconds. \\ \hline
calPattern & portDS & 32 bit value & Medium specific calibration pattern. \\ \hline
calPatternLen & portDS & 16 bit value & Number of bits of calPattern to be repeated. \\ \hline
wrMode & portDS & TRUE, FALSE & If TRUE, the port is working in WR mode. \\ \hline
wrAlpha & portDS & 32 bit value & \textit{Medium correlation parameter} as described in section~\ref{sec:singlefiber}. \\ \hline
grandmasterWrPortMode & parentDS & NON\_WR, WR\_SLAVE, WR\_MASTER & Determines predefined function of the PTP grandmaster. \\ \hline
grandmasterDeltaTx & parentDS & 64 bit value & Grandmaster's $\Delta_{tx}$ measured in picoseconds and multiplied by ${2^{16}}$. \\ \hline
grandmasterDeltaRx & parentDS & 64 bit value & Grandmaster's $\Delta_{rx}$ measured in picoseconds and multiplied by ${2^{16}}$. \\ \hline
grandmasterWrMode & parentDS & TRUE, FALSE & If TRUE, the grandmaster is working in WR mode. \\ \hline
\textbf{DS member} & \textbf{DS name}&\textbf{Values}& \textbf{D}ynamic or \textbf{S}tatic
\\
& & &
\\ \hline
wrConfig & portDS & NON\_WR,
WR\_S\_ONLY,
WR\_M\_ONLY
WR\_M\_AND\_S &S \\ \hline
wrMode & portDS & NON\_WR,
WR\_SLAVE,
WR\_MASTER &D \\ \hline
wrModeON & portDS & TRUE, FALSE &D \\ \hline
wrPortState & portDS & Table~\ref{tab:wrFSMdesc} &D \\ \hline
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
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
parentWrConfig & portDS & NON\_WR,
WR\_S\_ONLY,
WR\_M\_ONLY
WR\_M\_AND\_S &D \\ \hline
parentWrMode & portDS & NON\_WR,
WR\_SLAVE,
WR\_MASTER &D \\ \hline
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
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
primarySlavePortNumber & currentDS & 16 bits value &D \\ \hline
\end{tabular}
\label{tab:wrDS}
\end{table}
\newpage
\paragraph{wrConfig} Determines predefined function of a WR port.
\paragraph{wrMode} Determines current WR-role of a WR port which is determined by BMC.
\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{wrPortState} Stores current state of WRPTP state machine (see chapter~\ref{wrFSM}).
\paragraph{calibrated} If true, it indicates that fixed delays of the given port are known.
\paragraph{deltaTx} Port's $\Delta_{tx}$ measured in picoseconds and multiplied by ${2^{16}}$.
\paragraph{deltaRx} Port's $\Delta_{rx}$ measured in picoseconds and multiplied by ${2^{16}}$.
\paragraph{calPeriod} Calibration period in microseconds.
\paragraph{calPattern} Medium specific calibration pattern.
\paragraph{calPatternLen} Number of bits of calPattern to be repeated.
\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{parentWrConfig} Stores the value of wrConfig parameter of the parent port.
\paragraph{parentWrMode} Stores the value of wrMode of the parent port.
\paragraph{parentWrModeON} Stores the value of wrModeON of the parent port.
\paragraph{parentCalibrated} Stores the value of calibrated of the parent port.
\paragraph{parentDeltaTx} Stores the value of deltaTx of the parent port.
\paragraph{parentDeltaRx} Stores the value of deltaRx of the parent port.
\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{parentCalPatternLen} Stores the value of calPatternLen parameter of the parent port.
\subsubsection{backupParentDS data set specifications}
A boundary clock shall maintain an implementation-specific backupParentDS data set for the purpose
of qualifying redundant sources of synchronisation, i.e.:
\begin{itemize}
\item backup paths to the current grandmaster clock, or
\item paths to alternate grandmaster clock(s).
\end{itemize}
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,
\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}).
\subsection{Modified Best Master Clock Algorithm}
\label{sec:wrBMC}
\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
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.
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
(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.
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 Best Master Clock algorithm comprises of State Decision Algorithm (SDA), 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
mentioned.
\subsubsection{State Decision Algorithm}
\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.
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
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
Figure~\ref{fig:modifiedSDA}) and parentDS data set updated (S1), the port's number is
stored in currentDS.primarySlavePortNumber.
\item If the recommended state is $BMC\_SLAVE$ at block-8 or block-13, the master is considered
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.
\end{itemize}
The order of second and lower level best masters determined in this way is used to update
backupParentDS data set.
The Best Master Clock algorithm is used in PTP to compare local clocks, to determine which
clock is the \textit{"best"} and to recommend the next state of the PTP state machine (section 9.3, PTP).
It is required from the modified BMC that the comparison of a WR Master with a WR Slave or
non-WR clock results in the WR Master being the \textit{"best"} clock. To ensure a proper
BMC outcome, the WR Master $clockClass$ value shall be in the range of 1 through 127
(recommended 6) and the WR Slave $clockClass$ shall be in the range of 128 through 255 (recommended 255).
\begin{figure}[ht!]
\centering
\includegraphics[width=0.85\textwidth]{fig/SDA.ps}
\caption{Modified State Decision Algorithm (modifications in red).}
\label{fig:modifiedSDA}
\end{figure}
\newpage
\subsection{WRPTP Messages}
\label{sec:wrMSG}
\subsubsection{Update of Data Sets}
\subsubsection{Overview}
The modifications to the rules governing update of 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.
\end{itemize}
White Rabbit benefits from PTP's messaging facilities. It uses a two-step clock delay
request-response mechanism and customizes Announce and Management messages (Figure~\ref{fig:wrptpMSGs}).
In particular, it adds a suffix to the Announce message, defines a \textit{WR Type-Length-Valu}e
(WR TLV) type, WR management action and management~IDs.
\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} \\
& \\ \hline
currentDS & \\ \hline
currentDS.primarySlavePortNumber & set to 0 \\ \hline
A White Rabbit Master node announces its presence by adding a WR TLV suffix to the Announce message.
The suffix is defined by the PTP standard as a set of TLV entities (section 13.4, PTP). Unrecognized 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 a WR Slave to decide
whether the WR link can be established and maintained. The WR link is established through the WR Link
Setup process in the PTP UNCALIBRATED state. If a WR Link Setup is required, the WR Slave starts
the process and requests 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 Management mechanism extended
for White Rabbit requirements. Once the WR link has been established, the WR nodes use a
PTP delay request-response mechanism (section 11.3, PTP).
\end{tabular}
\label{tab:modifiedM1M2}
\end{table}
\begin{table}[ht!]
\caption{Modification to Table~16 of IEEE1588-2008: Update for state decision code S1.}
\centering
\begin{tabular}{| c | c |} \hline
\textbf{Update this field} & \textbf{From the indicated source} \\
& \\ \hline
currentDS & \\ \hline
currentDS.primarySlavePortNumber & portDS.portIdentity.portNumber \\ \hline
\end{tabular}
\label{tab:modifiedS1}
\end{table}
\subsubsection{WR Type-Length-Value Type}
\begin{table}[ht!]
\caption{Update for state decision code S2}
\centering
\begin{tabular}{| c | c |} \hline
\textbf{Update this field} & \textbf{From the indicated source} \\
& \\ \hline
backupParentDS & \\ \hline
backupParentDS.secondarySlavePortNumber & portDS.portIdentity.portNumber \\ \hline
backupParentDS.backupParentSourcePortIdentity & sourcePortIdentity of $E_{rbest}$ \\ \hline
\end{tabular}
\label{tab:modifiedS2}
\end{table}
\newpage
\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}).
A WR Master 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,
the WR nodes use a PTP delay request-response mechanism (section 11.3, PTP).
\subsubsection{WR Type-Length-Value}
\label{sec:wrTLVtype}
All PTP messages can be extended by means of a standard \textit{type, length, value} (TLV) extension mechanism.
White Rabbit defines the value of TLV type out of the range reserved for Experimental TLVs (Table 34, PTP)
as depicted in Table~\ref{tab:wrTLVtype}. This value is used to recognize the WR TLV entity in all WR custom messages.
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}.
\begin{table}[ht]
\caption{White Rabbit Type-Length-Value (WR TLV) type }
\begin{table}[h!]
\caption{Organization specific TLV fields for WR (see Table~35, PTP).}
\centering
\begin{tabular}{| c | c | c |} \hline
\textbf{tlvType values} & \textbf{Value (hex)} & \textbf{Defined in clause} \\
& & \\ \hline
White Rabbit TLV (WR TLV type) & 0x2004 & --- \\ \hline
\begin{tabular}{| c | c | c | c | c | c | c | c | c | c |c| p{4.3cm} |}
\hline
\multicolumn{8}{|c|}{\textbf{Bits}} & \textbf{Octets} & \textbf{TLV} & \textbf{WR TLV} & \\
%\hline
\cline{0-7}
7 & 6 & 5 & 4 & 3 & 2 & 1 & 0 & & \textbf{Offset} & \textbf{Content} & \textbf{Description} \\
\hline
\multicolumn{8}{|c|}{tlvType } & 2 & 0 & 0x0003 & Organization extension,
see Table~34 PTP. \\ \hline
\multicolumn{8}{|c|}{lengthField } & 2 & 2 & 8+N & N is an even number of wrDataField
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
within protocols identified by CERN's OUI. \\
\cline{9-12} %\hline
\multicolumn{8}{|c|}{} & 1 & 9 & versionNumber& 0x01 - WRPTP version.\\
\hline
\multicolumn{8}{|c|}{DataField} & 2 & 10 & wrMessageID & WR-specific messages identifier,
see Table~\ref{tab:wrMessageId}. \\
\cline{9-12} %\hline
\multicolumn{8}{|c|}{ } & N & 12 & wrDataField & Content of WR-specific message. \\
\hline
\end{tabular}
\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.
\begin{table}[ht!]
\caption{White Rabbit Message ID values}
\centering
\begin{tabular}{| l | p{2.5cm} | c | c |} \hline
\textbf{managementId name} & \textbf{wrMessageId value (hex)} & \textbf{Sent in message type} \\
& & \\ \hline
SLAVE\_PRESENT & 0x1000 & Signaling \\ \hline
LOCK & 0x1001 & Signaling \\ \hline
LOCKED & 0x1002 & Signaling \\ \hline
CALIBRATE & 0x1003 & Signaling \\ \hline
CALIBRATED & 0x1004 & Signaling \\ \hline
WR\_MODE\_ON & 0x1005 & Signaling \\ \hline
ANN\_SUFIX & 0x2000 & Announce \\ \hline
\end{tabular}
\label{tab:wrMessageId}
\end{table}
\subsubsection{WRPTP Announce Message}
\label{sec:wrAnnounceMSG}
The standard PTP Announce Message is suffixed by one entity of the data type TLV with the tlvType of WR TLV.
The WRPTP Announce message has the structure defined in Table~\ref{tab:wrAnnounce}. The $dataField$ of the suffix
TLV stores the $wrFlags$ which are defined in Table~\ref{tab:wrFlags}.
The standard PTP Announce Message is suffixed by one entity of WR TLV.
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}.
\begin{table}[h!]
\caption{White Rabbit Announce Message}
......@@ -572,11 +869,15 @@ TLV stores the $wrFlags$ which are defined in Table~\ref{tab:wrFlags}.
\cline{0-7}
7 & 6 & 5 & 4 & 3 & 2 & 1 & 0 & & \textbf{Offset} & \\
\hline
\multicolumn{8}{|c|}{header } & 34 & 0 & section 13.3, PTP. \\ \hline
\multicolumn{8}{|c|}{body } & 30 & 34 & section 13.5, PTP. \\ \hline
\multicolumn{8}{|c|}{tlvType } & 2 & 64 & 0x2004, see \ref{sec:wrTLVtype}. \\ \hline
\multicolumn{8}{|c|}{lengthField } & 2 & 66 & 0x2, section 14.1.2, PTP. \\ \hline
\multicolumn{8}{|c|}{wrFlags } & 2 & 68 & see Table~\ref{tab:wrFlags}. \\ \hline
\multicolumn{8}{|c|}{header } & 34 & 0 & section 13.3, PTP. \\ \hline
\multicolumn{8}{|c|}{body } & 30 & 34 & section 13.5, PTP. \\ \hline
\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|}{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
\end{tabular}
\label{tab:wrAnnounce}
\end{table}
......@@ -589,10 +890,15 @@ TLV stores the $wrFlags$ which are defined in Table~\ref{tab:wrFlags}.
\textbf{Octet} &\textbf{Bit} & \textbf{Message type} & \textbf{Name} & \textbf{Description} \\
& & & & \\ \hline
0 &0 & Announce & wrMaster & TRUE if the port of the originator is predefined WR Master.\\ \hline
0 &1 & Announce & wrSlave & TRUE if the port of the originator is predefined WR Slave.\\ \hline
0 &2 & Announce & calibrated & TRUE if the port of the originator is calibrated.\\ \hline
0 &3 & Announce & wrModeOn & TRUE if the port of the originator is in WR mode.\\ \hline
0 &0 & \multirow{2}{*}{Announce} & \multirow{2}{*}{wrConfig} &
\multirow{2}{5.3cm}{The value of wrConfig parameter from portDS.} \\ \cline{1-2}
0 &1 & & &\\ \hline
0 &2 & Announce & calibrated & TRUE if the source port
is calibrated.\\
\hline
0 &3 & Announce & wrModeON & The value of wrModeON
parameter of portDS.\\
\hline
\end{tabular}
\label{tab:wrFlags}
\end{table}
......@@ -600,21 +906,25 @@ TLV stores the $wrFlags$ which are defined in Table~\ref{tab:wrFlags}.
\newpage
\subsubsection{WRPTP Management Messages}
\label{wrManagementMSG}
\subsubsection{WRPTP Signaling Messages}
\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.
White Rabbit extends the default PTP management mechanism described in section 15.2 of PTP.
The extension conforms to the PTP management message format presented in Table~\ref{tab:wrManagementMSG}.
It uses the reserved range of \textit{actionField} values (Table 38, PTP) to define a
\textit{White Rabbit Command} (WRC) as described in Table~\ref{tab:wrActionField}.
WRC management messages trigger transitions in WR state machines. They are recognized by the \textit{managementId}
field of \textit{managementTLV} (Table~\ref{tab:wrOtherTLV}, \ref{tab:wrCalibrateTLV} \& \ref{tab:wrCalibratedTLV}).
WR \textit{management IDs} are defined in Table~\ref{tab:wrManagementId}. WRPTP management messages are
exchanged only within one link connection (no forwarding), therefore the \textit{startingBoundaryHops} and
\textit{boundaryHops} fields are unused and set to 0x0. The rest of this subsection describes the WR management messages in detail.
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).
Signaling Message are used in WRPTP to trigger transitions in WR state machines 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.
The rest of this subsection describes the WRPTP Signaling Messages in details.
\begin{table}[h!]
\caption{PTP Management Message (Table 37, PTP) }
\caption{PTP Signaling message fields (Table 33, PTP) }
\centering
\begin{tabular}{| c | c | c | c | c | c | c | c | c | c |}
\hline
......@@ -625,111 +935,91 @@ exchanged only within one link connection (no forwarding), therefore the \textit
\hline
\multicolumn{8}{|c|}{header } & 34 & 0 \\ \hline
\multicolumn{8}{|c|}{targetPortIdentity } & 10 & 34 \\ \hline
\multicolumn{8}{|c|}{startingBoundaryHops } & 1 & 44 \\ \hline
\multicolumn{8}{|c|}{boundaryHops } & 1 & 45 \\ \hline
\multicolumn{4}{|c|}{reserved } &
\multicolumn{4}{|c|}{actionField } & 1 & 46 \\ \hline
\multicolumn{8}{|c|}{reserved } & 1 & 47 \\ \hline
\multicolumn{8}{|c|}{managementTLV } & M & 48 \\ \hline
\multicolumn{8}{|c|}{WR TLV } & M & 44 \\ \hline
\end{tabular}
\label{tab:wrManagementMSG}
\label{tab:wrSignalingMSG}
\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{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}.
\begin{table}[ht!]
\caption{White Rabbit value of the actionField}
\centering
\begin{tabular}{| c | p{7.9cm} | c |} \hline
\textbf{Action} & \textbf{Action taken} & \textbf{Value (hex)} \\
& & \\ \hline
WR\_CMD & The management message shall carry a single TLV. The \textit{managementId}
field of the TLV indicates the specific event which triggers transition in WR FSMs. & 0x5 \\ \hline
\end{tabular}
\label{tab:wrActionField}
\end{table}
\begin{table}[ht!]
\caption{White Rabbit managementId values}
\centering
\begin{tabular}{| l | p{2.5cm} | c | c | c |} \hline
\textbf{managementId name} & \textbf{managementId value (hex)} & \textbf{Allowed actions} & \textbf{Applies to} \\
& & & \\ \hline
SLAVE\_PRESENT & 0x6000 & WR\_CMD & port \\ \hline
LOCK & 0x6001 & WR\_CMD & port \\ \hline
LOCKED & 0x6002 & WR\_CMD & port \\ \hline
CALIBRATE & 0x6003 & WR\_CMD & port \\ \hline
CALIBRATED & 0x6004 & WR\_CMD & port \\ \hline
WR\_MODE\_ON & 0x6005 & WR\_CMD & port \\ \hline
\end{tabular}
\label{tab:wrManagementId}
\end{table}
\paragraph{LOCKED} Message sent by the WR Slave to the WR Master. It indicates successful
completion of frequency locking. The message shall have the format specified in
Table~\ref{tab:wrOtherTLV}.
\newpage
\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{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 completion of frequency locking.
The message shall have the format specified in Table~\ref{tab:wrOtherTLV}.
\begin{table}[h!]
\caption{WR Management TLV}
\caption{WR TLV for SLAVE\_PRESENT, LOCK, LOCKED AND WR\_MODE\_ON Signaling Messages.}
\centering
\begin{tabular}{| c | c | c | c | c | c | c | c | c | c | p{4.5cm} |}
\begin{tabular}{| c | c | c | c | c | c | c | c | c | c | p{4.5cm} |}
\hline
\multicolumn{8}{|c|}{\textbf{Bits}} & \textbf{Octets} & \textbf{TLV} &\\
\multicolumn{8}{|c|}{\textbf{Bits}} & \textbf{Octets} & \textbf{TLV} & \textbf{Content} \\
%\hline
\cline{0-7}
7 & 6 & 5 & 4 & 3 & 2 & 1 & 0 & & \textbf{Offset} & \textbf{Content} \\
7 & 6 & 5 & 4 & 3 & 2 & 1 & 0 & & \textbf{Offset} & \\
\hline
\multicolumn{8}{|c|}{tlvType } & 2 & 0 & 0x2004, see \ref{sec:wrTLVtype}. \\ \hline
\multicolumn{8}{|c|}{lengthField } & 2 & 2 & 0x2, section 15.5.2.3, PTP. \\ \hline
\multicolumn{8}{|c|}{managementId } & 2 & 4 & Defined in Table~\ref{tab:wrManagementId}.\\ \hline
\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|}{versionNumber } & 1 & 9 & 0x01. \\ \hline
\multicolumn{8}{|c|}{wrMessageId } & 2 & 10 & Defined in Table~\ref{tab:wrMessageId}.\\ \hline
\end{tabular}
\label{tab:wrOtherTLV}
\end{table}
\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
Table~\ref{tab:wrCalibrateTLV}.
\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 Table~\ref{tab:wrCalibrateTLV}.
\begin{table}[h!]
\caption{CALIBRATE WR Management TLV}
\caption{WR TLV CALIBRATE Signaling Message }
\centering
\begin{tabular}{| c | c | c | c | c | c | c | c | c | c | p{5cm} |}
\begin{tabular}{| c | c | c | c | c | c | c | c | c | c | p{7.5cm} |}
\hline
\multicolumn{8}{|c|}{\textbf{Bits}} & \textbf{Octets} & \textbf{TLV} &\\
\multicolumn{8}{|c|}{\textbf{Bits}} & \textbf{Octets} & \textbf{TLV} & \textbf{Content} \\
%\hline
\cline{0-7}
7 & 6 & 5 & 4 & 3 & 2 & 1 & 0 & & \textbf{Offset} & \textbf{Content} \\
7 & 6 & 5 & 4 & 3 & 2 & 1 & 0 & & \textbf{Offset} & \\
\hline
\multicolumn{8}{|c|}{tlvType } & 2 & 0 & 0x2004, see \ref{sec:wrTLVtype}. \\ \hline
\multicolumn{8}{|c|}{lengthField } & 2 & 2 & 0xC, section 15.5.2.3 PTP.\\ \hline
\multicolumn{8}{|c|}{managementId } & 2 & 4 & CALIBRATE.\\ \hline
\multicolumn{8}{|c|}{calibrationSendPattern}& 2 & 6 & The value determines whether calibration pattern should be sent. If the value is 0x1, the calibration pattern is sent. If the value is 0x0, the calibration pattern is not sent. \\ \hline
\multicolumn{8}{|c|}{calibrationPeriod} & 4 & 8 & 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 & 12 & The value defines the calibration pattern which should be sent by the receiving node.\\ \hline
\multicolumn{8}{|c|}{calibrationPatternLen} & 2 & 14 & 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|}{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|}{versionNumber } & 1 & 9 & 0x01. \\ \hline
\multicolumn{8}{|c|}{wrMessageId } & 2 & 10 & CALIBRATE. \\ \hline
\multicolumn{8}{|c|}{calibrationSendPattern} & 2 & 12 & The value determines whether calibration
pattern should be sent. If the value
is 0x1, the calibration pattern is sent. If
the value is 0x0, the calibration pattern is
not sent. \\ \hline
\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
\end{tabular}
\label{tab:wrCalibrateTLV}
\end{table}
\newpage
......@@ -741,20 +1031,27 @@ values of its fixed delays ($\Delta_{tx}$ and $\Delta_{rx}$).
The message shall have the format specified in Table~\ref{tab:wrCalibratedTLV}.
\begin{table}[ht]
\caption{CALIBRATED WR Management TLV}
\caption{WR TLV for CALIBRATED Signaling Message.}
\centering
\begin{tabular}{| c | c | c | c | c | c | c | c | c | c | p{4.5cm} |}
\begin{tabular}{| c | c | c | c | c | c | c | c | c | c | p{7.5cm} |}
\hline
\multicolumn{8}{|c|}{\textbf{Bits}} & \textbf{Octets} & \textbf{TLV} &\\
%\hline
\cline{0-7}
7 & 6 & 5 & 4 & 3 & 2 & 1 & 0 & & \textbf{Offset} & \textbf{Content} \\
\hline
\multicolumn{8}{|c|}{tlvType } & 2 & 0 & 0x2004, see \ref{sec:wrTLVtype}. \\ \hline
\multicolumn{8}{|c|}{lengthField } & 2 & 2 & 0x24, section 15.5.2.3 IEEE1588 \cite{IEEE1588}. \\ \hline
\multicolumn{8}{|c|}{managementId } & 2 & 4 & CALIBRATED.\\ \hline
\multicolumn{8}{|c|}{deltaTx } & 16 & 6 & The value of $\Delta_{tx_m}$ measured in picoseconds and multiplied by ${2^{16}}$.\\ \hline
\multicolumn{8}{|c|}{deltaRx } & 16 & 22 & The value of $\Delta_{rx_m}$ measured in picoseconds and multiplied by ${2^{16}}$.\\ \hline
\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|}{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
picoseconds and multiplied by ${2^{16}}$.\\
\hline
\multicolumn{8}{|c|}{deltaRx } & 16 & 28 & The value of $\Delta_{rx_m}$ measured in
picoseconds and multiplied by ${2^{16}}$.\\
\hline
\end{tabular}
\label{tab:wrCalibratedTLV}
\end{table}
......@@ -762,10 +1059,50 @@ 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
\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}.
\newpage
\subsection{PTP State Machine}
\label{ptpStateMachine}
The WR Link Setup (WR state machine) is performed in the PTP\_UNCALIBRATED state of 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 introduces new state transition event to the original PTP state machine:
\textit{CALIBRATION\_FORCED\_BY\_SLAVE}. It is depicted in red (number 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.
\begin{figure}[ht!]
\centering
\includegraphics[width=0.85\textwidth]{fig/modifiedPtpFSM.ps}
\caption{Modified PTP Finite State Machine.}
\label{fig:modifiedPtpFSM}
\end{figure}
\newpage
\subsection{White Rabbit State Machine}
\label{wrFSM}
......@@ -773,30 +1110,43 @@ The White Rabbit finite state machine (WR FSM) controls the process of establish
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
executed in the PTP UNCALIBRATED state, it is depicted in Figure~\ref{fig:wrFSM} and described in the rest of
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.
A typical flow of a complete WR Management Message exchange between a WR Slave and a WR Master during WR Link Setup is presented
in Appendix~\ref{ap:wr_lsu_flow}.
A typical flow of a complete WR Signalin 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}.
\subsubsection{Condition to start the WR FSM by WR Slave}
\label{sec:wrSlaveFSMstart}
The WR FSM in a WR Slave exits the IDLE state and starts execution by entering the \textit{PRESENT} state, only when the PTP state machine (Appendix~\ref{ptpFSM})
is in the PTP UNCALIBRATED state and the following conditions are met:
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:
\begin{itemize}
\item the node is a WR Slave: \\ ($portDS.wrPortMode = WR\_SLAVE$) \textbf{AND}
\item the parent node is a WR Master: \\ ($parentDS.grandmasterWrPortMode = WR\_MASTER$) \textbf{AND}
\item the node or parent node or both nodes are not in WR Mode: \\ (\textit{portDS.wrMode = FALSE OR parentDS.grandmasterWrMode = FALSE}).
\item the port is WR Slave-enabled: \\
\textit{portDS.portWrConfig = ($WR\_S\_ONLY$ \textbf{OR} $WR\_M\_AND\_S$)} \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}
\label{sec:wrMasterFSMstart}
The WR Master node shall enter the PTP UNCALIBRATED state, and start execution of the WR FSM by entering the \textit{LOCK} state, when it receives a SLAVE\_PRESENT WR Management message (Table~\ref{tab:wrManagementId}).
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}).
\newpage
......@@ -813,23 +1163,42 @@ Table~\ref{tab:wrFSMdesc} specifies the WR states notation used in Figure~\ref{f
\textbf{PTP portState} & \textbf{Description} \\
& \\ \hline
\small
IDLE & The WR FSM shall be in the IDLE state if the PTP FSM is in a state other than UNCALIBRATED. \\ \hline
PRESENT & Slave-only state. The WR Slave sends a SLAVE\_PRESENT message to the WR Master and waits for the $LOCK$ message.\\ \hline
M\_LOCK & Master-only state. The WR master waits for the WR Slave to finish successfully the locking process. \\ \hline
S\_LOCK & Slave-only state. The WR Slave locks its logic to the frequency distributed over physical layer by the WR Master. \\ \hline
LOCKED & Slave-only state. The WR Slave is syntonized, it sends a \textit{LOCKED} message to the WR Master and waits for the \textit{CALIBRATE} message. \\ \hline
REQ\_CALIBRATION & In this state, optional calibration of the node's reception fixed delay can be performed.
The node sends a \textit{CALIBRATE} message to the other node. If the calibration is needed,
(\textit{calibrated} is set to false), the \textit{calibrationSendPattern} flag in the \textit{CALIBRATE} message
is sent to TRUE (0x1). If the calibration is not needed, the \textit{calibrationSendPattern} flag is set to FALSE (0x0).
If calibration is not needed, the next state is entered directly, otherwise an indication from the hardware
IDLE & The WR FSM shall be in the IDLE state if the PTP FSM is in a state other than
UNCALIBRATED. \\ \hline
PRESENT & Slave-only state. The WR Slave sends a SLAVE\_PRESENT message to the WR
Master and waits for the $LOCK$ message.\\ \hline
M\_LOCK & Master-only state. The WR master waits for the WR Slave to finish
successfully the locking process. \\ \hline
S\_LOCK & Slave-only state. The WR Slave locks its logic to the frequency distributed
over physical layer by the WR Master. \\ \hline
LOCKED & Slave-only state. The WR Slave is syntonized, it sends a \textit{LOCKED}
message to the WR Master and waits for the \textit{CALIBRATE} message. \\
\hline
REQ\_CALIBRATION & In this state, optional calibration of the node's reception fixed delay can
be performed.
The node sends a \textit{CALIBRATE} message to the other node. If the
calibration is needed,
(\textit{calibrated} is set to false), the \textit{calibrationSendPattern}
flag in the \textit{CALIBRATE} message
is sent to TRUE (0x1). If the calibration is not needed, the
\textit{calibrationSendPattern} flag is set to FALSE (0x0).
If calibration is not needed, the next state is entered directly, otherwise an
indication from the hardware
that the calibration has been finished successfully is awaited. \\ \hline
CALIBRATED & The node sends a \text{CALIBRATED} message with information about its fixed delays. \\ \hline
RESP\_CALIB\_REQ & The node's action in this state depends on the value of the \textit{calibrationSendPattern} flag received in the \textit{CALIBRATE} message. A TRUE value of the flag
indicates that the calibration pattern shall be enabled. The pattern shall be disabled after \textit{calibrationPeriod}
or on reception of the \textit{CALIBRATED} message. If the value of the \textit{calibrationSendPattern} flag is FALSE,
the \textit{CALIBRATED} message is awaited for a default timeout. On reception of the \textit{CALIBRATED} message, the next state is entered.\\ \hline
WR\_LINK\_ON & The value of \textit{wrMode} is set to TRUE and the \textit{IDLE} state is entered. \\ \hline
CALIBRATED & The node sends a \text{CALIBRATED} message with information about its fixed
delays. \\ \hline
RESP\_CALIB\_REQ & The node's action in this state depends on the value of the
\textit{calibrationSendPattern} flag received in the \textit{CALIBRATE}
message. A TRUE value of the flag
indicates that the calibration pattern shall be enabled. The pattern shall be
disabled after \textit{calibrationPeriod}
or on reception of the \textit{CALIBRATED} message. If the value of the
\textit{calibrationSendPattern} flag is FALSE,
the \textit{CALIBRATED} message is awaited for a default timeout. On
reception of the \textit{CALIBRATED} message, the next state is entered.\\
\hline
WR\_LINK\_ON & The value of \textit{wrMode} is set to TRUE and the \textit{IDLE} state is
entered. \\ \hline
\end{tabular}
\label{tab:wrFSMdesc}
\end{table}
......@@ -856,30 +1225,106 @@ WR\_LINK\_ON & The value of \textit{wrMode} is set to TRUE and the \texti
\begin{description}
\item[]
\item[POWERUP] Turning on power to the device or reseting.
\item[WR LINK SETUP REQUIRED DECISION] (abrv. D\_WR\_SETUP\_REQ) Event indicating that a WR Link Setup is required and that the WR FSM should be executed starting at the
\textit{PRESENT} state, see section~\ref{sec:wrSlaveFSMstart}.
\item[LOCK MESSAGE] (abrv. M\_LOCK) WR $LOCK$ Management message which triggers frequency locking over the physical layer.
\item[LOCKED HARDWARE EVENT] (abrv. HW\_LOCKED) Indication from the hardware that frequency locking has been completed successfully.
\item[LOCKED MESSAGE] (abrv. M\_LOCKED) WR $LOCKED$ Management message which notifies the WR Master that frequency locking has been completed
\item[WR LINK SETUP REQUIRED DECISION] (abrv. D\_WR\_SETUP\_REQ) Event indicating that a WR
Link Setup is required and that the WR FSM should be executed starting at the
\textit{PRESENT} state, see section~\ref{sec:wrSlaveFSMstart}.
\item[LOCK MESSAGE] (abrv. M\_LOCK) WR $LOCK$ Management message
which triggers frequency locking over the physical layer.
\item[LOCKED HARDWARE EVENT] (abrv. HW\_LOCKED) Indication from the hardware
that frequency locking has been completed successfully.
\item[LOCKED MESSAGE] (abrv. M\_LOCKED) WR $LOCKED$ Management
message which notifies the WR Master that frequency locking has been completed
successfully by the WR Slave.
\item[CALIBRATE MESSAGE] (abrv. M\_CALIBRATE) WR $CALIBRATE$ Management message. It requests the recipient to enter the
\textit{RESP\_CALIB\_REQ} state, indicates whether sending of the calibration pattern is required and
provides calibration parameters.
\item[CALIBRATED HARDWARE EVENT] (abrv. HW\_CALIBRATE) Notification from the hardware indicating that calibration has been completed successfully.
\item[CALIBRATED MESSAGE] (abrv. M\_CALIBRATED) WR \text{CALIBRATED} Management message. It indicates that the node is calibrated.
If the \textit{CALIBRATED} message is received when the calibration pattern is being sent by the recipient,
sending of the pattern shall be disabled. The message carries information about fixed delays of the sending node.
\item[WR MODE ON] (abrv. M\_WR\_MODE\_ON) WR \textit{WR\_MODE\_ON} Management message. It indicates that the WR Master finished successfully
the WR Link Setup and set the \text{wrMode} flag to TRUE. It requests the WR Slave to set the \text{wrMode} flag to TRUE.
\item[RETRY $n_{name}$] The White Rabbit state machine waits in a given state for a transition event only for a limited time (\textit{TIMEOUT})
The states to which this rule applies are the following: \textit{M\_LOCK},
\textit{REQ\_CALIBRATEION}, \textit{CALIBRATED}, \textit{PRESENT}, \textit{S\_LOCK},
\textit{LOCKED}, \textit{RESP\_CALIB\_REQ}. After the \textit{TIMEOUT} expires, the state is re-entered for \\
$n_{\{M\_LOCK, REQ\_CAL, CALIBed, PRESENT, S\_LOCK, LOCKED, RESP\_CALIB\_RESP\}}$ number of times.
\item[EXCEED TIMEOUT RETRIES] (abrv. EXC\_TIMEOUT\_RETRY) Indicates that the state has been re-entered for a set number of times \\($n_{\{M\_LOCK, REQ\_CAL, CALIBed, PRESENT, S\_LOCK, LOCKED, RESP\_CALIB\_RESP\}}$) and the \textit{TIMEOUT} has expired for the $n + 1$ time.
\item[CALIBRATE MESSAGE] (abrv. M\_CALIBRATE) WR $CALIBRATE$ Management
message. It requests the recipient to enter the
\textit{RESP\_CALIB\_REQ} state, indicates whether sending of the calibration pattern is
required and provides calibration parameters.
\item[CALIBRATED HARDWARE EVENT] (abrv. HW\_CALIBRATE) Notification from the
hardware indicating that calibration has been completed successfully.
\item[CALIBRATED MESSAGE] (abrv. M\_CALIBRATED) WR \text{CALIBRATED}
Management message. It indicates that the node is calibrated. If the \textit{CALIBRATED}
message is received when the calibration pattern is being sent by the recipient,
sending of the pattern shall be disabled. The message carries information about fixed delays
of the sending node.
\item[WR MODE ON] (abrv. M\_WR\_MODE\_ON) WR \textit{WR\_MODE\_ON}
Management message. It indicates that the WR Master finished successfully the WR Link Setup
and set the \text{wrMode} flag to TRUE. It requests the WR Slave to set the \text{wrMode} flag
to TRUE.
\item[RETRY $n_{name}$] The White Rabbit state
machine waits in a given state for a transition event only for a limited time
(\textit{TIMEOUT}) The states to which this rule applies are the following: \textit{M\_LOCK},
\textit{REQ\_CALIBRATEION}, \textit{CALIBRATED}, \textit{PRESENT}, \textit{S\_LOCK},
\textit{LOCKED},\textit{RESP\_CALIB\_REQ}. After the \textit{TIMEOUT} expires, the state is
re-entered for \\ $n_{\{M\_LOCK, REQ\_CAL,
CALIBed, PRESENT, S\_LOCK, LOCKED, RESP\_CALIB\_RESP\}}$ number of times.
\item[EXCEED TIMEOUT RETRIES] (abrv. EXC\_TIMEOUT\_RETRY) Indicates that the state
has been re-entered for a set number of times \\($n_{\{M\_LOCK, REQ\_CAL, CALIBed, PRESENT,
S\_LOCK, LOCKED, RESP\_CALIB\_RESP\}}$) and the \textit{TIMEOUT} has expired for the $n + 1$
time.
\end{description}
\newpage
\subsection{White Rabbit PTP Profile Summary}
\subsubsection{Identification}
\begin{table}[ht!]
\caption{Profile print form (clause 19.3.3 of PTP)}
\centering
\begin{tabular}{| c | c |} \hline
\multicolumn{2}{|c|}{\textbf{PTP Profile}} \\ \hline
prifleName & White Rabbit \\ \hline
profileVersion & 1.0 \\ \hline
profileIdentifier & 08-00-03-00-01-00 \\ \hline
organizationName & European Organization for Nuclear Research (CERN) \\ \hline
sourceIdentification & http://www.ohwr.org/projects/white-rabbit \\ \hline
\end{tabular}
\label{tab:wrPtpProfile}
\end{table}
\subsubsection{PTP attribute values}
All nodes shall support the ranges and shall have the default initialization values for
the attributes as follows:
\begin{itemize}
\item portDS.logSyncInterval: The default initialization value shall be 0. The configuration range
shall be -1 to 6.
\item defaultDS.priority1: The default initialization value shall be 64.
\end{itemize}
\subsubsection{PTP Optins}
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 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 TLV mechanism described in Chapter~\ref{sec:wrMSG} shall be supported.
\subsection{WRPTP Extensions to PTP}
WRPTP extends PTP by adding state transition event defined in subchapter~\ref{ptpStateMachine}.
\subsection{Implementation-specific additions to PTP required by WRPTP}
WRPTP shell implement 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 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}.
\end{itemize}
\newpage
......@@ -892,12 +1337,16 @@ WR\_LINK\_ON & The value of \textit{wrMode} is set to TRUE and the \texti
\section{PTP State Machine}
\label{ptpFSM}
\begin{figure}[ht!]
\centering
\includegraphics[width=0.85\textwidth]{fig/ptpFSM.ps}
\caption{State machine for a full implementation of PTP (Figure 23, IEEE1588).}
\label{fig:ptpFSM}
\end{figure}
\begin{figure}[ht!]
\centering
\includegraphics[width=0.85\textwidth]{fig/ptpFSM.ps}
\caption{State machine for a full implementation of PTP (Figure 23, IEEE1588).}
\label{fig:ptpFSM}
\end{figure}
\newpage
\begin{table}[hp!]
\caption{PTP portState definition (Table 10, IEEE1588).}
......@@ -906,34 +1355,56 @@ WR\_LINK\_ON & The value of \textit{wrMode} is set to TRUE and the \texti
\textbf{PTP portState} & \textbf{Description} \\
& \\ \hline
\small
INITIALIZING & \small While a port is in the INITIALIZING state, the port initializes its data sets, hardware, and
communication facilities. No port of the clock shall place any PTP messages on its
communication path. If one port of a boundary clock is in the INITIALIZING state, then all ports
INITIALIZING & \small While a port is in the INITIALIZING state, the port initializes its
data sets, hardware, and
communication facilities. No port of the clock shall place any PTP messages
on its
communication path. If one port of a boundary clock is in the INITIALIZING
state, then all ports
shall be in the INITIALIZING state. \\ \hline
FAULTY & \small The fault state of the protocol. A port in this state shall not place any PTP messages except for
management messages that are a required response to another management message on its
communication path. In a boundary clock, no activity on a faulty port shall affect the other ports
of the device. If fault activity on a port in this state cannot be confined to the faulty port, then all
FAULTY & \small The fault state of the protocol. A port in this state shall not place
any PTP messages except for
management messages that are a required response to another management
message on its
communication path. In a boundary clock, no activity on a faulty port
shall affect the other ports
of the device. If fault activity on a port in this state cannot be confined
to the faulty port, then all
ports shall be in the FAULTY state. \\ \hline
DISABLED & \small The port shall not place any messages on its communication path. In a boundary clock, no
activity at the port shall be allowed to affect the activity at any other port of the boundary clock.
A port in this state shall discard all PTP received messages except for management messages. \\ \hline
LISTENING & \small The port is waiting for the announceReceiptTimeout to expire or to receive an Announce
message from a master. The purpose of this state is to allow orderly addition of clocks to a
domain. A port in this state shall not place any PTP messages on its communication path except
for Pdelay\_Req, Pdelay\_Resp, Pdelay\_Resp\_Follow\_Up, or signaling messages, or management
DISABLED & \small The port shall not place any messages on its communication path. In a
boundary clock, no
activity at the port shall be allowed to affect the activity at any other
port of the boundary clock.
A port in this state shall discard all PTP received messages except for
management messages. \\ \hline
LISTENING & \small The port is waiting for the announceReceiptTimeout to expire or to
receive an Announce
message from a master. The purpose of this state is to allow orderly addition
of clocks to a
domain. A port in this state shall not place any PTP messages on its
communication path except
for Pdelay\_Req, Pdelay\_Resp, Pdelay\_Resp\_Follow\_Up, or signaling
messages, or management
messages that are a required response to another management message. \\ \hline
PRE\_MASTER & \small The port shall behave in all respects as though it were in the MASTER state except that it shall
not place any messages on its communication path except for Pdelay\_Req, Pdelay\_Resp,
PRE\_MASTER & \small The port shall behave in all respects as though it were in the
MASTER state except that it shall
not place any messages on its communication path except for Pdelay\_Req,
Pdelay\_Resp,
Pdelay\_Resp\_Follow\_Up, signaling, or management messages. \\ \hline
MASTER & \small The port is behaving as a master port. \\ \hline
PASSIVE & \small The port shall not place any messages on its communication path except for Pdelay\_Req,
Pdelay\_Resp, Pdelay\_Resp\_Follow\_Up, or signaling messages, or management messages that
PASSIVE & \small The port shall not place any messages on its communication path except
for Pdelay\_Req,
Pdelay\_Resp, Pdelay\_Resp\_Follow\_Up, or signaling messages, or management
messages that
are a required response to another management message.\\ \hline
UNCALIBRATED & \small One or more master ports have been detected in the domain. The appropriate master port has
been selected, and the local port is preparing to synchronize to the selected master port. This is a
transient state to allow initialization of synchronization servos, updating of data sets when a new
master port has been selected, and other implementation-specific activity. \\ \hline
UNCALIBRATED & \small One or more master ports have been detected in the domain. The
appropriate master port has
been selected, and the local port is preparing to synchronize to the selected
master port. This is a
transient state to allow initialization of synchronization servos, updating of
data sets when a new
master port has been selected, and other implementation-specific activity.
\\ \hline
SLAVE & \small The port is synchronizing to the selected master port. \\ \hline
\end{tabular}
\label{tab:ptp_port_state_def}
......@@ -957,20 +1428,22 @@ 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.
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.
\begin{figure}[ht!]
\centering
\includegraphics[width=0.60\textwidth]{fig/calibrate.ps}
\caption{Measurement of fixed delays $\Delta_{\{tx, rx\}}$ in Gigabit Ethernet-based WR node with not fully-deterministic PHY.}
\caption{Measurement of fixed delays $\Delta_{\{tx, rx\}}$ in Gigabit Ethernet-based WR node with
not fully-deterministic PHY.}
\label{fig:wrCalibration}
\end{figure}
Measurement of fixed delays for Gigabit Ethernet over optic fiber, and any other medium, is optional.
It is not needed if deterministic PHYs or internal FPGA transceivers which can be internally
characterized \cite{Peek2010} are used. In such case, the information about the fixed delays is distributed across
the link without preceding measurement.
characterized \cite{Peek2010} are used. In such case, the information about the fixed delays is
distributed across the link without preceding measurement.
\newpage
......@@ -986,11 +1459,27 @@ the link without preceding measurement.
\newpage
\section{PTP and WR FSMs from POWER ON use case}
\label{ap:ptpAndWrFSMS}
\begin{figure}[ht!]
\centering
% \vspace{-1.3cm}
\includegraphics[width=1.0\textwidth]{fig/ptpAndWrFSMs.ps}
\caption{PTP and WR FSMs from POWER ON use case}
\label{fig:wrFSMcommun}
\end{figure}
\newpage
\begin{thebibliography}{9}
\bibitem{IEEE1588}
IEEE Std 1588-2008
\emph{IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems}.
\emph{IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and
Control Systems}.
IEEE Instrumentation and Measurement Society, New York,
2008,
http://ieee1588.nist.gov/.
......@@ -1002,6 +1491,12 @@ the link without preceding measurement.
2010,\\
http://www.nikhef.nl/pub/services/biblio/technicalreports/ETR2010-01.pdf.
\bibitem{Takahide}
Takahide Murakami and Yukio Horiuchi,
\emph{A Master Redundancy Technique in IEEE 1588 Synchronization with a Link Congestion
Estimation}.
ISPCS Proccedings,
2010,\\
\end{thebibliography}
......
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