%
% wrspec.tex
%
% White Rabbit Spec. Currently an informal draft.
%
% best master clock algorithm 6.6.2.3
% domain number, profiles 7.1, annex J (p. 237)
% asymmetry 6.2.c, 7.4.2 (positive if t_MS > t_SM)
%

\documentclass[a4paper, 12pt]{article}
%\documentclass{article}

\usepackage{fullpage}
\usepackage{pgf}
\usepackage{tikz}
\usetikzlibrary{arrows,automata,shapes}


\usepackage[latin1]{inputenc}
\usepackage{verbatim}
\usepackage{amsmath}
\usepackage{times,mathptmx}
\usepackage{chngcntr}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% creating subsubsubsection notation
% src: http://www.latex-community.org/forum/viewtopic.php?f=5&t=791
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\setcounter{secnumdepth}{6}
\renewcommand\theparagraph{\Alph{paragraph}}

\makeatletter
\renewcommand\paragraph{\@startsection{paragraph}{4}{\z@}%
                                     {-3.25ex\@plus -1ex \@minus -.2ex}%
                                     {0.0001pt \@plus .2ex}%
                                     {\normalfont\normalsize\bfseries}}
\renewcommand\subparagraph{\@startsection{subparagraph}{5}{\z@}%
                                     {-3.25ex\@plus -1ex \@minus -.2ex}%
                                     {0.0001pt \@plus .2ex}%
                                     {\normalfont\normalsize\bfseries}}

