I assumed that you have presented the = complete list of=20 expected deliveries of the WG-to-be (split into 2 phases) and not a = superset of=20 topics for short listing. Looks like I misunderstood your intention (and, judging by the = emails on=20 the list, the misunderstanding = was=20 common).

Can you please explain why do you want to = reduce the=20 list of targets? (You can always cite "too much work to do" as the = reason, of=20 course:-).

As I see it, all the documents you've named = are indeed=20 required unless we want to adopt a certain solution regardless of the = problem.=20

And I do not see alternative WGs in the IETF = that could=20 handle these documents.

Regards,

&nbs= p; =20 Sasha

From: Yaakov Stein = [mailto:yaakov_s@rad.com]=20
Sent: Tuesday, October 23, 2007 11:15 AM
To: Sasha=20 Vainshtein
Cc: tictoc@ietf.org
Subject: RE: [TICTOC] = preparatory material for new TICTOC charter

Sasha

The=20 idea was to identify a subset of topics.

If you=20 believe that no targets are left out,

then=20 it is not a PROPER subset. :)

Y(J)S

From: Sasha Vainshtein = [mailto:Sasha@AXERRA.com]=20
Sent: Monday, October 22, 2007 7:37 PM
To: Yaakov=20 Stein
Cc: tictoc@ietf.org
Subject: RE: [TICTOC] = preparatory=20 material for new TICTOC charter

Yaakov=20 and all,

Looks=20 like a reasonable schedules with no targets left = out.

Regards,

&nbs= p; =20 Sasha

From: Yaakov Stein = [mailto:yaakov_s@rad.com]=20
Sent: Monday, October 22, 2007 7:20 PM
To:=20 tictoc@ietf.org
Subject: [TICTOC] preparatory material for new = TICTOC=20 charter

Hi all,

Today Stewart, Karen and I = discussed Mark's=20 request to
quickly focus on which of the "modules" need be in scope = for the=20 potential WG.

We have come up with the following = deliverables,
broken=20 down into two phases
(times in parentheses are months from chartering = of=20 WG).

Phase 1:

0. Architecture = draft=20 (based on modularization draft)      =20 (INFO)    (6)
1.1 requirements for time/frequency = distribution=20 protocol(s) (INFO)    (9)
1.2 analysis of existing = protocols=20 in light of = 1.1          =20 (INFO)   (12)
1.3 selection and documentation of = distribution=20 protocol(s)  (STD)    (24)
2  =20 Autodiscovery (including security=20 aspects)           = ;    (STD)   =20 (12)
3   Topology discovery (including security=20 aspects)          (STD)=    =20 (24)

Phase 2:

4 OAM including=20 SSM           &nbs= p;            = ;            =       (STD)   =20 (30)
5 Performance=20 measurement          &n= bsp;           &nb= sp;           &nbs= p; (STD)   =20 (33)
6 Ranging=20 techniques          &nb= sp;           &nbs= p;            = ;     =20 (BCP)    (36)
7=20 MIBs           &nb= sp;           &nbs= p;            = ;            =        (STD)   =20 (30)

Additional work, such as BCPs for various=20 algorithms,
detailed requirements for specific applications (e.g. = cellular=20 backhaul),
and research topics such as globally converging classless=20 methods,
will be developed based on interest and = participation.

We=20 would appreciate feedback from the list on the choice of
milestones, = and the=20 times allotted.

Y(J)S

