Multicast IP routing allows multicast messaging beyond a subnet. Multicast IP routing is not available over the internet but it is now fairly common on enterprise networks.
John, can you describe a use case for alternate timescales and explain how the endstation can know that the timescale is correct local time or which alternate timescale to use if there are multiple? Kevin Gross +1-303-447-0517 Media Network Consultant AVA Networks - www.AVAnw.com <http://www.avanw.com/> On Tue, Oct 29, 2013 at 4:18 AM, John Fletcher <[email protected]>wrote: > Just to be clear, I am not suggesting use of a different epoch in > timestamp fields. I am talking about the optional TLV described in section > 16.3 which can give you the offset(s) between PTP time and one or more > timescales of your choice.**** > > ** ** > > Regarding spanning timezones, there is a difference between the extent of > the enterprise network and the extent of the part of network served by a > PTP master. The latter is probably a subnet since multicast messages (e.g. > Announce) are usually confined to a subnet. A subnet spanning multiple > timezones would be less common. However you can have more than one > Alternate Timescale if necessary.**** > > ** ** > > This feature is just an option; I’m not suggesting it be required, just > that it not be forbidden.**** > > ** ** > > John**** > > ** ** > > *From:* Douglas Arnold [mailto:[email protected]] > *Sent:* 28 October 2013 20:06 > *To:* John Fletcher > > *Cc:* [email protected] > *Subject:* Re: [TICTOC] Enterprise Profile**** > > ** ** > > Hello John,**** > > ** ** > > I agree that local time is useful. I would not be averse to creating a > TLV to distribute local time offset, so that end node can convert to local > time and present it to users.**** > > ** ** > > However, I do not support the idea of using a local time epoch in the PTP > timestamp fields. This is an allowed option in IEEE 1588-2008, but I > believe that this is likely to cause interoperability problems, when some > vendors support it and others do not. Also some system architechs have > indicated that they deploy PTP across large networks, which span time > zones. This is the feature that should be forbidden. **** > > ** ** > > In the NTP standard (RFC5905) the timestamps in the packet all use a > specific time epoch, and generate all other desired time epoch as > corrections performed at the end points. Note also that in most computer > operating systems a single standard time epoch is used in and local time is > generated at the presentation layer for human readable interfaces.**** > > ** ** > > Doug**** > > ** ** > > On Mon, Oct 28, 2013 at 8:10 AM, John Fletcher <[email protected]> > wrote:**** > > I'd also like to ask that you don't prohibit the Alternate Timescales > option. This is potentially useful to distribute "local time" (your > time-zone and dst) and there doesn't seem to be any need to prohibit it. * > *** > > ** ** > > John**** > ------------------------------ > > *From:* [email protected] [[email protected]] on behalf of > John Fletcher [[email protected]] > *Sent:* 25 October 2013 11:01 > *To:* Douglas Arnold > *Cc:* [email protected] > *Subject:* Re: [TICTOC] Enterprise Profile**** > > Doug,**** > > **** > > I would be interested to know the circumstances when you see the maximum > phase adjustment information being used.**** > > **** > > Some comments:**** > > **** > > In section 6, you say, “In all three of the delay measurement modes…”. At > that point in the text you have not yet mentioned multicast, hybrid and > unicast modes so it’s not clear which modes you are referring to.**** > > **** > > In section 9, you say, “Slaves SHOULD NOT Synchronize to a Rogue Master.” > It’s not clear how a slave would know that a master is rogue; presumably it > would need to examine the announce messages of all masters and do its own > BMCA evaluation. A more realistic “rogue” master would probably meet the > BMCA criteria for selection.**** > > **** > > In section 12, “Alternative Time Scales” should be “Alternate Timescales”. > **** > > **** > > **** > > Regards,**** > > John Fletcher**** > > **** > > *From:* [email protected] [mailto:[email protected]] *On > Behalf Of *Douglas Arnold > *Sent:* 25 October 2013 01:35 > *To:* [email protected] > *Subject:* [TICTOC] Enterprise Profile**** > > **** > > Hello Everyone,**** > > **** > > Attached is an updated version of the Enterprise profile. Sorry I missed > the upload deadline for the Vancouver meeting. If you get a chance to > look at it before then I will be there and would love to discuss it. **** > > **** > > Summary of changes:**** > > **** > > I also changed the TLV format to fit the latest proposal in the 1588 > revision. **** > > **** > > I added a statement about not going into the master state unless one had a > current UTC offset. **** > > **** > > I added to the TLV fields to indicate maximum phase correction over a sync > cycle.**** > > **** > > -- **** > > Doug Arnold**** > > Principal Technologist**** > > *JTime!* Meinberg USA**** > > +1-707-303-5559**** > > **** > > **** > > **** > > ---------------------------- > > http://www.bbc.co.uk > This e-mail (and any attachments) is confidential and may contain personal > views which are not the views of the BBC unless specifically stated. > If you have received it in error, please delete it from your system. > Do not use, copy or disclose the information in any way nor act in > reliance on it and notify the sender immediately. > Please note that the BBC monitors e-mails sent or received. > Further communication will signify your consent to this.**** > > ---------------------**** > > **** > > ---------------------------- > > http://www.bbc.co.uk > This e-mail (and any attachments) is confidential and may contain personal > views which are not the views of the BBC unless specifically stated. > If you have received it in error, please delete it from your system. > Do not use, copy or disclose the information in any way nor act in > reliance on it and notify the sender immediately. > Please note that the BBC monitors e-mails sent or received. > Further communication will signify your consent to this.**** > > ---------------------**** > > > > **** > > ** ** > > -- **** > > Doug**** >
_______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