\counterwithin{paragraph}{subsubsection}
\counterwithin{subparagraph}{paragraph}
\makeatother
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\newcommand{\eqoffset}[1]{%
  {\ensuremath{%
      {\text{offset}}_{#1}}%
  }%
}
\newcommand{\eqdelay}[1]{{\text{delay}}_{#1}}
\newcommand{\eqasymm}{{\text{asymmetry}}}

\begin{document}

\title{White Rabbit Specification: \\Draft for Comments}
\author{Emilio G. Cota\\ Maciej Lipinski \\ Tomasz Wlostowski}
\date{September 2010}
\maketitle

\begin{figure}[ht!]
  \centering
  \vspace{1.3cm}
  \includegraphics[width=0.50\textwidth]{fig/wr_logo.ps}
  \label{fig:hybrid-network}
\end{figure}

\newpage

\begin{center}
\large Revision History Table 
\end{center} 


\begin{table}[ht]
%\caption{White Rabbit Specification Revision History Table } 
\centering
\begin{tabular}{| c |  c | c | p{6cm}    |}          \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,\\
    &            &              & 2.~Changed WR managementIDs,\\
    &            &              & 3.~Added authors, this rev. table, explanatory figures and descriptions.
					\\ \hline
\end{tabular}
\label{tab:revHist}
\end{table}

\newpage

\section{Introduction}

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 term 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
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), 
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.

\begin{figure}[ht!]
  \centering
%  \vspace{-1.3cm}
  \includegraphics[width=1.00\textwidth]{fig/clocks.ps}
  \caption{Synchronization and syntonization in a White Rabbit link.}
  \label{fig:wrNodes}
\end{figure}


\newpage

The precise knowledge of the link delay is obtained by accurate hardware 
timestamps and calculation of the delay asymmetry (see section~\ref{sec:delayAsymCal}).

The described single-link synchronization can be replicated. 
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, 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 does not apply, or is at 
least greatly diminished by the clock recovery mechanism.

\begin{figure}[ht!]
  \centering
%  \vspace{-1.3cm}
  \includegraphics[width=0.80\textwidth]{fig/wr_net_topology.ps}
  \caption{White Rabbit network; it forms a hierarchical topology.}
  \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.




\newpage

\section{Precision Time Protocol}
\label{sec:ptp}

The IEEE1588-2008 standard, known as Precise 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. 

PTP is a packet-based protocol designed to synchronize devices in distributed systems. 
The standard defines two kinds of messages which are exchanged between \textit{PTP nodes}: 
\textit{event messages} and \textit{general messages}. Both, the time of transmission and 
the time of reception of event messages are \textit{timestamped}. General messages 
are used by PTP nodes to identify other PTP nodes, establish clock hierarchy and 
exchange data, e.g.~timestamps, settings or parameters. PTP defines several methods 
for node' synchronization. Figure~\ref{fig:wrPTPmsgs} presents the messages used when 
the \textit{delay request-response mechanism} (with \textit{two-step clock}) is used, 
which is the case in White Rabbit. For simplicity reasons, a PTP node is 
considered an \textit{ordinary clock} in the remainder of this section; such clocks 
have only one port. 

\begin{figure}[ht!]
  \centering
  \includegraphics[width=0.30\textwidth]{fig/ptpMSGs.ps}
  \caption{PTP messages used by WRPTP.}
  \label{fig:wrPTPmsgs}
\end{figure}

An \textit{Announce Message} is periodically broadcast by the PTP node which is 
in the Master state. The message carries information about its originator and 
the originator's clock source quality. This enables other PTP nodes receiving 
the announce message to perform the Best Master Clock (BMC) Algorithm. 
The algorithm defines the role of each PTP node in PTP network hierarchy; 
the outcome of the algorithm is the recommended next state of the PTP node and 
the node's synchronization source (grandparent). In other words, a PTP node 
decides to which other PTP node it should synchronize based on the information 
provided in announce messages and using the BMC algorithm. A PTP node which is in 
the SLAVE state synchronizes to the clock of another PTP node. A PTP node 
which is in the MASTER state is regarded as a source of synchronization 
for the other PTP nodes. The full PTP state machine with state descriptions 
is included in Appendix~\ref{ptpFSM}.



\textit{Sync Messages} and \textit{Delay\_Req Messages} are timestamped 
($t_{1}$, $t_{2}$, $t_{3}$, $t_{4}$) and these timestamps are used to calculate 
the offset and the delay between the nodes exchanging the messages. \textit{Follow\_UP Messages} 
and \textit{Delay\_Resp Messages} are used to send timestamps between Master 
and Slave (in the case of a two-step clock). 

\textit{Management Messages} are used only for configuration and 
administrative purposes. They are not essential for the PTP synchronization.

The flow of events in the PTP delay request-respons (two-step clock) mechanism is the following 
(simplified overview): 
\begin{enumerate}
\item The master sends periodically Announce messages.
\item The slave receives the Announce message, uses the BMC algorithm to establish its place in the network hierarchy.
\item The master sends periodically 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 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 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.
\item Repeat 1-10.
\end{enumerate}


\newpage

\section{Link Delay Model}
\label{sec:delaymodel}

The delay of a message travelling from master to slave (see Figure~\ref{fig:delaymodel}) 
can be expressed as the sum

\begin{equation}
  \label{eq:delayms}
  \eqdelay{ms} = \Delta_{tx_m} + \delta_{ms} + \Delta_{rx_s}
\end{equation}

where $\Delta_{tx_m}$ is the fixed delay due to the master's transmission
circuitry, $\delta_{ms}$ is the variable delay incurred in the
transmission medium, and $\Delta_{rx_s}$ is the fixed delay due to the
slave's reception circuitry.
In a similar fashion, the delay of a message travelling from slave to
master can be decomposed as

\begin{equation}
  \label{eq:delaysm}
  \eqdelay{sm} = \Delta_{tx_s} + \delta_{sm} + \Delta_{rx_m}
\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.

\begin{figure}[ht!]
  \centering
    \includegraphics[width=0.95\textwidth]{fig/delaymodel.eps}
  \caption{Delay model of a WR link. The timestamps are accurately corrected
    for link asymmetries by the usage of the four fixed delays
    $\Delta_{\{tx_m, rx_s, tx_s, rx_m\}}$ and the relationship
    between both variable delays $\delta_{\{ms, sm\}}$. }
  \label{fig:delaymodel}
\end{figure}

\subsection{Physical Medium Correlation}
\label{sec:physcorr}

An accurate correlation 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$).

\subsubsection{Ethernet 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
the form \cite{Peek2010}:
\begin{equation}
\delta_{ms} = (1 + \alpha) \, \delta_{sm}
\label{eq:singlefiber}
\end{equation}

\section{Delay Asymmetry Calculation}
\label{sec:delayAsymCal}

Let us start from the PTP sync timestamps, represented by the familiar
set $t_1$, $t_2$, $t_3$ and $t_4$. The mean path delay is then defined as
\begin{equation}
  \mu = \frac{(t_2 - t_1) + (t_4 - t_3)}{2}
\end{equation}
Note that the transmission delays $t_2 - t_1$ and $t_4 - t_3$ can be
expressed in terms of WR's Delay Model:
\begin{align}
  t_2 - t_1 = \Delta_{tx_m} + \delta_{ms} + \Delta_{rx_s} + \eqoffset{ms}\\
  t_4 - t_3 = \Delta_{tx_s} + \delta_{sm} + \Delta_{rx_m} - \eqoffset{ms}
\end{align} where \eqoffset{ms} is the time offset between the
slave's clock and the master's. Combining the three equations above
we obtain
\begin{equation}
\label{eq:mu}
  2\mu = \Delta + \delta_{sm} + \delta_{ms}
\end{equation} where $\Delta$ accounts for all fixed delays in the path,
i.e.
\begin{equation}
\label{eq:delta}
  \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 IEEE1588-2008
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
  \label{eq:asymm} \\
  \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:
\begin{gather}
  \delta_{ms} = \frac{1 + \alpha}{2 + \alpha} \, (2\mu - \Delta)
  \label{eq:deltams} \\
  \delta_{sm} = \frac{2\mu - \Delta}{2 + \alpha}
  \label{eq:deltasm}
\end{gather}
\\
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}.




\section{Fixed delays}
\label{sec:fixedDelays}
The knowledge of fixed delays $\Delta_{\{tx_m, rx_s, tx_s, rx_m\}}$ is necessary to calculate 
delay asymmetry \eqref{eq:aqasymm}. Such delays may be constant for the lifetime of the hardware, 
its up-time or the duration of the link connection. Therefore, the method for obtaining fixed 
delays is medium-specific and implementation-dependent. The delays are measured (if necessary) 
and the information about its values is distributed across the link during the process of 
establishing the WR link, which is called \textit{WR Link Setup} in this document. 
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 a 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}.

\newpage

\section{White Rabbit PTP Extension}
\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).