------_=_NextPart_001_01C81599.5D028F0C-- --===============0404731771== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ TICTOC mailing list TICTOC@ietf.org https://www1.ietf.org/mailman/listinfo/tictoc --===============0404731771==-- From tictoc-bounces@ietf.org Wed Oct 24 04:46:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkbsD-000464-3g; Wed, 24 Oct 2007 04:45:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkbsB-00045t-On for tictoc@ietf.org; Wed, 24 Oct 2007 04:45:55 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IkbsA-0004LG-D8 for tictoc@ietf.org; Wed, 24 Oct 2007 04:45:55 -0400 X-IronPort-AV: E=Sophos;i="4.21,323,1188770400"; d="scan'208";a="156226773" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 24 Oct 2007 10:45:46 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l9O8jk3b026511; Wed, 24 Oct 2007 10:45:46 +0200 Received: from stewart-bryants-computer.local (ams3-vpn-dhcp938.cisco.com [10.61.67.170]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l9O8jYUh026644; Wed, 24 Oct 2007 08:45:36 GMT Message-ID: <471F062F.4000806@cisco.com> Date: Wed, 24 Oct 2007 09:45:35 +0100 From: Stewart Bryant User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Brad Knowles References: <46A5719F.4050509@gis.net> <46A5F3A7.3010304@innovationslab.net> <471E1E23.8040701@innovationslab.net> <471EC148.6000403@ntp.isc.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1797; t=1193215546; x=1194079546; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=stbryant@cisco.com; z=From:=20Stewart=20Bryant=20 |Subject:=20Re=3A=20[ntpwg]=20Documents, =20slides, =20etc.=20from=20WG=20m eeting |Sender:=20; bh=zv1k1eU4PfaMk93HeDqPmg718XzsH4RMYEcK/SPK/+0=; b=f332FfLPTt3YbAxzbjeJQaD0LlNMnCgxCCHNg0nAjU1Yi7eFLrz2DsVrWlgGJE98SQZNmzah CpLQcNHLXpcedm0msTii1DTsi/5T/LcYrPqkIHyA+1nvIonMN4W4qVfX; Authentication-Results: ams-dkim-2; header.From=stbryant@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: mayer@ntp.isc.org, NTP Working Group , Brian Haberman , "tictoc@ietf.org" Subject: [TICTOC] Re: [ntpwg] Documents, slides, etc. from WG meeting X-BeenThere: tictoc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: stbryant@cisco.com List-Id: Timing over IP Connection and Transfer of Clock BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tictoc-bounces@ietf.org Brad > From reading the IEEE 1588 > page, it's not clear whether this works over IP or not. In discussing 1588, you need to make sure you are talking about the V2 spec. V1 is not likely to see significant deployment, whist V2 is likely to get significant hardware support and hence be widely deployed. Both V1 and V2 can use multicast IP encapsulation and you can in principle build an IP multicast net, but I have always regarded this mode of operation as a little strange and unlikely to ge deployed outside a highly controlled network. I doubt if we will ever see the 1588 multicast mode on the Internet. However V2 can run over a unicast IP connection, and this is likely to find use in wide area networks. Indeed it exists largely to support the needs of the telecommunications operators for a method of providing clock sync over packet. > , although it > does seem to work over Ethernet (and maybe others?). But IEEE 1588 > seems to focus on ultra-high resolution, like sub-microsecond or even > sub-nanosecond. Meinberg appears to have a clock that does both NTP > and IEEE 1588. > > But I'm not seeing how IEEE 1588 can provide synchronization to an > outside reference, and I'm not seeing how it can be used outside of > certain limited circumstances on a pretty much pure Ethernet network. > > I am not sure what you mean by this. How the grand master acquires and locks to an external clock reference is outside the scope of the protocol, but it's also outside the scope of the NTP. However 1588 does have a grand master election mechanism that - given honest representation by the clocks - selects the best clock as the grand master to which the slaves synchronise and avoids the formation of timing looks. Stewart _______________________________________________ TICTOC mailing list TICTOC@ietf.org https://www1.ietf.org/mailman/listinfo/tictoc From tictoc-bounces@ietf.org Wed Oct 24 05:13:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkcIy-0007vn-Hd; Wed, 24 Oct 2007 05:13:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkcIx-0007p9-8M for tictoc@ietf.org; Wed, 24 Oct 2007 05:13:35 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IkcIo-0005Hn-OK for tictoc@ietf.org; Wed, 24 Oct 2007 05:13:35 -0400 X-IronPort-AV: E=Sophos;i="4.21,323,1188770400"; d="scan'208";a="156230420" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 24 Oct 2007 11:13:26 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l9O9DQ6O028240; Wed, 24 Oct 2007 11:13:26 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l9O9DPUh009878; Wed, 24 Oct 2007 09:13:25 GMT Received: from xmb-ams-33a.cisco.com ([144.254.231.85]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Oct 2007 11:13:25 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [TICTOC] Clock metrics in timing packets versus OAM Date: Wed, 24 Oct 2007 11:13:25 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TICTOC] Clock metrics in timing packets versus OAM Thread-Index: AcgVlt6QTwk7TeosQbWXh3AUNad+uAANtH5g From: "Laurent Montini (lmontini)" To: X-OriginalArrivalTime: 24 Oct 2007 09:13:25.0581 (UTC) FILETIME=[22078FD0:01C8161E] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15502.001 X-TM-AS-Result: No--16.795300-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=15492; t=1193217206; x=1194081206; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lmontini@cisco.com; z=From:=20=22Laurent=20Montini=20(lmontini)=22=20 |Subject:=20RE=3A=20[TICTOC]=20Clock=20metrics=20in=20timing=20packets=20 versus=20OAM |Sender:=20; bh=yitV5P53KkcmFHmcbCDpcqlhWBE5kI4dz4hW3B9EqpA=; b=KhyR2R3lFftcwUHDX4RrVm0hMvyCJqzMm9z1qIB695SYCN5XMJDLKabqt9bLrdwcUrkD//JC Ce0K16T1KJm/ffSIIT6yN8yfsRgGpkjb82HpOx4JJvnJfdSY1Swwf1UG; Authentication-Results: ams-dkim-1; header.From=lmontini@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: efb5d987e2484f3d9a304cc31a003441 Cc: STUART VENTERS , tictoc@ietf.org X-BeenThere: tictoc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Timing over IP Connection and Transfer of Clock BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tictoc-bounces@ietf.org Hi Dave, Another way to look at SSM. Actually SSM in SONET/SDH carries a value, the QL (Quality Level) value. Change of QL value is part of clock selection process. If SSM is limited to QL value in SONET/SDH, it does not mean it should for packet network. For SyncE, we still talk about SSM or ESSM but it was agreed we should be able to add field extensions.=20 The ESSM slow protocol provides this capability. ESSM will have one mandatory "QL field" and could have other fields (like source ID, hop count from source, ...). Another idea would thus be to consider the term SSM "Synchronization Status Messaging" for a channel providing messages about synchronization network status or condition and not SSM :=3D QL. Did I miss something from the old world? :-) Cheers, .lm > -----Original Message----- > From: DTonks@semtech.com [mailto:DTonks@semtech.com]=20 > Sent: mardi 23 octobre 2007 19:03 > To: STUART VENTERS > Cc: tictoc@ietf.org > Subject: RE: [TICTOC] Clock metrics in timing packets versus OAM >=20 > Hi Stuart, > Looks like I misled you a little. When I said there was no=20 > bandwidth for extra info, I was referring to the TDM frames=20 > (DS1, E1, SONET, SDH). For example, only 4 bits were=20 > allocated to carrying the SSM value in SONET/SDH. > Of course, since we got 8000 frames a second, we got 32kbps=20 > of SSM (which had a static 4-bit value for 99.9999....% of=20 > the time!), but, in the interests of design simplicity, it=20 > was better to have a value which was repeated every frame=20 > rather than, say, build a more complex message over a=20 > multiframe. Hence, we only got 4 bits to carry info and this=20 > had to be devoted to the SSM value. But it also meant we=20 > could detect a new SSM value very quickly, even when the SSM=20 > value was occasionally corrupted, and this allowed us to=20 > react fast when we needed to (given that the new SSM value=20 > may have to go through many nodes before it hit one that was=20 > timed from a better clock). It works well in those=20 > circumstances when it works, but it cannot solve all our=20 > problems (it can't fix timing loops all by itself, for=20 > example, so it's not much use in an automated timing path=20 > build process - that little limitation keeps sync engineers=20 > in business, of course). >=20 > In packet networks, we will only get a few packets per=20 > second, but we can make the most of them because they include=20 > error-checking so we can trust the info they carry, and so we=20 > can still get a fast enough response. But we only use 4 bits=20 > out of the packet to carry the SSM value, so there's plenty=20 > of room for new stuff. I know the ITU have adopted the slow=20 > protocol for the OAM specifically for Synchronous Ethernet,=20 > but I can't see any reason why it can't be used for other=20 > things - so long as it stays hop-by-hop. If we want to use=20 > the same packet for extra info, then it would be tidier if we=20 > can come up with a name for this packet which does not appear=20 > to tie it too much to SSM.....the problem is, for example, if=20 > we call it the SSM packet, we may confuse future generations=20 > when we start to add extra info in there which is not SSM=20 > related. We need a more general-purpose name which tells you=20 > the packet carries sync-related info, of which a part is SSM.=20 > But don't call it a sync packet! Or a Sync Status Message=20 > either! Any ideas? >=20 > The sort of info that I've heard proposed to help automatic=20 > path builds include physical location of PRCs, number of hops=20 > to the PRC, and port IDs, but there will be lots more when we=20 > get going. Some things might be a bit esoteric, but we could=20 > accommodate them if we have a flexible approach to the packet=20 > layout - such as using TLVs. Same sort of thing for the=20 > timing metrics. The timing metrics could change the priority=20 > of each path dynamically - if a path became too noisy, for=20 > example, it could be demoted. > We can do the same thing at the moment - if a path becomes=20 > noisy or clock recovery produces an erratic clock, the path=20 > can be demoted. >=20 > Best wishes, >=20 > dave >=20 >=20 > =20 > =20 > "STUART VENTERS" =20 > =20 > =20 > dtran.com> =20 > To=20 > =20 > =20 > 10/23/2007 04:34 =20 > cc=20 > PM =20 > =20 > =20 > Subject=20 > RE: [TICTOC] Clock=20 > metrics in =20 > timing packets versus=20 > OAM =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 >=20 >=20 >=20 >=20 > Dave, >=20 > Thanks for the reply. I'd like to understand this old ground=20 > a little better. > (It sounds a bit like a minefield ;-) >=20 > I agree with you that having SSM alone is not sufficient to=20 > choose clock paths. > Some additional information is required. (Perhaps a path=20 > metric and a priority or source ID, which NTP may have in=20 > the Precision, Dispersion, and RefID fields.) The additional=20 > bandwidth seems meager compared to the advantage of knowing=20 > quickly when an input changes. > If there is a general feeling that quick is not good and so=20 > this function should be OAM, then I'd like to better understand it. >=20 > I do agree that some functions, like tracing out the clock=20 > tree would be fine as OAM. >=20 >=20 > Regards, >=20 > Stuart >=20 >=20 > -----Original Message----- > From: DTonks@semtech.com [mailto:DTonks@semtech.com] > Sent: Tuesday, October 23, 2007 4:43 AM > To: tictoc@ietf.org > Cc: tictoc@ietf.org > Subject: [TICTOC] Re: TICTOC Digest, Vol 15, Issue 6 >=20 >=20 > Stuart, > You've asked a good question about what is SSM about. SSM=20 > always looks like it can do more than it was designed for,=20 > and this is causing some confusion. SSM has its limitations=20 > and it cannot be used for advanced things like automatically=20 > building timing trails - although such things were proposed,=20 > there just wasn't the bandwidth available in the frame. > We'll have to find some other way to do that, and although it=20 > may be loosely linked in with SSM it would be separate from=20 > it. Just remember that SSM only indicates the quality of the=20 > sync source currently at the head of a timing path. It's a=20 > way of passing information about a remote timing node that=20 > can't be obtained by inspecting the signal being received=20 > (for example, to a downstream SEC, the quality of a signal=20 > timed by an SSU in holdover would be indistinguishable from=20 > one being timed by a PRC - the SSM tells the SEC what the=20 > quality is so that it can compare this trail with=20 > alternatives). The SSM supplements other info that can be=20 > obtained locally, such as LOS, OOF, AIS, all of which are=20 > used to disqualify a timing trail. > That's all the SSM can do, really. Forgive me if I'm going=20 > over old ground. > Now, if we can all agree just what additional information=20 > would be needed for advanced features, then this info could=20 > be made available, but it would be separate from and in=20 > addition to the SSM info itself. Points 2 and 3 in the list=20 > in Yaakov's email mention autodiscovery and topology=20 > discovery, so whatever information is needed for these would=20 > have to be made available - but these would be separate to=20 > the SSM value. > We would also have to agree the best way to present this=20 > extra info - OAM springs to mind, but is this the only/best=20 > way? Personally, I think so. The ITU have decided to carry=20 > SSMs in a slow protocol defined for OAM purposes, and there=20 > is plenty of space in the message for other info. So, the=20 > same messages that are used to carry SSM values could be used=20 > to carry additional info for building timing trails, and so=20 > on - but this is not an additional burden on the SSM flow,=20 > and we should strive to keep SSM separate from these things.=20 > (How we relate TICTOC to the ITU is TDB, I > guess.) > Overall, then, we may find that an OAM flow is used for=20 > points 2,3 and 4, but SSM is kept as it is. Note, I'm=20 > avoiding the issue of possibly making SSM obsolete if we have=20 > access to other info...that's a topic for later. >=20 > Taking up your other point about performance, I think it's=20 > important from day one to recognise that different=20 > applications will have different performance requirements.=20 > Maybe each application will need some sort of individual=20 > profile? We will have to define the various performance=20 > requirements in some way (MTIE, TDEV masks? Anything else?).=20 > Your point 2 is very important - we should recognise that=20 > some network conditions will be too severe to support the=20 > performance requirements. I think this should be used as part=20 > of the timing-trail-selection mechanism so that an=20 > alternative timing path can be selected when the current one=20 > goes outside an agreed behaviour limit. Ultimately, though,=20 > this may not be sufficient to guarantee good timing paths are=20 > available, and we may eventually have to go the traditional=20 > way and impose PDV limits on each network element (ie, > switch/router) - that should be fun. >=20 > Getting back to metrics, the ITU are also active here, with=20 > network behaviour metrics currently being looked at. By the=20 > way (and pardon me for > advertising) but there will be a few presentations on these=20 > metrics at the ITSF next month, if anyone wants to see what's=20 > involved (http://conferences.theiet.org/itsf/). >=20 > Cheers > Dave >=20 >=20 >=20 >=20 > tictoc-request@ie > tf.org > =20 > To > 10/22/2007 07:22 tictoc@ietf.org > PM =20 > cc >=20 > =20 > Subject > Please respond to TICTOC Digest, Vol 15, Issue 6 > tictoc@ietf.org >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Send TICTOC mailing list submissions to > tictoc@ietf.org >=20 > To subscribe or unsubscribe via the World Wide Web, visit > https://www1.ietf.org/mailman/listinfo/tictoc > or, via email, send a message with subject or body 'help' to > tictoc-request@ietf.org >=20 > You can reach the person managing the list at > tictoc-owner@ietf.org >=20 > When replying, please edit your Subject line so it is more=20 > specific than "Re: Contents of TICTOC digest..." >=20 >=20 > Today's Topics: >=20 > 1. RE: preparatory material for new TICTOC charter=20 > (STUART VENTERS) >=20 >=20 > ---------------------------------------------------------------------- >=20 > Message: 1 > Date: Mon, 22 Oct 2007 13:18:05 -0500 > From: "STUART VENTERS" > Subject: RE: [TICTOC] preparatory material for new TICTOC charter > To: "Yaakov Stein" > Cc: tictoc@ietf.org > Message-ID: >=20 > <8F242B230AD6474C8E7815DE0B4982D70B99D1FF@EXV1.corp.adtran.com> > Content-Type: text/plain; charset=3D"iso-8859-1" >=20 > Yaakov, >=20 > Looks great overall, I just have a couple of minor nits. >=20 > Is SSM about management, automatic clock routing, or more likely both? > (Although I don't know how to handle it better, > I'm wondering if mentioning SSM with 4, but not 2 and 3=20 > is misleading.) >=20 > Should performance measurement be broken into 2 parts? > 1) Performance of the time/freq reference provided by TICTOC > 2) Performance required from the network TICTOC is running over. >=20 >=20 > Regards, >=20 > Stuart >=20 >=20 > -----Original Message----- > From: Yaakov Stein [mailto:yaakov_s@rad.com] > Sent: Monday, October 22, 2007 12:20 PM > To: tictoc@ietf.org > Subject: [TICTOC] preparatory material for new TICTOC charter >=20 >=20 > Hi all, >=20 > Today Stewart, Karen and I discussed Mark's request to=20 > quickly focus on which of the "modules" need be in scope for=20 > the potential WG. >=20 > We have come up with the following deliverables, broken down=20 > into two phases (times in parentheses are months from=20 > chartering of WG). >=20 > Phase 1: >=20 > 0. Architecture draft (based on modularization draft) =20 > (INFO) (6) > 1.1 requirements for time/frequency distribution protocol(s)=20 > (INFO) (9) > 1.2 analysis of existing protocols in light of 1.1 =20 > (INFO) (12) > 1.3 selection and documentation of distribution protocol(s) =20 > (STD) (24) > 2 Autodiscovery (including security aspects) =20 > (STD) (12) > 3 Topology discovery (including security aspects) =20 > (STD) (24) >=20 > Phase 2: >=20 > 4 OAM including SSM =20 > (STD) (30) > 5 Performance measurement =20 > (STD) (33) > 6 Ranging techniques =20 > (BCP) (36) > 7 MIBs =20 > (STD) (30) >=20 > Additional work, such as BCPs for various algorithms,=20 > detailed requirements for specific applications (e.g.=20 > cellular backhaul), and research topics such as globally=20 > converging classless methods, will be developed based on=20 > interest and participation. >=20 > We would appreciate feedback from the list on the choice of=20 > milestones, and the times allotted. >=20 > Y(J)S >=20 >=20 >=20 > ------------------------------ >=20 > _______________________________________________ > TICTOC mailing list > TICTOC@ietf.org > https://www1.ietf.org/mailman/listinfo/tictoc >=20 >=20 > End of TICTOC Digest, Vol 15, Issue 6 > ************************************* >=20 >=20 >=20 > _______________________________________________ > TICTOC mailing list > TICTOC@ietf.org > https://www1.ietf.org/mailman/listinfo/tictoc >=20 >=20 >=20 > _______________________________________________ > TICTOC mailing list > TICTOC@ietf.org > https://www1.ietf.org/mailman/listinfo/tictoc >=20 _______________________________________________ TICTOC mailing list TICTOC@ietf.org https://www1.ietf.org/mailman/listinfo/tictoc From tictoc-bounces@ietf.org Wed Oct 24 05:21:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkcQr-0003tf-KW; Wed, 24 Oct 2007 05:21:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkcQp-0003tW-J5 for tictoc@ietf.org; Wed, 24 Oct 2007 05:21:43 -0400 Received: from [221.130.253.133] (helo=cmccmta) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IkcQo-0005br-9E for tictoc@ietf.org; Wed, 24 Oct 2007 05:21:43 -0400 Received: from Foxmail ([10.1.6.103]) by mail.chinamobile.com (Lotus Domino Release 6.5.5FP1) with SMTP id 2007102417211181-33424 ; Wed, 24 Oct 2007 17:21:11 +0800 From: "Zhou Linlang" To: Yaakov Stein , tictoc@ietf.org Subject: Re: [TICTOC] preparatory material for new TICTOC charter X-mailer: Foxmail 4.2 [cn] Mime-Version: 1.0 Date: Wed, 24 Oct 2007 17:21:21 +0800 X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.5FP1 | April 14, 2006) at 2007-10-24 17:21:11, Serialize by Router on cmccmta/servers/cmcc(Release 6.5.5FP1 | April 14, 2006) at 2007-10-24 17:21:42, Serialize complete at 2007-10-24 17:21:42 Message-ID: Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="GB2312" X-Spam-Score: 1.9 (+) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: X-BeenThere: tictoc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: zhoulinlang@chinamobile.com List-Id: Timing over IP Connection and Transfer of Clock BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tictoc-bounces@ietf.org Dear Yaakov, I wonder what is the relation between IEEE1588=A1=A2NTP and the= Architecture/mechanism of our TICTOC=A3=BF TICTOC would choose IEEE1588=A3=BFNTP=A3=BF or create a new mechanism=A3=BF Angela ZHOU China Mobile =09 =3D=3D=3D=3D=3D=3D=3D 2007-10-22 19:19:00 you wrote=A3=BA=3D=3D=3D=3D=3D=3D=3D >Hi all, > >Today Stewart, Karen and I discussed Mark's request to >quickly focus on which of the "modules" need be in scope for= the >potential WG. > >We have come up with the following deliverables, >broken down into two phases >(times in parentheses are months from chartering of WG). > >Phase 1: > >0. Architecture draft (based on modularization draft) = (INFO) >(6) >1.1 requirements for time/frequency distribution protocol(s)= (INFO) >(9) >1.2 analysis of existing protocols in light of 1.1 = (INFO) >(12) >1.3 selection and documentation of distribution protocol(s) = (STD) >(24) >2 Autodiscovery (including security aspects) = (STD) >(12) >3 Topology discovery (including security aspects) = (STD) >(24) > >Phase 2: > >4 OAM including SSM = (STD) >(30) >5 Performance measurement = (STD) >(33) >6 Ranging techniques = (BCP) >(36) >7 MIBs = (STD) >(30) > >Additional work, such as BCPs for various algorithms, >detailed requirements for specific applications (e.g. cellular >backhaul), >and research topics such as globally converging classless= methods, >will be developed based on interest and participation. > >We would appreciate feedback from the list on the choice of >milestones, and the times allotted. > >Y(J)S >_______________________________________________ >TICTOC mailing list >TICTOC@ietf.org >https://www1.ietf.org/mailman/listinfo/tictoc =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =09=09=09 =09=09=09=09 =A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1Zhou Linlang =A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1zhoulinlang@chinamobile.com =A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A12007-10-24 _______________________________________________ TICTOC mailing list TICTOC@ietf.org https://www1.ietf.org/mailman/listinfo/tictoc From tictoc-bounces@ietf.org Wed Oct 24 06:07:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ikd8t-0006dO-Uh; Wed, 24 Oct 2007 06:07:15 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ikd8s-0005AW-4b for tictoc@ietf.org; Wed, 24 Oct 2007 06:07:14 -0400 Received: from mail2.semtech.com ([12.155.129.43]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ikd87-0007qw-4G for tictoc@ietf.org; Wed, 24 Oct 2007 06:06:28 -0400 In-Reply-To: Subject: RE: [TICTOC] Clock metrics in timing packets versus OAM To: "Laurent Montini (lmontini)" X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 Message-ID: From: DTonks@semtech.com Date: Wed, 24 Oct 2007 11:08:08 +0100 X-MIMETrack: Serialize by Router on Mail2/SMTC(Release 7.0.2FP1|January 10, 2007) at 10/24/2007 03:05:41 AM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 3643ee1fccf5d6cf2af25f27d28abb29 Cc: STUART VENTERS , tictoc@ietf.org X-BeenThere: tictoc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Timing over IP Connection and Transfer of Clock BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tictoc-bounces@ietf.org Hi Laurent, OK, on the wire, the SSM represents the QL value of the selected source. But there are QL values which will never be seen on the wire, QL-INVx, QL-FAILED, etc - these are internal QL values which exist only inside the network element. The QL used internally in the selection process is arrived at by combining the SSM value with other quality indicators like LOS, LOF and AIS. LOS and LOF are generated by the receiver and exist only within the network element, and this is why the QL can only exist inside the network element. But the outgoing SSM value still indicates the quality/accuracy/stability of the timing source that the network element is locked to (however distant it is) - unless, of course, you want to make sure the line is not selected for timing by a downstream network element (then, SSM = DNU). With a 4-bit field, there just aren't enough hex values to represent all the possible QL values - are you saying we could carry the whole QL value in a packet-based method? The QL values themselves are left to the implementers (they can't be 4-bit values anymore), so we'd have to specify something else. What would we gain? Since the term SSM has been used for years to carry the QL value, I'd warn against using it for a new channel or things will really get confusing. We need a new name for this channel. Cheers Dave Semtech Ltd Office address: 2-3 Park Court, Premier Way, Abbey Park Ind Est, Romsey, SO51 9DN Tel: +44 (0)1794 527600 Fax: +44 (0)1794 527601 Registered office: 4th Floor, Saltire Court, 20 Castle Terrace, Edinburgh, EH1 2EN Registered in Scotland 53259 VAT No. GB572685604 "Laurent Montini (lmontini)" cc 10/24/2007 10:15 , "STUART VENTERS" AM Subject RE: [TICTOC] Clock metrics in timing packets versus OAM Hi Dave, Another way to look at SSM. Actually SSM in SONET/SDH carries a value, the QL (Quality Level) value. Change of QL value is part of clock selection process. If SSM is limited to QL value in SONET/SDH, it does not mean it should for packet network. For SyncE, we still talk about SSM or ESSM but it was agreed we should be able to add field extensions. The ESSM slow protocol provides this capability. ESSM will have one mandatory "QL field" and could have other fields (like source ID, hop count from source, ...). Another idea would thus be to consider the term SSM "Synchronization Status Messaging" for a channel providing messages about synchronization network status or condition and not SSM := QL. Did I miss something from the old world? :-) Cheers, .lm > -----Original Message----- > From: DTonks@semtech.com [mailto:DTonks@semtech.com] > Sent: mardi 23 octobre 2007 19:03 > To: STUART VENTERS > Cc: tictoc@ietf.org > Subject: RE: [TICTOC] Clock metrics in timing packets versus OAM > > Hi Stuart, > Looks like I misled you a little. When I said there was no > bandwidth for extra info, I was referring to the TDM frames > (DS1, E1, SONET, SDH). For example, only 4 bits were > allocated to carrying the SSM value in SONET/SDH. > Of course, since we got 8000 frames a second, we got 32kbps > of SSM (which had a static 4-bit value for 99.9999....% of > the time!), but, in the interests of design simplicity, it > was better to have a value which was repeated every frame > rather than, say, build a more complex message over a > multiframe. Hence, we only got 4 bits to carry info and this > had to be devoted to the SSM value. But it also meant we > could detect a new SSM value very quickly, even when the SSM > value was occasionally corrupted, and this allowed us to > react fast when we needed to (given that the new SSM value > may have to go through many nodes before it hit one that was > timed from a better clock). It works well in those > circumstances when it works, but it cannot solve all our > problems (it can't fix timing loops all by itself, for > example, so it's not much use in an automated timing path > build process - that little limitation keeps sync engineers > in business, of course). > > In packet networks, we will only get a few packets per > second, but we can make the most of them because they include > error-checking so we can trust the info they carry, and so we > can still get a fast enough response. But we only use 4 bits > out of the packet to carry the SSM value, so there's plenty > of room for new stuff. I know the ITU have adopted the slow > protocol for the OAM specifically for Synchronous Ethernet, > but I can't see any reason why it can't be used for other > things - so long as it stays hop-by-hop. If we want to use > the same packet for extra info, then it would be tidier if we > can come up with a name for this packet which does not appear > to tie it too much to SSM.....the problem is, for example, if > we call it the SSM packet, we may confuse future generations > when we start to add extra info in there which is not SSM > related. We need a more general-purpose name which tells you > the packet carries sync-related info, of which a part is SSM. > But don't call it a sync packet! Or a Sync Status Message > either! Any ideas? > > The sort of info that I've heard proposed to help automatic > path builds include physical location of PRCs, number of hops > to the PRC, and port IDs, but there will be lots more when we > get going. Some things might be a bit esoteric, but we could > accommodate them if we have a flexible approach to the packet > layout - such as using TLVs. Same sort of thing for the > timing metrics. The timing metrics could change the priority > of each path dynamically - if a path became too noisy, for > example, it could be demoted. > We can do the same thing at the moment - if a path becomes > noisy or clock recovery produces an erratic clock, the path > can be demoted. > > Best wishes, > > dave > > > > > "STUART VENTERS" > > > dtran.com> > To > > > 10/23/2007 04:34 > cc > PM > > > Subject > RE: [TICTOC] Clock > metrics in > timing packets versus > OAM > > > > > > > > > > > > > > > > > Dave, > > Thanks for the reply. I'd like to understand this old ground > a little better. > (It sounds a bit like a minefield ;-) > > I agree with you that having SSM alone is not sufficient to > choose clock paths. > Some additional information is required. (Perhaps a path > metric and a priority or source ID, which NTP may have in > the Precision, Dispersion, and RefID fields.) The additional > bandwidth seems meager compared to the advantage of knowing > quickly when an input changes. > If there is a general feeling that quick is not good and so > this function should be OAM, then I'd like to better understand it. > > I do agree that some functions, like tracing out the clock > tree would be fine as OAM. > > > Regards, > > Stuart > > > -----Original Message----- > From: DTonks@semtech.com [mailto:DTonks@semtech.com] > Sent: Tuesday, October 23, 2007 4:43 AM > To: tictoc@ietf.org > Cc: tictoc@ietf.org > Subject: [TICTOC] Re: TICTOC Digest, Vol 15, Issue 6 > > > Stuart, > You've asked a good question about what is SSM about. SSM > always looks like it can do more than it was designed for, > and this is causing some confusion. SSM has its limitations > and it cannot be used for advanced things like automatically > building timing trails - although such things were proposed, > there just wasn't the bandwidth available in the frame. > We'll have to find some other way to do that, and although it > may be loosely linked in with SSM it would be separate from > it. Just remember that SSM only indicates the quality of the > sync source currently at the head of a timing path. It's a > way of passing information about a remote timing node that > can't be obtained by inspecting the signal being received > (for example, to a downstream SEC, the quality of a signal > timed by an SSU in holdover would be indistinguishable from > one being timed by a PRC - the SSM tells the SEC what the > quality is so that it can compare this trail with > alternatives). The SSM supplements other info that can be > obtained locally, such as LOS, OOF, AIS, all of which are > used to disqualify a timing trail. > That's all the SSM can do, really. Forgive me if I'm going > over old ground. > Now, if we can all agree just what additional information > would be needed for advanced features, then this info could > be made available, but it would be separate from and in > addition to the SSM info itself. Points 2 and 3 in the list > in Yaakov's email mention autodiscovery and topology > discovery, so whatever information is needed for these would > have to be made available - but these would be separate to > the SSM value. > We would also have to agree the best way to present this > extra info - OAM springs to mind, but is this the only/best > way? Personally, I think so. The ITU have decided to carry > SSMs in a slow protocol defined for OAM purposes, and there > is plenty of space in the message for other info. So, the > same messages that are used to carry SSM values could be used > to carry additional info for building timing trails, and so > on - but this is not an additional burden on the SSM flow, > and we should strive to keep SSM separate from these things. > (How we relate TICTOC to the ITU is TDB, I > guess.) > Overall, then, we may find that an OAM flow is used for > points 2,3 and 4, but SSM is kept as it is. Note, I'm > avoiding the issue of possibly making SSM obsolete if we have > access to other info...that's a topic for later. > > Taking up your other point about performance, I think it's > important from day one to recognise that different > applications will have different performance requirements. > Maybe each application will need some sort of individual > profile? We will have to define the various performance > requirements in some way (MTIE, TDEV masks? Anything else?). > Your point 2 is very important - we should recognise that > some network conditions will be too severe to support the > performance requirements. I think this should be used as part > of the timing-trail-selection mechanism so that an > alternative timing path can be selected when the current one > goes outside an agreed behaviour limit. Ultimately, though, > this may not be sufficient to guarantee good timing paths are > available, and we may eventually have to go the traditional > way and impose PDV limits on each network element (ie, > switch/router) - that should be fun. > > Getting back to metrics, the ITU are also active here, with > network behaviour metrics currently being looked at. By the > way (and pardon me for > advertising) but there will be a few presentations on these > metrics at the ITSF next month, if anyone wants to see what's > involved (http://conferences.theiet.org/itsf/). > > Cheers > Dave > > > > > tictoc-request@ie > tf.org > > To > 10/22/2007 07:22 tictoc@ietf.org > PM > cc > > > Subject > Please respond to TICTOC Digest, Vol 15, Issue 6 > tictoc@ietf.org > > > > > > > > > > Send TICTOC mailing list submissions to > tictoc@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www1.ietf.org/mailman/listinfo/tictoc > or, via email, send a message with subject or body 'help' to > tictoc-request@ietf.org > > You can reach the person managing the list at > tictoc-owner@ietf.org > > When replying, please edit your Subject line so it is more > specific than "Re: Contents of TICTOC digest..." > > > Today's Topics: > > 1. RE: preparatory material for new TICTOC charter > (STUART VENTERS) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 22 Oct 2007 13:18:05 -0500 > From: "STUART VENTERS" > Subject: RE: [TICTOC] preparatory material for new TICTOC charter > To: "Yaakov Stein" > Cc: tictoc@ietf.org > Message-ID: > > <8F242B230AD6474C8E7815DE0B4982D70B99D1FF@EXV1.corp.adtran.com> > Content-Type: text/plain; charset="iso-8859-1" > > Yaakov, > > Looks great overall, I just have a couple of minor nits. > > Is SSM about management, automatic clock routing, or more likely both? > (Although I don't know how to handle it better, > I'm wondering if mentioning SSM with 4, but not 2 and 3 > is misleading.) > > Should performance measurement be broken into 2 parts? > 1) Performance of the time/freq reference provided by TICTOC > 2) Performance required from the network TICTOC is running over. > > > Regards, > > Stuart > > > -----Original Message----- > From: Yaakov Stein [mailto:yaakov_s@rad.com] > Sent: Monday, October 22, 2007 12:20 PM > To: tictoc@ietf.org > Subject: [TICTOC] preparatory material for new TICTOC charter > > > Hi all, > > Today Stewart, Karen and I discussed Mark's request to > quickly focus on which of the "modules" need be in scope for > the potential WG. > > We have come up with the following deliverables, broken down > into two phases (times in parentheses are months from > chartering of WG). > > Phase 1: > > 0. Architecture draft (based on modularization draft) > (INFO) (6) > 1.1 requirements for time/frequency distribution protocol(s) > (INFO) (9) > 1.2 analysis of existing protocols in light of 1.1 > (INFO) (12) > 1.3 selection and documentation of distribution protocol(s) > (STD) (24) > 2 Autodiscovery (including security aspects) > (STD) (12) > 3 Topology discovery (including security aspects) > (STD) (24) > > Phase 2: > > 4 OAM including SSM > (STD) (30) > 5 Performance measurement > (STD) (33) > 6 Ranging techniques > (BCP) (36) > 7 MIBs > (STD) (30) > > Additional work, such as BCPs for various algorithms, > detailed requirements for specific applications (e.g. > cellular backhaul), and research topics such as globally > converging classless methods, will be developed based on > interest and participation. > > We would appreciate feedback from the list on the choice of > milestones, and the times allotted. > > Y(J)S > > > > ------------------------------ > > _______________________________________________ > TICTOC mailing list > TICTOC@ietf.org > https://www1.ietf.org/mailman/listinfo/tictoc > > > End of TICTOC Digest, Vol 15, Issue 6 > ************************************* > > > > _______________________________________________ > TICTOC mailing list > TICTOC@ietf.org > https://www1.ietf.org/mailman/listinfo/tictoc > > > > _______________________________________________ > TICTOC mailing list > TICTOC@ietf.org > https://www1.ietf.org/mailman/listinfo/tictoc > _______________________________________________ TICTOC mailing list TICTOC@ietf.org https://www1.ietf.org/mailman/listinfo/tictoc From tictoc-bounces@ietf.org Wed Oct 24 07:56:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ikepz-0006xA-NA; Wed, 24 Oct 2007 07:55:51 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ikepx-0006vE-Ij for tictoc@ietf.org; Wed, 24 Oct 2007 07:55:49 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ikepx-00024q-83 for tictoc@ietf.org; Wed, 24 Oct 2007 07:55:49 -0400 X-IronPort-AV: E=Sophos;i="4.21,324,1188770400"; d="scan'208";a="156242604" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 24 Oct 2007 13:55:36 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l9OBtah8023437; Wed, 24 Oct 2007 13:55:36 +0200 Received: from dhcp-gpk02-vlan300-64-103-65-150.cisco.com (dhcp-gpk02-vlan300-64-103-65-150.cisco.com [64.103.65.150]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l9OBtSUh018809; Wed, 24 Oct 2007 11:55:29 GMT Message-ID: <471F32B0.7000308@cisco.com> Date: Wed, 24 Oct 2007 12:55:28 +0100 From: Stewart Bryant User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: zhoulinlang@chinamobile.com Subject: Re: [TICTOC] preparatory material for new TICTOC charter References: In-Reply-To: Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=540; t=1193226936; x=1194090936; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=stbryant@cisco.com; z=From:=20Stewart=20Bryant=20 |Subject:=20Re=3A=20[TICTOC]=20preparatory=20material=20for=20new=20TICTO C=20charter |Sender:=20; bh=dp4JSl9VMd92zmEm3Gj7O1CVVGov+mLwXckSwZ3DohM=; b=dudapTtQT5ZiG/2nJdO4HvibzlyHsPShz8sIHsvuHD+2GuGJ5JYiOz+0ZH0bgKktkjqlE9lB 6MK80fiIhIzUzxVognAoGH+oNpFJQpEx/MNLZAyNOaZ1JtDmsRgN8yHP; Authentication-Results: ams-dkim-1; header.From=stbryant@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: "tictoc@ietf.org" X-BeenThere: tictoc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: stbryant@cisco.com List-Id: Timing over IP Connection and Transfer of Clock BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tictoc-bounces@ietf.org Zhou Linlang wrote: > Dear Yaakov, > > I wonder what is the relation between IEEE1588��NTP and the Architecture/mechanism of our TICTOC�� > > TICTOC would choose IEEE1588��NTP�� or create a new mechanism�� > > Deciding on the default time transfer mechanism is one of the first tasks that tictock would have to undertake, and the answer is by no means obvious. If anyone wants to start the ball rolling with a draft that tries to get to the core issues on which that decision rests that would be very valuable. Stewart _______________________________________________ TICTOC mailing list TICTOC@ietf.org https://www1.ietf.org/mailman/listinfo/tictoc From tictoc-bounces@ietf.org Wed Oct 24 08:25:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkfIf-0001ZE-2l; Wed, 24 Oct 2007 08:25:29 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkfIe-0001Z7-Hk for tictoc@ietf.org; Wed, 24 Oct 2007 08:25:28 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IkfId-0002kf-Hf for tictoc@ietf.org; Wed, 24 Oct 2007 08:25:28 -0400 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by sj-iport-2.cisco.com with ESMTP; 24 Oct 2007 05:25:25 -0700 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l9OCPOXE011537; Wed, 24 Oct 2007 14:25:24 +0200 Received: from dhcp-gpk02-vlan300-64-103-65-150.cisco.com (dhcp-gpk02-vlan300-64-103-65-150.cisco.com [64.103.65.150]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l9OCPJUh000850; Wed, 24 Oct 2007 12:25:24 GMT Message-ID: <471F39AF.3080307@cisco.com> Date: Wed, 24 Oct 2007 13:25:19 +0100 From: Stewart Bryant User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Brad Knowles References: <46A5719F.4050509@gis.net> <46A5F3A7.3010304@innovationslab.net> <471E1E23.8040701@innovationslab.net> <471EC148.6000403@ntp.isc.org> <471F062F.4000806@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=7155; t=1193228724; x=1194092724; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=stbryant@cisco.com; z=From:=20Stewart=20Bryant=20 |Subject:=20Re=3A=20[ntpwg]=20Documents, =20slides, =20etc.=20from=20WG=20m eeting |Sender:=20; bh=VTuY3rcOfav/d4FM3r1UxtAdC0vRczcecfCAmBylAU4=; b=NxdmAqT/uC39Gp4U70QgkZl/mMyIDAElbvLrLKxxuF0hwuVpKlHlIKuda9LC9L0PyFO5/7Fs npVIK0LH/r7Ve8DATDFgW5k9KJnprsVpHZLB4WwTK41XoZhNztLCEtHe; Authentication-Results: ams-dkim-2; header.From=stbryant@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Cc: mayer@ntp.isc.org, NTP Working Group , Brian Haberman , "tictoc@ietf.org" Subject: [TICTOC] Re: [ntpwg] Documents, slides, etc. from WG meeting X-BeenThere: tictoc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: stbryant@cisco.com List-Id: Timing over IP Connection and Transfer of Clock BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tictoc-bounces@ietf.org Brad Knowles wrote: > On 10/24/07, Stewart Bryant wrote: > >> In discussing 1588, you need to make sure you are talking about the V2 >> spec. V1 is not likely to see significant deployment, whist V2 is >> likely >> to get significant hardware support and hence be widely deployed. > > Therein lies the problem. I've been going through the page at > , and I can't find any real discussion of > the protocol, or specifics of the implementations. I didn't even find > any reference to V1 versus V2, and hence did not know that there was > an updated version. V2 has not been published yet. It is currently mid way though the IEEE ballot process at the moment. You may also wish to be aware of the 802.1AS project which is based on 1588 and is also in IEEE ballot. You could also look at the proceedings of a number of the timing conferences over the past couple of years - WSTS, ITSF and the IEEE1588 conference for more implementation and application information. > > > Sure, they reference specific chipsets as implementing IEEE 1588, and > other specific devices (this is how I found out about the clock that > Meinberg makes). > > But when the description given for IEEE 1588 is completely circular in > nature, just exactly what good does that do for anyone? I am not sure what you mean by that. > >> Both V1 and V2 can use multicast IP encapsulation and you can in >> principle build an IP multicast net, but I have always regarded this >> mode of operation as a little strange and unlikely to ge deployed >> outside a highly controlled network. I doubt if we will ever see the >> 1588 multicast mode on the Internet. > > We've talked to one of the guys at ISC about broad use of multicast on > the Internet, and they've explained why they believe that would be a > bad idea. > > You may get multicast internal to a given network at a single entity, > but you're unlikely to get it anywhere else. > >> However V2 can run over a unicast IP connection, and this is likely >> to find >> use in wide area networks. Indeed it exists largely to support the >> needs of >> the telecommunications operators for a method of providing clock >> sync over >> packet. > > If it's used by telecom operators, why do they need IP or anything > else that heavy? I mean, if we're talking about something like SONET > synchronization, and they're worried about sub-nanosecond resolution, > then it seems to me that IP is a very hefty hammer to be wielding. They are migrating off SONET to Ethernet, and hence loose the ability to deliver sync to some applications (for example cell sites) that need sync. There is some work on Synchronous Ethernet (meaning Ethernet with synchronous carrier, NOT synchronous packets, but that requires an end to end sync path which may not be available, hence the interest in sync over packet. There are many other applications for tiem and frequency sync, but the mobile phone network is the poster child. > >> I am not sure what you mean by this. How the grand master acquires and >> locks to an external clock reference is outside the scope of the >> protocol, >> but it's also outside the scope of the NTP. > > But we have reference clocks, right? And we have a defined way to > interface with them? Sure, you have Caesiums and GPS locked Quartz and Rhubidiums clocks, some subset of these speak 1588, just as some subset of them currently speak NTP, and by analogy some subset speak GPS. > > > Honestly, I'm not trying to argue. I'm trying to understand better > where IEEE 1588 fits into the picture, and I'm just not finding much > in the way of what I consider to be useful documentation on the IEEE > website. You could read John Eidson's book, though this is mainly about V1. However it does give a lot of context and the applications are invariant to a V1 or a V2 solution. > > From what little I can tell, it seems to me that IEEE 1588 is much > more oriented towards a closed single-entity local area (or near-local > area) network environment, where you don't care if you're sync'ed to > any given external reference, or how close or far you may be from The > One True Time, you just care that all your internal slaves are sync'ed > to your given master, and that you have some pretty tight tolerances > on how far out of sync the slaves can get. Absolutely not. One of the GM selection criteria is external reference and that includes GPS, Atomic etc. > > In contrast, it seems to me that NTP works well on the broader WAN > multi-entity internet (global and beyond), and that it can work just > fine on smaller scale single-entity networks where sub-nanosecond > accuracy timekeeping is not required. > > > The two protocols seem to complement each other pretty well, and it > would appear that the folks at Meinberg agree. The key issue is that we need better accuracy in the wide area. > > > Ahh, okay. Found the URL for one of the tutorials at > , which was a little more > diffcult to find than it needed to be, thanks to the frame-based way > the web pages are laid out. > > Anyway, Page 6 of the PDF is where we want to start, where they > specifically compare IEEE 1588 and NTP, among others. I think they're > wrong to target the peer-to-peer mode exclusively for NTP, but that is > certainly one potential model that could be used with NTP. There are > other master/slave relationships that would be more typical for use > with NTP, but that doesn't really affect the conclusions you can draw > from those slides. > > Slide 9 is also useful: > > Objectives of IEEE 1588 > > + Sub-microsecond synchronization of real-time clocks in > components of a networked distributed measurement and > control system [0] > > + Intended for relatively localized systems typical of > industrial automation and test and measurement environments. [0] > > + Applicable to local area networks supporting multicast > communications (including but not limited to Ethernet) > > [0] indicates objectives that may be extended in version 2 > > > Hmm. Did they fix the assumption of symmetric delays between master & > slave in V2? No. The asymmetry is a fundamental issue in all two way time transfer protocols > > Or the complete lack of any kind of security? I mean, UDP is > trivially easy to spoof, and given that everyone on the subnet is > supposed to be operating with the exact same information and the exact > same algorithms, it seems like it would be simple to see who the > current master clock is and spoof them as being bogus and force a new > master clock to be selected -- which you should be able to guarantee > is your selected trojan machine.... > There is an informational description of a security mechanism in the V2 specification, although I think that is something that the IETF should take a look at if we write and IETF 1588 profile. Stewart _______________________________________________ TICTOC mailing list TICTOC@ietf.org https://www1.ietf.org/mailman/listinfo/tictoc From tictoc-bounces@ietf.org Wed Oct 24 08:52:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ikfik-0007S2-Su; Wed, 24 Oct 2007 08:52:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ikdti-0000AV-JU for tictoc@ietf.org; Wed, 24 Oct 2007 06:55:38 -0400 Received: from smtp102.his.com ([216.194.225.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IkdtW-0008VP-IS for tictoc@ietf.org; Wed, 24 Oct 2007 06:55:32 -0400 Received: from localhost (localhost [127.0.0.1]) by smtp102.his.com (Postfix) with ESMTP id 579031900A1; Wed, 24 Oct 2007 06:54:41 -0400 (EDT) Received: from smtp102.his.com ([216.194.225.125]) by localhost (smtp102.his.com [216.194.225.125]) (amavisd-new, port 10024) with ESMTP id 32017-04; Wed, 24 Oct 2007 06:54:34 -0400 (EDT) Received: from vhost109.his.com (vhost109.his.com [216.194.225.101]) by smtp102.his.com (Postfix) with ESMTP id 5FBF019007B; Wed, 24 Oct 2007 06:54:33 -0400 (EDT) Received: from [192.168.1.135] (localhost.his.com [127.0.0.1]) by vhost109.his.com (8.13.1/8.12.3) with ESMTP id l9OAsV3W075528; Wed, 24 Oct 2007 06:54:32 -0400 (EDT) (envelope-from brad@shub-internet.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <471F062F.4000806@cisco.com> References: <46A5719F.4050509@gis.net> <46A5F3A7.3010304@innovationslab.net> <471E1E23.8040701@innovationslab.net> <471EC148.6000403@ntp.isc.org> <471F062F.4000806@cisco.com> Date: Wed, 24 Oct 2007 05:54:07 -0500 To: stbryant@cisco.com, Brad Knowles From: Brad Knowles Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Virus-Scanned: Debian amavisd-new at smtp502.his.com X-Spam-Status: No, score=-4.375 tagged_above=-99 required=5 tests=[ALL_TRUSTED=-1.8, AWL=0.024, BAYES_00=-2.599] X-Spam-Score: -4.375 X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 X-Mailman-Approved-At: Wed, 24 Oct 2007 08:52:26 -0400 Cc: mayer@ntp.isc.org, NTP Working Group , Brian Haberman , "tictoc@ietf.org" Subject: [TICTOC] Re: [ntpwg] Documents, slides, etc. from WG meeting X-BeenThere: tictoc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Timing over IP Connection and Transfer of Clock BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tictoc-bounces@ietf.org On 10/24/07, Stewart Bryant wrote: > In discussing 1588, you need to make sure you are talking about the V2 > spec. V1 is not likely to see significant deployment, whist V2 is likely > to get significant hardware support and hence be widely deployed. Therein lies the problem. I've been going through the page at , and I can't find any real discussion of the protocol, or specifics of the implementations. I didn't even find any reference to V1 versus V2, and hence did not know that there was an updated version. Sure, they reference specific chipsets as implementing IEEE 1588, and other specific devices (this is how I found out about the clock that Meinberg makes). But when the description given for IEEE 1588 is completely circular in nature, just exactly what good does that do for anyone? > Both V1 and V2 can use multicast IP encapsulation and you can in > principle build an IP multicast net, but I have always regarded this > mode of operation as a little strange and unlikely to ge deployed > outside a highly controlled network. I doubt if we will ever see the > 1588 multicast mode on the Internet. We've talked to one of the guys at ISC about broad use of multicast on the Internet, and they've explained why they believe that would be a bad idea. You may get multicast internal to a given network at a single entity, but you're unlikely to get it anywhere else. > However V2 can run over a unicast IP connection, and this is likely to find > use in wide area networks. Indeed it exists largely to support the needs of > the telecommunications operators for a method of providing clock sync over > packet. If it's used by telecom operators, why do they need IP or anything else that heavy? I mean, if we're talking about something like SONET synchronization, and they're worried about sub-nanosecond resolution, then it seems to me that IP is a very hefty hammer to be wielding. > I am not sure what you mean by this. How the grand master acquires and > locks to an external clock reference is outside the scope of the protocol, > but it's also outside the scope of the NTP. But we have reference clocks, right? And we have a defined way to interface with them? Honestly, I'm not trying to argue. I'm trying to understand better where IEEE 1588 fits into the picture, and I'm just not finding much in the way of what I consider to be useful documentation on the IEEE website. From what little I can tell, it seems to me that IEEE 1588 is much more oriented towards a closed single-entity local area (or near-local area) network environment, where you don't care if you're sync'ed to any given external reference, or how close or far you may be from The One True Time, you just care that all your internal slaves are sync'ed to your given master, and that you have some pretty tight tolerances on how far out of sync the slaves can get. In contrast, it seems to me that NTP works well on the broader WAN multi-entity internet (global and beyond), and that it can work just fine on smaller scale single-entity networks where sub-nanosecond accuracy timekeeping is not required. The two protocols seem to complement each other pretty well, and it would appear that the folks at Meinberg agree. Ahh, okay. Found the URL for one of the tutorials at , which was a little more diffcult to find than it needed to be, thanks to the frame-based way the web pages are laid out. Anyway, Page 6 of the PDF is where we want to start, where they specifically compare IEEE 1588 and NTP, among others. I think they're wrong to target the peer-to-peer mode exclusively for NTP, but that is certainly one potential model that could be used with NTP. There are other master/slave relationships that would be more typical for use with NTP, but that doesn't really affect the conclusions you can draw from those slides. Slide 9 is also useful: Objectives of IEEE 1588 + Sub-microsecond synchronization of real-time clocks in components of a networked distributed measurement and control system [0] + Intended for relatively localized systems typical of industrial automation and test and measurement environments. [0] + Applicable to local area networks supporting multicast communications (including but not limited to Ethernet) [0] indicates objectives that may be extended in version 2 Hmm. Did they fix the assumption of symmetric delays between master & slave in V2? Or the complete lack of any kind of security? I mean, UDP is trivially easy to spoof, and given that everyone on the subnet is supposed to be operating with the exact same information and the exact same algorithms, it seems like it would be simple to see who the current master clock is and spoof them as being bogus and force a new master clock to be selected -- which you should be able to guarantee is your selected trojan machine.... -- Brad Knowles LinkedIn Profile: _______________________________________________ TICTOC mailing list TICTOC@ietf.org https://www1.ietf.org/mailman/listinfo/tictoc From tictoc-bounces@ietf.org Wed Oct 24 13:37:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkkAf-0007Xr-QL; Wed, 24 Oct 2007 13:37:33 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkkAe-0007Xj-N2 for tictoc@ietf.org; Wed, 24 Oct 2007 13:37:32 -0400 Received: from mail4.symmetricom.com ([69.25.98.6]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IkkAe-0003ai-CK for tictoc@ietf.org; Wed, 24 Oct 2007 13:37:32 -0400 X-ASG-Debug-ID: 1193247451-1fb0032f0000-4wH9i1 X-Barracuda-URL: http://192.168.10.95:80/cgi-bin/mark.cgi Received: from sjowa.symmetricom.com (localhost [127.0.0.1]) by mail4.symmetricom.com (Spam Firewall) with ESMTP id 1DBCC27C64C for ; Wed, 24 Oct 2007 10:37:31 -0700 (PDT) Received: from sjowa.symmetricom.com ([192.168.10.41]) by mail4.symmetricom.com with ESMTP id BQTHwyRWvk3aAGhu for ; Wed, 24 Oct 2007 10:37:31 -0700 (PDT) X-ASG-Whitelist: Client Received: from sjmail2.symmetricom.com ([192.168.10.66]) by sjowa.symmetricom.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 24 Oct 2007 10:37:30 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-ASG-Orig-Subj: Combinations of protocols X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 24 Oct 2007 10:37:30 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: Combinations of protocols thread-index: AcgWNQdOkUAhZwBZSkCKyMX9+k5msAAFT/vQ References: From: "Jeremy Bennington" To: X-OriginalArrivalTime: 24 Oct 2007 17:37:30.0945 (UTC) FILETIME=[8DABDB10:01C81664] X-Barracuda-Connect: UNKNOWN[192.168.10.41] X-Barracuda-Start-Time: 1193247451 X-Barracuda-Virus-Scanned: by Symmetricom Spam Gateway at symmetricom.com X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Subject: [TICTOC] Combinations of protocols X-BeenThere: tictoc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Timing over IP Connection and Transfer of Clock BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tictoc-bounces@ietf.org =20 > Stewart wrote: > Deciding on the default time transfer mechanism is one of the first tasks that tictoc would have to=20 > undertake, and the answer is by no means obvious. I agree the answer is not completely obvious or consistent across the network. =20 In the current draft of tictocmod we have a model for frequency and time acquisition. These functions may be related so there could be several combinations for us to consider: NTP with a Stratum 1 traceable frequency present (SyncE (G.8261), SDH, etc.) 1588 with a Stratum 1 traceable frequency present (SyncE, SDH, etc.) NTP without=20 1588 without There may also be interworking functions. For instance if we are just trying to provide frequency recovery over packet then we could also have: SyncE to NTP SyncE to 1588 etc. There may also be requirements within a POP that are more strict than over the network. I assume that is outside the scope of tictoc? Thanks! -Jeremy B. =20 _______________________________________________ TICTOC mailing list TICTOC@ietf.org https://www1.ietf.org/mailman/listinfo/tictoc From tictoc-bounces@ietf.org Wed Oct 24 16:46:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ikn6y-0001YJ-Kv; Wed, 24 Oct 2007 16:45:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ikn6x-0001Y9-Mk for tictoc@ietf.org; Wed, 24 Oct 2007 16:45:55 -0400 Received: from mail4.symmetricom.com ([69.25.98.6]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ikn6r-0005Tl-A2 for tictoc@ietf.org; Wed, 24 Oct 2007 16:45:55 -0400 X-ASG-Debug-ID: 1193258737-1ddb00810000-4wH9i1 X-Barracuda-URL: http://192.168.10.95:80/cgi-bin/mark.cgi Received: from sjowa.symmetricom.com (localhost [127.0.0.1]) by mail4.symmetricom.com (Spam Firewall) with ESMTP id 045E227E1B4; Wed, 24 Oct 2007 13:45:37 -0700 (PDT) Received: from sjowa.symmetricom.com ([192.168.10.41]) by mail4.symmetricom.com with ESMTP id KxKgvkLNZUPZpAWX; Wed, 24 Oct 2007 13:45:37 -0700 (PDT) X-ASG-Whitelist: Client Received: from sjmail2.symmetricom.com ([192.168.10.66]) by sjowa.symmetricom.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 24 Oct 2007 13:45:37 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-ASG-Orig-Subj: RE: [ntpwg] Documents, slides, etc. from WG meeting X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 24 Oct 2007 13:45:29 -0700 Message-ID: In-Reply-To: <471F8AE2.6060709@udel.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [ntpwg] Documents, slides, etc. from WG meeting thread-index: AcgWacTmAm/qF0d+RROZ3uEz5JKqoQAEkT2Q From: "Greg Dowd" To: "David L. Mills" X-OriginalArrivalTime: 24 Oct 2007 20:45:37.0738 (UTC) FILETIME=[D51FCAA0:01C8167E] X-Barracuda-Connect: UNKNOWN[192.168.10.41] X-Barracuda-Start-Time: 1193258738 X-Barracuda-Virus-Scanned: by Symmetricom Spam Gateway at symmetricom.com X-Spam-Score: 0.0 (/) X-Scan-Signature: b84f8c8fba0e1389e5eb998b64078964 Cc: NTP Working Group , tictoc@ietf.org Subject: [TICTOC] RE: [ntpwg] Documents, slides, etc. from WG meeting X-BeenThere: tictoc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Timing over IP Connection and Transfer of Clock BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tictoc-bounces@ietf.org At the recent ISPCS2007 plugfest, there were dozens of oem's demoing v2 of IEEE1588. Symmetricom demonstrated v2 default profile (multicast) and telecom profile (unicast) as did many others. The v2 draft isn't final yet which I imagine is why you don't see "pre-n" grandmasters showing up as GA product. In the unicast, multicast arena the same problem with delay requests already applies but it's even worse. V1 delay requests/response are multicast (many-to-many). In the v2 unicast model, each client negotiates their own announce, sync and delay request flows with the master. More load on the master but the other ne's get the benefit. Also, depending on the physical network implementation, some networks don't allow multicast in both directions. There is discussion ongoing on blended approaches such as that you mentioned (mc sync with unicast delay) but that has the stronger possibility of creating path asymmetry for time applications. One thing I haven't seen mentioned is separation of sync and servo. In ntp, the servo is intrinsically part of the protocol while 1588 separates the two. Lastly, regardless of the protocol the network itself is only capable of passing phase and frequency to some level which is very difficult to identify. Google minTDEV. =20 Ok, jury duty calls. =20 =20 -----Original Message----- From: ntpwg-bounces+gdowd=3Dsymmetricom.com@lists.ntp.org [mailto:ntpwg-bounces+gdowd=3Dsymmetricom.com@lists.ntp.org] On Behalf = Of David L. Mills Sent: Wednesday, October 24, 2007 11:12 AM Cc: NTP Working Group; tictoc@ietf.org Subject: Re: [ntpwg] Documents, slides, etc. from WG meeting Guys, I have carefully trod over the V2 spec and investigated the available 1588-capable devices. You have to be very careful when comparing NTP and 1588. The bottom line is that NTP is best used to synchronizes computer system clocks, while 1588 is best used to synchronize hardware interface clocks and other data acquisition or telecom devices on a LAN. To sustain the best accuracy, special Ethernet switches called boundary clocks are necessary, so 1588 would not normally be expected to transit a level-3 router, although in priciple it could. The comments about 1588 V1 and V2 are interesting. All the devices I know about from Symmetricom, Meinberg and 1588 Ethernet interfaces are V1 (1588-2002). The Intel chipsets should be able to do both. The Symmetricom 1588 grandmaster costs several thousand bucks and doesn't even do NTP. The Meinberg grandmaster does 1588 and NTP and in fact does everything the public NTPv4 distribution does, including Autokey. There are a few straightforward issues that might have been overlooked.=20 The computer system clock is typically interpolated by the PCC/TSC with resolution 1 ns, but reading it via syscall typically burns 500 ns in modern silicon. The resolution of a 1588 timestamp is 1 ns, while the resolution of an NTP timestamp is 0.232 ns, although the difference is not significant. It is reasonable that the ioctl time to fetch a timestamp from a 1588 interface would be comparable to the time to read the system clock, 500 ns. The TCXO rock in a 1588 interface is not likely to operate at frequencies much above 20 MHz, although a cold rock might be higher. In other words, the 1588 resolution as a practical matter will be in the 50 ns range. The NSI Etherface and Symmetricom grandmaster claim resolution of 50 ns. What the above suggests is that 1588 will likely find the most important application to synchronize LAN hardware interface clocks to a grandmaster to the order of 50 ns. Real-time devices can provide signals that latch the interface clock which is later read by the program. This has nothing to do with the computer system clock. However, it is interesting to speculate on how 1588 and NTP could interoperate or support each other. In one approach 1588 can be used within a LAN with time exported beyond the level-3 router by NTP. In another, 1588 interfaces can be used to derive precision timestamps for use by NTP. A project on my shelf is to modify the driver for my 1588 Etherface for use as a reference clock driver. In answer to a previous question, 1588 V2 has the same limitations as NTP; both use four timestamps to compute offset and delay and assume the one-way delays are very nearly the same. There is a proposal for security extensions to 1588, although it does not address the issue of possibly degraded accuracy. Since 1588 uses hardware derived timestamps and is not expected to face seriously hostile attacks as assumed in NTP, this might not matter. As a very simple security provision, 1588 could well adopt the NTP protocol defenses used to deflect hostile replays and lost packets. This does not change the protocol or packet format. Finally, the observation that 1588 multicast might become deprecated is interesting. I make no judgement about that, but Symmetricom promotes its use in networks with thousands (!) of 1588 slaves. Well, maybe; the SYNC message is one-to-many, but this will be followed by thousands of DELAY_REQ messages imploding at the grandmaster. Dave Brad Knowles wrote: > On 10/24/07, Stewart Bryant wrote: > >> In discussing 1588, you need to make sure you are talking about the=20 >> V2 spec. V1 is not likely to see significant deployment, whist V2 is=20 >> likely to get significant hardware support and hence be widely deployed. > > > Therein lies the problem. I've been going through the page at=20 > , and I can't find any real discussion of=20 > the protocol, or specifics of the implementations. I didn't even find=20 > any reference to V1 versus V2, and hence did not know that there was=20 > an updated version. > > > Sure, they reference specific chipsets as implementing IEEE 1588, and=20 > other specific devices (this is how I found out about the clock that=20 > Meinberg makes). > > But when the description given for IEEE 1588 is completely circular in > nature, just exactly what good does that do for anyone? > >> Both V1 and V2 can use multicast IP encapsulation and you can in=20 >> principle build an IP multicast net, but I have always regarded this=20 >> mode of operation as a little strange and unlikely to ge deployed=20 >> outside a highly controlled network. I doubt if we will ever see the >> 1588 multicast mode on the Internet. > > > We've talked to one of the guys at ISC about broad use of multicast on > the Internet, and they've explained why they believe that would be a=20 > bad idea. > > You may get multicast internal to a given network at a single entity,=20 > but you're unlikely to get it anywhere else. > >> However V2 can run over a unicast IP connection, and this is likely=20 >> to find use in wide area networks. Indeed it exists largely to=20 >> support the needs of the telecommunications operators for a method of >> providing clock sync over packet. > > > If it's used by telecom operators, why do they need IP or anything=20 > else that heavy? I mean, if we're talking about something like SONET=20 > synchronization, and they're worried about sub-nanosecond resolution,=20 > then it seems to me that IP is a very hefty hammer to be wielding. > >> I am not sure what you mean by this. How the grand master acquires=20 >> and locks to an external clock reference is outside the scope of the=20 >> protocol, but it's also outside the scope of the NTP. > > > But we have reference clocks, right? And we have a defined way to > interface with them? > > > Honestly, I'm not trying to argue. I'm trying to understand better > where IEEE 1588 fits into the picture, and I'm just not finding much > in the way of what I consider to be useful documentation on the IEEE > website. > > From what little I can tell, it seems to me that IEEE 1588 is much > more oriented towards a closed single-entity local area (or > near-local area) network environment, where you don't care if you're > sync'ed to any given external reference, or how close or far you may > be from The One True Time, you just care that all your internal > slaves are sync'ed to your given master, and that you have some > pretty tight tolerances on how far out of sync the slaves can get. > > In contrast, it seems to me that NTP works well on the broader WAN > multi-entity internet (global and beyond), and that it can work just > fine on smaller scale single-entity networks where sub-nanosecond > accuracy timekeeping is not required. > > > The two protocols seem to complement each other pretty well, and it > would appear that the folks at Meinberg agree. > > > Ahh, okay. Found the URL for one of the tutorials at > , which was a little > more diffcult to find than it needed to be, thanks to the frame-based > way the web pages are laid out. > > Anyway, Page 6 of the PDF is where we want to start, where they > specifically compare IEEE 1588 and NTP, among others. I think > they're wrong to target the peer-to-peer mode exclusively for NTP, > but that is certainly one potential model that could be used with > NTP. There are other master/slave relationships that would be more > typical for use with NTP, but that doesn't really affect the > conclusions you can draw from those slides. > > Slide 9 is also useful: > > Objectives of IEEE 1588 > > + Sub-microsecond synchronization of real-time clocks in > components of a networked distributed measurement and > control system [0] > > + Intended for relatively localized systems typical of > industrial automation and test and measurement environments. [0] > > + Applicable to local area networks supporting multicast > communications (including but not limited to Ethernet) > > [0] indicates objectives that may be extended in version 2 > > > Hmm. Did they fix the assumption of symmetric delays between master > & slave in V2? > > Or the complete lack of any kind of security? I mean, UDP is > trivially easy to spoof, and given that everyone on the subnet is > supposed to be operating with the exact same information and the > exact same algorithms, it seems like it would be simple to see who > the current master clock is and spoof them as being bogus and force a > new master clock to be selected -- which you should be able to > guarantee is your selected trojan machine.... > _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org https://lists.ntp.org/mailman/listinfo/ntpwg _______________________________________________ TICTOC mailing list TICTOC@ietf.org https://www1.ietf.org/mailman/listinfo/tictoc From tictoc-bounces@ietf.org Thu Oct 25 10:00:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il3Gd-0005aH-Cv; Thu, 25 Oct 2007 10:00:59 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il3Gc-0005SM-0D for tictoc@ietf.org; Thu, 25 Oct 2007 10:00:58 -0400 Received: from webmail.resolutenetworks.com ([80.179.15.67] helo=mail.resolutenetworks.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Il3GZ-0007fI-CZ for tictoc@ietf.org; Thu, 25 Oct 2007 10:00:55 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-cr-puzzleid: {703D8AAF-9F28-4772-9E39-73701A13D5DF} Content-class: urn:content-classes:message x-cr-hashedpuzzle: AAwy Bufx CCK9 EKvX EMtd EavI Erdm FXWH FXnG GEqE GiYU IM5I ImkY Iqz4 J6Ct LTf4; 1; dABpAGMAdABvAGMAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {703D8AAF-9F28-4772-9E39-73701A13D5DF}; cgBvAG4AYwBAAHIAZQBzAG8AbAB1AHQAZQBuAGUAdAB3AG8AcgBrAHMALgBjAG8AbQA=; Thu, 25 Oct 2007 14:03:31 GMT; VABJAEMAVABPAEMAIABzAGMAbwBwAGUAOgAgAFAAdQBiAGwAaQBjACAASQBuAHQAZQByAG4AZQB0ACAAbwByACAAUAByAG8AdgBpAGQAZQByACAAcwBjAG8AcABlAA== Date: Thu, 25 Oct 2007 16:03:31 +0200 Message-ID: <0606D918CE9CEA4E9835D2CDAA001A95F89694@ilmail1.il.reduxcom.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TICTOC scope: Public Internet or Provider scope Thread-Index: AcgXD9L+LeZ/EG/MTJafJii3GvaYiA== From: "Ron Cohen" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Subject: [TICTOC] TICTOC scope: Public Internet or Provider scope X-BeenThere: tictoc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Timing over IP Connection and Transfer of Clock BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tictoc-bounces@ietf.org Hi, I have concerns regarding the scope of work and charter proposed for TICTOC.=20 I'm in the opinion that TICTOC should focus its effort on timing distribution within a single provider administrated network. Once successful, TICTOC may need to address the multi-provider or multi-administrator network case. I do not believe that TICTOC need to address the public Internet scope at all. The model I have in mind is PWE3 that focused initially on a single provider as a first step and moved to multi-hop solutions as a second step only. A focused scope is key to the success of the working group in building the right solution in reasonable time. I believe that NTP handles well the public internet timing distribution and there is no strong enough need to address the public internet timing distribution in TICTOC. In my opinion the problem scope should be: A provider has timing information within its core. Provider edge devices connected over PSN require timing information. Timing distribution is intra-provider from its core to its edges. I raise this concern following the TICTOC module draft by Yaakov, Karen and Stewart which states: "The TICTOC architecture will be commensurate with the public Internet, and the timing distribution protocol chosen will be able to function over general packet switched networks." Opinions appreciated, Best, Ron Ron Cohen Resolute Networks _______________________________________________ TICTOC mailing list TICTOC@ietf.org https://www1.ietf.org/mailman/listinfo/tictoc From tictoc-bounces@ietf.org Thu Oct 25 10:26:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il3fa-0006ZF-0d; Thu, 25 Oct 2007 10:26:46 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il3fZ-0005tF-44 for tictoc@ietf.org; Thu, 25 Oct 2007 10:26:45 -0400 Received: from mail2.semtech.com ([12.155.129.43]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Il3fB-0000E3-17 for tictoc@ietf.org; Thu, 25 Oct 2007 10:26:21 -0400 In-Reply-To: <0606D918CE9CEA4E9835D2CDAA001A95F89694@ilmail1.il.reduxcom.com> Subject: Re: [TICTOC] TICTOC scope: Public Internet or Provider scope To: "Ron Cohen" X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 Message-ID: From: PDiamond@semtech.com Date: Thu, 25 Oct 2007 07:28:06 -0700 X-MIMETrack: Serialize by Router on Mail2/SMTC(Release 7.0.2FP1|January 10, 2007) at 10/25/2007 07:25:32 AM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: tictoc@ietf.org X-BeenThere: tictoc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Timing over IP Connection and Transfer of Clock BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tictoc-bounces@ietf.org Hi Ron, I support you in this position. This is a very large and complex task to identify all the elements and gain consensus. I agree we should not try and eat the entire Elephant in one bite. I would also encourage the group to consider the establishment early in the process of the notion of network performance profiles that relate to specific service type delivery. This could be used to create a quasi class of service definition on a network and path basis. Regards, Patrick Diamond "Ron Cohen" To 10/25/2007 07:05 cc AM Subject [TICTOC] TICTOC scope: Public Internet or Provider scope Hi, I have concerns regarding the scope of work and charter proposed for TICTOC. I'm in the opinion that TICTOC should focus its effort on timing distribution within a single provider administrated network. Once successful, TICTOC may need to address the multi-provider or multi-administrator network case. I do not believe that TICTOC need to address the public Internet scope at all. The model I have in mind is PWE3 that focused initially on a single provider as a first step and moved to multi-hop solutions as a second step only. A focused scope is key to the success of the working group in building the right solution in reasonable time. I believe that NTP handles well the public internet timing distribution and there is no strong enough need to address the public internet timing distribution in TICTOC. In my opinion the problem scope should be: A provider has timing information within its core. Provider edge devices connected over PSN require timing information. Timing distribution is intra-provider from its core to its edges. I raise this concern following the TICTOC module draft by Yaakov, Karen and Stewart which states: "The TICTOC architecture will be commensurate with the public Internet, and the timing distribution protocol chosen will be able to function over general packet switched networks." Opinions appreciated, Best, Ron Ron Cohen Resolute Networks _______________________________________________ TICTOC mailing list TICTOC@ietf.org https://www1.ietf.org/mailman/listinfo/tictoc _______________________________________________ TICTOC mailing list TICTOC@ietf.org https://www1.ietf.org/mailman/listinfo/tictoc From tictoc-bounces@ietf.org Thu Oct 25 11:20:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il4V3-0005f9-Hg; Thu, 25 Oct 2007 11:19:57 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il4V2-0005aY-44 for tictoc@ietf.org; Thu, 25 Oct 2007 11:19:56 -0400 Received: from p02c11o142.mxlogic.net ([208.65.144.75]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Il4Ux-00022Q-MZ for tictoc@ietf.org; Thu, 25 Oct 2007 11:19:51 -0400 Received: from unknown [208.251.151.99] by p02c11o142.mxlogic.net (mxl_mta-5.2.0-1) with SMTP id 714b0274.1701145520.49662.00-032.p02c11o142.mxlogic.net (envelope-from ); Thu, 25 Oct 2007 09:19:51 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 25 Oct 2007 10:19:42 -0500 Message-ID: <8F242B230AD6474C8E7815DE0B4982D70B99D20D@EXV1.corp.adtran.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TICTOC scope: Public Internet or Provider scope Thread-Index: AcgXGne1IBhp5jLjTVCdd6oRVwcnew== From: "STUART VENTERS" To: X-Spam: [F=0.0146302204; S=0.014(2007101601); SS=0.500] X-MAIL-FROM: X-SOURCE-IP: [208.251.151.99] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: tictoc@ietf.org Subject: [TICTOC] TICTOC scope: Public Internet or Provider scope X-BeenThere: tictoc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Timing over IP Connection and Transfer of Clock BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1282848527==" Errors-To: tictoc-bounces@ietf.org This is a multi-part message in MIME format. --===============1282848527== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8171A.7794F30D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8171A.7794F30D Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Ron, Your proposed initial TicToc scope limit of=20 single administrative domain core to edge is certainly first on my list, but I wonder if distribution in the single provider's core should be = included as well? Regards, Stuart ------_=_NextPart_001_01C8171A.7794F30D Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable TICTOC scope: Public Internet or Provider scope

