Re: [TICTOC] PTP Enterprise Profile draft

[<[e-mail]>]

Hi Doug, all,

I am also in line with Silvana and Stefano.

I would be also interested to better understand the use case that is addressed, and what makes it so specific that it requires the development of a dedicated PTP profile.
By nature, enterprise networks have always been very close to telecom networks (I might however have missed an important point).

Indeed, in my opinion, most of the PTP options that are included in this draft are more or less available in PTP profiles already developed or under development. Just to give an idea:


-          The mixed unicast/multicast arrangement, if required, is something that was originally planned in G.8265.1 (see Appendix I). This is something which could be finalized if a valid use case shows the interest in this mode (ITU stopped at some point working on this mode to focus on the full unicast mode, but there was originally interest from various companies). As mentioned by Stefano, this arrangement seems only relevant to frequency synchronization, and not accurate time synchronization, due to the asymmetry generated.


-          The possibility to include PTP unaware nodes in the chain corresponds to the so-called "partial support" case, for which a study item has been started in ITU-T. This may result in the definition of a dedicated PTP profile, currently envisaged in future G.8275.2.

As you can see, there is some overlapping with on-going studies outside TICTOC, so it might be worth trying to coordinate to avoid that similar work would be developed twice.

Finally, I also share the warnings that defining a PTP profile only (protocol aspects) cannot ensure that the relevant performance will be met.

I won't be in Orlando to further discuss this work, but I'll try to follow remotely what happens, maybe with the help of some colleagues, and provide comments if useful.

Thanks.

BR,

Sébastien

De : [e-mail] [mailto:[e-mail]] De la part de Rodrigues, Silvana
Envoyé : mardi 5 mars 2013 04:07
À : Stefano Ruffini; Doug Arnold; [e-mail]
Objet : Re: [TICTOC] PTP Enterprise Profile draft

Doug,

Thanks for the draft. I also agree with Stefano's comment and I have a few additional comments.

Item 3 and 4 from Stefano's email below, I think that there is a need to add some warning in the text, as the way it is written, it does look like that  if this profile is implemented over any network the 1us requirement will be met.

Section 10, it states that slave may use an Acceptable Master list. How this will work when transparent clocks are used and the source address in the TCs are changed to the TC source address? The Slave will no longer have the source address of the masters.

Section 12, it states that Unicast negotiation is forbidden. How the packet rate will be negotiated between the master and slave for Unicast Mode?

Thanks,

Silvana


From: [e-mail] [mailto:[e-mail]] On Behalf Of Stefano Ruffini
Sent: Monday, March 04, 2013 11:20 AM
To: Doug Arnold; [e-mail]
Subject: Re: [TICTOC] PTP Enterprise Profile draft

Hi Doug,


thanks for your draft .


There are a few points that I think would need some clarification.

1) As also mentioned at last tictoc meeting, there is a risk of multiplication of profiles.
It is not fully clear in the Introduction what is so specific to enterprise networks to requiring the definition of a specific profile.



2) the proposed profile would support a combinations of various options (e.g. various modes defined in section 6) but the task of a profile should normally also be to minimize the number of IEEE1588 options. Are all these options really required ?


3) section 4 indicates a target requirement of 1 us : is there a reference for that?

4) It should be noted that the performance (e.g. 1 us) can not be guaranteed by a profile as such.
Other aspects, such as network reference model, clock characteristics, also have to be defined in order to provide some guarantee on the achievable performance.
How are these planned to be addressed? Will it make reference to ITU-T recommendations?


5) Concerning the "Hybrid" and "Unicast" mode in section 6.3 (see also remark from Laurent on the confusing terminology used), in case of "partial support" , the potential risk of adiditonal asymmetries should be mentioned (see also Appendix I in G.8265.1) .
This is not an issue in case of frequency sync but it is in case of time sync.


Best Regards
Stefano

________________________________
From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]] On Behalf Of Doug Arnold
Sent: lunedì 25 febbraio 2013 22.52
To: [e-mail]<mailto:[e-mail]>
Subject: [TICTOC] PTP Enterprise Profile draft
Here is a first cut at a draft of a PTP profile foe enterprise networks.  Any feedback/suggestions would be much appreciated.

I enclose both a MS Word version and a pure text version, since I used the Joe Touch's template.

//Doug


_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
Thank you.