Skip to content

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

work in progress

parent c02b1562
Hide whitespace changes
Inline Side-by-side
Showing with 575 additions and 649 deletions
documents/ISPCS2015-HA/L1SynOp.bib
View file @ d4b7ffe9
......@@ -161,4 +161,10 @@
year = "2012",
howpublished = {\\\url{https://ieee-sa.centraldesktop.com/1588/file/24747556/}}
}
@electronic{wrCalibration,
title = "{White Rabbit calibration procedure}",
author = "Grzegorz Daniluk",
date = {August 13, 2014},
howpublished = {\\\url{http://www.ohwr.org/documents/213}}
}
\ No newline at end of file
documents/ISPCS2015-HA/L1SynOp.tex
View file @ d4b7ffe9
......@@ -33,60 +33,53 @@
\begin{abstract}
The High Accuracy (HA) sub-committee (SC) is a part of the P1588 Working Group (WG). It works
The High Accuracy (HA) sub-committee (SC) is a part of the P1588 Working Group (WG). It works
on a suite of additional options to the IEEE1588 Precision Time Protocol (PTP).
These options are meant to enable interoperable PTP implementations
with enhanced synchronization accuracy. The HA work is
based on the White Rabbit (WR) extension to PTP~\cite{wr}.
% HA is meant to generalize mechanisms used in WR.
Synchronization in WR enhances PTP in two areas: (1)~calibration/measurement of
asymmetries and (2)~precise round-trip measurement.
The latter is the first to be tackled by HA in an attempt of generalization and
formulation into standard language as a "Layer 1 Syntonization Option" (L1SynOp). Based on a
few months of HA SC work and a few iterations, this paper proposes an outline of L1SynOp.
WR extensions are investigated by HA in an attempt of generalization and
formulation into standard language.
This article offers an insight into the current work of High Accuracy SC. It provides technical
background, definitions and explanations of different features being developed in the committee,
relating them to the original White Rabbit.
\end{abstract}
\section{Introduction: High accuracy basic dependencies}
\section{Introduction}
The ongoing revision of IEEE1588 \cite{P1588WG} is undertaken by P1588 Working Group (WG). Its
work was divided into five major domains, each handled by a
dedicated sub-committee~(SC): Maintenance, Architecture, Security, Management and High Accuracy.
The task of High Accuracy SC is summarized in the following sentence stated in the P1588 Project
Authorization Request: \textit{The protocol enhances support for synchronization to better than 1 nanosecond.}
The work of High Accuracy SC is based on White Rabbit (WR) extension to PTP~\cite{wr}.
A number of independent aspects of WR was distinguished.
These aspects are handled separately to be potentially included in the IEEE1588 as HA Optional
Features. A High Accuracy Profile will likely use all the HA Optional Features to enable sub-nanosecond
accuracy of synchronization. The features may be used separately by any profile
in order to increase synchronization performance.
This article first presents what dependencies need to be fulfilled to achieve high accuracy.
These dependencies are related to different aspects of the original White Rabbit. Then,
terms used throughout the article, and in the work of High Accuracy SC, are defined to
facilitate further explanations. The rest of the article explains two High Accuracy
dependencies: \textit{Precise round-trip measurement} and \textit{Ingress and egress latency asymmetry}.
It focuses on the former, since its the first and most advanced. It gives
a high-level overview of the later. Finally, some insights into the future challenges in
the work of High Accuracy SC are outlined.
\section{High accuracy basic dependencies}
High accuracy is a link-based affair. It can be achieved if a number of dependencies,
described below and presented in Figure~\ref{fig:HAdependency}, are fulfilled.
\subsection{Asymmetry calibration} Knowledge of the \textit{asymmetry introduced on the link}
is required to precisely calculate the master-to-slave delay from
the round-trip measurement. Such asymmetry can introduce tens --~or hundreds~-- of
nanoseconds
of constant offset (inaccuracy). It is device-dependent and medium-dependent.
The overall link asymmetry has two contributors; HA accuracy requires knowledge of both of
them:
\begin{itemize}
\item \textbf{Transmission and Reception (Tx/Rx) delays}
are introduced by the hardware that transmits and receives frames.
Two types of Tx/Rx delays can be distinguished:
\begin{enumerate}
\item variable delay introduced by the Serializer/Deserializer (SerDes), i.e.
bitslide \cite{bitslide}. It is
the phase offset between the "edge" of the 8b/10b symbol and the
edge of the \textit{L1 clock signal}\footnote{In this paper, the term \textit{clock} represents a time counter and a \textit{clock signal}.
The term \textit{clock signal} represents a square waveform of a given frequency and phase.
Thus, a \textit{PTP clock} is
characterized by the time of day, frequency and phase; a \textit{ PTP clock signal} is characterized by frequency and phase.
This terminology is strictly followed.} recovered from the data,
as depicted in Figure~\ref{fig:bitslide}. It requires dedicated
measurement unless the SerDes guarantees it to be a fixed known value.
\item fixed delays introduced by hardware, e.g. PHY, traces,
internal FPGA, connector. These delays are constant to first order,
i.e. ageing or temperature effects are not taken into account.
It should be possible to measure these delays. Alternatively, fixed delays
can be set in such a way that the asymmetry of any two connected ports
cancels out, through some kind of calibration process.
\end{enumerate}
\item \textbf{Medium asymmetry} is introduced by the difference of transmission
delays in the two directions in the medium alone. It must be
known and depends on the medium.
\end{itemize}
\begin{figure}[!t]
\centering
\includegraphics[width=0.49\textwidth]{figs/HAdependency.eps}
......@@ -94,72 +87,127 @@ described below and presented in Figure~\ref{fig:HAdependency}, are fulfilled.
\label{fig:HAdependency}
\end{figure}
\begin{figure}[!t]
\subsection{Precise round-trip measurement} Precise knowledge of round-trip is a
prerequisite to calculate the master-to-slave delay. It depends on the
resolution and precision of timestamps which can introduce nanoseconds of jitter
(imprecision) in synchronization. White Rabbit achieves picoseconds precision of
timestamps through physical syntonization and phase detection. Although this technique
relies mostly on appropriate implementation, it requires cooperation of connected PTP nodes to ensure
proper syntonization of their frequencies and enable exchange of the necessary
information. This calls for protocol solution which is tackled in the High Accuracy
SC as the \textit{Layer 1 Syntonization Optional Feature}
\subsection{Asymmetry calibration} Precise knowledge of the asymmetry introduced on the link
is required to calculate the master-to-slave delay from the round-trip measurement.
Such asymmetry can introduce tens --~or hundreds~-- of nanoseconds
of constant offset (inaccuracy). It is device-dependent and medium-dependent.
The overall link asymmetry has two contributors; HA requires knowledge of both of
them:
\begin{itemize}
\item \textbf{Ingress and egress latency asymmetry} is introduced by the
difference of delays in hardware that transmits and receives frames.
White Rabbit accounts for this asymmetry through online measurement of
bitslide \cite{bitslide} and system-wide calibration procedure \cite{wrCalibration}.
This is handled by High Accuracy SC within \textit{Calibration} effort.
\item \textbf{Medium asymmetry} is introduced by the difference of transmission
delays in the two directions in the medium alone. White Rabbit provides
method to estimate this asymmetry for single-mode single fibre used as
bi-directional medium. This is not currently handled by High Accuracy SC.
\end{itemize}
\section{Definitions and terms}
\label{Definitions}
Discussing accurate synchronization requires precise definitions. This section defines basic
terms that will be used throughout this article (always in \textit{italic}).
\textbf{PTP node} is used to mean a network element
that acts as Boundary, Ordinary or Transparent Clock. A node can have several \textbf{PTP ports}.
\textbf{Clock signal} provides frequency and phase. It is represented by a physical signal that
has periodic events (e.g. oscillator output). The events mark the significant instants at
which the time counter of the physical clock is incremented
\textbf{Clock} provides time. It is either
\begin{itemize}
\item Physical: it is represented by a \textit{clock signal} and time counter, or
\item Mathematical: it is represented by a model which describes relation of this clock
to another clock (e.g. to a physical clock in a different timescale), the model
enables to calculate the time.
\end{itemize}
\textbf{Local PTP clock signal} provides PTP frequency and phase. It is the \textit{clock signal}
of a \textit{PTP node} that generates the \textit{local PTP clock}.
\textbf{Local PTP clock} provides PTP time. It is the \textit{clock} of a \textit{PTP node} that provides local
estimate of the time of its Grandmaster, i.e. it is synchronized to the Grandmaster.
\textbf{L1 clock signal} provides L1 frequency and phase. It is the \textit{clock signal} that is used
by the physical elements that transmit and receive data (e.g. PHYs). \textbf{L1 tx clock signal}
is used to transmit data; \textbf{L1 rx clock signal} is recovered from the received data.
\textbf{Bitslide} is the term used for misalignment of symbols encoded as serial and parallel data
when serializing/deserializing. As an example for Gigabit Ethernet, it is the phase offset
between the "edge" of the 8b/10b symbol and the edge of the \textit{L1 clock signal}
with which the 8b parallel word is aligned, as depicted in Figure~\ref{fig:bitslide}.
\begin{figure}[!ht]
\centering
\includegraphics[width=0.35\textwidth]{figs/bitslide.eps}
\includegraphics[width=0.45\textwidth]{figs/bitslide.eps}
\caption{Bitslide.}
\label{fig:bitslide}
\end{figure}
\subsection{Precise round-trip measurement}
Hardware timestamps ($t_{hw}$) are usually taken by sampling frames
using the time-keeping \textit{PTP clock}.
However, the frames (data) are received/transmitted using the \textit{L1 clock signal} which is
different from the \textit{PTP clock signal}. This results in timestamping resolution of several
nanoseconds. For example, if the frequency of the \textit{PTP clock signal} is 125MHz, timestamps will have a resolution of 8ns.
It is possible to enhance the timestamping resolution by knowing the
phase offset between PTP and L1 clock signals, i.e. $x(t_{hw})$.
The precision and feasibility of a technique used for phase detection depends
on the mutual frequency stability of the two compared clock signals.
Ideally, the phase offset should be constant, which means that the L1 and PTP clock signals are
syntonized. A phase offset which changes at a slow, constant rate decreases the
precision of phase detection but still enables to get meaningful and useful data.
This can be the case if the two clock signals are indirectly syntonized or if they are
syntonized to independent Primary Reference Clocks (PRCs), such as caesium or rubidium.
Both cases will be presented later.
The \textit{precise round-trip measurement} requires some level of syntonization between the
PTP and L1 clock signals, which would allow a meaningful measurement of phase offsets between them.
\section{Precise round-trip measurement}
\label{L1SynOp}
\textit{Precise round-trip measurement} is tackled in the High Accuracy SC as
the \textit{Layer 1 Syntonization Optional Feature} (L1SynOp). Most
of its "workload" is on the implementation.
However, it requires cooperation
of two connected PTP nodes\footnote{The term \textit{PTP node} is used to mean a network element
that acts as Boundary, Ordinary or Transparent Clock. A node can have several \textit{PTP ports}.} to ensure proper syntonization of their
frequencies and enable exchange of the necessary information.
This calls for protocol tools to ensure interoperability between implementations. In order
to better understand what is required from the protocol,
a \textit{Reference model} is defined.
\section{Reference Model}
the \textit{Layer 1 Syntonization Optional Feature} (L1SynOp). Most of its "workload" relies
on the implementation to provide precise timestamps however it requires both communicating
PTP nodes to agree on configuration and ensure compatibility. First we introduce the idea
of enhancing timestamp precision and its requirements, then we present a reference model
which shows it works on a single link.
\subsection{Enhancing precision of hardware timestamps}
Hardware timestamps are usually taken by sampling frames using the time-keeping
\textit{local PTP clock}. However, the frames (data) are received/transmitted using the
\textit{L1 clock signal} which is different from the \textit{local PTP clock signal}. This
results in timestamping resolution of several nanoseconds. For example, if the frequency of
the \textit{local PTP clock signal} is 125MHz, timestamps will have a resolution of 8ns.
It is possible to enhance the timestamping resolution by knowing the phase offset between
\textit{local PTP and L1 clock signals}, i.e. $x$. The precision and feasibility of
a technique used for phase detection depends on the mutual frequency stability of the two
compared \textit{clock signals}. Ideally, the phase offset should be constant, which means
that the \textit{local PTP and L1 clock signals} are syntonized. A phase offset which changes
at a slow, constant rate decreases the precision of phase detection but still enables to get
meaningful and useful data. This can be the case if the two clock signals are indirectly
syntonized or if they are syntonized to independent Primary Reference Clocks (PRCs), such
as caesium or rubidium.
\subsection{Reference Model}
\label{RefModel}
Figure~\ref{fig:refModel} depicts a single link between two PTP nodes. In each
The idea of enhancing timestamping precision is modelled for a round-trip measurement.
Figure~\ref{fig:refModel} depicts a link between two PTP nodes. In each
node three clock signals are distinguished:
\begin{itemize}
\item \textit{PTP clock signal} ($clk_{PTP\_A}$, $clk_{PTP\_B}$) -- used for time-keeping
of the \textit{timescale} distributed by PTP. Its edge marks the time of day. It might be either a physical signal
or a "paper clock".
\item \textit{L1 Tx clock signal} ($clk_{L1\_Tx\_A}$, $clk_{L1\_Tx\_B}$) --
used to encode the data transmitted over the physical medium.
\item \textit{L1 Rx clock signal} ($clk_{L1\_Rx\_A}$, $clk_{L1\_Rx\_B}$) --
recovered from the received data.
\end{itemize}
In Figure~\ref{fig:refModel}, the transmission circuit (Tx) of \textit{Node A} is connected to the reception circuit (Rx)
\textit{Local PTP clock signal} ($clk_{PTP\_A}$, $clk_{PTP\_B}$),
\textit{L1 Tx clock signal} ($clk_{L1\_Tx\_A}$, $clk_{L1\_Tx\_B}$), and
\textit{L1 Rx clock signal} ($clk_{L1\_Rx\_A}$, $clk_{L1\_Rx\_B}$).
The transmission circuit (Tx) of \textit{Node A} is connected to the reception circuit (Rx)
of \textit{Node B}, and vice versa. Consequently, thanks to the clock and data recovery (CDR) circuit in
each receiver, the frequency of the \textit{L1 Tx clock signal}
in \textit{Node A} is equal to the frequency of the \textit{L1 Rx clock signal} in \textit{Node B} ($clk_{L1\_Tx\_A}$
and $clk_{L1\_Rx\_B}$ respectively), and vice versa.
The phase offset between the rising edge of the \textit{PTP clock signal} and the transmission
\textit{L1 Tx clock signal}, captured with respect to the \textit{PTP clock signal}, is
marked as $x_{Tx\_A}$ and $x_{Tx\_B}$ for \textit{Node A} and \textit{Node B} respectively.
The phase offset between the rising edge of the \textit{PTP clock signal} and the
reception \textit{L1 Rx clock signal}, captured with respect to the \textit{PTP clock signal},
The phase offset between the rising edge of the \textit{local PTP clock signal} and the
transmission \textit{L1 Tx clock signal} is marked as $x_{Tx\_A}$ and $x_{Tx\_B}$ for
\textit{Node A} and \textit{Node B} respectively. The phase offset between the rising edge of
the \textit{local PTP clock signal} and the reception \textit{L1 Rx clock signal}
is marked as $x_{Rx\_A}$ and $x_{Rx\_B}$ for \textit{Node A} and \textit{Node B} respectively.
\begin{figure}[!t]
......@@ -173,15 +221,14 @@ is marked as $x_{Rx\_A}$ and $x_{Rx\_B}$ for \textit{Node A} and \textit{Node B}
The fine part of the round-trip can be calculated when the values of all the phase offsets,
i.e. $x_{Tx\_A}$, $x_{Tx\_B}$, $x_{Rx\_A}$, and $x_{Rx\_B}$, are known for the appropriate
instances (i.e the transmission and reception time of the relevant event messages).
Therefore, both nodes participating in the link must "know" their phase offsets.
The PTP Slave must be informed about the phase offsets of the PTP Master.
"Knowing" can take different forms. For example, if the \textit{L1 Rx clock signal} is used
directly for the PTP time-keeping ($clk_{PTP}=clk_{L1\_Rx}$), their phase offset is known to be
zero (i.e. $x_{Rx}=0$). Similarly, if the
\textit{PTP clock signal} is used directly to encode the transmitted data
(i.e. $clk_{PTP}=clk_{L1\_Tx}$), the phase offset between the PTP and L1 clock signals is known to be zero
(i.e. $x_{Tx}=0$). If not known by design, the phase offset must be measured
\textit{local PTP clock signal} is used directly to encode the transmitted data
(i.e. $clk_{PTP}=clk_{L1\_Tx}$), the phase offset between the \textit{PTP and L1 clock signals}
is known to be zero (i.e. $x_{Tx}=0$). If not known by design, the phase offset must be measured
or derived in some other way.
......@@ -194,561 +241,434 @@ The reference model relies on the following requirements:
\item The PTP Slave node is provided with the values of the PTP Master phase offsets. These values can be embedded in the timestamps if agreed.
\end{itemize}
\subsection{Reference Model applied to White Rabbit}
As an example, the \textit{reference model} is applied to White Rabbit:
\begin{itemize}
\item Both nodes use the \textit{PTP clock signal} for the data transmission ($clk_{PTP}=clk_{L1\_Tx}$),
and the transmission phase offsets are know to be zero ($x_{Tx}=0$).
\item The PTP Slave node uses its recovered \textit{L1 clock signal} for PTP time-keeping
but shifts the \textit{PTP clock signal} to phase-align its phase with
the phase of the clock of the PTP Master. The reception phase offset on the
PTP Slave is known (it is set): $x_{Rx}=set\_point$.
\item The PTP Master node measures (using a DDMTD phase detector \cite{ddmtd}) its reception
phase offset: $x_{Rx}=DDMTD\_measurement$.
\item The PTP Slave node is assured that all the phase offsets are known after successfully
accomplishing the \textit{WR link setup procedure} (page 14-15 of \cite{wrdraft}).
\item The PTP Master node embeds its reception phase offset ($x_{Rx}$) into
the $t_4$ timestamp by correcting it, using the fractional nanosecond part included
in the correction field.
\end{itemize}
\section{High Accuracy in multi-domain PTP networks}
\label{HAinMultiDomain}
PTP networks can support many \textit{domains}. The time for a \textit{domain} is established
by a grandmaster. In other words, all the PTP nodes in the \textit{domain} are synchronized
to the time provided by the grandmaster, \textit{GM time}. The \textit{GM time} specifies
epoch and definition of a second. Two grandmasters in the same timescale, might have slightly
different \textit{GM times}. For example, two grandmasters synchronized using separate GPS
receivers are expected to be off by tens of nanoseconds. Similarly, two grandmasters
syntonized to separate Rubinium sources exhibit frequency offset, therefore their
definition of a second is not precisely the same.
Many \textit{GM times} can be independently propagated in separate domains over the
same physical network of PTP nodes. In such case, PTP message
communication and synchronization are performed for each \textit{domain} separately.
Effectively, each PTP node participates in multiple domains and synchronizes to multiple
\textit{GM times}. Frequency offsets between such \textit{GM time} exist.
The primary syntonization method in PTP networks uses timestamps to measure
the \textit{Sync message} rate. This information is then used to control the frequency of
the slave. The method is limited by the timestamping precision and the control loop frequency.
SyncE achieves more precise syntonization by using the \textit{L1 clock signal} in the
physical layer. However, a single SyncE network can be used to syntonize precisely only one
PTP \textit{domain}. Many \textit{GM times} can only be transported over SyncE networks
by using timestamp-based syntonization.
It has been noticed that the knowledge of the phase offset between the PTP and the L1 clock
signals in the HA nodes can be used to recreate precisely many \textit{GM times}.
Effectively, a single physical \textit{L1 clock signal} can provide precise syntonization for
\textit{PTP clock signals} in different domains.
This can be decoupled from the direction of propagation of the L1 syntonization.
The SyncE spanning tree in the network is irrelevant as long as the
information required to recreate the \textit{PTP clock signal} is distributed from the
PTP master to the PTP slave.\\
\section{(Non-) Congruency between L1 syntonization and PTP synchronization}
\begin{figure}[!t]
\centering
\includegraphics[width=0.5\textwidth]{figs/NonCongruency.eps}
\caption{Telecom synchronous network partially upgraded to HA -- a use case for non-congruency.}
\label{fig:nonCongruency}
\end{figure}
Non-congruency between the L1 syntonization spanning tree and the PTP synchronization spanning tree
can be useful in a number of cases. One is described below.
An existing ITU-T SyncE network is partially upgraded to support High Accuracy,
as depicted in Figure~\ref{fig:nonCongruency}.
Two nodes in the network are replaced with HA-capable devices (blue).
The HA installation provides synchronization between the Primary Reference Time Clock (PRTC)
at the \textit{Experiment installation headquarters} and the experimental base station at another
site.
The syntonization spanning tree (red) in the SyncE network cannot be modified due to the
legacy equipment. Therefore, non-congruent HA links are required to provide synchronization
for the HA installation. For example,
the link between the HA~grandmaster at the \textit{Experiment installation headquarters}
and the HA node in the SyncE network. The grandmaster uses the
SyncE \textit{L1 clock signal} (red) to distribute its PTP \textit{timescale} (blue).
It measures the relation between the blue and red clock signals. This information
is then distributed to the other HA nodes to recreate the blue
PTP \textit{timescale} along the HA synchronization path (dashed blue and red line).
Finally, the \textit{experimental base station} is synchronized to the blue PTP \textit{timescale}.
The rate of change of the phase offset between the blue and red clock signals must be small
enough for the offset to be measurable and useful. This is true if the references of
the red and the blue frequencies are caesium or rubidium standards.
\section{Indirect L1 syntonization}
\begin{figure}[!t]
\centering
\includegraphics[width=0.5\textwidth]{figs/BackupLink.eps}
\caption{Indirect syntonization on a redundant and "passive" link.}
\label{fig:BackupLink}
\end{figure}
A redundant link is an example of indirect syntonization. Figure~\ref{fig:BackupLink}
shows a grandmaster node A connected to two nodes, B and C, which are synchronized and
syntonized to the grandmaster. There is a direct link between node B and C which is
redundant for the synchronization and syntonization spanning trees. The \textit{PTP clock signal} of
node B is not syntonized to the \textit{L1 clock signal} recovered on its West interface.
Neither is the \textit{PTP clock signal} of node C on its East interface.
However, the \textit{PTP clock signals} of
both nodes are syntonized through the grandmaster. We say that nodes B and C are indirectly
syntonized. A precise round-trip measurement is possible on such an indirectly syntonized
link provided the reference model requirements from section~\ref{RefModel} are fulfilled.
\section{Layer 1 Syntonization Optional Feature (L1SynOp) proposal}
The L1SynOp shall provide a standard way for the interconnected ports of two PTP nodes to:
\begin{itemize}
\item agree on the ability to perform the \textit{precise round-trip measurement},
\item exchange necessary information,
\item enable multi-domain syntonization.
\end{itemize}
A PTP port that is capable of performing L1SynOp is called \textit{L1SynOp port}. A PTP
node that has \textit{L1SynOp ports} is called \textit{L1SynOp node}.
The prerequisite condition for the \textit{precise round-trip measurement} is a direct
link between two \textit{L1SynOp ports}.
Switches or routers without L1SynOp support are not allowed "in between" the \textit{L1SynOp ports}.
Such non-L1SynOp network elements can be detected by sending option-specific frames to the
link-limited reserved address\footnote{01-80-C2-00-00-0E for the IEEE 802.3/Ethernet mapping}.
These frames are discarded by all the network elements except the \textit{L1SynOp nodes}.
% This kind of verification shall be provided by the L1SynOp.
Provided a direct link exists, two connected \textit{L1SynOp ports} shall verify that the
requirements of the reference model are satisfied. In particular, the exchanged information
shall enable:
\begin{itemize}
\item verification of syntonization between the PTP and L1 clock signals on both \textit{L1SynOp ports},
\item confirmation that both \textit{L1SynOp ports} know their phase offsets,
\item exchange of the phase offset values so that the \textit{L1SynOp port} in the PTP Slave
state can use them in its calculations.
\end{itemize}
The \textit{L1SynOp port} in the PTP Master state can embed its phase
offsets into timestamps by correcting their values. If phase offsets are embedded,
the $t_1$ shall be corrected with $x_{Tx}$ and $t_4$ with $x_{Rx}$.
\subsection{L1SynOp information exchange}
A single Type-Length-Value (TLV) is defined for the exchange of all the L1SynOp information.
It is called the L1InfoTLV. Two types of L1InfoTLV are distinguished by a \textit{Type ID}:
\begin{enumerate}
\item Announce-L1InfoTLV. It is suffixed to PTP Announce Messages and/or sent in
Signaling Messages, depending on the profile specification.
\item Response-L1InfoTLV. It is sent in Signaling Messages using a reserved destination
address. It is sent only as a response to a request carried in
the Announce-L1InfoTLV.
\end{enumerate}
A \textit{L1SynOp port} sends Response-L1InfoTLV if it receives Announce-L1InfoTLV
with the \textit{Response Request flag} set to \textit{True}, see
Table~\ref{tab:L1InfoTLV}. This mechanism provides means for an \textit{L1SynOp port} to
(1) verify whether a link is direct, and
(2) request an update from the other \textit{L1SynOp port}.
The rules for setting the \textit{Response Request flag} are defined by L1SynOp and can be
fine-tuned by a profile.
The \textit{Response Request flag} is set to \textit{True} whenever the physical interface goes up.
It is set to False whenever a Response-L1InfoTLV is received in a response to Announce-L1InfoTLV.
The flag can be periodically set to \textit{True} for link re-verification. The verification
is repeated at regular time intervals. The default value for the time interval is zero,
which means that re-verification is disabled. However, a profile can modify the
interval accordingly.
A Boundary or Ordinary Clock (BC \& OC) sends
the Announce-L1InfoTLVs on its \textit{L1SynOp ports} which are in the PTP Master or
Uncalibrated state. It can be sent in other states if defined by the profile.
A Transparent Clock (TC) sends Announce-L1InfoTLV on all its \textit{L1SynOp ports}
periodically.
A profile that uses L1SynOp defines the condition to activate the L1SynOp implementation-specific mechanisms
which enable precise round-trip measurement. This condition uses the information provided
by the L1SynOp.
\subsection{L1InfoTLV content}
\label{L1InfoTLV}
\begin{table}[!t]
\centering
\begin{tabular}{| c | c | } \hline
\textbf{Name} & \textbf{Values} \\ \hline
& \\ \hline
Type ID & Announce, Response \\ \hline
Response Request flag & True, False \\ \hline
Link-verified flag & True, False \\ \hline
Phase offsets known flag & True, False \\ \hline
Congruent & True, False \\ \hline
Coupled & True, False \\ \hline
L1 status & Master, Slave, Not syntonized \\ \hline
L1 configuration & Master, Slave, Both \\ \hline
Timestamps corrected & True, False \\ \hline
Parameter(s) & \textit{Integer}(s) \\ \hline
Parameter Flag & True, False \\ \hline
Parameter Valid Flag & True, False \\ \hline
FrequencyClass & See Table~\ref{tab:freqClass}
in Section~\ref{FrequencyClass} \\ \hline
\end{tabular}
\caption{L1InfoTLV content.}
\label{tab:L1InfoTLV}
\end{table}
Table~\ref{tab:L1InfoTLV} presents the information that is sent
in the L1InfoTLV. Each field is described below.\\
\textbf{Type ID} ensures distinction between the Announce-L1InfoTLV
and Response-L1InfoTLV. The former is specified by the profile to be either suffixed to the
PTP Announce or sent in the Signaling Message. The latter
is required to be sent on request in the Signaling Message to a link-limited address, regardless of
the profile specification.
\\
\textbf{Response Request flag}. If it is set to \textit{True} in the Announce-L1InfoTLV received by
the \textit{L1SynOp port}, a Response-L1InfoTLV is sent. It is set to False in all the Response-L1InfoTLVs.
\\
\textbf{Link-verified flag} is set to \textit{True} if the sending \textit{L1SynOp port} has successfully verified
that the link is direct.
\\
\textbf{Phase offsets known} is set to \textit{True} if the sending \textit{L1SynOp port} "knows" the phase
offsets between its PTP and L1 clock signals: $x_{Rx}$ and $x_{Tx}$. For example, it is set
to \textit{True} by an \textit{L1SynOp port} that uses directly the recovered \textit{L1 clock signal} for its
PTP time-keeping ($x_{Rx}=0$) and uses the same clock signal for transmission ($x_{Tx}=0$). The flag is
also set to \textit{True} by an \textit{L1SynOp port} that uses its \textit{PTP clock signal} to transmit traffic
($x_{Tx}=0$) and measures the phase offset between its \textit{PTP clock signal} and the recovered
\textit{L1 clock signal} ($x_{Rx}=measurement$).
\\
\textbf{Congruent} informs about a profile-wide relation between the PTP synchronization
spanning tree and the L1 syntonization spanning tree. If it is set to \textit{True}, the L1 spanning tree
is determined by the PTP spanning tree and the frequency source node is chosen as the same node as
the PTP grandmaster. For example, if SyncE is used for L1 syntonization, the Ethernet Synchronization
Message Channel (ESMC) is disabled and SyncE is configured by the PTP stack.
\\
\textbf{Coupled} informs about a profile-wide relation between the PTP synchronization
and the L1 syntonization process. If it is set to \textit{True}, an \textit{L1SynOp port} recommended to enter
the PTP Slave state waits to do so until the L1 syntonization is completed.
It allows the definition of profiles which give some level of guarantee that no phase jumps or shifting
occurs when PTP synchronization happens.
\\
\textbf{L1 status} informs about the status of the L1 syntonization on the sending \textit{L1SynOp port}.
The status is obtained from a media-dependent mechanism (e.g. ITU-T-SyncE or WR-SyncE)
via a media-independent interface, detailed in section~\ref{mediaIndependentIF}.
The following \textit{L1 status} values are defined: \textit{L1 Slave}, \textit{L1 Master} and \textit{Not syntonized}.\\
\textbf{L1 configuration} informs about whether the sending \textit{L1SynOp port}
can act as an L1 Master, or an L1 Slave, or both.
This information is foreseen for congruent mode when the PTP spanning tree controls
the L1 spanning tree and an L1-specific protocol is not used. This could be the case e.g. if ESMC is disabled.
\textbf{Timestamps corrected} informs about whether the sending \textit{L1SynOp port}
embeds its phase offsets into timestamps by correcting their values.
\\
\textbf{Parameters} -- a set of values that inform about the relation between the
\textit{L1 clock signal} used for transmitting data and the \textit{PTP clock signal}
in the domain in which the PTP messages are exchanged.
These parameters can enable an optional multi-domain syntonization.
\\
\textbf{Parameters Flag} informs that the \textit{Parameters} are provided by the
sending \textit{L1SynOp port}.
\\
\textbf{Parameters Valid Flag} informs that the sent \textit{Parameters}
are valid.
\\
\textbf{FrequencyClass} informs about the quality of the \textit{L1 clock signal}
on the syntonization path from the PRTC. Its usage is left to a profile. It is described in
details in the following section. %To be investigated.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Parameters}
\label{parameters}
The main intention of exchanging the \textit{Parameters}, as explained in
Section~\ref{HAinMultiDomain}, is to precisely recreate \textit{PTP clocks} in different
domains using a single physical \textit{L1 clock signal}.
The exchanged parameters can be also useful for diagnostics, R\&D, or correction of timestamps.
It is proposed to capture the relation between the \textit{PTP clock signal} and the
\textit{L1 clock signal} by timestamping periodic events and capturing phase offset between
the L1 and PTP clock signals at the event occurrence. The events shall be timestamped using the
\textit {PTP clock} ($t_n$). The phase offset between the rising edge of the \textit{PTP clock
signal} and the following rising edge of the \textit{L1 clock signal} shall be captured in the
\textit{PTP clock signal} timebase.
The proposed schema is depicted in Figure~\ref{fig:Parameters}, which shows the events as
dashed red lines. The generation of events is implementation-specific. An event can be, for
example, a transmission of the PTP message, such as a Sync Message or a Signaling Message. In
principle, an event can be virtual, especially if the \textit{PTP clock} is a "paper clock"
which is only calculated.
The frequency of events shall be such that the difference between the consecutive (measured)
phase offsets is much smaller than the period of the \textit{PTP clock signal}, i.e.
$x_{n+1}-x_n < T_0$.
The following values are proposed to be sent in the L1InfoTLV as \textit{Parameters}:
\begin{itemize}
\item \textbf{timestamp ($t_n$)} of each event, captured using the \textit{PTP~clock},
\item \textbf{phase offset ($x_n$)} at the event occurrence, between the rising edge of the
\textit{PTP clock signals} and the following rising edge of the \textit{L1 clock
signal}, measured using the \textit{PTP~clock signal} definition of the
second,
\item \textbf{flag} to indicate whether the above values are valid.
\end{itemize}
\begin{figure}[!t]
\centering
\includegraphics[width=0.5\textwidth]{figs/Parameters-2.eps}
\caption{Relation between PTP and L1 clocks expressed using timestamps and
phase offsets ($t_n$ and $x_n$).}
\label{fig:Parameters}
\end{figure}
It has been suggested to enable sending the value of the \textbf{fractional frequency offset}
between the L1 and PTP clock signals, along with a \textbf{flag} indicating that the value
is valid. The \textit{fractional frequency offset} value can be calculated by an \textit{L1SynOp
port} after receiving two consecutive L1InfoTLVs:
\begin{equation}
\label{eq:frequencyOffset}
y_n= \frac{x_n - x_{n-1}}{t_n - t_{n-1}}
\end{equation}
There is a number of arguments in favour of sending this seemingly redundant information.
These arguments are presented below and need to be evaluated:
\begin{itemize}
\item
Let's consider an example where the \textit{PTP clock signal} is generated from the
\textit{L1 clock signal} by applying the \textit{frequency offset} as a control word,
as depicted in Figure~\ref{fig:freqOffset}.
The control algorithm is unknown to the other \textit{L1SynOp node}.
The \textit{frequency offset} ($y_n$) applied for the subsequent interval ($T_{n+1}$) can be
calculated only when the interval has passed and all the four values are available:
$x_n$, $x_{n+1}$, $t_{n}$ and $t_{n+1}$. If the \textit{frequency offset} is sent, the
other \textit{L1SynOp node} can apply it directly, rather than wait $T$.
\item
For some "alternative media" there may not be a well defined timestamping instance
(or at least not related to packet sending). The decoupling of L1 info from the
timestamps, by providing the frequency offset value, may possibly give useful
freedom in implementations or definitions.
\item
\textit{Frequency offset} is the "natural" value to control VCXOs, thus can
be directly supplied to their controller and no extra computation is required.
\end{itemize}
\begin{figure}[!t]
\centering
\includegraphics[width=0.5\textwidth]{figs/FreqOffset-2.eps}
\caption{Frequency offset applied as control word for L1 Tx clock signal generation.}
\label{fig:freqOffset}
\end{figure}
\subsection{Media independent interface}
\label{mediaIndependentIF}
The media independent interface enables exchange of information between the
media-independent \textit{L1SynOp entity} and a media-dependent syntonization mechanism, e.g. WR-SyncE or
ITU-T-SyncE, as depicted in Figure~\ref{fig:IF}.
The exchange happens at each \textit{L1SynOp port} in two directions: lower-to-upper and upper-to-lower.
\begin{figure}[!t]
\centering
\includegraphics[width=0.3\textwidth]{figs/IF.eps}
\caption{Media-independent interface.}
\label{fig:IF}
\end{figure}
\subsubsection{Lower-to-upper} the media-dependent mechanism provides information to
the \textit{L1SynOp entity}. The information concerns the status of L1 syntonization
and is sent in the \textit{L1InfoTLV} as the \textit{L1 status}.
The interface shall enable the \textit{L1SynOp entity} to query about the syntonization status:
\begin{itemize}
\item Is this port an L1-Master that is locked to a source~?
\item Is this port an L1-Slave that is locked to the recovered \textit{L1 clock signal}~?
\end{itemize}
\subsubsection{Upper-to-lower} an \textit{L1SynOp port} in congruent mode shall be able to
configure the syntonization mechanism. The interface shall provide the
\textit{L1SynOp entity} with the possibility of sending the following requests to the media-dependent mechanism:
\begin{itemize}
\item Become L1-Master.
\item Become L1-Slave.
\end{itemize}
The result of the above requests can be verified by using the lower-to-upper queries.
\subsection{Passive ports}
The L1SynOp works on so-called "passive links" which exist between
ports in the PTP Master and Passive states. A \textit{L1SynOp port} in the PTP Master state
sends Announce-L1InfoTLVs. If the \textit{Response Request flag} is set to \textit{True},
the \textit{L1SynOp port} in the PTP Passive state replies
with the Response-L1InfoTLV. Such an exchange is possible since Signaling Messages are allowed
by PTP on ports in the Passive state.
The mutual exchange of information on the "passive link" enables to verify the link and
the applicability of the \textit{reference model}; the L1SynOp information can be kept up to date.
\section{Potential applications of the information exchanged in the L1SynOp TLV}
This section explains different functionalities provided by \textit{L1SynOp} to
a profile using it. Ideas and intentions behind exchanging the information
listed in Table~\ref{tab:L1InfoTLV} are detailed and potential applications are
presented. First, the basic set of
information required to specify a WR profile is introduced. Then, we present and
explain the information that is intended to introduce flexibility and/or additional
L1 syntonization-based tools that can be used to enhance synchronization performance.
\subsection{The basic WR set}
The exchange of the \textit{L1InfoTLV} is required by WR to establish a congruent
and coupled synchronization architecture in which PTP clocks are getting support
from the L1 syntonization of clock signals.
The reception of the \textit{L1InfoTLV} enables recognition of a
PTP node that supports the \textit{L1SynOp}. In the original WR \cite{wrdraft}, the TLV
is used to recognize a PTP node using WR Profile. In the case when "the other node is
not WR", the WR node switches to the default PTP profile. This enables basic interoperability.
Since the \textit{L1SynOp} is expected to be used by a number of different profiles,
the \textit{L1InfoTLV} alone cannot be used to recognize a profile. Instead, we expect
the \textit{Profile ID TLV}
to be defined and do the job. However, the \textit{L1InfoTLV} can still be used to recognize
a PTP node that supports the \textit{L1SynOp} allowing definition of a profile that
uses \textit{L1SynOp} optionally.\footnote{Exchanging a complete configuration of
the \textit{L1SynOp} enables interoperability between profiles using \textit{L1SynOp},
as explained in later sections.}
The basic set of the \textit{L1SynOp} information which is functionally equivalent to the
original WR and enables to define a WR Profile, includes \textit{Type ID},
\textit{Response Request flag}, \textit{L1 Status}, and \textit{L1 configuration}.
The \textit{Type ID} and \textit{Response Request flag} are used to control
the exchange of the \textit{L1InfoTLVs}. It is particularly useful for a port of a BC in
the \textit{PTP Uncalibrated} state to enforce more frequent exchange of the
\textit{L1InfoTLVs} and fast update of the \textit{L1 Status}.
The \textit{L1 Status} is exchanged to \textit{couple} the PTP synchronization and the L1
syntonization. In particular, the status of the L1 syntonization is verified before starting
the PTP synchronization and exiting the \textit{PTP Uncalibrated} state.
The \textit{L1 configuration} has (at least) two practical application. First, it can be used
to represent per-port hardware capabilities specific to the \textit{L1SynOp}. In particular, the
complexity of some of the \textit{L1SynOp} mechanisms might motivate its implementation only
on a limited number of ports, especially if it concerns slave port functionalities. In such
case, the hardware limitation can be reflected using the \textit{L1 configuration} flag.
% to avoid network misconfiguration
Second, in congruent networks, where the L1 and PTP states agree, the
\textit{L1 configuration} flag enables to influence the synchronization/syntonization
spanning tree. In particular, it acts as a protection mechanism which prevents unwanted
network arrangements. The \textit{Option to explicitly configure port state}
\cite{ExPortConfig}, if specified, might be considered instead of the
\textit{L1 configuration}.
\subsection{Media-specific link verification}
\textit{L1SynOp nodes} are required to be directly connected, without non-compliant devices
in-between. In \textit{ITU-T SyncE} networks, such verification is done (to some extend) using
the Ethernet Synchronization Message Channel (ESMC).
In PTP networks using \textit{L1SynOp}, the ESMC cannot be expected nor required whereas
the verification mechanism depends on the medium/mapping that is used. For the Ethernet
mapping (PTP Annex F), the reserved address, 01-80-C2-00-00-0E, can be used as a Destination
MAC address of the Signaling Messages carrying \textit{L1InfoTLV}. Other media might define
different and media-specific mechanisms.
The \textit{Link-verified flag} enables to communicate the result of a link verification
performed by each \textit{L1SynOp port} independently. The verification might be
medium-specific, uni-- or bi--directional. Regardless, the lin k is conside red "verif ied" if
both ports set the \textit{Link-verified flag} to true.
\subsection{Flexible hardware support in non-congruent network}
The \textit{L1 configuration} flag seems useful only in congruent networks when the PTP
synchronization spanning tree controls the L1 syntonization spanning tree. The flag is
a static configuration that enables to influence the spanning tree arrangement.
On the other hand, the \textit{Phase offsets known} flag is dynamic and indicates whether the
\textit{reference model} conditions required from an \textit{L1SynOp port} are fulfilled
in a given arrangement or configuration. For example, let's assume that L1 and PTP spanning
trees are not
congruent and the ITU-T SyncE is used for the L1 syntonization, along with the ESMC for
the L1 spanning tree configuration. The \textit{Phase offsets known} flag indicates
whether phase offset values are available to a \textit{L1SynOp port} in a given
L1 and PTP states, configuration and with the provided hardware support.
\subsection{L1SynOp configuration and interoperability between profiles using L1SynOp}
The \textit{congruent} and \textit{coupled} flags enable flexibility in defining profiles
and potential interoperability between profiles using the \textit{L1SynOp}.
This two properties of the \textit{L1SynOp} must be known by \textit{L1SynOp nodes} to
facilitate proper enhancement mechanisms and guarantee certain level of accuracy.
Provided the \textit{Profile ID TLV} is available and profiles can be identified,
the properties can be defined statically for a given profile. However, exchanging the flags
allows to define profiles which enable:
\begin{itemize}
\item network-wide configuration of the \textit{congruent} flag,
\item per-node configuration of the \textit{coupled} flag (which affects nodes down the
spanning tree),
\item potential interoperability between different profiles using \textit{L1SynOp}.
\end{itemize}
\subsection{Media-flexibility}
\label{MediaFlexibility}
The original WR\cite{wrdraft} always embeds the phase measurement into timestamps,
effectively enhancing their precision. This requires two-step mechanism and works fine only
with media where timestamping plane is precisely defined.
The \textit{timestamps corrected} flag indicates whether the timestamp correction
is performed by the sending \textit{L1SynOp port}. If it is not performed, the phase
measurement shall be sent in the \textit{Parameters}. In this case, a 1-step mechanism
can be used, with correction based on the information provided in \textit{L1InfoTLV}.
Moreover, avoiding direct correction/enhancement of timetamps enables to decouple timestamping
from measurement of the phase offset. The slave can interpolate the phase offset value based on
the TLV information to get the correction for the "interesting moment" in time.
The possibility to separate phase measurement from timetamping can widen the number of medium
which can be used with \textit{L1SynOp}. In particular, to the media which do not have the
timestamping plane well-defined (or at least not related to packet sending).
\subsection{Interoperability between different L1 syntonization methods}
\textit{L1SynOp} requires L1 syntonization of clock signals which can be performed using
different mechanisms, such as WR SyncE or ITU-T SyncE. The achievable enhancement of
the synchronization accuracy depends on the mechanism used. Mixing L1 syntonization mechanisms
seems possible and results in synchronization enhancements determined by the
less performant mechanism. It seems reasonable to mix different mechanisms if the
more performant is used in the top levels of the synchronization/syntonization spanning tree.
PTP provides no mean to represent the quality of L1 syntonization and trace its quality
on the path from the frequency source. Such information is needed to influence the
synchronization/syntonization spanning tree in congruent networks in order to achieve
efficient interoperability between \textit{L1SynOp nodes} using different L1 syntonization
methods. The exchange of \textit{FrequencyClass} is meant to enable profiles defining
such interoperability.
\subsection{High Accuracy in Multi-domain PTP networks}
The \textit{Parameters} can be used to provide enhanced accuracy
in separate domains by using a common \textit{L1 clock signal}, as detailed in
Section~\ref{HAinMultiDomain}.
The value of phase measurement carried as one of the parameters can be used
to correct received timestamps (interpolated correction), if the value is not embedded at the
timestamping node, as described in Section~\ref{MediaFlexibility}.
It is the task of the \textit{Layer 1 Syntonization Optional Feature} to make sure the
requirements are fulfilled on the link.
% \subsection{Reference Model applied to White Rabbit}
%
% As an example, the \textit{reference model} is applied to White Rabbit:
% \begin{itemize}
% \item Both nodes use the \textit{PTP clock signal} for the data transmission ($clk_{PTP}=clk_{L1\_Tx}$),
% and the transmission phase offsets are know to be zero ($x_{Tx}=0$).
% \item The PTP Slave node uses its recovered \textit{L1 clock signal} for PTP time-keeping
% but shifts the \textit{PTP clock signal} to phase-align its phase with
% the phase of the clock of the PTP Master. The reception phase offset on the
% PTP Slave is known (it is set): $x_{Rx}=set\_point$.
% \item The PTP Master node measures (using a DDMTD phase detector \cite{ddmtd}) its reception
% phase offset: $x_{Rx}=DDMTD\_measurement$.
% \item The PTP Slave node is assured that all the phase offsets are known after successfully
% accomplishing the \textit{WR link setup procedure} (page 14-15 of \cite{wrdraft}).
% \item The PTP Master node embeds its reception phase offset ($x_{Rx}$) into
% the $t_4$ timestamp by correcting it, using the fractional nanosecond part included
% in the correction field.
% \end{itemize}
% \subsection{High Accuracy in multi-domain PTP networks}
% \label{HAinMultiDomain}
%
% PTP networks can support many \textit{domains}. The time for a \textit{domain} is established
% by a grandmaster. In other words, all the PTP nodes in the \textit{domain} are synchronized
% to the time provided by the grandmaster, \textit{GM time}. The \textit{GM time} specifies
% epoch and definition of a second. Two grandmasters in the same timescale, might have slightly
% different \textit{GM times}. For example, two grandmasters synchronized using separate GPS
% receivers are expected to be off by tens of nanoseconds. Similarly, two grandmasters
% syntonized to separate Rubinium sources exhibit frequency offset, therefore their
% definition of a second is not precisely the same.
%
% Many \textit{GM times} can be independently propagated in separate domains over the
% same physical network of PTP nodes. In such case, PTP message
% communication and synchronization are performed for each \textit{domain} separately.
% Effectively, each PTP node participates in multiple domains and synchronizes to multiple
% \textit{GM times}. Frequency offsets between such \textit{GM time} exist.
%
% The primary syntonization method in PTP networks uses timestamps to measure
% the \textit{Sync message} rate. This information is then used to control the frequency of
% the slave. The method is limited by the timestamping precision and the control loop frequency.
%
% SyncE achieves more precise syntonization by using the \textit{L1 clock signal} in the
% physical layer. However, a single SyncE network can be used to syntonize precisely only one
% PTP \textit{domain}. Many \textit{GM times} can only be transported over SyncE networks
% by using timestamp-based syntonization.
%
% It has been noticed that the knowledge of the phase offset between the PTP and the L1 clock
% signals in the HA nodes can be used to recreate precisely many \textit{GM times}.
% Effectively, a single physical \textit{L1 clock signal} can provide precise syntonization for
% \textit{PTP clock signals} in different domains.
% This can be decoupled from the direction of propagation of the L1 syntonization.
% The SyncE spanning tree in the network is irrelevant as long as the
% information required to recreate the \textit{PTP clock signal} is distributed from the
% PTP master to the PTP slave.\\
%
%
%
% \section{(Non-) Congruency between L1 syntonization and PTP synchronization}
%
% \begin{figure}[!t]
% \centering
% \includegraphics[width=0.5\textwidth]{figs/NonCongruency.eps}
% \caption{Telecom synchronous network partially upgraded to HA -- a use case for non-congruency.}
% \label{fig:nonCongruency}
% \end{figure}
%
% Non-congruency between the L1 syntonization spanning tree and the PTP synchronization spanning tree
% can be useful in a number of cases. One is described below.
%
% An existing ITU-T SyncE network is partially upgraded to support High Accuracy,
% as depicted in Figure~\ref{fig:nonCongruency}.
% Two nodes in the network are replaced with HA-capable devices (blue).
% The HA installation provides synchronization between the Primary Reference Time Clock (PRTC)
% at the \textit{Experiment installation headquarters} and the experimental base station at another
% site.
% The syntonization spanning tree (red) in the SyncE network cannot be modified due to the
% legacy equipment. Therefore, non-congruent HA links are required to provide synchronization
% for the HA installation. For example,
% the link between the HA~grandmaster at the \textit{Experiment installation headquarters}
% and the HA node in the SyncE network. The grandmaster uses the
% SyncE \textit{L1 clock signal} (red) to distribute its PTP \textit{timescale} (blue).
% It measures the relation between the blue and red clock signals. This information
% is then distributed to the other HA nodes to recreate the blue
% PTP \textit{timescale} along the HA synchronization path (dashed blue and red line).
% Finally, the \textit{experimental base station} is synchronized to the blue PTP \textit{timescale}.
%
% The rate of change of the phase offset between the blue and red clock signals must be small
% enough for the offset to be measurable and useful. This is true if the references of
% the red and the blue frequencies are caesium or rubidium standards.
%
% \section{Indirect L1 syntonization}
%
% \begin{figure}[!t]
% \centering
% \includegraphics[width=0.5\textwidth]{figs/BackupLink.eps}
% \caption{Indirect syntonization on a redundant and "passive" link.}
% \label{fig:BackupLink}
% \end{figure}
%
%
% A redundant link is an example of indirect syntonization. Figure~\ref{fig:BackupLink}
% shows a grandmaster node A connected to two nodes, B and C, which are synchronized and
% syntonized to the grandmaster. There is a direct link between node B and C which is
% redundant for the synchronization and syntonization spanning trees. The \textit{PTP clock signal} of
% node B is not syntonized to the \textit{L1 clock signal} recovered on its West interface.
% Neither is the \textit{PTP clock signal} of node C on its East interface.
% However, the \textit{PTP clock signals} of
% both nodes are syntonized through the grandmaster. We say that nodes B and C are indirectly
% syntonized. A precise round-trip measurement is possible on such an indirectly syntonized
% link provided the reference model requirements from section~\ref{RefModel} are fulfilled.
%
%
% \section{Layer 1 Syntonization Optional Feature (L1SynOp) proposal}
%
% The L1SynOp shall provide a standard way for the interconnected ports of two PTP nodes to:
% \begin{itemize}
% \item agree on the ability to perform the \textit{precise round-trip measurement},
% \item exchange necessary information,
% \item enable multi-domain syntonization.
% \end{itemize}
% A PTP port that is capable of performing L1SynOp is called \textit{L1SynOp port}. A PTP
% node that has \textit{L1SynOp ports} is called \textit{L1SynOp node}.
%
% The prerequisite condition for the \textit{precise round-trip measurement} is a direct
% link between two \textit{L1SynOp ports}.
% Switches or routers without L1SynOp support are not allowed "in between" the \textit{L1SynOp ports}.
% Such non-L1SynOp network elements can be detected by sending option-specific frames to the
% link-limited reserved address\footnote{01-80-C2-00-00-0E for the IEEE 802.3/Ethernet mapping}.
% These frames are discarded by all the network elements except the \textit{L1SynOp nodes}.
% % This kind of verification shall be provided by the L1SynOp.
%
% Provided a direct link exists, two connected \textit{L1SynOp ports} shall verify that the
% requirements of the reference model are satisfied. In particular, the exchanged information
% shall enable:
% \begin{itemize}
% \item verification of syntonization between the PTP and L1 clock signals on both \textit{L1SynOp ports},
% \item confirmation that both \textit{L1SynOp ports} know their phase offsets,
% \item exchange of the phase offset values so that the \textit{L1SynOp port} in the PTP Slave
% state can use them in its calculations.
% \end{itemize}
% The \textit{L1SynOp port} in the PTP Master state can embed its phase
% offsets into timestamps by correcting their values. If phase offsets are embedded,
% the $t_1$ shall be corrected with $x_{Tx}$ and $t_4$ with $x_{Rx}$.
%
%
% \subsection{L1SynOp information exchange}
%
% A single Type-Length-Value (TLV) is defined for the exchange of all the L1SynOp information.
% It is called the L1InfoTLV. Two types of L1InfoTLV are distinguished by a \textit{Type ID}:
% \begin{enumerate}
% \item Announce-L1InfoTLV. It is suffixed to PTP Announce Messages and/or sent in
% Signaling Messages, depending on the profile specification.
% \item Response-L1InfoTLV. It is sent in Signaling Messages using a reserved destination
% address. It is sent only as a response to a request carried in
% the Announce-L1InfoTLV.
% \end{enumerate}
% A \textit{L1SynOp port} sends Response-L1InfoTLV if it receives Announce-L1InfoTLV
% with the \textit{Response Request flag} set to \textit{True}, see
% Table~\ref{tab:L1InfoTLV}. This mechanism provides means for an \textit{L1SynOp port} to
% (1) verify whether a link is direct, and
% (2) request an update from the other \textit{L1SynOp port}.
% The rules for setting the \textit{Response Request flag} are defined by L1SynOp and can be
% fine-tuned by a profile.
%
% The \textit{Response Request flag} is set to \textit{True} whenever the physical interface goes up.
% It is set to False whenever a Response-L1InfoTLV is received in a response to Announce-L1InfoTLV.
% The flag can be periodically set to \textit{True} for link re-verification. The verification
% is repeated at regular time intervals. The default value for the time interval is zero,
% which means that re-verification is disabled. However, a profile can modify the
% interval accordingly.
%
% A Boundary or Ordinary Clock (BC \& OC) sends
% the Announce-L1InfoTLVs on its \textit{L1SynOp ports} which are in the PTP Master or
% Uncalibrated state. It can be sent in other states if defined by the profile.
%
% A Transparent Clock (TC) sends Announce-L1InfoTLV on all its \textit{L1SynOp ports}
% periodically.
%
%
% A profile that uses L1SynOp defines the condition to activate the L1SynOp implementation-specific mechanisms
% which enable precise round-trip measurement. This condition uses the information provided
% by the L1SynOp.
%
% \subsection{L1InfoTLV content}
% \label{L1InfoTLV}
%
% \begin{table}[!t]
% \centering
% \begin{tabular}{| c | c | } \hline
% \textbf{Name} & \textbf{Values} \\ \hline
% & \\ \hline
% Type ID & Announce, Response \\ \hline
% Response Request flag & True, False \\ \hline
% Link-verified flag & True, False \\ \hline
% Phase offsets known flag & True, False \\ \hline
% Congruent & True, False \\ \hline
% Coupled & True, False \\ \hline
% L1 status & Master, Slave, Not syntonized \\ \hline
% L1 configuration & Master, Slave, Both \\ \hline
% Timestamps corrected & True, False \\ \hline
% Parameter(s) & \textit{Integer}(s) \\ \hline
% Parameter Flag & True, False \\ \hline
% Parameter Valid Flag & True, False \\ \hline
% FrequencyClass & See Table~\ref{tab:freqClass}
% in Section~\ref{FrequencyClass} \\ \hline
% \end{tabular}
% \caption{L1InfoTLV content.}
% \label{tab:L1InfoTLV}
% \end{table}
%
%
% Table~\ref{tab:L1InfoTLV} presents the information that is sent
% in the L1InfoTLV. Each field is described below.\\
% \textbf{Type ID} ensures distinction between the Announce-L1InfoTLV
% and Response-L1InfoTLV. The former is specified by the profile to be either suffixed to the
% PTP Announce or sent in the Signaling Message. The latter
% is required to be sent on request in the Signaling Message to a link-limited address, regardless of
% the profile specification.
% \\
% \textbf{Response Request flag}. If it is set to \textit{True} in the Announce-L1InfoTLV received by
% the \textit{L1SynOp port}, a Response-L1InfoTLV is sent. It is set to False in all the Response-L1InfoTLVs.
% \\
% \textbf{Link-verified flag} is set to \textit{True} if the sending \textit{L1SynOp port} has successfully verified
% that the link is direct.
% \\
% \textbf{Phase offsets known} is set to \textit{True} if the sending \textit{L1SynOp port} "knows" the phase
% offsets between its PTP and L1 clock signals: $x_{Rx}$ and $x_{Tx}$. For example, it is set
% to \textit{True} by an \textit{L1SynOp port} that uses directly the recovered \textit{L1 clock signal} for its
% PTP time-keeping ($x_{Rx}=0$) and uses the same clock signal for transmission ($x_{Tx}=0$). The flag is
% also set to \textit{True} by an \textit{L1SynOp port} that uses its \textit{PTP clock signal} to transmit traffic
% ($x_{Tx}=0$) and measures the phase offset between its \textit{PTP clock signal} and the recovered
% \textit{L1 clock signal} ($x_{Rx}=measurement$).
% \\
% \textbf{Congruent} informs about a profile-wide relation between the PTP synchronization
% spanning tree and the L1 syntonization spanning tree. If it is set to \textit{True}, the L1 spanning tree
% is determined by the PTP spanning tree and the frequency source node is chosen as the same node as
% the PTP grandmaster. For example, if SyncE is used for L1 syntonization, the Ethernet Synchronization
% Message Channel (ESMC) is disabled and SyncE is configured by the PTP stack.
% \\
% \textbf{Coupled} informs about a profile-wide relation between the PTP synchronization
% and the L1 syntonization process. If it is set to \textit{True}, an \textit{L1SynOp port} recommended to enter
% the PTP Slave state waits to do so until the L1 syntonization is completed.
% It allows the definition of profiles which give some level of guarantee that no phase jumps or shifting
% occurs when PTP synchronization happens.
% \\
% \textbf{L1 status} informs about the status of the L1 syntonization on the sending \textit{L1SynOp port}.
% The status is obtained from a media-dependent mechanism (e.g. ITU-T-SyncE or WR-SyncE)
% via a media-independent interface, detailed in section~\ref{mediaIndependentIF}.
% The following \textit{L1 status} values are defined: \textit{L1 Slave}, \textit{L1 Master} and \textit{Not syntonized}.\\
%
%
% \textbf{L1 configuration} informs about whether the sending \textit{L1SynOp port}
% can act as an L1 Master, or an L1 Slave, or both.
% This information is foreseen for congruent mode when the PTP spanning tree controls
% the L1 spanning tree and an L1-specific protocol is not used. This could be the case e.g. if ESMC is disabled.
%
% \textbf{Timestamps corrected} informs about whether the sending \textit{L1SynOp port}
% embeds its phase offsets into timestamps by correcting their values.
% \\
% \textbf{Parameters} -- a set of values that inform about the relation between the
% \textit{L1 clock signal} used for transmitting data and the \textit{PTP clock signal}
% in the domain in which the PTP messages are exchanged.
% These parameters can enable an optional multi-domain syntonization.
% \\
% \textbf{Parameters Flag} informs that the \textit{Parameters} are provided by the
% sending \textit{L1SynOp port}.
% \\
% \textbf{Parameters Valid Flag} informs that the sent \textit{Parameters}
% are valid.
% \\
% \textbf{FrequencyClass} informs about the quality of the \textit{L1 clock signal}
% on the syntonization path from the PRTC. Its usage is left to a profile. It is described in
% details in the following section. %To be investigated.
% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% \subsection{Parameters}
% \label{parameters}
%
% The main intention of exchanging the \textit{Parameters}, as explained in
% Section~\ref{HAinMultiDomain}, is to precisely recreate \textit{PTP clocks} in different
% domains using a single physical \textit{L1 clock signal}.
% The exchanged parameters can be also useful for diagnostics, R\&D, or correction of timestamps.
%
% It is proposed to capture the relation between the \textit{PTP clock signal} and the
% \textit{L1 clock signal} by timestamping periodic events and capturing phase offset between
% the L1 and PTP clock signals at the event occurrence. The events shall be timestamped using the
% \textit {PTP clock} ($t_n$). The phase offset between the rising edge of the \textit{PTP clock
% signal} and the following rising edge of the \textit{L1 clock signal} shall be captured in the
% \textit{PTP clock signal} timebase.
%
% The proposed schema is depicted in Figure~\ref{fig:Parameters}, which shows the events as
% dashed red lines. The generation of events is implementation-specific. An event can be, for
% example, a transmission of the PTP message, such as a Sync Message or a Signaling Message. In
% principle, an event can be virtual, especially if the \textit{PTP clock} is a "paper clock"
% which is only calculated.
% The frequency of events shall be such that the difference between the consecutive (measured)
% phase offsets is much smaller than the period of the \textit{PTP clock signal}, i.e.
% $x_{n+1}-x_n < T_0$.
%
%
% The following values are proposed to be sent in the L1InfoTLV as \textit{Parameters}:
% \begin{itemize}
% \item \textbf{timestamp ($t_n$)} of each event, captured using the \textit{PTP~clock},
% \item \textbf{phase offset ($x_n$)} at the event occurrence, between the rising edge of the
% \textit{PTP clock signals} and the following rising edge of the \textit{L1 clock
% signal}, measured using the \textit{PTP~clock signal} definition of the
% second,
% \item \textbf{flag} to indicate whether the above values are valid.
% \end{itemize}
%
% \begin{figure}[!t]
% \centering
% \includegraphics[width=0.5\textwidth]{figs/Parameters-2.eps}
% \caption{Relation between PTP and L1 clocks expressed using timestamps and
% phase offsets ($t_n$ and $x_n$).}
% \label{fig:Parameters}
% \end{figure}
%
% It has been suggested to enable sending the value of the \textbf{fractional frequency offset}
% between the L1 and PTP clock signals, along with a \textbf{flag} indicating that the value
% is valid. The \textit{fractional frequency offset} value can be calculated by an \textit{L1SynOp
% port} after receiving two consecutive L1InfoTLVs:
% \begin{equation}
% \label{eq:frequencyOffset}
% y_n= \frac{x_n - x_{n-1}}{t_n - t_{n-1}}
% \end{equation}
% There is a number of arguments in favour of sending this seemingly redundant information.
% These arguments are presented below and need to be evaluated:
% \begin{itemize}
% \item
% Let's consider an example where the \textit{PTP clock signal} is generated from the
% \textit{L1 clock signal} by applying the \textit{frequency offset} as a control word,
% as depicted in Figure~\ref{fig:freqOffset}.
% The control algorithm is unknown to the other \textit{L1SynOp node}.
% The \textit{frequency offset} ($y_n$) applied for the subsequent interval ($T_{n+1}$) can be
% calculated only when the interval has passed and all the four values are available:
% $x_n$, $x_{n+1}$, $t_{n}$ and $t_{n+1}$. If the \textit{frequency offset} is sent, the
% other \textit{L1SynOp node} can apply it directly, rather than wait $T$.
% \item
% For some "alternative media" there may not be a well defined timestamping instance
% (or at least not related to packet sending). The decoupling of L1 info from the
% timestamps, by providing the frequency offset value, may possibly give useful
% freedom in implementations or definitions.
% \item
% \textit{Frequency offset} is the "natural" value to control VCXOs, thus can
% be directly supplied to their controller and no extra computation is required.
% \end{itemize}
% \begin{figure}[!t]
% \centering
% \includegraphics[width=0.5\textwidth]{figs/FreqOffset-2.eps}
% \caption{Frequency offset applied as control word for L1 Tx clock signal generation.}
% \label{fig:freqOffset}
% \end{figure}
%
%
%
%
% \subsection{Media independent interface}
% \label{mediaIndependentIF}
%
% The media independent interface enables exchange of information between the
% media-independent \textit{L1SynOp entity} and a media-dependent syntonization mechanism, e.g. WR-SyncE or
% ITU-T-SyncE, as depicted in Figure~\ref{fig:IF}.
% The exchange happens at each \textit{L1SynOp port} in two directions: lower-to-upper and upper-to-lower.
%
% \begin{figure}[!t]
% \centering
% \includegraphics[width=0.3\textwidth]{figs/IF.eps}
% \caption{Media-independent interface.}
% \label{fig:IF}
% \end{figure}
%
% \subsubsection{Lower-to-upper} the media-dependent mechanism provides information to
% the \textit{L1SynOp entity}. The information concerns the status of L1 syntonization
% and is sent in the \textit{L1InfoTLV} as the \textit{L1 status}.
% The interface shall enable the \textit{L1SynOp entity} to query about the syntonization status:
% \begin{itemize}
% \item Is this port an L1-Master that is locked to a source~?
% \item Is this port an L1-Slave that is locked to the recovered \textit{L1 clock signal}~?
% \end{itemize}
%
% \subsubsection{Upper-to-lower} an \textit{L1SynOp port} in congruent mode shall be able to
% configure the syntonization mechanism. The interface shall provide the
% \textit{L1SynOp entity} with the possibility of sending the following requests to the media-dependent mechanism:
% \begin{itemize}
% \item Become L1-Master.
% \item Become L1-Slave.
% \end{itemize}
% The result of the above requests can be verified by using the lower-to-upper queries.
%
% \subsection{Passive ports}
%
% The L1SynOp works on so-called "passive links" which exist between
% ports in the PTP Master and Passive states. A \textit{L1SynOp port} in the PTP Master state
% sends Announce-L1InfoTLVs. If the \textit{Response Request flag} is set to \textit{True},
% the \textit{L1SynOp port} in the PTP Passive state replies
% with the Response-L1InfoTLV. Such an exchange is possible since Signaling Messages are allowed
% by PTP on ports in the Passive state.
% The mutual exchange of information on the "passive link" enables to verify the link and
% the applicability of the \textit{reference model}; the L1SynOp information can be kept up to date.
\section{Ingress and egress latency asymmetry}
Three types of latencies are distinguished:
\begin{itemize}
\item \textbf{static} -- introduced by hardware, e.g. PHY, traces, internal FPGA,
connector; constant to first order, i.e. ageing or temperature
effects are not taken into account; in White Rabbit, this latency
is accounted for through system-wide calibration \cite{wrCalibration}.
\item \textbf{semi-static} -- introduced by PHY's Serializer/Deserializer (SerDes);
constant to fist order while link is established
but varying between link-up cycles; in White Rabbit, this
latency is referred to as \textit{bitslide} and is measured
each time the link is established.
\item \textbf{dynamic} -- variable during operation; in White Rabbit, this latency
is negligible due to physical syntonization.
\end{itemize}
\section{Future work}
\section{Conclusions}
\bibliographystyle{IEEEtran}
\bibliography{IEEEabrv,./L1SynOp}
......
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