Ron,

Your proposed initial = TicToc scope limit of

single administrative domain = core to edge is certainly first on my list,

but I wonder if distribution = in the single provider's core should be included as well?

Regards,

Stuart

------_=_NextPart_001_01C8171A.7794F30D-- --===============1282848527== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ TICTOC mailing list TICTOC@ietf.org https://www1.ietf.org/mailman/listinfo/tictoc --===============1282848527==-- From tictoc-bounces@ietf.org Thu Oct 25 11:49:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il4xJ-0006g0-62; Thu, 25 Oct 2007 11:49:09 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ikki9-0007kx-JR for tictoc@ietf.org; Wed, 24 Oct 2007 14:12:09 -0400 Received: from whimsy.udel.edu ([128.4.2.3]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ikki7-0004fI-Sg for tictoc@ietf.org; Wed, 24 Oct 2007 14:12:09 -0400 Received: by whimsy.udel.edu (Postfix, from userid 62) id 41636163C; Wed, 24 Oct 2007 18:11:55 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on whimsy.udel.edu X-Spam-Level: X-Spam-Status: No, score=-1.2 required=4.1 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [128.4.2.6] (backroom.udel.edu [128.4.2.6]) by whimsy.udel.edu (Postfix) with ESMTP id 1DD571591; Wed, 24 Oct 2007 18:11:47 +0000 (UTC) Message-ID: <471F8AE2.6060709@udel.edu> Date: Wed, 24 Oct 2007 18:11:46 +0000 From: "David L. Mills" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en References: <46A5719F.4050509@gis.net> <46A5F3A7.3010304@innovationslab.net> <471E1E23.8040701@innovationslab.net> <471EC148.6000403@ntp.isc.org> <471F062F.4000806@cisco.com> In-Reply-To: X-Sanitizer: This message has been sanitized! X-Sanitizer-URL: http://mailtools.anomy.net/ X-Sanitizer-Rev: UDEL-ECECIS: Sanitizer.pm, v 1.64 2002/10/22 MIME-Version: 1.0 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format="flowed" Content-Transfer-Encoding: 7bit X-Spam-Score: 1.6 (+) X-Scan-Signature: bf422c85703d3d847fb014987125ac48 X-Mailman-Approved-At: Thu, 25 Oct 2007 11:49:08 -0400 Cc: NTP Working Group , "tictoc@ietf.org" Subject: [TICTOC] Re: [ntpwg] Documents, slides, etc. from WG meeting X-BeenThere: tictoc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Timing over IP Connection and Transfer of Clock BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tictoc-bounces@ietf.org Guys, I have carefully trod over the V2 spec and investigated the available 1588-capable devices. You have to be very careful when comparing NTP and 1588. The bottom line is that NTP is best used to synchronizes computer system clocks, while 1588 is best used to synchronize hardware interface clocks and other data acquisition or telecom devices on a LAN. To sustain the best accuracy, special Ethernet switches called boundary clocks are necessary, so 1588 would not normally be expected to transit a level-3 router, although in priciple it could. The comments about 1588 V1 and V2 are interesting. All the devices I know about from Symmetricom, Meinberg and 1588 Ethernet interfaces are V1 (1588-2002). The Intel chipsets should be able to do both. The Symmetricom 1588 grandmaster costs several thousand bucks and doesn't even do NTP. The Meinberg grandmaster does 1588 and NTP and in fact does everything the public NTPv4 distribution does, including Autokey. There are a few straightforward issues that might have been overlooked. The computer system clock is typically interpolated by the PCC/TSC with resolution 1 ns, but reading it via syscall typically burns 500 ns in modern silicon. The resolution of a 1588 timestamp is 1 ns, while the resolution of an NTP timestamp is 0.232 ns, although the difference is not significant. It is reasonable that the ioctl time to fetch a timestamp from a 1588 interface would be comparable to the time to read the system clock, 500 ns. The TCXO rock in a 1588 interface is not likely to operate at frequencies much above 20 MHz, although a cold rock might be higher. In other words, the 1588 resolution as a practical matter will be in the 50 ns range. The NSI Etherface and Symmetricom grandmaster claim resolution of 50 ns. What the above suggests is that 1588 will likely find the most important application to synchronize LAN hardware interface clocks to a grandmaster to the order of 50 ns. Real-time devices can provide signals that latch the interface clock which is later read by the program. This has nothing to do with the computer system clock. However, it is interesting to speculate on how 1588 and NTP could interoperate or support each other. In one approach 1588 can be used within a LAN with time exported beyond the level-3 router by NTP. In another, 1588 interfaces can be used to derive precision timestamps for use by NTP. A project on my shelf is to modify the driver for my 1588 Etherface for use as a reference clock driver. In answer to a previous question, 1588 V2 has the same limitations as NTP; both use four timestamps to compute offset and delay and assume the one-way delays are very nearly the same. There is a proposal for security extensions to 1588, although it does not address the issue of possibly degraded accuracy. Since 1588 uses hardware derived timestamps and is not expected to face seriously hostile attacks as assumed in NTP, this might not matter. As a very simple security provision, 1588 could well adopt the NTP protocol defenses used to deflect hostile replays and lost packets. This does not change the protocol or packet format. Finally, the observation that 1588 multicast might become deprecated is interesting. I make no judgement about that, but Symmetricom promotes its use in networks with thousands (!) of 1588 slaves. Well, maybe; the SYNC message is one-to-many, but this will be followed by thousands of DELAY_REQ messages imploding at the grandmaster. Dave Brad Knowles wrote: > On 10/24/07, Stewart Bryant wrote: > >> In discussing 1588, you need to make sure you are talking about the V2 >> spec. V1 is not likely to see significant deployment, whist V2 is likely >> to get significant hardware support and hence be widely deployed. > > > Therein lies the problem. I've been going through the page at > , and I can't find any real discussion of > the protocol, or specifics of the implementations. I didn't even > find any reference to V1 versus V2, and hence did not know that there > was an updated version. > > > Sure, they reference specific chipsets as implementing IEEE 1588, and > other specific devices (this is how I found out about the clock that > Meinberg makes). > > But when the description given for IEEE 1588 is completely circular > in nature, just exactly what good does that do for anyone? > >> Both V1 and V2 can use multicast IP encapsulation and you can in >> principle build an IP multicast net, but I have always regarded this >> mode of operation as a little strange and unlikely to ge deployed >> outside a highly controlled network. I doubt if we will ever see the >> 1588 multicast mode on the Internet. > > > We've talked to one of the guys at ISC about broad use of multicast > on the Internet, and they've explained why they believe that would be > a bad idea. > > You may get multicast internal to a given network at a single entity, > but you're unlikely to get it anywhere else. > >> However V2 can run over a unicast IP connection, and this is likely >> to find >> use in wide area networks. Indeed it exists largely to support the >> needs of >> the telecommunications operators for a method of providing clock sync >> over >> packet. > > > If it's used by telecom operators, why do they need IP or anything > else that heavy? I mean, if we're talking about something like SONET > synchronization, and they're worried about sub-nanosecond resolution, > then it seems to me that IP is a very hefty hammer to be wielding. > >> I am not sure what you mean by this. How the grand master acquires and >> locks to an external clock reference is outside the scope of the >> protocol, >> but it's also outside the scope of the NTP. > > > But we have reference clocks, right? And we have a defined way to > interface with them? > > > Honestly, I'm not trying to argue. I'm trying to understand better > where IEEE 1588 fits into the picture, and I'm just not finding much > in the way of what I consider to be useful documentation on the IEEE > website. > > From what little I can tell, it seems to me that IEEE 1588 is much > more oriented towards a closed single-entity local area (or > near-local area) network environment, where you don't care if you're > sync'ed to any given external reference, or how close or far you may > be from The One True Time, you just care that all your internal > slaves are sync'ed to your given master, and that you have some > pretty tight tolerances on how far out of sync the slaves can get. > > In contrast, it seems to me that NTP works well on the broader WAN > multi-entity internet (global and beyond), and that it can work just > fine on smaller scale single-entity networks where sub-nanosecond > accuracy timekeeping is not required. > > > The two protocols seem to complement each other pretty well, and it > would appear that the folks at Meinberg agree. > > > Ahh, okay. Found the URL for one of the tutorials at > , which was a little > more diffcult to find than it needed to be, thanks to the frame-based > way the web pages are laid out. > > Anyway, Page 6 of the PDF is where we want to start, where they > specifically compare IEEE 1588 and NTP, among others. I think > they're wrong to target the peer-to-peer mode exclusively for NTP, > but that is certainly one potential model that could be used with > NTP. There are other master/slave relationships that would be more > typical for use with NTP, but that doesn't really affect the > conclusions you can draw from those slides. > > Slide 9 is also useful: > > Objectives of IEEE 1588 > > + Sub-microsecond synchronization of real-time clocks in > components of a networked distributed measurement and > control system [0] > > + Intended for relatively localized systems typical of > industrial automation and test and measurement environments. [0] > > + Applicable to local area networks supporting multicast > communications (including but not limited to Ethernet) > > [0] indicates objectives that may be extended in version 2 > > > Hmm. Did they fix the assumption of symmetric delays between master > & slave in V2? > > Or the complete lack of any kind of security? I mean, UDP is > trivially easy to spoof, and given that everyone on the subnet is > supposed to be operating with the exact same information and the > exact same algorithms, it seems like it would be simple to see who > the current master clock is and spoof them as being bogus and force a > new master clock to be selected -- which you should be able to > guarantee is your selected trojan machine.... > _______________________________________________ TICTOC mailing list TICTOC@ietf.org https://www1.ietf.org/mailman/listinfo/tictoc From tictoc-bounces@ietf.org Thu Oct 25 13:57:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il6ws-00068N-NT; Thu, 25 Oct 2007 13:56:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il6wr-00068H-L9 for tictoc@ietf.org; Thu, 25 Oct 2007 13:56:49 -0400 Received: from mail4.symmetricom.com ([69.25.98.6]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Il6wl-0006lW-61 for tictoc@ietf.org; Thu, 25 Oct 2007 13:56:49 -0400 X-ASG-Debug-ID: 1193334993-770001bb0000-4wH9i1 X-Barracuda-URL: http://192.168.10.95:80/cgi-bin/mark.cgi Received: from sjowa.symmetricom.com (localhost [127.0.0.1]) by mail4.symmetricom.com (Spam Firewall) with ESMTP id DA7D8284075; Thu, 25 Oct 2007 10:56:33 -0700 (PDT) Received: from sjowa.symmetricom.com ([192.168.10.41]) by mail4.symmetricom.com with ESMTP id vlHQA6fuFeWfYE56; Thu, 25 Oct 2007 10:56:33 -0700 (PDT) X-ASG-Whitelist: Client Received: from sjmail2.symmetricom.com ([192.168.10.66]) by sjowa.symmetricom.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 25 Oct 2007 10:56:33 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 X-ASG-Orig-Subj: RE: [TICTOC] Re: [ntpwg] Documents, slides, etc. from WG meeting Subject: RE: [TICTOC] Re: [ntpwg] Documents, slides, etc. from WG meeting Date: Thu, 25 Oct 2007 10:56:33 -0700 Message-ID: In-Reply-To: <471F8AE2.6060709@udel.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [TICTOC] Re: [ntpwg] Documents, slides, etc. from WG meeting thread-index: AcgXHu6E2n6DH2YFRCKR4XLx3VPROQADd7lQ From: "Mark Elliot" To: "David L. Mills" X-OriginalArrivalTime: 25 Oct 2007 17:56:33.0465 (UTC) FILETIME=[61145290:01C81730] X-Barracuda-Connect: UNKNOWN[192.168.10.41] X-Barracuda-Start-Time: 1193334993 X-Barracuda-Virus-Scanned: by Symmetricom Spam Gateway at symmetricom.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 36fb765c89ed47dab364ab702a78e8fd Cc: NTP Working Group , tictoc@ietf.org X-BeenThere: tictoc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Timing over IP Connection and Transfer of Clock BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tictoc-bounces@ietf.org Since I'm intimately familiar with Symmetricom's NTP and IEEE 1588, I'd like to correct some observations. First of all, Symmetricom does offer an IEEE 1588 grandmaster. The same unit offers NTP at the same time. NTP is an option and it is on a second port from IEEE 1588 card. There is nothing to prevent anyone from placing both of these services on the same Internet subnet. It's true that the current IEEE 1588 grandmaster does support IEEE 1588 version 1. In the same platform we've also demonstrated IEEE 1588 version 2 in the last IEEE 1588 plug fest. Therefore, you can conclude that at some time in the future will be offering version 2 as well. On the subject of supporting thousands of IEEE 1588 clients this is true. For IEEE 1588 version 1, set at a two second sync rate, a delay request comes in from a client approximately every 30 seconds. This number is approximate for two reasons. Reason number one is I don't have manual in front of me right now and I'm going on remembered laboratory experience. The second and most important reason is this rate is randomized so that all the requests do not come in at once. On average, 1000 clients will generate just over 33 packets per second. =20 For the most part IEEE 1588 works well in the real world. The only disadvantage of this scheme is when one grandmasters fails over to another grandmaster, the 30 sec. delay request message rate can ring the system more than some people would like. This is a well document and explored subject within the IEEE 1588 group. Version 2 has ways of mitigating this last effect as well as a host of other features. I hope this clarifies things, Mark Elliot. =20 -----Original Message----- From: David L. Mills [mailto:mills@udel.edu]=20 Sent: Wednesday, October 24, 2007 11:12 AM Cc: NTP Working Group; tictoc@ietf.org Subject: [TICTOC] Re: [ntpwg] Documents, slides, etc. from WG meeting Guys, I have carefully trod over the V2 spec and investigated the available 1588-capable devices. You have to be very careful when comparing NTP and 1588. The bottom line is that NTP is best used to synchronizes computer system clocks, while 1588 is best used to synchronize hardware interface clocks and other data acquisition or telecom devices on a LAN. To sustain the best accuracy, special Ethernet switches called boundary clocks are necessary, so 1588 would not normally be expected to transit a level-3 router, although in priciple it could. The comments about 1588 V1 and V2 are interesting. All the devices I know about from Symmetricom, Meinberg and 1588 Ethernet interfaces are V1 (1588-2002). The Intel chipsets should be able to do both. The Symmetricom 1588 grandmaster costs several thousand bucks and doesn't even do NTP. The Meinberg grandmaster does 1588 and NTP and in fact does everything the public NTPv4 distribution does, including Autokey. There are a few straightforward issues that might have been overlooked.=20 The computer system clock is typically interpolated by the PCC/TSC with resolution 1 ns, but reading it via syscall typically burns 500 ns in modern silicon. The resolution of a 1588 timestamp is 1 ns, while the resolution of an NTP timestamp is 0.232 ns, although the difference is not significant. It is reasonable that the ioctl time to fetch a timestamp from a 1588 interface would be comparable to the time to read the system clock, 500 ns. The TCXO rock in a 1588 interface is not likely to operate at frequencies much above 20 MHz, although a cold rock might be higher. In other words, the 1588 resolution as a practical matter will be in the 50 ns range. The NSI Etherface and Symmetricom grandmaster claim resolution of 50 ns. What the above suggests is that 1588 will likely find the most important application to synchronize LAN hardware interface clocks to a grandmaster to the order of 50 ns. Real-time devices can provide signals that latch the interface clock which is later read by the program. This has nothing to do with the computer system clock. However, it is interesting to speculate on how 1588 and NTP could interoperate or support each other. In one approach 1588 can be used within a LAN with time exported beyond the level-3 router by NTP. In another, 1588 interfaces can be used to derive precision timestamps for use by NTP. A project on my shelf is to modify the driver for my 1588 Etherface for use as a reference clock driver. In answer to a previous question, 1588 V2 has the same limitations as NTP; both use four timestamps to compute offset and delay and assume the one-way delays are very nearly the same. There is a proposal for security extensions to 1588, although it does not address the issue of possibly degraded accuracy. Since 1588 uses hardware derived timestamps and is not expected to face seriously hostile attacks as assumed in NTP, this might not matter. As a very simple security provision, 1588 could well adopt the NTP protocol defenses used to deflect hostile replays and lost packets. This does not change the protocol or packet format. Finally, the observation that 1588 multicast might become deprecated is interesting. I make no judgement about that, but Symmetricom promotes its use in networks with thousands (!) of 1588 slaves. Well, maybe; the SYNC message is one-to-many, but this will be followed by thousands of DELAY_REQ messages imploding at the grandmaster. Dave Brad Knowles wrote: > On 10/24/07, Stewart Bryant wrote: > >> In discussing 1588, you need to make sure you are talking about the=20 >> V2 spec. V1 is not likely to see significant deployment, whist V2 is=20 >> likely to get significant hardware support and hence be widely deployed. > > > Therein lies the problem. I've been going through the page at=20 > , and I can't find any real discussion of=20 > the protocol, or specifics of the implementations. I didn't even find=20 > any reference to V1 versus V2, and hence did not know that there was=20 > an updated version. > > > Sure, they reference specific chipsets as implementing IEEE 1588, and=20 > other specific devices (this is how I found out about the clock that=20 > Meinberg makes). > > But when the description given for IEEE 1588 is completely circular in > nature, just exactly what good does that do for anyone? > >> Both V1 and V2 can use multicast IP encapsulation and you can in=20 >> principle build an IP multicast net, but I have always regarded this=20 >> mode of operation as a little strange and unlikely to ge deployed=20 >> outside a highly controlled network. I doubt if we will ever see the >> 1588 multicast mode on the Internet. > > > We've talked to one of the guys at ISC about broad use of multicast on > the Internet, and they've explained why they believe that would be a=20 > bad idea. > > You may get multicast internal to a given network at a single entity,=20 > but you're unlikely to get it anywhere else. > >> However V2 can run over a unicast IP connection, and this is likely=20 >> to find use in wide area networks. Indeed it exists largely to=20 >> support the needs of the telecommunications operators for a method of >> providing clock sync over packet. > > > If it's used by telecom operators, why do they need IP or anything=20 > else that heavy? I mean, if we're talking about something like SONET=20 > synchronization, and they're worried about sub-nanosecond resolution,=20 > then it seems to me that IP is a very hefty hammer to be wielding. > >> I am not sure what you mean by this. How the grand master acquires=20 >> and locks to an external clock reference is outside the scope of the=20 >> protocol, but it's also outside the scope of the NTP. > > > But we have reference clocks, right? And we have a defined way to > interface with them? > > > Honestly, I'm not trying to argue. I'm trying to understand better > where IEEE 1588 fits into the picture, and I'm just not finding much > in the way of what I consider to be useful documentation on the IEEE > website. > > From what little I can tell, it seems to me that IEEE 1588 is much > more oriented towards a closed single-entity local area (or > near-local area) network environment, where you don't care if you're > sync'ed to any given external reference, or how close or far you may > be from The One True Time, you just care that all your internal > slaves are sync'ed to your given master, and that you have some > pretty tight tolerances on how far out of sync the slaves can get. > > In contrast, it seems to me that NTP works well on the broader WAN > multi-entity internet (global and beyond), and that it can work just > fine on smaller scale single-entity networks where sub-nanosecond > accuracy timekeeping is not required. > > > The two protocols seem to complement each other pretty well, and it > would appear that the folks at Meinberg agree. > > > Ahh, okay. Found the URL for one of the tutorials at > , which was a little > more diffcult to find than it needed to be, thanks to the frame-based > way the web pages are laid out. > > Anyway, Page 6 of the PDF is where we want to start, where they > specifically compare IEEE 1588 and NTP, among others. I think > they're wrong to target the peer-to-peer mode exclusively for NTP, > but that is certainly one potential model that could be used with > NTP. There are other master/slave relationships that would be more > typical for use with NTP, but that doesn't really affect the > conclusions you can draw from those slides. > > Slide 9 is also useful: > > Objectives of IEEE 1588 > > + Sub-microsecond synchronization of real-time clocks in > components of a networked distributed measurement and > control system [0] > > + Intended for relatively localized systems typical of > industrial automation and test and measurement environments. [0] > > + Applicable to local area networks supporting multicast > communications (including but not limited to Ethernet) > > [0] indicates objectives that may be extended in version 2 > > > Hmm. Did they fix the assumption of symmetric delays between master > & slave in V2? > > Or the complete lack of any kind of security? I mean, UDP is > trivially easy to spoof, and given that everyone on the subnet is > supposed to be operating with the exact same information and the > exact same algorithms, it seems like it would be simple to see who > the current master clock is and spoof them as being bogus and force a > new master clock to be selected -- which you should be able to > guarantee is your selected trojan machine.... > _______________________________________________ TICTOC mailing list TICTOC@ietf.org https://www1.ietf.org/mailman/listinfo/tictoc _______________________________________________ TICTOC mailing list TICTOC@ietf.org https://www1.ietf.org/mailman/listinfo/tictoc From tictoc-bounces@ietf.org Fri Oct 26 13:12:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlSjZ-0003wb-5f; Fri, 26 Oct 2007 13:12:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlSjY-0003vj-QM for tictoc@ietf.org; Fri, 26 Oct 2007 13:12:32 -0400 Received: from webmail.resolutenetworks.com ([80.179.15.67] helo=mail.resolutenetworks.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IlSjO-0004wK-9w for tictoc@ietf.org; Fri, 26 Oct 2007 13:12:28 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 26 Oct 2007 19:14:49 +0200 Message-ID: <0606D918CE9CEA4E9835D2CDAA001A95F896A6@ilmail1.il.reduxcom.com> In-Reply-To: <8F242B230AD6474C8E7815DE0B4982D70B99D20D@EXV1.corp.adtran.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TICTOC scope: Public Internet or Provider scope Thread-Index: AcgXGne1IBhp5jLjTVCdd6oRVwcnewA2D7sw References: <8F242B230AD6474C8E7815DE0B4982D70B99D20D@EXV1.corp.adtran.com> From: "Ron Cohen" To: "STUART VENTERS" X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b66a1e94d7d92973ece9e5da449ff80 Cc: tictoc@ietf.org Subject: [TICTOC] RE: TICTOC scope: Public Internet or Provider scope X-BeenThere: tictoc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Timing over IP Connection and Transfer of Clock BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1634487703==" Errors-To: tictoc-bounces@ietf.org This is a multi-part message in MIME format. --===============1634487703== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C817F3.C2F17A1A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C817F3.C2F17A1A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Stuart, =20 In my opinion distribution in the core/metro should be included. The scope should probably be 'within a single administrative domain'.=20 =20 Best, Ron =20 From: STUART VENTERS [mailto:stuart.venters@adtran.com]=20 Sent: Thursday, October 25, 2007 5:20 PM To: Ron Cohen Cc: tictoc@ietf.org Subject: TICTOC scope: Public Internet or Provider scope =20 Ron, Your proposed initial TicToc scope limit of=20 single administrative domain core to edge is certainly first on my list, but I wonder if distribution in the single provider's core should be included as well? =20 Regards, Stuart --=20 This message was scanned by ESVA and is believed to be clean.=20 Click here to report this message as spam. =20 ------_=_NextPart_001_01C817F3.C2F17A1A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable TICTOC scope: Public Internet or Provider scope