\begin{figure}[ht!]
  \centering
%  \vspace{-1.3cm}
  \includegraphics[width=0.80\textwidth]{fig/wrptpMSGs.ps}
  \caption{Simplified overview of a 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):
\newpage
\begin{enumerate}
\item The WR Master sends periodically WR Announce message with the 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 starts WR Link Setup by sending the SLAVE\_PRESENT WR Management message.
\item The WR Master starts sends the LOCK WR Management message to request the WR Slave to start syntonization.
\item The WR Slave sends 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 sends periodically 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$).
\item The WR Master receives the Delay\_Req message sent by the master (timestamped on reception, $t_4$).
\item The WR Master sends a Delay\_Resp message which carries $t_4$.
\item The WR Slave receives the Delay\_Resp.
\item The WR Slave adjusts its clock using the offset and the delay calculated with the timestamps 
($t_{1}$, $t_{2}$, $t_{3}$, $t_{4}$) corrected due to the precise knowledge of the link delay. 
It results in the Slave's synchronization with the Master clock with sub-ns accuracy.
\item Repeat 1, 11-18.
\end{enumerate}

Since the WR Link Setup is performed in the PTP UNCALIBRATED state, 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. 

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. 

Figure~\ref{fig:hybrid-network} depicts the topology of a \emph{hybrid} WR/IEEE1588 
network where optimal synchronization with grandmaster is 
achieved by connecting a 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 a part of PTP standard.



\begin{table}[ph!]
\caption{WRPTP Data Sets fields}
\centering
\begin{tabular}{| c     |     c        |        p{2.5cm}                |            p{4cm}                                                                |}        \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

\end{tabular}
\label{tab:wrDS}
\end{table}

\newpage

\subsection{Modified Best Master Clock Algorithm}
\label{sec:wrBMC}


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 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).


\subsection{WRPTP Messages}
\label{sec:wrMSG}

\subsubsection{Overview}

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.

A White Rabbit Master node announces its presence by adding a WR TLV suffix to the Announce message. 
The suffix is defined by 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).


\subsubsection{WR Type-Length-Value Type}
\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.

\begin{table}[ht]
\caption{White Rabbit Type-Length-Value (WR TLV) type } 
\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
\end{tabular}
\label{tab:wrTLVtype}
\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}.

\begin{table}[h!]
\caption{White Rabbit Announce Message}
\centering
\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}  & \textbf{Content} \\
%\hline
\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
\end{tabular}
\label{tab:wrAnnounce}
\end{table}


\begin{table}[ht!]
\caption{White Rabbit flags (unused flags are reserved and shall be written to 0, ignored when read)}
\centering
\begin{tabular}{| c | c | c | c | p{5.3cm} |}          \hline

\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
\end{tabular}
\label{tab:wrFlags}
\end{table}

\newpage


\subsubsection{WRPTP Management Messages}
\label{wrManagementMSG}

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:wrManagemetnMSG}. 
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.

\begin{table}[h!]
\caption{PTP Management Message (Table 37, PTP) }
\centering
\begin{tabular}{| c | c | c | c | c | c | c | c | c | c |}
\hline
\multicolumn{8}{|c|}{\textbf{Bits}}               & \textbf{Octets} & \textbf{TLV}  \\
%\hline
\cline{0-7}
7 & 6 & 5 & 4 & 3 & 2 & 1 & 0                     &                 & \textbf{Offset}    \\
\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
\end{tabular}
\label{tab:wrManagemetnMSG}
\end{table}





\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}


