Subject: Re: [TICTOC] Comments on module-02/architecture proposed draft

From: "Doug Arnold" <[email-masked]>
Date: Mon, 4 Aug 2008 10:15:28 -0700

Thanks Laurent.  There are a lot of good comments and suggestions here.

I am especially interested in your question: "Should we consider 1588
and PTP as interchangeable?"  I suggest that we use the term PTP when we
are referring to the protocol, and 1588 when we are referring to the
document which defines the protocol.  This would be consistent with
referring to NTP as a protocol, and the RFC number when referring to the
document which defines it.  

//Doug Arnold

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Laurent Montini (lmontini)
Sent: Thursday, July 31, 2008 8:23 AM
To: [email-masked]
Subject: [TICTOC] Comments on module-02/architecture proposed draft

 
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
	
_______________________________________________
TICTOC mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tictoc
_______________________________________________
TICTOC mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tictoc

---

From: "Laurent Montini (lmontini)" <[email-masked]>
Date: Tue, 5 Aug 2008 19:08:33 +0200

Hi Doug,

Actually in the IEEE Std 1588-2008, Clause 6.1

  This standard specifies:
   a) The Precision Time Protocol, and
   b) The node, system, and communication properties necessary to support PTP. 

.lm

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Doug Arnold
> Sent: lundi 4 août 2008 19:15
> To: [email-masked]
> Subject: Re: [TICTOC] Comments on module-02/architecture 
> proposed draft
> 
> I am especially interested in your question: "Should we 
> consider 1588 and PTP as interchangeable?"  I suggest that we 
> use the term PTP when we are referring to the protocol, and 
> 1588 when we are referring to the document which defines the 
> protocol.  This would be consistent with referring to NTP as 
> a protocol, and the RFC number when referring to the document 
> which defines it.  
> 
> //Doug Arnold
> 
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Laurent Montini 
> (lmontini)
>  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.
> ****************
> 
> 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 time" would be more appropriate as written on the 
> next paragraph
> 
>    generated by the networking hardware.  **** When this is 
> not possible, the 
> 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:
> 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
> *****************
> 
> 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 ...
> ****************
> 
> 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.
> 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.
> 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 
> The IEEE1588 protocol has a follow-up message PTP has a 
> follow-up message
> ****************
> 
> page 12
> 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.
> ****************
> 1588 WG, and in its recently revised version [IEEE-2008] it  
> better accommodates telecommunication applications.
> 
> 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
>

---

From: "Doug Arnold" <[email-masked]>
Date: Tue, 5 Aug 2008 11:14:39 -0700

Good point Laurent.  All the more reason to not use the term IEEE1588 to refer to the protocol.  //Doug

-----Original Message-----
From: Laurent Montini (lmontini) [mailto:[email-masked]] 
Sent: Tuesday, August 05, 2008 10:09 AM
To: Doug Arnold; [email-masked]
Subject: RE: [TICTOC] Comments on module-02/architecture proposed draft

Hi Doug,

  This standard specifies:

.lm

> Subject: Re: [TICTOC] Comments on module-02/architecture proposed 
> draft
> 
> and PTP as interchangeable?"  I suggest that we use the term PTP when 
> we are referring to the protocol, and
> 1588 when we are referring to the document which defines the protocol.  
> This would be consistent with referring to NTP as a protocol, and the 
> RFC number when referring to the document which defines it.
> 
> //Doug Arnold
> 
>  The purpose of the time acquisition module is to enable multiple 
> TICTOC clients to share a single offset,
> 
>  distribution protocols be optimised for their purpose distribution 
> protocols be optimized for their purpose
> ****************
> 
> Page 12, 3.2:
> 
> packets To transfer time it is necessary to know the time of flight of 
> packets
> *****************
> 
> IEEE1588v2 are useful or the use of the peer-to-peer mechanism 
> described in 1588-2008 are useful
> ****************
> 
> Page 15:
> frequencies  A timing loop is an erroneous topology that causes 
> locking onto frequencies
> ***************
> 
> Page 17:
> 
> symmetric, or when asymmetry or best estimate of asymmetry is known, 
> or paths may be selected ...
> ****************
> 
> In such cases, it may be required for the master to inform the client 
> of the change in operating conditions.
> 
> 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.
> 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 
> The IEEE1588 protocol has a follow-up message PTP has a follow-up 
> message
> ****************
> 
> page 12
> 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.
> ****************
> assistance by intermediate network elements, such as IEEE Std 
> 1588-2008 Transparent Clocks [1588-2008].
> ****************
> 
> .lm
>

---

From: "Laurent Montini (lmontini)" <[email-masked]>
Date: Thu, 7 Aug 2008 17:57:14 +0200

It may be true for both frequency and time but probably much more prevalent for time if we consider asymmetry and particularly because the use of on-path support functions.
For frequency it can be uniquely one-way PDV factor only.
 
Do you expect a need of on-path support for frequency transfer?
 
Still we need to define what on-path support is and if this includes BC/Str server function as a freq distribution relay.
 
.lm

________________________________

	From: [email-masked] [mailto:[email-masked]] 
	Sent: mercredi 6 août 2008 11:41
	To: Laurent Montini (lmontini)
	Cc: Doug Arnold; [email-masked]; [email-masked]
	Subject: 答复: Re: [TICTOC] Comments on module-02/architecture proposed draft

	Page19 5.5 
	
	"it may be that the optimum path for time transfer is not congruent with the optimum path for data transfer." 
	
	Should it be "timing transfer" or "time and frequency transfer" rather than "time transfer"? 

	Fei Su 

	"Laurent Montini (lmontini)" <[email-masked]> 
发件人： [email-masked] 

2008-08-06 01:08 

        收件人：        "Doug Arnold" <[email-masked]>, <[email-masked]> 
        抄送：         
        主题：        Re: [TICTOC] Comments on module-02/architecture proposed draft

	Hi Doug,

	 This standard specifies:

	.lm

	--------------------------------------------------------
	ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
	This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
	This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

	--------------------------------------------------------
	ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
	This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
	This message has been scanned for viruses and Spam by ZTE Anti-Spam system.