Skip to content

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

ISPCS2012 special session paper - corrections by Eric

parent 667be371
Hide whitespace changes
Inline Side-by-side
Showing with 74 additions and 60 deletions
documents/ISPCS2012-specialSession_submision/wrspec.tex
View file @ f485ae85
......@@ -86,8 +86,8 @@
\section {Title:} High accuracy extension/option/profile
\section {Author:} Maciej Lipinski
\section {Affiliation:} European Organization for Nuclear Research (CERN)/Warsaw University of Technology (WUT)
\section {Date of submission:} 14 May 2012
\section {Affiliation:} CERN -- European Organization for Nuclear Research / Warsaw University of Technology
\section {Date of submission:} 21 May 2012
\section {Clauses of IEEE 1588-2008 (V2) proposed for revision:}
\begin{itemize*}
\item Changes required in clauses: 7.6.2.5, 14.1.1, Annex F.4 and Annex J
......@@ -95,74 +95,75 @@
\end{itemize*}
\section {Character of the proposed revision:}
New feature. This revision proposes extending PTPv2 to enable high accuracy of synchronization -- the level
of accuracy (i.e. sub-nanosecond) beyond what is achievable by the current "standard" implementations.
New feature. This revision proposes extending PTPv2 to enable a high accuracy of synchronization --
the sub-nanosecond level of accuracy is beyond what is achievable by the current "standard" implementations.
\section {Reason or rational for the proposed revision}
It has been shown (see \cite{WRinGS} and \cite{WRinISPCS2011}) that PTPv2 can be implemented such that
It has been shown \cite{WRinGS}\cite{WRinISPCS2011} that PTPv2 can be implemented in such a way that
a sub-nanosecond accuracy and picoseconds jitter of synchronization can be achieved over a number of
boundary clocks and several kilometers of cables. Such implementation benefits from additional mechanisms
boundary clocks and several kilometers of cables. Such an implementation benefits from additional mechanisms
(i.e. Synchronous Ethernet \cite{SynchE}, phase detection \cite{icalepcs09}) incorporated into PTPv2 in
a way that does not break interoperability with "standard" implementations while improving greatly the performance.
The mechanisms used could be incorporated into the IEEE 1588 standard to indicate to the vendors the (optional) means to enhance
a way that keeps interoperability with "standard" implementations while improving greatly the performance.
The mechanisms used could be incorporated into the IEEE 1588 standard to indicate to the vendors the optional means to enhance
PTP's performance and to ensure interoperability of such high-accuracy implementations.
The presented solution (mainly in section~\ref{highAccuracy}) is based on \cite{WRPTP}, the author sees a potential for the solution's
further simplification/alignment with PTP in the process of standardization.
The presented solution is based on \cite{WRPTP}
% , the author sees a potential for the solution's
% further simplification/alignment with PTP in the process of standardization.
\section {Proposed revision}
\section {Proposed revision:}
%loads of text here
In this section four types of changes are proposed:
(1) addition/modification of the transport annex;
(2) addition of an optional "high accuracy" clause;
(3) addition of "Default High Accuracy" profile to Annex J and
(4) minor changes
to the existing clauses to accommodate (1)-(3).
In this section four types of changes are proposed: \\
section~\ref{syncEandEthernet} -- addition/modification of the transport annex;\\
section~\ref{highAccuracy} -- addition of an optional "high accuracy" clause; \\
section~\ref{HAprofile} -- addition of the "Default High Accuracy" profile to Annex J ; \\
section~\ref{PTPchanges} -- minor changes to the existing clauses to accommodate (1)-(3).
\subsection{Syntonization capability of IEEE 802.3/Ethernet}
\subsection{Syntonization capability of IEEE 802.3/Ethernet (modification to Annex F.4)}
\label{syncEandEthernet}
It is proposed to extend Annex F (it is also possible to add a new annex) such that the physical syntonization
of clocks is foreseen (i.e. by using Synchronous Ethernet). Proposed changes to Table F.2 and addition of
new Table F.3 are presented below.
of clocks is foreseen (i.e. by using Synchronous Ethernet). Proposed changes to Table F.2 and the addition of
a new Table F.3 are presented below.
\begin{table}[ht!]
\caption{Table F.2 -- Ethernet transportSpecific field}
\caption{\textcolor{gray}{Table F.2 -- Ethernet transportSpecific field} (Changes to existing Table F.2)}
\centering
\begin{tabular}{| l | l | p{9cm} |} \hline
\textbf{Enumeration} & \textbf{Value}(hex) & \textbf{Specification} \\ \hline
DEFAULT & 0 & All PTP layer 2 Ethernet transmission not covered by another enumeration value. \\ \hline
ETHERNET\_AVB & 1 & This value is reserved for use in connection with the standard being developed by the IEEE 802.1 AVB Task Group as P802.1AS \\ \hline
ETHERNET\_SYNCE & 2-6 & Ethernet $+$ Synchronous Ethernet, further specified in Table~F.3 \\ \hline
Reserved & 6-F & Reserved for assignment in future version s of the standard \\ \hline
\textcolor{gray}{\textbf{Enumeration}} & \textcolor{gray}{\textbf{Value}(hex)} & \textbf{\textcolor{gray}{Specification}} \\ \hline
\textcolor{gray}{DEFAULT} & \textcolor{gray}{ 0} & \textcolor{gray}{All PTP layer 2 Ethernet transmission not covered by another enumeration value} \\ \hline
\textcolor{gray}{ETHERNET\_AVB} & \textcolor{gray}{1} & \textcolor{gray}{This value is reserved for use in connection with the standard being developed by the IEEE 802.1 AVB Task Group as P802.1AS} \\ \hline
ETHERNET\_SYNCE&2-6 & Ethernet $+$ Synchronous Ethernet, further specified in Table~F.3\\ \hline
\textcolor{gray}{Reserved} & \textcolor{gray}{ 6-F} & \textcolor{gray}{Reserved for assignment in future version s of the standard} \\ \hline
\end{tabular}
\label{tab:transportSpecific}
\end{table}
% \vspace*{-2em}
\begin{table}[ht!]
\caption{Table F.3 - Syntonization capable Ethernet transportSpecific values}
\caption{Table F.3 - Syntonization capable Ethernet transportSpecific values (new table)}
\centering
\begin{tabular}{| l | p{13cm} |} \hline
\textbf{Value}(hex) & \textbf{Specification} \\ \hline
2 or 3 & Syntonization distribution topology aligned with PTP topology
(i.e SyncE without using Ethernet Synchronization Messaging Channel (ESMC)) \\ \hline
(i.e~SyncE without using Ethernet Synchronization Messaging Channel (ESMC) \cite{SynchE2}) \\ \hline
4 or 5 & Syntonization distribution topology independent from PTP topology
(i.e. SyncE using Ethernet Synchronization Messaging Channel (ESMC)) \\ \hline
(i.e.~SyncE using Ethernet Synchronization Messaging Channel (ESMC) \cite{SynchE2}) \\ \hline
2 or 4 & Frequency loopback disabled \\ \hline
3 or 5 & Frequency loopback enabled \\ \hline
\end{tabular}
\label{tab:transportSpecific}
\end{table}
When frequency loopback is enabled, a port (acting as a slave) which recovers frequency from a data stream
shall, after proper phase alignment, encode such frequency into data stream and send back to the source
When frequency loopback is enabled, a port (acting as a slave) which recovers frequency from the incoming data stream
shall, after proper phase alignment, encode such frequency into the outgoing data stream and send it back to the source
(a port acting as a master).
\subsection{High Accuracy (optional) clause}
\subsection{High Accuracy (optional) clause (addition to Annex J)}
\label{highAccuracy}
It is proposed to add optional clause which could be implemented by devices for high accuracy synchronization.
The actions which are defined in this clause take place while a PTP link is being established -- in the
UNCALIBRATED state of BMC-selected slave port and in the MASTER state of BMC-selected master port.
It is proposed to add an optional clause that could be implemented by devices for high accuracy synchronization.
The actions which are defined in this clause take place while a PTP link is being established; that is in the
UNCALIBRATED state of the BMC-selected slave port and in the MASTER state of BMC-selected master port.
This clause presents the following requirements to the hardware/implementation:
\begin{itemize*}
\item It shall feature constant rx/tx latencies during operation and inform higher layers
......@@ -172,15 +173,15 @@ This clause presents the following requirements to the hardware/implementation:
be included in the correctionField as specified in PTPv2.
\item It shall be able to generate the calibration pattern on request
(RD+K28.7 code group, Appendix 36A.2 of IEEE802.3).
\item It shall provide estimation of the asymmetry using parameters provided by this clause
\item It shall provide an estimation of the asymmetry using parameters provided by this clause
(e.g. using Link Delay Model, tx/rx latencies and relative delay coefficient as explained in \cite{WRPTP}).
\end{itemize*}
\subsubsection{Definition of Data Set Fields}
The implementation-specific Data Set fields are defined to store (per-port) a clause specific data:
The implementation-specific Data Set fields are defined to store per-port clause specific data:
(1)~values of hardware characteristics (e.g.: rx/tx latencies);
(2)~configuration parameters (e.g.: whether calibration patter is required, calibration period/pattern);
(2)~configuration parameters (e.g.: whether a calibration pattern is required, calibration period/pattern);
(3)~current state of the Finite State Machine (section~\ref{fsm}).
The (re-)initialization methods and values are defined.
......@@ -191,7 +192,7 @@ It is proposed to define TLVs recognized by tlvType HIGH\_ACCURACY\_OPTION
(extension to clause 14.1.1) of the format presented in Table~\ref{tab:TLVformat}. Different messages of such TLV type
are recognized by messageID as defined in Table~\ref{tab:MessageId}. These TLVs are used to
exchange clause-specific data and trigger transitions in the Finite State Machine (section~\ref{fsm}).
They are carried in Signaling Messages or suffixed to Announce message (see Table~\ref{tab:MessageId}).
They are carried in Signaling Messages or suffixed to an Announce message (see Table~\ref{tab:MessageId}).
\begin{table}[h!]
......@@ -233,15 +234,16 @@ ANN\_SUFIX & 0x2000 & Announce \\ \hline
\subsubsection{Finite State Machine}
\label{fsm}
The Finite State Machine (FSM) controls the process of establishing a high accuracy (HA)
link between two ports implementing high accuracy option. The FSM shall be non-preemptive with regards
The Finite State Machine (FSM) controls the process of establishing a high accuracy (abbreviated \textit{HA}
in the figures)
link between two ports implementing high accuracy option. The FSM shall be non-preemptive with regard
to the execution of the PTP State Machine. It enables syntonization over the physical layer,
optional measurement of tx/rx latencies and exchange of their values across the link. The FSM shall be
executed in the PTP UNCALIBRATED state on the port which recommended (by BMC) state is SLAVE --
called Slave -- and in the PTP MASTER state on the port which recommended state is MASTER -- called
executed in the PTP UNCALIBRATED state on the port on which the recommended (by BMC) state is SLAVE --
called Slave -- and in the PTP MASTER state on the port which the recommended state is MASTER -- called
Master. The FSM is depicted in Figure~\ref{fig:wrFSM} and described in Table~\ref{tab:wrFSMdesc}.
The FSM shall be started when a port in non-Slave state is recommended to be Slave by the BMC and
appropriate conditions are fullfiled (e.g. both communicating ports implement the high accuracy option).
The FSM shall be started when a port in non-Slave state is recommended (by BMC) to be Slave and
appropriate conditions are fulfilled (i.e. both communicating ports implement the high accuracy option).
% \vspace*{-1.0em}
\begin{table}[hp!]
\caption{State definitions}
......@@ -266,11 +268,11 @@ LOCKED & Slave-only state. Upon entering this state, the Slave send
CALIBRATION & In this state, optional calibration of the port's rx and/or
tx latencies can be performed.
Upon entering this state, the Port sends a \textit{CALIBRATE} message to
the other Port -- in the message the characteristics of calibration pattern
the other Port. In this message the characteristics of calibration pattern
are sent. If calibration is not needed, the next state is entered, otherwise an
indication from the hardware
that the calibration has been finished successfully is awaited. \\ \hline
CALIBRATED & Upon entering this state, the WR Port sends a \text{CALIBRATED} message with the
CALIBRATED & Upon entering this state the WR Port sends a \text{CALIBRATED} message with the
values of its rx/tx latencies. \\ \hline
RESP\_CALIB\_REQ & The Port's action in this state depends on the content of CALIBRATION message.
If required, the calibration pattern shall be enabled (sent). The pattern shall be
......@@ -297,34 +299,38 @@ HA\_LINK\_ON & Upon entering this state, the Master sends the HIGH\_ACCUR
\subsubsection{Event definition}
Implementation of two PTP State Machine transition events described as \textit{implementation-specific} is defined in this clause.
The implementation of two PTP State Machine transition events described as \textit{implementation-specific} is defined in this clause.
The \textbf{SYNCHRONIZATION\_FAULT} shall occur when syntonization break is detected by hardware
(link disconnected) or high accuracy mode is exited out of other reason (e.g. management). It shall result in
(e.g. link disconnected) or the high accuracy mode is exited out of another reason (e.g. management). It shall result in
clearing the record of foreign masters. The \textbf{MASTER\_CLOCK\_SELECTED} shall occur on the successful
completion of the FSM execution on the port selected by BMC as Slave and
being in PTP\_UNCALIBRATED state. Consequently, the PTP\_SLAVE state shall be entered.
\subsection{High Accuracy Default Profile}
\label{HAprofile}
The delay request-response mechanism shall be the only path delay measurement mechanism for this profile.
It shall define default mapping using Annex F (networkProtocol=0003)
with transportSpecific flag set to 3 (i.e. SyncE without ECMS and with frequency loopback enabled).
with the transportSpecific flag set to 3 (i.e. SyncE without ECMS and with frequency loopback enabled).
However, using transportSpecific flag set to 0 (DEFAULT) is allowed if the link partner is not
SyncE-capable. Such situation shall be detected and handled properly by a port implementing this profile to ensure
SyncE-capable. Such a situation shall be detected and handled properly by a port implementing this profile, therefore guaranteeing
backward-compatibility and interoperability. \\
By default, the "High Accuracy" option shall be active. If a link-partner uses mapping defined in Annex F
By default the "High Accuracy" option shall be active. If a link-partner uses mapping defined in Annex F
with DEFAULT transport Specific field, the "High Accuracy" option shall be disabled.
\newpage
\subsection{Changes to clauses of PTPv2}
\label{PTPchanges}
\vspace{1em}
\vspace*{-1em}
\begin{table}[ph!]
\begin{table}[h!]
\begin{tabular}{ l p{12.5cm}}
\multicolumn{2}{l}{\textbf{Required changes:}} \\
Clause 7.6.2.5: & Table 6 -- add accuracies greater then 25ns \\
Clause 14.1.1: & Table 34 -- add HIGH\_ACCURACY\_OPTION tlvType \\
% Annex F.4: & Described in section~\ref{highAccuracy} \\
% Annex J: & Described in section~\ref{HAprofile} \\
\multicolumn{2}{l}{ \textbf{Possibly helpful changes:}} \\
Clause 3.1: & Add time definition (time = time of day and/or frequency) \\
Clause 5.3.3: & Add picoseconds to the Timestamp structure \\
......@@ -342,19 +348,21 @@ with DEFAULT transport Specific field, the "High Accuracy" option shall be disab
\end{tabular}
\end{table}
\vspace*{-1em}
\section {Benefits of the proposed revision}
This revision allows high-accuracy implementation of PTP protocol by providing to an implementer
a standardize way of deriving very stable frequency from physical medium, evaluating physical delays,
This revision allows a high-accuracy implementation of the PTP protocol by providing to an implementer
a standardized way of deriving a stable frequency from the physical medium, evaluating physical delays,
using phase detection for enhancing timestamping precision and evaluating link asymmetry.
Additionally, using SyncE with PTP is considered by Telecom profile, therefore adding it to the
transport annex can be useful for telecommunication applications.
Moreover, the modification proposed in section~\ref{syncEandEthernet} can be useful in a currently
developed (by ITU-T) PTP Telecom profile.
\section {Backward compatibility to IEEE-1588:} A: Complete backward compatibility, i.e. V2 and the
revised version interoperate although V2 devices do not receive benefits of revision.
\vspace*{-1em}
\begin{thebibliography}{9}
\footnotesize
......@@ -377,6 +385,12 @@ revised version interoperate although V2 devices do not receive benefits of revi
TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU,
07/2010.\\
\vspace*{-2em}
\bibitem{SynchE2}
ITU-T G.8264/Y.1364
\emph{Distribution of timing information through packet network}.
TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU,
10/2008.\\
\vspace*{-2em}
\bibitem{icalepcs09}
J. Serrano, P. Alvarez, M. Cattin, E. G. Cota, J. H. Lewis, P. Moreira, T. W\l{}ostowski
and others,
......
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