Stuart,

In my opinion distribution in the core/metro should be = included. The scope should probably be ‘within a single administrative = domain’.

Best,

Ron

From:= STUART = VENTERS [mailto:stuart.venters@adtran.com]
Sent: Thursday, October 25, 2007 5:20 PM
To: Ron Cohen
Cc: tictoc@ietf.org
Subject: TICTOC scope: Public Internet or Provider = scope

Ron,

Your proposed initial TicToc scope limit of

single administrative domain core to edge is certainly first on my = list,

but = I wonder if distribution in the single provider's core should be included as = well?

Regards,

Stuart=

--
This message was scanned by ESVA and is believed to be clean.
Click here to report this message as spam.

------_=_NextPart_001_01C817F3.C2F17A1A-- --===============1634487703== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ TICTOC mailing list TICTOC@ietf.org https://www1.ietf.org/mailman/listinfo/tictoc --===============1634487703==-- From tictoc-bounces@ietf.org Sun Oct 28 15:51:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImE9y-0006g8-IM; Sun, 28 Oct 2007 15:50:58 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImE9x-0006G6-B9 for tictoc@ietf.org; Sun, 28 Oct 2007 15:50:57 -0400 Received: from [80.74.100.144] (helo=antivir2.rad.co.il) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ImE9N-0007P4-Db for tictoc@ietf.org; Sun, 28 Oct 2007 15:50:22 -0400 Received: from exrad3.rad.co.il (HELO exrad3.ad.rad.co.il) ([192.114.24.112]) by antivir2.rad.co.il with ESMTP; 28 Oct 2007 21:50:17 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [TICTOC] RE: TICTOC scope: Public Internet or Provider scope Date: Sun, 28 Oct 2007 21:50:16 +0200 Message-ID: <457D36D9D89B5B47BC06DA869B1C815D05646271@exrad3.ad.rad.co.il> In-Reply-To: <0606D918CE9CEA4E9835D2CDAA001A95F896A6@ilmail1.il.reduxcom.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TICTOC] RE: TICTOC scope: Public Internet or Provider scope Thread-Index: AcgXGne1IBhp5jLjTVCdd6oRVwcnewA2D7swAGnAAIA= From: "Yaakov Stein" To: "Ron Cohen" , "STUART VENTERS" X-Spam-Score: 0.1 (/) X-Scan-Signature: 311e798ce51dbeacf5cdfcc8e9fda21b Cc: tictoc@ietf.org X-BeenThere: tictoc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Timing over IP Connection and Transfer of Clock BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1478621645==" Errors-To: tictoc-bounces@ietf.org This is a multi-part message in MIME format. --===============1478621645== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8199B.C38D6A13" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8199B.C38D6A13 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ron and everyone else, =20 We can certainly put single provider networks as a main focus for TICTOC, but this is the IETF.=20 =20 If we limit it to special hardware,=20 then I doubt we are going to get anywhere here. =20 If we develop a protocol that can run over existing hardware we have to assume that someone is going to run it over the public Internet. =20 In any case, we did not specify that TICTOC would be optimized for the public Internet. We used the term "general PSNs" (i.e. IP or MPLS networks without special HW). However, if run over the public Internet it needs to work, and not to interfere with existing applications. =20 NTP indeed solves some problems quite well,=20 but if does not address all applications specified in the problem statement. For example,=20 it does not have a pure frequency distribution mode, as required in some of the TICTOC main application areas. =20 =20 Y(J)S =20 =20 ------_=_NextPart_001_01C8199B.C38D6A13 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable TICTOC = scope: Public Internet or Provider scope

