Subject: [TICTOC] Comments on Architecture doc

From: "Doug Arnold" <[email-masked]>
Date: Wed, 30 Jul 2008 07:06:24 -0700

Comments on Architecture for the transmission of Timing over Packet
Networks: draft-stein-tictoc-modules-02.txt

1.	This document should have a section on timescales.

2.	This document sometimes uses server and master interchangeably,
and client and slave interchangeably. Master-slave protocols are
fundamentally different from client-server protocols.

3.	We need a better term for time-of-day than "wall clock". Wall
clock is likely to be mis-interpreted as inaccurate time.

4.	Master clocks do not always employ atomic clocks. A master clock
often has only an OCXO or TCXO.

5.	Section 2.2: Frequency transfer in not always done with a one
way protocol. In constrained networks two way protocols can be used.
Note that to select packets with the lowest delays for the servo loop we
will want a two way protocol.

6.	Section 2.4: PLLs as well as frequency synthesizers are used to
create additional frequencies.

7.	Section 3.1: Another challenge to the use of transparent clocks
is that they modify packets. This is a serious challenge for security.

8.	Section 3.1: Time distribution can in fact be done entirely in
multicast, such as in IEEE1588. However this is limited to networks
which can run multicast. There are also scaling issues with the
proliferation of multicast delay request and delay response messages,
unless the peer delay mechanism used.

9.	Section 3.1: The recent revision of IEEE1588 included many
enhancements and revisions, not all of which were related to the needs
of the telecommunications industry.

10.	Section 3.3: The presentation of time also includes the
generation of timing signals, for example IRIG-B.

11.	Section 4.1: Not all slaves are simple. Security mechanisms
should scale to allow equipment designers to make trade-offs between
computational complexity and security robustness.

//Doug Arnold

_______________________________________________
TICTOC mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tictoc

---

From: "Laurent Montini (lmontini)" <[email-masked]>
Date: Thu, 31 Jul 2008 17:23:21 +0200

Page 5:

 The purpose of the time acquisition module is to enable multiple TICTOC
clients to share a single offset,

Multiple TICTOC clients/slaves using the same server/master would have
to share a single offset.
Considering distinct clients/slaves may use distinct timescales, they
might use distinct masters/servers using the same network.
****************

Page 7: Synchronous Ethernet should have upper case on S & E.
****************

Page 8:

 while unicast transmission is often more desirable

It would be useful for the reader to have further explanation on this
statement.
****************

 In general it achieves this by comparing the arrival rate of packets
with the original sending rate. 

"arrival rate" tends to describe a CBR type ACR.
"arrival time" would be more appropriate as written on the next
paragraph

 Observed arrival times of frequency distribution protocol packets...
****************

Page 11, 3.1:
   In order for the timestamp to accurately indicate the time that the 
   packet was actually injected into the network (rather than some 
   earlier time when the packet was formed, separated by a stochastic 
   time delay from the injection time), the timestamp should be 
   generated by the networking hardware.  **** When this is not
possible, the 
   stochastic delay should be minimized.  The IEEE1588 protocol has a 
   follow-up message, to indicate the actual injection time of the 
   previous packet.  *****

The 1588 one-step clock is about timestamping and modifying the packet
on the fly at egress.
The 1588 two-step clock is timestamping the packet at egress but the
value is provided by a follow_up message.
Actually to get the actual injection time you'd need hardware assistance
in both cases.
*****************

Page 12:
 distribution protocols be optimised for their purpose
 distribution protocols be optimized for their purpose
****************

Page 12, 3.2:

To transfer time it is necessary to know the time of flight of time of
packets
To transfer time it is necessary to know the time of flight of packets
*****************