\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}
\centering
\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} &\\
%\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  & 0x2, section 15.5.2.3, PTP. \\ \hline
\multicolumn{8}{|c|}{managementId      } & 2 & 4  & Defined in Table~\ref{tab:wrManagementId}.\\ \hline
\end{tabular}
\label{tab:wrOtherTLV}
\end{table}





\paragraph{CALIBRATE} Messages sent by the WR node entering the REQ\_CALIBRATION state (see section~\ref{wrFSM}). It informs the other node 
whether sending 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}
\centering
\begin{tabular}{| c | c | c | c | c | c | c | c | c | c |  p{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  & 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 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
\end{tabular}
\label{tab:wrCalibrateTLV}
\end{table}

\newpage



\paragraph{CALIBRATED} Message sent by the WR node entering \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}$). 
The messages shall have the format specified in Table~\ref{tab:wrCalibratedTLV}.

\begin{table}[ht]
\caption{CALIBRATED WR Management TLV}
\centering
\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} &\\
%\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 & MASTER\_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
\end{tabular}
\label{tab:wrCalibratedTLV}
\end{table}




\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{White Rabbit 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 
executed in the PTP UNCALIBRATED state, it is depicted in Figure~\ref{fig:wrFSM} and described in the rest of 
this section.

A simplified flow of WR Management Message exchange between a WR Slave and a WR Master during WR Link Setup is presented 
in Appedix~\ref{fig:wrFSMcommun}.

\subsubsection{Condition to start WR FSM by WR Slave}
\label{sec:wrSlaveFSMstart}

The WR FSM in 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:
\begin{itemize}
\item the node is WR Slave: \\ ($portDS.wrPortMode = WR\_SLAVE$) \textbf{AND}
\item the parent node is 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}).
\end{itemize}

\subsubsection{Condition to start WR FSM by WR Master}
\label{sec:wrMasterFSMstart}


The WR Master node shall enter the PTP UNCALBRATED state, and start execution of the WR FSM by entering \textit{LOCK} state, when it receives a SLAVE\_PRESENT WR Management message (Table~\ref{tab:wrManagementId}). 


\newpage


\paragraph{State Description}

Table~\ref{tab:wrFSMdesc} specifies the WR states notation used in Figure~\ref{fig:wrFSM}.

\begin{table}[hp!]
\caption{WR state definition}
\centering
\begin{tabular}{| c | p{11cm} |}          \hline
\textbf{PTP portState}  &  \textbf{Description} \\ 
&   \\ \hline
\small
IDLE               &  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 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 \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 \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, 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 \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. TRUE value of the flag
		      indicates that 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}





\begin{figure}[ht!]
  \centering
%  \vspace{-1.3cm}
  \includegraphics[width=1.00\textwidth]{fig/wrFSM.ps}
  \caption{White Rabbit state machine.}
  \label{fig:wrFSM}
\end{figure}






\paragraph{WR FSM Transition Events and Conditions}

\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 WR Link Setup is required and WR FSM should be executed starting with 
									\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 request the recipient to enter 
									\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 
									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}$]							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
\begin{center}
\huge Appendix
\end{center} 

\normalsize
\appendix
\section{Measurement of fixed delays for Gigabit Ethernet over Optic Fiber}
\label{sec:calibForGigbitE}

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, in example, 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 calibration.

The calibration pattern used to describe the methods is not compliant with 8b/10b encoding standard. 
For the real-life implementation, a 8b/10b compliant pattern is preferable.

\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 full-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.

\newpage

\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{table}[hp!]
\caption{PTP portState definition (Table 10, IEEE1588).}
\centering
\begin{tabular}{| c | p{9.5cm} |}          \hline
\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
		      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
		      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
		      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,
		      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
		      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
SLAVE              &  \small The port is synchronizing to the selected master port.  \\ \hline
\end{tabular}
\label{tab:wrManagementId}
\end{table}


\newpage

\section{Flow of WR Management message exchange between a WR Master and a WR Slave (no exceptions) during WR Link Setup}
\begin{figure}[ht!]
  \centering
%  \vspace{-1.3cm}
  \includegraphics[width=1.0\textwidth]{fig/wrMSGsExchangeFlow.ps}
  \caption{Flow of events (no exceptions) during WR Link Setup.}
  \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}.
  IEEE Instrumentation and Measurement Society, New York,
  2008,
  http://ieee1588.nist.gov/.

\bibitem{Peek2010}
  P.P.M. Jansweijer, H.Z. Peek,
  \emph{Measuring propagation delay over a 1.25 Gbps bidirectional data link}.
  National Institute for Subatomic Physics, Amsterdam,
  2010,\\
  http://www.nikhef.nl/pub/services/biblio/technicalreports/ETR2010-01.pdf.



\end{thebibliography}


\end{document}