Ron=20 and everyone else,

We can=20 certainly put single provider networks as a main focus for=20 TICTOC,

but=20 this is the IETF.

If=20 we limit it to special hardware,

then I=20 doubt we are going to get anywhere here.

If we=20 develop a protocol that can run over = existing hardware

we have to assume=20 that someone is going to run it over the public=20 Internet.

In any=20 case, we did not specify that TICTOC would be = optimized

for=20 the public Internet. We used the term "general PSNs"

(i.e.=20 IP or MPLS networks without special HW).

However, if run over the public Internet it needs to=20 work,

and=20 not to interfere with existing applications.

NTP indeed solves some problems quite well, =

but if=20 does not address all applications specified

in the=20 problem statement. For example,

it=20 does not have a pure frequency distribution mode,

as=20 required in some of the TICTOC main application = areas.

Y(J)S

------_=_NextPart_001_01C8199B.C38D6A13-- --===============1478621645== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ TICTOC mailing list TICTOC@ietf.org https://www1.ietf.org/mailman/listinfo/tictoc --===============1478621645==-- From tictoc-bounces@ietf.org Tue Oct 30 04:45:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Immj4-0007Qo-24; Tue, 30 Oct 2007 04:45:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Immj2-0007Qe-NE for tictoc@ietf.org; Tue, 30 Oct 2007 04:45:28 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Immiv-0006nx-V1 for tictoc@ietf.org; Tue, 30 Oct 2007 04:45:28 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 314D120447; Tue, 30 Oct 2007 09:45:04 +0100 (CET) X-AuditID: c1b4fb3e-ae831bb0000007e1-84-4726ef10ab3a Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 118EF201F5; Tue, 30 Oct 2007 09:45:04 +0100 (CET) Received: from EITRMMW021.eemea.ericsson.se ([141.137.48.176]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Oct 2007 09:45:03 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [TICTOC] RE: TICTOC scope: Public Internet or Provider scope Date: Tue, 30 Oct 2007 09:44:59 +0100 Message-ID: <7D33CA0905CE1443BADA4BD279ACFC6003B30728@EITRMMW021.eemea.ericsson.se> In-Reply-To: <457D36D9D89B5B47BC06DA869B1C815D05646271@exrad3.ad.rad.co.il> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TICTOC] RE: TICTOC scope: Public Internet or Provider scope Thread-Index: AcgXGne1IBhp5jLjTVCdd6oRVwcnewA2D7swAGnAAIAAH+3kkA== References: <0606D918CE9CEA4E9835D2CDAA001A95F896A6@ilmail1.il.reduxcom.com> <457D36D9D89B5B47BC06DA869B1C815D05646271@exrad3.ad.rad.co.il> From: "Stefano Ruffini" To: "Yaakov Stein" X-OriginalArrivalTime: 30 Oct 2007 08:45:03.0712 (UTC) FILETIME=[2A1D7600:01C81AD1] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: e654cfa5e44bd623be3eb2c720858b05 Cc: tictoc@ietf.org X-BeenThere: tictoc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Timing over IP Connection and Transfer of Clock BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0072682349==" Errors-To: tictoc-bounces@ietf.org This is a multi-part message in MIME format. --===============0072682349== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C81AD1.2985E335" This is a multi-part message in MIME format. ------_=_NextPart_001_01C81AD1.2985E335 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Yaakov, =20 some considerations on the "frequency distribution mode" . =20 Please consider that NTP as well as other relevant protocols (RTP, PTP) have been proven to be suitable to carry "frequency" reference for some relevant applications (e.g. GSM, WCDMA FDD, which require to recover 50 ppb on the radio interface), and without requiring additional requirements on the packet network nodes. Other aspects (than the actual protocol), are key factors in terms of the achievable performance (i.e. characteristics of the Packet delay variation in the network, oscillator characteristics in the end equipment, etc. ).=20 =20 I expect that the efforts to define new protocols or new arrangements as part of the TICTOC sope, will rather focus on the distribution of accurate phase and time (e.g. in the microsecond - submicrosecond level). The distribution of reference timing signals (frequency distribution) fulfilling the "PRC interface" masks (see G.823 and G.824) could also be of interest, but in this case I would also recommend to consider the option of synchronous ethernet (please refer to the work ongoing within ITU-T Q13).=20 =20 Best Regards Stefano ________________________________ From: Yaakov Stein [mailto:yaakov_s@rad.com]=20 Sent: domenica 28 ottobre 2007 20.50 To: Ron Cohen; STUART VENTERS Cc: tictoc@ietf.org Subject: RE: [TICTOC] RE: TICTOC scope: Public Internet or Provider scope Ron and everyone else, =20 We can certainly put single provider networks as a main focus for TICTOC, but this is the IETF.=20 =20 If we limit it to special hardware,=20 then I doubt we are going to get anywhere here. =20 If we develop a protocol that can run over existing hardware we have to assume that someone is going to run it over the public Internet. =20 In any case, we did not specify that TICTOC would be optimized for the public Internet. We used the term "general PSNs" (i.e. IP or MPLS networks without special HW). However, if run over the public Internet it needs to work, and not to interfere with existing applications. =20 NTP indeed solves some problems quite well,=20 but if does not address all applications specified in the problem statement. For example,=20 it does not have a pure frequency distribution mode, as required in some of the TICTOC main application areas. =20 =20 Y(J)S =20 =20 ------_=_NextPart_001_01C81AD1.2985E335 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable TICTOC = scope: Public Internet or Provider scope

