Skip to content

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

HA article for ISPCS2015, based on L1SynOp article, starting with the L1SynOp… 

HA article for ISPCS2015, based on L1SynOp article, starting with the L1SynOp article as published on CD
parent 4bcb9621
Hide whitespace changes
Inline Side-by-side
Showing with 42115 additions and 0 deletions
documents/ISPCS2015-HA/L1SynOp.bib 0 → 100644
View file @ 29dd3cb1
@electronic{wr,
title = "{White Rabbit}",
howpublished = {\url{http://www.ohwr.org/projects/white-rabbit}}
}
@article{icalepcs2011,
author = "M. Lipi\'{n}ski and J. Serrano and T. W\l{}ostowski and C. Prados",
title = "{Reliability In A White Rabbit Network}",
journal = "Proceedings of ICALEPCS",
address = "Grenoble, France",
year = "2011",
}
@standard{ieee8023,
title = "IEEE Standard for
Information Technology--Telecommunications and Information Exchange Between
Systems--Local and Metropolitan Area Networks--Specific Requirements Part 3:
Carrier Sense Multiple Access With Collision Detection (CSMA/CD) Access Method
and Physical Layer Specifications - Section Three",
year = "2008",
organization = "IEEE",
address = "New York",
number = "802.3-2008",
}
@standard{synce,
title = "Timing characteristics of a synchronous Ethernet equipment slave clock {(EEC)}",
year = "2007",
number = "G.8262",
organization = "ITU-T",
}
@standard{ieee1588,
title = "IEEE Standard for a Precision
Clock Synchronization Protocol for Networked Measurement and Control Systems",
organization = "IEEE",
address = "New York",
number = "1588-2008",
year = "2008",
}
@article{ispcs2011,
author = "M. Lipi\'{n}ski and T. W\l{}ostowski and J. Serrano and P. Alvarez",
title = "{White Rabbit: a PTP application for robust sub-nanosecond synchronization}",
journal = "Proceedings of ISPCS",
address = "Munich, Germany",
year = "2011",
}
@Misc{wrdraft,
author = "E.G. Cota and M. Lipi\'{n}ski and T. W\l{}ostowski and E.V.D. Bij and J. Serrano",
title = "{White Rabbit Specification: Draft for Comments}",
note = "v2.0",
month = "july",
year = "2011",
howpublished = {\url{www.ohwr.org/documents/21}}
}
@mastersthesis{tom,
author = "T. W\l{}ostowski",
title = "Precise time and frequency transfer in a {White} {Rabbit} network",
month = "may",
year = "2011",
school = "Warsaw University of Technology",
howpublished = {\url{http://www.ohwr.org/documents/80}}
}
@Inproceedings{wrproject,
author = "J. Serrano and P. Alvarez and M. Cattin and E. G. Cota and J. H. Lewis, P.
Moreira and T. W\l{}ostowski and others",
title = "{The White Rabbit Project}",
booktitle = "Proceedings of ICALEPCS TUC004",
address = "Kobe, Japan",
year = "2009",
}
@article{ddmtd,
author = "P. Moreira and P. Alvarez and J. Serrano and I. Darwezeh and T. Wlostowski",
title = "{Digital Dual Mixer Time Difference for Sub-Nanosecond Time Synchronization in Ethernet}",
journal = "Frequency Control Symposium (FCS), 2010 IEEE International",
address = "London, UK",
year = "2010",
}
@electronic{ppsimanual,
title = "{PPSi Manual}",
howpublished = {\\\url{www.ohwr.org/attachments/download/1952/ppsi-manual-130311.pdf}}
}
@electronic{ptpd,
title = "{PTPd project}",
howpublished = {\url{www.ptpd.sourceforge.net}}
}
@electronic{P1588WG,
title = "{IEEE P1588 Working Group}",
howpublished = {\url{ieee-sa.centraldesktop.com/1588public}}
}
@electronic{ptp-proposal,
title = "{White Rabbit PTP Proposal}",
howpublished = {\url{www.ohwr.org/documents/92}}
}
@electronic{gladstone,
title = "{White Rabbit Developers Mailing List}",
howpublished = {\\\url{lists.ohwr.org/sympa/arc/white-rabbit-dev/2014-03/msg00015.html}}
}
@electronic{spec,
title = "{Simple PCIe FMC carrier (SPEC)}",
howpublished = {\\\url{www.ohwr.org/projects/spec}}
}
@electronic{svec,
title = "{Simple VME FMC Carrier (SVEC)}",
howpublished = {\\\url{www.ohwr.org/projects/svec}}
}
@electronic{lgpl,
title = "{GNU Lesser General Public License}",
howpublished = {\\\url{www.gnu.org/licenses/lgpl.html}}
}
@article{better,
author = "Alessandro Rubini",
title = "{PPSi}",
journal = "Better Embedded Conference",
address = "Firenze, Italia",
month = "July",
year = "2013",
howpublished = {\\\url{www.betterembedded.it/conference/talks/ppsi-ptp-ported-to-silicon}}
}
@article{IBIC2013,
author = "J. Serrano and M. Cattin and E. Gousiou and E. van der Bij and T. Włostowski and G. Daniluk and M. Lipi\'{n}ski",
title = "{THE WHITE RABBIT PROJECT}",
journal = "Proceedings of IBIC2013",
address = "Oxford, UK",
year = "2013",
}
@electronic{wrpc,
title = "{White Rabbit PTP Core}",
howpublished = {\\\url{www.ohwr.org/projects/wr-cores/wiki/Wrpc\_core}}
}
@electronic{ppsi-repo,
title = "{PPSi's Public Git Repository}",
howpublished = {\\\url{git://ohwr.org/white-rabbit/ppsi.git}}
}
@article{bitslide,
title = {Measuring propagation delay over a 1.25 Gbps bidirectional data link},
author = {{P.P.M. Jansweijer} and {H.Z. Peek}},
date = {2010-05-31},
file = {ETR2010-01.pdf:/home/mlipinsk/.mozilla/firefox/64taeemp.default-1397950810482/zotero/storage/VPV8BSIP/ETR2010-01.pdf:application/pdf}
}
@article{ExPortConfig,
author = "J.C. Eidson",
title = "{Option to explicitly configure port state}",
journal = "ISPCS2012",
address = "San Francisco",
year = "2012",
howpublished = {\\\url{https://ieee-sa.centraldesktop.com/1588/file/24747556/}}
}
\ No newline at end of file
documents/ISPCS2015-HA/L1SynOp.tex 0 → 100755
View file @ 29dd3cb1
\documentclass[conference]{IEEEtran}
\usepackage{listings}
\usepackage{datetime}
\usepackage{color}
\lstset{basicstyle=\small\ttfamily,frame=lines,captionpos=b}
\usepackage{tikz}
% *** Do not adjust lengths that control margins, column widths, etc. ***
% *** Do not use packages that alter fonts (such as pslatex). ***
% There should be no need to do such things with IEEEtran.cls V1.6 and later.
% (Unless specifically asked to do so by the journal or conference you plan
% to submit to, of course. )
\begin{document}
% paper title
% can use linebreaks \\ within to get better formatting as desired
\title{ High Accuracy:\\ Layer 1 Syntonization Optional Feature}
% author names and affiliations
% use a multiple column layout for up to three different
% affiliations
\author{
\IEEEauthorblockN{Maciej Lipi\'{n}ski}
\IEEEauthorblockA{CERN, Geneva, Switzerland}
\and
\IEEEauthorblockN{Opher Ronen}
\IEEEauthorblockA{Oscilloquartz an ADVA Optical Networking Company, Raanana, Israel}
}
% make the title area
% \date{\today}
\maketitle
\color{gray}
\begin{abstract}
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.
\end{abstract}
% \date{\today}
\section{Introduction: 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.
% \begin{itemize}
% \item \textbf{Asymmetry calibration}
\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}
% The asymmetry between Tx and Rx delays must be known.
\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}
\caption{High Accuracy dependencies.}
\label{fig:HAdependency}
\end{figure}
\begin{figure}[!t]
\centering
\includegraphics[width=0.35\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.
% as well as the knowledge of phase offsets between these clocks signals.
% This means that translates into small and constant frequency offset (y, the derivative of phase
% offset), and some level of syntonization between L1clk and PTPclk.
% Two types of
% syntonization are distinguished in this article: direct and indirect. If the frequency
% offset is zero, syntnization is direct. If the frequency offset is non-zero but
% small enough for phase detection, the syntonization is called indirect.
%
% directly syntonized. If it's sufficiently small, it is said (in this article) to be indirectly syntonized.
% Direct or indirect syntonization is required for precise round-trip measurement
% (this is the assumption for this article).
% \end{itemize}
\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.
% which typically requires dedicated
% hardware support
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}
\label{RefModel}
Figure~\ref{fig:refModel} depicts a single 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{PTP timescale}. Its edge marks the time of day. It might be either a physical signal
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)
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. \color{black}
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},
is marked as $x_{Rx\_A}$ and $x_{Rx\_B}$ for \textit{Node A} and \textit{Node B} respectively.
\begin{figure}[!t]
\centering
\includegraphics[width=0.49\textwidth]{figs/ReferenceModel3.eps}
\caption{Precise round-trip measurement reference model.}
\label{fig:refModel}
\end{figure}
%
% The measurement of precise part of the round trip requires knowledge of all the phase
% offsets between PTP and L1 clocks, i.e. $x_{Tx\_A}$, $x_{Rx\_A}$, $x_{Tx\_B}$, $x_{Rx\_B}$.
% Therefore, syntonization between this clock is required .
% Consequently, the phase offset
% between these clocks ($x_{Tx\_A}$, $x_{Rx\_A}$, $x_{Tx\_B}$, $x_{Rx\_B}$) is constant or
% slowly changing, thus measurable. The change rate of phase offset is quantified as
% frequency offset:
% \begin{equation}
% \label{eq:freqOffset}
% y(t)= \frac{d}{dt}x(t)
% \end{equation}
% The frequency offset can be derived from subsequent samples of phase offsets, thus it
% is a mathematically redundant information. However, it is used in the model out of the
% following reasons:
% \begin{itemize}
% \item distinguish between the case where phase difference is important and when it is
% not. If frequency offset is mentioned, it means that phase \& time is not considered
% \item simplification of description (e.g. it is easier to say that frequency offset between
% clock A and B should be 1ppm)
% \item it is commonly used and understood in Telecom
% \item phase offset can be a control information, whereas phase difference is retrospective
% information
% \end{itemize}
% In a generic case, provided the L1 and PTP clock signals are syntonized, the fine part of the
% round-trip can be calculated knowing all the phase offset values, i.e. $x_{Tx\_A}$, $x_{Tx\_B}$,
% $x_{Rx\_A}$, and $x_{Rx\_B}$. \color{gray}
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). \color{gray}
% is:
% \begin{equation}
% \label{eq:phaseOffset}
% x= x_{Tx\_A} + x_{Rx\_A} + x_{Tx\_B} + x_{Rx\_B}
% % x= (x_{Tx\_A} - x_{Rx\_A}) + (x_{Tx\_B} - x_{Rx\_B})
% \end{equation}
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
or derived in some other way.
% It is the PTP slave port to use the "knowledge" about all phase offsets, therefore the slave
% must be provided with the following information:
% \begin{itemize}
% \item whether PTP master port knows the value of its offsets
% \item what are the values of offsets (i.e. $x_{Tx}$ and $x_{Rx}$) -- these are possibly
% embedded into the timestamps
% \end{itemize}
The reference model relies on the following requirements:
\begin{itemize}
\item The PTP and L1 clock signals are syntonized at a level sufficient to measure their phase offsets.
\item Each node "knows" the phase offset between its PTP and L1 clock signals.
\item The PTP Slave node is informed that the PTP Master node "knows" its phase offsets.
\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}
\color{black}
\section{High Accuracy in multi-domain PTP networks}
\label{HAinMultiDomain}
% \begin{figure}[!t]
% \centering
% \includegraphics[width=0.4\textwidth]{figs/MultiDomainSynt.eps}
% \caption{xxxxx.}
% \label{fig:MultiDomainSynt}
% \end{figure}
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.\\
\color{gray}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%5
% PTP networks can support independent \textit{timescales}, each in a separate \textit{domain}.
% The \textit{timescale} for a \textit{domain} is established by a grandmaster.
% Many \textit{timescales} 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
% timescales. Frequency offsets between such \textit{timescales} 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{timescales} 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{timescales}.
% 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.
%
% \begin{figure}[!t]
% \centering
% \includegraphics[width=0.5\textwidth]{figs/NonCongruency2.eps}
% \caption{xxxxx 2.}
% \label{fig:nonCongruency}
% \end{figure}
\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}
% The blue and red frequencies in the example from the previous section are required to be indirectly
% syntonized for the described mechanism to work. In particular, the change rate of the phase offset must
% be small enough for it to be measurable and useful. This is an example of indirectly
% syntonized frequencies originating from reference sources.
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.
% exchange of the phase offset values so that the \textit{L1SynOp port} in the PTP Slave state
% can correct 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}$.
% Optionally, the exchanged information shall include:
% \begin{itemize}
% \item relation between the different \textit{PTP timescales} based on the \textit{L1 clock signal},
% \item verification of the quality of the \textit{L1 clock signal}.
% \end{itemize}
\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.
% new
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
% Sequence Number & \textit{Integer} \\ \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 locked & True, False \\ \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.\\
% \begin{table}[ph!]
% \subsubsection{Profile-specific information}
% The exchanged information can be divided into 3 groups:
% \begin{itemize}
% \item profile-specific configuration which shall be the uniform for all the nodes using
% L1SynOp within a single profile, i.e.
% \textit{Congruent}, \textit{Coupled}, \textit{Parameter Dynamic Flag}
% \item information reflecting operational state or configuration of the port, i.e.
% \textit{Link-verified flag},\textit{Phase offsets known flag},\textit{L1 status},
% \textit{L1 locked},\textit{L1 configuration},
% \item
% \end{itemize}
%
%
% This parameters can be seen as profile-specific configuration which shall be the uniform for
% all the nodes using L1SynOp within a single profile. This is because the parameters have
% effects which exceed single link, e.g. influence syntonization spanning tree or require
% proper hardware support.
% \subsubsection{Operational information}
\textbf{Type ID} ensures distinction between the Announce-L1InfoTLV
% that can be specified by the
% profile to be either suffixed to the PTP Announce or sent in a Signaling Messages,
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}.\\
% \begin{itemize}
% \item \textit{L1 Slave} -- the \textit{PTP clock signal} is syntonized to the \textit{L1~Rx~clock~signal}
% on the sending \textit{L1SynOp port}.
% \item \textit{L1 Master} -- the \textit{L1 Tx clock signal} on the sending \textit{L1SynOp port} is syntonized to the
% \textit{PTP clock signal}. The \textit{PTP clock signal} is locked to a source,
% such as \textit{L1 clock signal} on another port or an external source.
% \item \textit{Not syntonized} -- otherwise.
% \end{itemize}
% In the congruent mode, the \textit{L1 status} should reflect the setting provided by the L1SynOp according
% to BMCA. In the
% non-congruent mode, it informs about the settings decided by a PTP-independent
% mechanism/protocol, such as SyncE algorithm based on hand
% configuration and Ethernet Synchronization Message Channel (ESMC).
% \\
\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.
% If the new revision of 1588 allows configuration of PTP ports to be slave-only or master-only,
% it will do the same work. However, such configuration in a
% boundary
% \textit{Master} means that
% the port is an active source of frequency. \textit{Slave} means that the PTP clock of
% the node should be locked to the L1 clock recovered on the sending port. Otherwise,
% \textit{non} is sent.
% \\
% \textbf{L1 locked} -- it informs whether the sending node is locked to a source of
% frequency, i.e. if the sending port is L1 Slave, \textit{L1 locked} is set to True if
% the PTP clock is locked to the L1 clocked recovered on the sending port; if the sending
% port is L1 Master, \textit{L1 locked} is set to True if another port of the node is in L1
% Slave state and locked.
\\
\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.
% They are
% described in more details in section~\ref{parameters}.
\\
\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.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\color{black}
\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.
% If possible and applicable, an event might be defined in future to facilitate control aspects.
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{interval} between consecutive events, captured using the \textit{L1~clock~signal}:~$T_n$,
\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{Frequency Class}
\label{FrequencyClass}
\textit{Frequency Class} is a numerical representation of the syntonization characteristics
of the \textit{L1 clock signal} provided by an \textit{L1SynOp node}; the
lower the value, the "better" the characteristics.
It is not based on a real-time measurement but rather a set of requirements that are fulfilled
by the equipment. The requirements shall rather concern noise transfer/generation than
holdover/stability (to be discussed). For example, if an ITU-T SyncE is used by the
\textit{L1SynOp node} for the L1 syntonization, the \textit{Frequency Class} represents the
characteristics specified by the appropriate ITU-T Recommendation.
Table~\ref{tab:freqClass} defines \textit{Frequency Classes}. The \textit{Ideal} class
represents a clock signal characteristics that are impossible to provide, thus the value
should never be used and new frequency classes should be added in the reserved spaces
(values greater than 0x0000). The \textit{No L1} class represents a node with a free-running
oscillator. In between \textit{Ideal} and \textit{No L1}, different \textit{L1 clock signal}
characteristics are mapped into \textit{Frequency Class} values.
% This includes mapping of the
% ITU-T clocks, PTP-base syntonization and characteristics required to achieve sub-ns synchronization
% (WR).
% Likewise,
% if a profile specifies WR SyncE to be used by the L1SynOp as the syntonization mechanism, the
% the \textit{Frequency Class} represents WR characteristics which need to be specified somewhere.
\begin{table}[!t]
\centering
\begin{tabular}{| c | c | c | } \hline
\textbf{Value} & \textbf{Name} & \textbf{Specification} \\ \hline
% & & \\ \hline
0x0000 & Ideal & \\ \hline
\textcolor{gray}{Reserved}& & \\ \hline
0x0010 & WR & IEEE1588-201x Appendix \\ \hline
% \textcolor{gray}{Reserved}& & \\ \hline
% 0x0100--0x0200 & Enhanced SyncE & ITU-T Recommendations \\ \hline
\textcolor{gray}{Reserved}& & \\ \hline
0x0100--0x0200 & SyncE & ITU-T Recommendations \\ \hline
\textcolor{gray}{Reserved}& & \\ \hline
0xF000 & PTP & No specification \\ \hline
\textcolor{gray}{Reserved}& & \\ \hline
% 0xFF00 & Unknown & No specification \\ \hline
% \textcolor{gray}{Reserved}& & \\ \hline
0xFFFF & No L1 & \\ \hline
\end{tabular}
\caption{Frequency Classes -- initial proposal, to be finished.}
\label{tab:freqClass}
\end{table}
The \textit{L1SynOp} specifies the rules for exchanging \textit{Frequency Class}
in the \textit{L1InfoTLV} but leaves to the profile the specification of how the information
is used and propagated by the \textit{L1SynOp nodes}. Two ideas of how the \textit{Frequency Class}
could be used by a profile are presented below:
\subsubsection{Worst class in the path}
The \textit{L1InfoTLV} carries the value of the "worst" \textit{Frequency Class} node in the
path from the source of frequency. An \textit{L1SynOp node} knows the value of its
\textit{Frequency Class}, the node sends this value if it is "worse" than the
value received from the direction of the frequency source. Otherwise, it forwards the
value of the \textit{Frequency Class} received. This enables, for example, to ensure that an
\textit{L1SynOp node} with the White Rabbit \textit{Frequency Class} is connected with the
frequency source through a path consisting only of \textit{L1SynOp nodes} of the same
\textit{Frequency Class}. Connecting an \textit{L1SynOp node} of a "worse" class to an
\textit{L1SynOp node} of a "better" class can be allowed, but not the other way around.
\subsubsection{Path trail}
The \textit{L1InfoTLV} carries a dynamic list of 2-tuples which trails the path from the frequency
source. Each 2-tuple contains two values: \textit{Frequency Class}, and \textit{Counter}
of the \textit{L1SynOp nodes} of that \textit{Frequency Class} in the path from the source
of frequency.
% \begin{itemize}
% \item \textit{Frequency Class},
% \item Counter of the \textit{L1SynOp nodes} of that \textit{Frequency Class} in the path from
% the source of frequency.
% \end{itemize}
% The list is dynamic and contains only the \textit{Frequency Classes} of the nodes that are
% in the path.
An \textit{L1SynOp node} is required to update the \textit{Frequency Class} list by either (1)
incrementing the counter in an existing 2-tuple, or (2) adding a new tuple with its
\textit{Frequency Class}.
% The list trails the syntonization spanning tree.
A profile that uses \textit{L1SynOp} defines how the information is used. For example, a WR
Profile would not use the path that contains non-WR nodes. A different profile could define
an algorithm that uses the \textit{Frequency Class} list to compare different paths; then, the
result of the comparison could be used to construct syntonization and/or synchronization
spanning tree.
\color{gray}
\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.
% There profile can specify that the PTP Passive port sends periodically
% Announce-L1InfoTLVs to update the adjacent node on its state.
\section{A White Rabbit profile using L1SynOp}
\begin{figure}[!t]
\centering
\includegraphics[width=0.35\textwidth]{figs/MessageExchangeWR.eps}
\caption{Exchange of L1InfoTLVs in a White Rabbit profile using L1SynOp.}
\label{fig:HAexchange}
\end{figure}
The White Rabbit HA profile that uses L1SynOp can be defined as follows (see Figure~\ref{fig:HAexchange}):
\begin{itemize}
\item IEEE 802.3/Ethernet Mapping.
\item Medium-dependent mechanism used: WR-SyncE \\(\textit{FrequencyClass} = WR).
\item Configuration: \\
\textit{Congruent} = \textit{True}; \\
\textit{Coupled} = \textit{True}; \\
\textit{Parameters Flag} = False.
\item Timestamps are corrected with the phase offset values:\\
\textit{Timestamps corrected} = \textit{True}.
\item Announce-L1InfoTLV exchange rules:
\begin{itemize}
\item PTP Master state: it is suffixed to the PTP Announce Message
\item PTP Uncalibrated state: it is sent in Signaling Messages at
small intervals.
\end{itemize}
\item Response-L1InfoTLV is sent in Signaling Messages addressed to 01-80-C2-00-00-0E
\item L1SynOp is considered active on a link if the conditions below are fulfilled:
\begin{itemize}
\item The profile-specific configuration agrees on both \textit{L1SynOp ports},
\item The \textit{FrequencyClass} indicates that the path from the PRTC is exclusively WR,
\item The \textit{L1 configuration} agrees on both \textit{L1SynOp ports},
\item Before a timeout expires, the \textit{L1SynOp port} in the PTP Uncalibrated state: \\
(1) confirms that the \textit{Link-verified flag} of both nodes is \textit{True};\\
(2) confirms that the \textit{L1 state} of the PTP Master is L1-master; \\
(3) requests to \textit{become L1-Slave} and confirms that its \textit{L1 state} is L1-Slave;\\
(4) confirms that the \textit{Phase offsets known flag}s of both ports are \textit{True};
\item As soon as all the above steps and conditions are fulfilled, the port exits the PTP Uncalibrated
state and activates the mechanisms to account for the fine part of the round-trip.
Otherwise, if the timeout expires, the port exits the PTP Uncalibrated
state but does not activate the mechanisms.
\end{itemize}
If the conditions above are not fulfilled, PTP synchronization is performed without activating L1SynOp-related mechanisms.
\end{itemize}
% ADD
% - disabled SSM, use config
\section{A Telecom profile to use L1SynOp}
% \begin{figure}[!t]
% \centering
% \includegraphics[width=0.3\textwidth]{figs/MessageExchangeWR.eps}
% \caption{xxxxx 2.}
% \label{fig:nonCongruency}
% \end{figure}
A Telecom PTP \textit{time and phase profile} that uses L1SynOp can be defined as follows:
\begin{itemize}
\item IEEE 802.3/Ethernet Mapping.
\item Medium-dependent mechanism: ITU-T-SyncE \\
(\textit{FrequencyClass} = SyncE).
\item Configuration: \\
\textit{Congruent} = False; \\
\textit{Coupled} = False; \\
\textit{Parameters Flag} = \textit{True}.
\item Timestamps are corrected with the phase offset values:\\
\textit{Timestamps corrected} = \textit{True}.
\item Announce-L1InfoTLV is suffixed to the PTP Announce Message.
\item Response-L1InfoTLV is sent in Signaling Messages addressed to 01-80-C2-00-00-0E.
\item L1SynOp is considered active on a link if the conditions below are fulfilled:
\begin{itemize}
\item The profile-specific configuration agrees on both \textit{L1SynOp ports},
\item The \textit{FrequencyClass} indicates the path from the PRTC is not worse than SyncE,
\item The \textit{L1 configuration} agrees on both \textit{L1SynOp ports},
\item The \textit{Link-verified flag} of both nodes is \textit{True}.
\end{itemize}
If the conditions above are not fulfilled, PTP synchronization is performed without
activating L1SynOp-related mechanisms. If they are fulfilled, L1SynOp is activated
immediately.
\end{itemize}
% \section{Conclusions}
% \label{conclusions}
% This paper presents a proposal which is not an official HA SC proposal. It is an
% alternative to previously presented proposals which attempts to abstract and decouple
% protocol mechanisms from the hardware implementation and simplify things.
\color{black}
\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}.
% - L1 config - only for congruent, only because we have no mean to control L1, so we need
% to do it from ptp
% - Phase known - more for non-congruent cases, where we have no control over L1 but need to
% somehow adjust to the situation
% This is used in WR to enable interoperability between \textit{L1SynOp nodes} and PTP
% nodes implementing default (or other) profile. For example, a \textit{L1SynOp node} can
% switch to the default PTP profile if connected to the PTP node not supporting \textit{L1SynOp}.
% While the IEEE1588-2008 does not provide proper\footnote{It is possible to
% use management messages to query PTP device about the profile, but this feature is not
% obligatory and therefore unreliable.} means of recognizing profiles, the current revision
% will likely introduce \textit{Profile ID TLV} to do the job. In such a case, the
% L1InfoTLV can be still useful to add some flexibility, however profile recognition will fall
% onto the Profile ID TLV. For example, it can enable to define
% profiles that optionally use L1SynOp. It can also enable using the L1SynOp without
% implementing any profile.
\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.
% The hardware support required for an \textit{L1SynOp node} to act as a slave or a master
% differs. For example, if properly configured, an ITU-T SyncE switch with upgraded PTP stack
% can suffice to act as an \textit{L1SynOp slave node}. This is possible if the L1 clock signal
% is configured to be directly looped back at the slave, and the phase measurement is done
% on the \textit{L1SynOp master node}, provided a proper hardware support.
% On the other hand, the same ITU-T SyncE switch cannot become a \textit{L1SynOp master node},
% since it provides no hardware to measure phase.
%
% While the \textit{L1 Config} flag is used
% to influence the spanning tree and prevent an \textit{L1SynOp port} from entering that
% it has no mean to support, the \textit{Phase offsets known flag} informs the other
% \textit{L1SynOp port} whether the already entered state is provides enough information
% (i.e. phase offset knowledge) to satisfy the reference model and perform \textit{L1SynOp}
% enhancements.
\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}
% \begin{itemize}
% \item defining values of this flags in the profile,
% \item defining values of this flags as configuration by operators,
% \item defining profiles which interoperate with other profile where the values can vary.
% \end{itemize}
%
% The \textit{L1 status} provides a \textit{L1SynOp node} with the information about the
% status of L1 syntonization, its own and that of the \textit{L1SynOp node} connected to it.
% This information have a number of applications (Used in WR profile):
% \begin{itemize}
% \item An \textit{L1SynOp node} that is required to be "coupled", knows when it can start
% locking to the L1 Master.
% \item An \textit{L1SynOp node} that is required to be "congruent", knows whether the
% L1 configuration is applied
% \end{itemize}
%
% The \textit{L1 configuration} parameter enables to define a port to be Master-- or Slave--only.
% It can be used in the following use cases:
% \begin{itemize}
% \item Reflect limitation of the hardware. For example, implementation of L1 Slave
% requires much more effort and might be provided only on chosen ports. This ports
% are then configured to be Master-only.
% \item Hand-configuration of topology to avoid automatic reconfiguration
% \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}.
\color{gray}
\bibliographystyle{IEEEtran}
\bibliography{IEEEabrv,./L1SynOp}
\end{document}
% LocalWords: PPSi picoseconds SyncE CERN WRPTP Kconfig struct TimeInternal
% LocalWords: tstamp recv send init
documents/ISPCS2015-HA/Makefile 0 → 100644
View file @ 29dd3cb1
all: dvi ps pdf
dvi: L1SynOp.dvi
ps: L1SynOp.ps
pdf: L1SynOp.pdf
L1SynOp.dvi: L1SynOp.tex L1SynOp.bbl
latex L1SynOp
while ( grep -q \
'^LaTeX Warning: Label(s) may have changed' L1SynOp.log ); \
do latex L1SynOp; \
done
latex L1SynOp
L1SynOp.ps: L1SynOp.dvi
dvips L1SynOp.dvi
L1SynOp.pdf: L1SynOp.ps
ps2pdf -dPDFSETTINGS=/prepress -dSubsetFonts=true -dEmbedAllFonts=true -dMaxSubsetPct=100 -dCompatibilityLevel=1.4 L1SynOp.ps
L1SynOp.bbl: L1SynOp.bib
latex L1SynOp
bibtex L1SynOp
clean:
-rm *.log *.aux *.bbl *.blg *.dvi *.ps *~ *.pdf
.PHONY : all clean pdf
documents/ISPCS2015-HA/figs/BackupLink.eps 0 → 100644
View file @ 29dd3cb1
This source diff could not be displayed because it is too large. You can view the blob instead.
documents/ISPCS2015-HA/figs/FreqOffset-2.eps 0 → 100644
View file @ 29dd3cb1
This source diff could not be displayed because it is too large. You can view the blob instead.
documents/ISPCS2015-HA/figs/HAdependency.eps 0 → 100644
View file @ 29dd3cb1
This source diff could not be displayed because it is too large. You can view the blob instead.
documents/ISPCS2015-HA/figs/IF.eps 0 → 100644
View file @ 29dd3cb1
This source diff could not be displayed because it is too large. You can view the blob instead.
documents/ISPCS2015-HA/figs/MessageExchangeWR.eps 0 → 100644
View file @ 29dd3cb1
This source diff could not be displayed because it is too large. You can view the blob instead.
documents/ISPCS2015-HA/figs/NonCongruency.eps 0 → 100644
View file @ 29dd3cb1
This source diff could not be displayed because it is too large. You can view the blob instead.
documents/ISPCS2015-HA/figs/Parameters-2.eps 0 → 100644
View file @ 29dd3cb1
This source diff could not be displayed because it is too large. You can view the blob instead.
documents/ISPCS2015-HA/figs/ReferenceModel3.eps 0 → 100644
View file @ 29dd3cb1
This source diff could not be displayed because it is too large. You can view the blob instead.
documents/ISPCS2015-HA/figs/bitslide.eps 0 → 100644
View file @ 29dd3cb1
This source diff could not be displayed because it is too large. You can view the blob instead.
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