Page 13, last sentence before 3.3:

   Mechanisms to avoid asymmetry at the network layer (for 
   example using MPLS RSVP-TE paths, or the use of the peer-to-peer 
   mechanism described in IEEE1588v2 are useful, as is the ability to 
   correct asymmetry in the physical connection through the use of 
   external calibration. 

Closing bracket is missing.
   Mechanisms to avoid asymmetry at the network layer (for 
   example using MPLS RSVP-TE paths, or the use of the peer-to-peer 
   mechanism described in 1588-2008) are useful, as is the ability to 
   correct asymmetry in the physical connection through the use of 
   external calibration. 
******************

Page 13:

or the use of the peer-to-peer mechanism described in IEEE1588v2 are
useful
or the use of the peer-to-peer mechanism described in 1588-2008 are
useful 
****************

Page 15:
 A timing loop is an erroneous topology that causeslocking onto
frequencies
 A timing loop is an erroneous topology that causes locking onto
frequencies
***************

Page 17:

For example paths may be selected that are explicitly chosen to be
symmetric, or paths may be selected ...
For example paths may be selected that are explicitly chosen to be
symmetric, or when asymmetry or best estimate of asymmetry is known, or
paths may be selected ...
****************

Page 17: Synchronous Ethernet should have upper case on S & E.
****************

Page 17:

In such cases, it may be required for the master to inform the client of
the change in operating conditions. 

Can't this be broaden, as an option, to equipment providing time
protocol assistance (aka on-path support elements)?
**************** 

Page 19:

In some cases on-path support (for example IEEE1588 transparent clocks)
In some cases on-path support (for example 1588-2008 Transparent Clocks)
****************

Page 19, 5.5:
Leaving out the debate on "on-path" term for now, it could be useful to
describe in more generic terms what an "on-path" support could provide
and to differentiate the functions, or what TICTOC protocol(s) would
expect from an "on-path" support.
For instance in 1588-2008, there is the TC. 
Should we consider the BC function as an "on-path" support? If so, a NTP
Stratum server could be considered as an on-path support too. Is there a
difference (out of the notion of domain which is general in 1588)
between a BC and a stratum server in the sync distribution architecture?

Should we provide more generic name to such functions? For instance, BC
and Stratum server (>1) are sort of time relay when TC is time
transparent relay (which does not mean it is frequency transparent).

Also in section 5, because 1588 has this notion of domain, it may be
useful to introduce such notion.
1588-2008 definition
3.1.7 domain: A logical grouping of clocks that synchronize to each
other using the protocol, but that are not necessarily synchronized to
clocks in another domain.
*****************

- I already commented on IEEE Std 1588: 1588-2002, 1588-208, PTP
versions 1 & 2.
Should we consider 1588 and PTP as interchangeable?
IMHO we should distinguish the protocol (PTP) from the clock functions
described in 1588 that implement the PTP (or part of PTP).
More specifically:
 
Page 3:
The IEEE has recently revised its Precision Time Protocol [IEEE1588]
The IEEE has recently revised its Precision Time Protocol [1588-2008] 
as we talk about the latest version of IEEE Std 1588.
****************
Examples of such timing protocols include Network Time Protocol (NTP)
[RFC1305] and Precision Time Protocol (PTP) [IEEE1588].
Examples of such timing protocols include Network Time Protocol (NTP)
[RFC1305] and Precision Time Protocol (PTP) [1588-2008].
****************
In the reference (page 
[1588-2008] IEEE Std 1588-2008, "Standard for A Precision Clock
Synchronization 
           Protocol for Networked Measurement and Control Systems" .
****************

Page 11:
The IEEE1588 protocol has a follow-up message
PTP has a follow-up message
****************

page 12
The IEEE1588 protocol has an optional mechanism (transparent clocks)...
The 1588-2008 standard has an optional mechanism (transparent clocks)...

Transparent clock is not the protocol. But PTP can make use of it.
****************
There are two well-known protocols capable of running over a
general-purpose packet network, NTP [RFC1305], and IEEE1588 [IEEE1588].
There are two well-known protocols capable of running over a
general-purpose packet network, NTP [RFC1305], and PTP [1588-2008].  

We are talking about the protocol running over a general-purpose packet
network which is true for PTP as long as specific clock functions are
not added.
****************
IEEE1588 is a product of the IEEE Test and Measurement community, IEEE
1588 WG, and has recently been revised to better accommodate
telecommunication applications.
1588-2008 is a product of the IEEE Test and Measurement community, IEEE
1588 WG, and in its recently revised version [IEEE-2008] it  better
accommodates telecommunication applications.

The IEEE P1588 version 2 was not specifically defined for telecom.
****************
Some ranging mechanisms require or can exploit special hardware
assistance by intermediate network elements, such as IEEE 1588
transparent clocks [IEEE1588].
Some ranging mechanisms require or can exploit special hardware
assistance by intermediate network elements, such as IEEE Std 1588-2008
Transparent Clocks [1588-2008]. 
****************

.lm