Hi=20 Yaakov,

&nbs= p;

some=20 considerations on the "frequency distribution mode"=20 .

&nbs= p;

Please consider that NTP as well = as other=20 relevant protocols (RTP, PTP) have been proven to be suitable to carry=20 "frequency" reference for some relevant applications (e.g. GSM, WCDMA = FDD, which=20 require to recover 50 ppb = on the=20 radio interface), and=20 without requiring = additional=20 requirements on the packet network=20 nodes.

Other = aspects (than = the actual=20 protocol), are key factors in terms of the achievable performance (i.e. characteristics of the Packet delay = variation in=20 the network, oscillator characteristics in the end equipment, etc. ).

&nbs= p;

I expect = that the efforts=20 to define new=20 protocols or new = arrangements as part=20 of the TICTOC sope, will rather focus on the distribution of accurate = phase and=20 time (e.g. in the microsecond -=20 submicrosecond level). The=20 distribution of reference timing signals (frequency distribution) = fulfilling the=20 "PRC interface" masks (see G.823 and G.824) could also be of = interest,=20 but in this case I would also recommend to consider the option of = synchronous=20 ethernet (please refer to the work ongoing within ITU-T = Q13).

Best=20 Regards

Stefano

From: Yaakov Stein = [mailto:yaakov_s@rad.com]=20
Sent: domenica 28 ottobre 2007 20.50
To: Ron Cohen; = STUART=20 VENTERS
Cc: tictoc@ietf.org
Subject: RE: [TICTOC] = RE: TICTOC=20 scope: Public Internet or Provider scope

Ron=20 and everyone else,

We can=20 certainly put single provider networks as a main focus for=20 TICTOC,

but=20 this is the IETF.

If=20 we limit it to special hardware,

then I=20 doubt we are going to get anywhere here.

If we=20 develop a protocol that can run over = existing hardware

we have to assume=20 that someone is going to run it over the public=20 Internet.

In any=20 case, we did not specify that TICTOC would be = optimized

for=20 the public Internet. We used the term "general PSNs"

(i.e.=20 IP or MPLS networks without special HW).

However, if run over the public Internet it needs to=20 work,

and=20 not to interfere with existing applications.

NTP indeed solves some problems quite well, =

but if=20 does not address all applications specified

in the=20 problem statement. For example,

it=20 does not have a pure frequency distribution mode,

as=20 required in some of the TICTOC main application = areas.

Y(J)S

------_=_NextPart_001_01C81AD1.2985E335-- --===============0072682349== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ TICTOC mailing list TICTOC@ietf.org https://www1.ietf.org/mailman/listinfo/tictoc --===============0072682349==-- From tictoc-bounces@ietf.org Tue Oct 30 09:18:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imqz7-0004S3-SO; Tue, 30 Oct 2007 09:18:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imqz7-0004De-6i for tictoc@ietf.org; Tue, 30 Oct 2007 09:18:21 -0400 Received: from [212.199.240.16] (helo=antivir2.rad.co.il) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Imqyw-0002nQ-2c for tictoc@ietf.org; Tue, 30 Oct 2007 09:18:17 -0400 Received: from exrad3.rad.co.il (HELO exrad3.ad.rad.co.il) ([192.114.24.112]) by antivir2.rad.co.il with ESMTP; 30 Oct 2007 15:17:06 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [TICTOC] RE: TICTOC scope: Public Internet or Provider scope Date: Tue, 30 Oct 2007 15:16:53 +0200 Message-ID: <457D36D9D89B5B47BC06DA869B1C815D056FC887@exrad3.ad.rad.co.il> In-Reply-To: <7D33CA0905CE1443BADA4BD279ACFC6003B30728@EITRMMW021.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TICTOC] RE: TICTOC scope: Public Internet or Provider scope Thread-Index: AcgXGne1IBhp5jLjTVCdd6oRVwcnewA2D7swAGnAAIAAH+3kkAA3LLcQ From: "Yaakov Stein" To: "Stefano Ruffini" X-Spam-Score: 0.1 (/) X-Scan-Signature: 4a4195ffb11c7b0baf82f77b2a730aa9 Cc: tictoc@ietf.org X-BeenThere: tictoc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Timing over IP Connection and Transfer of Clock BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0969649299==" Errors-To: tictoc-bounces@ietf.org This is a multi-part message in MIME format. --===============0969649299== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C81AF7.2B47D434" This is a multi-part message in MIME format. ------_=_NextPart_001_01C81AF7.2B47D434 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Stefano =20 NTP and 1588 indeed distribute frequency, for their own (internal) purposes, and can do so pretty well. =20 However, this does not mean that they are optimized for this function. =20 Frequency distribution is a purely one-way function, and thus can be fully multicast or broadcast. =20 Time distribution requires a two-way exchange for ranging, and assumes symmetry (or some known asymmetry). =20 This difference can be very significant for many applications. =20 In the problem statement we have examples of applications where only frequency is needed (e.g. TDM PWs, GSM mobile backhauling). =20 Y(J)S ________________________________ From: Stefano Ruffini [mailto:stefano.ruffini@ericsson.com]=20 Sent: Tuesday, October 30, 2007 10:45 AM To: Yaakov Stein Cc: tictoc@ietf.org Subject: RE: [TICTOC] RE: TICTOC scope: Public Internet or Provider scope Hi Yaakov, =20 some considerations on the "frequency distribution mode" . =20 Please consider that NTP as well as other relevant protocols (RTP, PTP) have been proven to be suitable to carry "frequency" reference for some relevant applications (e.g. GSM, WCDMA FDD, which require to recover 50 ppb on the radio interface), and without requiring additional requirements on the packet network nodes. Other aspects (than the actual protocol), are key factors in terms of the achievable performance (i.e. characteristics of the Packet delay variation in the network, oscillator characteristics in the end equipment, etc. ).=20 =20 I expect that the efforts to define new protocols or new arrangements as part of the TICTOC sope, will rather focus on the distribution of accurate phase and time (e.g. in the microsecond - submicrosecond level). The distribution of reference timing signals (frequency distribution) fulfilling the "PRC interface" masks (see G.823 and G.824) could also be of interest, but in this case I would also recommend to consider the option of synchronous ethernet (please refer to the work ongoing within ITU-T Q13).=20 =20 Best Regards Stefano ________________________________ From: Yaakov Stein [mailto:yaakov_s@rad.com]=20 Sent: domenica 28 ottobre 2007 20.50 To: Ron Cohen; STUART VENTERS Cc: tictoc@ietf.org Subject: RE: [TICTOC] RE: TICTOC scope: Public Internet or Provider scope Ron and everyone else, =20 We can certainly put single provider networks as a main focus for TICTOC, but this is the IETF.=20 =20 If we limit it to special hardware,=20 then I doubt we are going to get anywhere here. =20 If we develop a protocol that can run over existing hardware we have to assume that someone is going to run it over the public Internet. =20 In any case, we did not specify that TICTOC would be optimized for the public Internet. We used the term "general PSNs" (i.e. IP or MPLS networks without special HW). However, if run over the public Internet it needs to work, and not to interfere with existing applications. =20 NTP indeed solves some problems quite well,=20 but if does not address all applications specified in the problem statement. For example,=20 it does not have a pure frequency distribution mode, as required in some of the TICTOC main application areas. =20 =20 Y(J)S =20 =20 ------_=_NextPart_001_01C81AF7.2B47D434 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable TICTOC = scope: Public Internet or Provider scope

Stefano

NTP=20 and 1588 indeed distribute frequency, for their own (internal)=20 purposes,

and=20 can do so pretty well.

However, this does not mean that they are optimized for this=20 function.

Frequency distribution is a purely one-way = function,

and=20 thus can be fully multicast or broadcast.

Time=20 distribution requires a two-way exchange for = ranging,

and=20 assumes symmetry (or some known asymmetry).

This=20 difference can be very significant for many = applications.

In the=20 problem statement we have examples of applications

where=20 only frequency is needed (e.g. TDM PWs, GSM mobile=20 backhauling).

Y(J)S

From: Stefano Ruffini=20 [mailto:stefano.ruffini@ericsson.com]
Sent: Tuesday, October = 30, 2007=20 10:45 AM
To: Yaakov Stein
Cc:=20 tictoc@ietf.org
Subject: RE: [TICTOC] RE: TICTOC scope: Public = Internet or Provider scope

Hi=20 Yaakov,

&nbs= p;

some=20 considerations on the "frequency distribution mode"=20 .

&nbs= p;

Best=20 Regards

Stefano

Ron=20 and everyone else,

We can=20 certainly put single provider networks as a main focus for=20 TICTOC,

but=20 this is the IETF.

If=20 we limit it to special hardware,

then I=20 doubt we are going to get anywhere here.

If we=20 develop a protocol that can run over = existing hardware

we have to assume=20 that someone is going to run it over the public=20 Internet.

In any=20 case, we did not specify that TICTOC would be = optimized

for=20 the public Internet. We used the term "general PSNs"

(i.e.=20 IP or MPLS networks without special HW).

However, if run over the public Internet it needs to=20 work,

and=20 not to interfere with existing applications.

NTP indeed solves some problems quite well, =

but if=20 does not address all applications specified

in the=20 problem statement. For example,

it=20 does not have a pure frequency distribution mode,

as=20 required in some of the TICTOC main application = areas.

Y(J)S

------_=_NextPart_001_01C81AF7.2B47D434-- --===============0969649299== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ TICTOC mailing list TICTOC@ietf.org https://www1.ietf.org/mailman/listinfo/tictoc --===============0969649299==-- From tictoc-bounces@ietf.org Wed Oct 31 08:28:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InCgV-0007PQ-8S; Wed, 31 Oct 2007 08:28:35 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlP0a-0006YG-AH for tictoc@ietf.org; Fri, 26 Oct 2007 09:13:52 -0400 Received: from whimsy.udel.edu ([128.4.2.3]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IlP0X-0001BP-NG for tictoc@ietf.org; Fri, 26 Oct 2007 09:13:52 -0400 Received: by whimsy.udel.edu (Postfix, from userid 62) id 31FC415F6; Fri, 26 Oct 2007 13:13:45 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on whimsy.udel.edu X-Spam-Level: X-Spam-Status: No, score=-2.0 required=4.1 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [128.4.2.6] (backroom.udel.edu [128.4.2.6]) by whimsy.udel.edu (Postfix) with ESMTP id 143471549; Fri, 26 Oct 2007 13:13:37 +0000 (UTC) Message-ID: <4721E802.2050105@udel.edu> Date: Fri, 26 Oct 2007 13:13:38 +0000 From: "David L. Mills" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en To: NTP Working Group , tictoc@ietf.org Subject: Re: [TICTOC] Re: [ntpwg] Documents, slides, etc. from WG meeting References: In-Reply-To: X-Sanitizer: This message has been sanitized! X-Sanitizer-URL: http://mailtools.anomy.net/ X-Sanitizer-Rev: UDEL-ECECIS: Sanitizer.pm, v 1.64 2002/10/22 MIME-Version: 1.0 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format="flowed" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2a9ffb6f997442a3b543bcdaf483b990 X-Mailman-Approved-At: Wed, 31 Oct 2007 08:28:33 -0400 Cc: X-BeenThere: tictoc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Timing over IP Connection and Transfer of Clock BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tictoc-bounces@ietf.org Mark, I think we have talked before. I was told that the Symmetricom 1588 grandmaster does not do NTP, but I was not told it could do NTP as an option. at the same time. I was told the customer would have to buy a separate server for that. The Meingerg grandmaster I have does both without special order option. The delay request/response behavior is as expected and does mitigate the implosion hazard. However, the features noted on the web page for the XLI suggest the device is safe for up to thousands of clients. My experience and that of USNO and NIST suggest loads like this present special hazards independent of 1588 or NTP. Dave Mark Elliot wrote: > Since I'm intimately familiar with Symmetricom's NTP and IEEE 1588, I'd > like to correct some observations. First of all, Symmetricom does offer > an IEEE 1588 grandmaster. The same unit offers NTP at the same time. > NTP is an option and it is on a second port from IEEE 1588 card. There > is nothing to prevent anyone from placing both of these services on the > same Internet subnet. It's true that the current IEEE 1588 grandmaster > does support IEEE 1588 version 1. In the same platform we've also > demonstrated IEEE 1588 version 2 in the last IEEE 1588 plug fest. > Therefore, you can conclude that at some time in the future will be > offering version 2 as well. > > On the subject of supporting thousands of IEEE 1588 clients this is > true. For IEEE 1588 version 1, set at a two second sync rate, a delay > request comes in from a client approximately every 30 seconds. This > number is approximate for two reasons. Reason number one is I don't > have manual in front of me right now and I'm going on remembered > laboratory experience. The second and most important reason is this > rate is randomized so that all the requests do not come in at once. On > average, 1000 clients will generate just over 33 packets per second. > > For the most part IEEE 1588 works well in the real world. The only > disadvantage of this scheme is when one grandmasters fails over to > another grandmaster, the 30 sec. delay request message rate can ring the > system more than some people would like. This is a well document and > explored subject within the IEEE 1588 group. Version 2 has ways of > mitigating this last effect as well as a host of other features. > > I hope this clarifies things, Mark Elliot. > > -----Original Message----- > From: David L. Mills [mailto:mills@udel.edu] > Sent: Wednesday, October 24, 2007 11:12 AM > Cc: NTP Working Group; tictoc@ietf.org > Subject: [TICTOC] Re: [ntpwg] Documents, slides, etc. from WG meeting > > Guys, > > I have carefully trod over the V2 spec and investigated the available > 1588-capable devices. You have to be very careful when comparing NTP and > 1588. The bottom line is that NTP is best used to synchronizes computer > system clocks, while 1588 is best used to synchronize hardware interface > clocks and other data acquisition or telecom devices on a LAN. To > sustain the best accuracy, special Ethernet switches called boundary > clocks are necessary, so 1588 would not normally be expected to transit > a level-3 router, although in priciple it could. > > The comments about 1588 V1 and V2 are interesting. All the devices I > know about from Symmetricom, Meinberg and 1588 Ethernet interfaces are > V1 (1588-2002). The Intel chipsets should be able to do both. The > Symmetricom 1588 grandmaster costs several thousand bucks and doesn't > even do NTP. The Meinberg grandmaster does 1588 and NTP and in fact does > everything the public NTPv4 distribution does, including Autokey. > > There are a few straightforward issues that might have been overlooked. > The computer system clock is typically interpolated by the PCC/TSC with > resolution 1 ns, but reading it via syscall typically burns 500 ns in > modern silicon. The resolution of a 1588 timestamp is 1 ns, while the > resolution of an NTP timestamp is 0.232 ns, although the difference is > not significant. It is reasonable that the ioctl time to fetch a > timestamp from a 1588 interface would be comparable to the time to read > the system clock, 500 ns. > > The TCXO rock in a 1588 interface is not likely to operate at > frequencies much above 20 MHz, although a cold rock might be higher. In > other words, the 1588 resolution as a practical matter will be in the 50 > ns range. The NSI Etherface and Symmetricom grandmaster claim resolution > of 50 ns. > > What the above suggests is that 1588 will likely find the most important > application to synchronize LAN hardware interface clocks to a > grandmaster to the order of 50 ns. Real-time devices can provide signals > that latch the interface clock which is later read by the program. This > has nothing to do with the computer system clock. > > However, it is interesting to speculate on how 1588 and NTP could > interoperate or support each other. In one approach 1588 can be used > within a LAN with time exported beyond the level-3 router by NTP. In > another, 1588 interfaces can be used to derive precision timestamps for > use by NTP. A project on my shelf is to modify the driver for my 1588 > Etherface for use as a reference clock driver. > > In answer to a previous question, 1588 V2 has the same limitations as > NTP; both use four timestamps to compute offset and delay and assume the > one-way delays are very nearly the same. There is a proposal for > security extensions to 1588, although it does not address the issue of > possibly degraded accuracy. Since 1588 uses hardware derived timestamps > and is not expected to face seriously hostile attacks as assumed in NTP, > this might not matter. As a very simple security provision, 1588 could > well adopt the NTP protocol defenses used to deflect hostile replays and > lost packets. This does not change the protocol or packet format. > > Finally, the observation that 1588 multicast might become deprecated is > interesting. I make no judgement about that, but Symmetricom promotes > its use in networks with thousands (!) of 1588 slaves. Well, maybe; the > SYNC message is one-to-many, but this will be followed by thousands of > DELAY_REQ messages imploding at the grandmaster. > > Dave > > Brad Knowles wrote: > >> On 10/24/07, Stewart Bryant wrote: >> >>> In discussing 1588, you need to make sure you are talking about the >>> V2 spec. V1 is not likely to see significant deployment, whist V2 is >>> likely to get significant hardware support and hence be widely >> > deployed. > >> >> Therein lies the problem. I've been going through the page at >> , and I can't find any real discussion of >> the protocol, or specifics of the implementations. I didn't even find >> any reference to V1 versus V2, and hence did not know that there was >> an updated version. >> >> >> Sure, they reference specific chipsets as implementing IEEE 1588, and >> other specific devices (this is how I found out about the clock that >> Meinberg makes). >> >> But when the description given for IEEE 1588 is completely circular in > > >> nature, just exactly what good does that do for anyone? >> >>> Both V1 and V2 can use multicast IP encapsulation and you can in >>> principle build an IP multicast net, but I have always regarded this >>> mode of operation as a little strange and unlikely to ge deployed >>> outside a highly controlled network. I doubt if we will ever see the >>> 1588 multicast mode on the Internet. >> >> >> We've talked to one of the guys at ISC about broad use of multicast on > > >> the Internet, and they've explained why they believe that would be a >> bad idea. >> >> You may get multicast internal to a given network at a single entity, >> but you're unlikely to get it anywhere else. >> >>> However V2 can run over a unicast IP connection, and this is likely >>> to find use in wide area networks. Indeed it exists largely to >>> support the needs of the telecommunications operators for a method of >> > >>> providing clock sync over packet. >> >> >> If it's used by telecom operators, why do they need IP or anything >> else that heavy? I mean, if we're talking about something like SONET >> synchronization, and they're worried about sub-nanosecond resolution, >> then it seems to me that IP is a very hefty hammer to be wielding. >> >>> I am not sure what you mean by this. How the grand master acquires >>> and locks to an external clock reference is outside the scope of the >>> protocol, but it's also outside the scope of the NTP. >> >> >> But we have reference clocks, right? And we have a defined way to >> interface with them? >> >> >> Honestly, I'm not trying to argue. I'm trying to understand better >> where IEEE 1588 fits into the picture, and I'm just not finding much >> in the way of what I consider to be useful documentation on the IEEE >> website. >> >> From what little I can tell, it seems to me that IEEE 1588 is much >> more oriented towards a closed single-entity local area (or >> near-local area) network environment, where you don't care if you're >> sync'ed to any given external reference, or how close or far you may >> be from The One True Time, you just care that all your internal >> slaves are sync'ed to your given master, and that you have some >> pretty tight tolerances on how far out of sync the slaves can get. >> >> In contrast, it seems to me that NTP works well on the broader WAN >> multi-entity internet (global and beyond), and that it can work just >> fine on smaller scale single-entity networks where sub-nanosecond >> accuracy timekeeping is not required. >> >> >> The two protocols seem to complement each other pretty well, and it >> would appear that the folks at Meinberg agree. >> >> >> Ahh, okay. Found the URL for one of the tutorials at >> , which was a little >> more diffcult to find than it needed to be, thanks to the frame-based >> way the web pages are laid out. >> >> Anyway, Page 6 of the PDF is where we want to start, where they >> specifically compare IEEE 1588 and NTP, among others. I think >> they're wrong to target the peer-to-peer mode exclusively for NTP, >> but that is certainly one potential model that could be used with >> NTP. There are other master/slave relationships that would be more >> typical for use with NTP, but that doesn't really affect the >> conclusions you can draw from those slides. >> >> Slide 9 is also useful: >> >> Objectives of IEEE 1588 >> >> + Sub-microsecond synchronization of real-time clocks in >> components of a networked distributed measurement and >> control system [0] >> >> + Intended for relatively localized systems typical of >> industrial automation and test and measurement environments. [0] >> >> + Applicable to local area networks supporting multicast >> communications (including but not limited to Ethernet) >> >> [0] indicates objectives that may be extended in version 2 >> >> >> Hmm. Did they fix the assumption of symmetric delays between master >> & slave in V2? >> >> Or the complete lack of any kind of security? I mean, UDP is >> trivially easy to spoof, and given that everyone on the subnet is >> supposed to be operating with the exact same information and the >> exact same algorithms, it seems like it would be simple to see who >> the current master clock is and spoof them as being bogus and force a >> new master clock to be selected -- which you should be able to >> guarantee is your selected trojan machine.... >> > > > _______________________________________________ > TICTOC mailing list > TICTOC@ietf.org > https://www1.ietf.org/mailman/listinfo/tictoc _______________________________________________ TICTOC mailing list TICTOC@ietf.org https://www1.ietf.org/mailman/listinfo/tictoc From tictoc-bounces@ietf.org Wed Oct 31 08:56:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InD7S-0000Kf-1d; Wed, 31 Oct 2007 08:56:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InD7Q-0000HJ-FX for tictoc@ietf.org; Wed, 31 Oct 2007 08:56:24 -0400 Received: from mail4.symmetricom.com ([69.25.98.6]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1InD7K-0003c8-5W for tictoc@ietf.org; Wed, 31 Oct 2007 08:56:24 -0400 X-ASG-Debug-ID: 1193835367-62e1004e0000-4wH9i1 X-Barracuda-URL: http://192.168.10.95:80/cgi-bin/mark.cgi Received: from sjowa.symmetricom.com (localhost [127.0.0.1]) by mail4.symmetricom.com (Spam Firewall) with ESMTP id 2EB082A64B9 for ; Wed, 31 Oct 2007 05:56:07 -0700 (PDT) Received: from sjowa.symmetricom.com ([192.168.10.41]) by mail4.symmetricom.com with ESMTP id 0Rx4AhCaF9iceLWG for ; Wed, 31 Oct 2007 05:56:07 -0700 (PDT) X-ASG-Whitelist: Client Received: from sjmail2.symmetricom.com ([192.168.10.66]) by sjowa.symmetricom.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 31 Oct 2007 05:56:07 -0700 Content-class: urn:content-classes:message X-ASG-Orig-Subj: What products can and can not do MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 31 Oct 2007 05:56:06 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: What products can and can not do Thread-Index: Acgbud0o70V+XWDHT7eIhzHIPIJ8dwAAfgqA References: From: "Jeremy Bennington" To: X-OriginalArrivalTime: 31 Oct 2007 12:56:07.0016 (UTC) FILETIME=[66F4FE80:01C81BBD] X-Barracuda-Connect: UNKNOWN[192.168.10.41] X-Barracuda-Start-Time: 1193835367 X-Barracuda-Virus-Scanned: by Symmetricom Spam Gateway at symmetricom.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: [TICTOC] What products can and can not do X-BeenThere: tictoc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Timing over IP Connection and Transfer of Clock BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tictoc-bounces@ietf.org Products, configurations, pricing, etc. change constantly based on market forces. There are several Symmetricom products that support PTP and NTP at various price points. As well as J.211, BITS, etc. As Dave said there are other vendors that support multiple formats as well. One of the challenges we face is that various products from various vendors perform differently with respect to NTP and PTP. To some degree this is differentiation, but on the other had it is confusing to a customer. If we can establish clearly defined operational guidelines and metrics for specific applications then the customer and vendor can match the correct products/pricing. Since we do not have clearly defined operational guidelines and metrics that the industry agrees on I think product comparisons are premature. -Jeremy B. _______________________________________________ TICTOC mailing list TICTOC@ietf.org https://www1.ietf.org/mailman/listinfo/tictoc From tictoc-bounces@ietf.org Wed Oct 31 13:22:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InHGv-0007XE-CS; Wed, 31 Oct 2007 13:22:29 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InHGu-0007X6-SV for tictoc@ietf.org; Wed, 31 Oct 2007 13:22:28 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1InHGu-0006Zi-I7 for tictoc@ietf.org; Wed, 31 Oct 2007 13:22:28 -0400 X-IronPort-AV: E=Sophos;i="4.21,352,1188802800"; d="scan'208";a="412134543" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 31 Oct 2007 10:05:34 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l9VH5X1x021144 for ; Wed, 31 Oct 2007 10:05:33 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l9VH4wAp023406 for ; Wed, 31 Oct 2007 17:05:33 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Oct 2007 13:05:23 -0400 Received: from da001d0832.cam-ma.osd.concentric.net ([10.82.242.246]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Oct 2007 13:05:23 -0400 Message-ID: <4728B5CF.4030008@cisco.com> Date: Wed, 31 Oct 2007 10:05:19 -0700 From: Mark Townsley User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: tictoc@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Oct 2007 17:05:23.0264 (UTC) FILETIME=[39935400:01C81BE0] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15516.002 X-TM-AS-Result: No--4.245200-8.000000-4 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=513; t=1193850334; x=1194714334; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=townsley@cisco.com; z=From:=20Mark=20Townsley=20 |Subject:=20BoF=20for=20Vancouver=20approved |Sender:=20; bh=xX1NMsl+lAtxISEoTorQpBfYNmJQCuS/PM0Nsu234Lk=; b=HNsnAh8ethPKdhsMV3k+GPX/sX2u9m5LcPqmiXAa2JImQcvJQGuy0AyImFjWoTKv03OJ+Dys xSSIO6PeXqd2fXwhm8L0BPh5yMQGClpQgOU25/VsMiv3DH8459BC+Irl; Authentication-Results: sj-dkim-4; header.From=townsley@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [TICTOC] BoF for Vancouver approved X-BeenThere: tictoc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Timing over IP Connection and Transfer of Clock BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tictoc-bounces@ietf.org I have approved the tictoc BoF for vancouver. I believe the proposed charter still needs some work if the BoF is going to be successful. My concern remains centered around a scope that seems a bit broad for the task at hand. For my part, I am traveling or on leave between now and the middle of next week. Please continue the good discussions you have been having between now and then, and I will work with you to nail down the proposed charter for Vancouver when I return. Thanks, - Mark _______________________________________________ TICTOC mailing list TICTOC@ietf.org https://www1.ietf.org/mailman/listinfo/tictoc From tictoc-bounces@ietf.org Wed Oct 31 14:21:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InIC5-0003Fs-CQ; Wed, 31 Oct 2007 14:21:33 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InIC3-000393-T5 for tictoc@ietf.org; Wed, 31 Oct 2007 14:21:31 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1InIC2-0000ls-Q1 for tictoc@ietf.org; Wed, 31 Oct 2007 14:21:31 -0400 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by sj-iport-1.cisco.com with ESMTP; 31 Oct 2007 11:21:28 -0700 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l9VILSEP010215; Wed, 31 Oct 2007 19:21:28 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l9VILPqV020634; Wed, 31 Oct 2007 18:21:27 GMT Received: from xmb-ams-33a.cisco.com ([144.254.231.85]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Oct 2007 19:21:27 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 31 Oct 2007 19:21:26 +0100 Message-ID: In-Reply-To: <200710282250.26627.martin.burnicki@gmx.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ntpwg] Documents, slides, etc. from WG meeting Thread-Index: AcgZrLD49oZMItYsSzaG9kk+/4c+rwCNGVoA From: "Laurent Montini (lmontini)" To: "Martin Burnicki" , "David L. Mills" X-OriginalArrivalTime: 31 Oct 2007 18:21:27.0202 (UTC) FILETIME=[D9E50020:01C81BEA] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15516.001 X-TM-AS-Result: No--9.325600-8.000000-2 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=7496; t=1193854888; x=1194718888; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lmontini@cisco.com; z=From:=20=22Laurent=20Montini=20(lmontini)=22=20 |Subject:=20RE=3A=20[ntpwg]=20Documents, =20slides, =20etc.=20from=20WG=20m eeting |Sender:=20; bh=QDp1XkL8Q+j/R/rVcCp+rgB6x8bVks6mpSUVQ3zzqck=; b=XsUTrt5lIt4sMmsYIjitJAptgzhCnc6Mj2Ry9PI8FDT6UUdmRKCRKwgKQ6Fn0gGC6LFsX8P/ lWSFY6pc/tJjL5kdZHgJId2AZaDWG+XGUfUXce9zIg/lYeBRwnyOwImj; Authentication-Results: ams-dkim-1; header.From=lmontini@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 Cc: NTP Working Group , tictoc@ietf.org Subject: [TICTOC] RE: [ntpwg] Documents, slides, etc. from WG meeting X-BeenThere: tictoc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Timing over IP Connection and Transfer of Clock BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tictoc-bounces@ietf.org Hi, I do foresee other issues to be considered with TC, related to message flows, message processing and state in equipments. 1- When using TC one can either use one-step or two-step mode. One-step mode would require the TC equipment to detect PTP event messages (e.g. SYNC message) at ingress and TS (timestamp) it (TSa). At egress, the same eqpt would have to TS the same message again, (TSb) calculate the internal delay (Residence Time =3DRT =3D TSb-TSa) and = write this value into the PTP payload (Correction Field: CF). TC would have to compute RT and add RT value to any other value existing into the CF. This demands important HW function and complex design for a large equipment with distributed architecture. 2- With two-step mode the difference is visible at TC egress. The TC equipment would have, at ingress, to detect PTP event messages (as frame or packet) and TS it (same as one-step above). At egress, the eqpt would have to TS the same message again. However the Residence Time calculation would be done after (at least independently of) the transmission of the event message. The RT value would be added to the Correction Field which would be sent with a Follow-Up (FU) general message (case of SYNC message). This solves some design issues. However, the process (1- or 2-step) must be done for every event messages of every PTP session (slave-master), whatever mcast or ucast transmission. As I'm considering ucast, this means processing every event messages of every master-slave pairs. 3- Considering the two-step mode (and SYNC event message only for now), the eqpt will switch the SYNC event message then process the FU messages for every PTP sessions. If going thru multiple serialized TCs, the event messages will be switched multiple times and the FU messages processed same number of times. It may then happen that a FU message of an event message n could arrive after the event message n+1 or n+d due to the sum of processing delay. That is there may be a misordering due to unequal transmission delays into TC. This delay will depend on (non exhaustive list): - the transmission mode - number of PTP sessions - rate of the event messages - CPU power or load of each TC - TC node design... The slave may rearrange using the Seq ID. This implies further processing (not sure this is expected by IEEE1588v2 slave). 4- Last potential issue of TC is the following. TC functions (TS and RT calculation) shall be performed for event messages SYNC and Delay_Req in order to get a delay correction for both directions. The sum of residence times must be known by the slave for delay correction computation (master does not care). For SYNC messages, the flow is in the "right" direction. That is the RT calculations are done by TC on the from master to slave direction. The FU will provide the master-to-slave CF value to the slave i.e. following the flow direction. However for Delay_Req, the flow is slave to master.=20 The CF value is thus the sum of the RT for TCs from slave to master. In order the slave to get the slave-to-master CF value, the TCs have two options. If one-step mode, the RT is added in HW in the CF of the Delay_Req. (cf. 1-). If two-step mode, the TCs will not use a FU general message (which would be sent to master).=20 Actually, every TC will hold its RT value and keep state of the RT value for every slave-master pair session. The TC will then wait for the Delay_Resp general message sent back to slave by the master (for the same master-slave session) and modify the Correction Field of the Delay_Resp message. This requires the TC to keep state of RT values for every master-slave session. This can be balanced, considering the rate of Delay_Req/Resp is lower than SYNC message rate.=20 Moreover using a physical (e.g. SyncE) instead of packet-based frequency distribution for syntonization could reduce the SYNC message rate.=20 An alternative approach to avoid state in TC, would be every TC to transmit its RT directly to slave (without waiting for the Delay_Resp back). If there is n times TC on the path to master, the slave should receive n time messages for every Delay_Req. This replaces state by message generation. Last note about servo cascading effect. AFAIK TC has been designed to overcome clock degration due to cascading BC with cheap servo clock on a long chain (10's of 1588 switches). Considering telecom network and nodes (restricting the scope to operator management domain and thus limited number of nodes), nodes may own a better servo clock than industrial equipment. Number of nodes between master and slaves may also be lower than in industrial environment.=20 Control loop performance may be sorted out the same way SDH or SyncE timing chain is specified. .lm=20 > -----Original Message----- > From: ntpwg-bounces+lmontini=3Dcisco.com@lists.ntp.org=20 > [mailto:ntpwg-bounces+lmontini=3Dcisco.com@lists.ntp.org] On=20 > Behalf Of Martin Burnicki > Sent: dimanche 28 octobre 2007 22:50 > To: David L. Mills > Cc: NTP Working Group > Subject: Re: [ntpwg] Documents, slides, etc. from WG meeting >=20 > Dave, >=20 > David L. Mills wrote: > > Guys, > > > > The 1588 provisions for switches and routers is called a=20 > boundary clock. > > It requires intricate management of various fixed latencies and=20 > > queueing delays. 1588 NICs known to me use the Intel=20 > chipset which has=20 > > an onboard ARM processor very definitely provisioned by=20 > firmware. As=20 > > for modifying NTP to simulate the 1588 two-step protocol, a=20 > > description on how to do this is in the architecture=20 > briefing on the NTP project page. >=20 > The boundary clock is just _one_ possible way to eliminate=20 > the latency of intermediate nodes between the grandmaster and=20 > the final client.=20 >=20 > In the NTP world this is comparable to an NTP server running=20 > on a company's firewall or router, which gets its time from=20 > the outside world and serves it to the internal network. >=20 > Since each boundary clock includes a control loop, a number=20 > of cascaded boundary clocks results in cascaded control=20 > loops, maybe with unknown characteristics, which may let the=20 > overall control loop between the final client and the=20 > grandmaster become instable. >=20 > So another approach is the transparent clock, which just adds=20 > to every packet how much the packet has been delayed when it=20 > has traversed an intermediate node. So even if there are=20 > several intermediate nodes, there's only on big control loop=20 > which includes the grandmaster and the final client, which=20 > can possibly easier be made stable than a number of cascaded loops. >=20 > For existing NTP installations the similar configuration is=20 > when clients behind a firewall directly send queries to a=20 > server in the outer world, and the queries and replies just=20 > go through the firewall, though of course a firewall or=20 > router would not try to compensate any latency it adds to the=20 > NTP packets. >=20 > The advantages and disadvantages of boundary clocks and=20 > transparent clocks for this purpose have been discussed on=20 > several PTP plug fests and meetings. >=20 > Martin > _______________________________________________ > ntpwg mailing list > ntpwg@lists.ntp.org > https://lists.ntp.org/mailman/listinfo/ntpwg >=20 _______________________________________________ TICTOC mailing list TICTOC@ietf.org https://www1.ietf.org/mailman/listinfo/tictoc