Subject: [TICTOC] RE: TICTOC Digest, Vol 6, Issue 9

From: "Jeremy Bennington" <[email-masked]>
Date: Mon, 15 Jan 2007 13:23:12 -0800

Hello all,

I would be happy to join the groups discussion and potential
specification work.

>From our point of view this effort can offer alternatives and/or
simplification of how time and frequency can be distributed over the
packet network.  The applications in the outline cover the immediate
applications our customers are clamoring about. 

G.823 and G.824 have MTIE and TDEV masks that specify the interface
performance requirements for a T1/E1 interface.  UMTS also requires 50
ppb.  The challenge is that these requirements would be the output of a
packet client.  So, what are the network requirements (delay and Packet
delay variation) that enable a low cost client to be built?   (I think
the integration time should be 24 hours).

G.8261 has begun to specify the network requirements by stating that the
end-to-end jitter must be less than 18us and 4.5us per hop.  That group
is focused on Synchronous Ethernet as well.   

An enhanced NTP approach (if possible) could have wide appeal since it
does not introduce another protocol into the network.  It would also be
preferable if the enhancements that TicToc suggest not only supports
these new applications, but improves the performance of existing
NTP/SNTP.  We should consider our enhancements in three categories:  
	SW changes (algorithms, protocol, etc.)
	Architecture changes  (Unicast/Multicast models, transmission
rate, etc.)
	HW changes (PHY/MAC timestamp engine)

The HW could be optional since not all applications would need this
level of precision.  Moreover a HW implementation should be backward
compatible.  For high precision application we may need to impose some
restrictions on number of hops or architecture, but I would not limit it
for all applications.

Regards,

Jeremy Bennington
Symmetricom
+1 (408) 307-1164

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, January 15, 2007 7:59 AM
To: [email-masked]
Subject: TICTOC Digest, Vol 6, Issue 9

Send TICTOC mailing list submissions to
	[email-masked]

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
	[email-masked]

You can reach the person managing the list at
	[email-masked]

When replying, please edit your Subject line so it is more specific than
"Re: Contents of TICTOC digest..."

Today's Topics:

   1. Re:  Draft BOF description (Marshall Eubanks)

----------------------------------------------------------------------

Message: 1
Date: Mon, 15 Jan 2007 10:58:41 -0500
From: Marshall Eubanks <[email-masked]>
Subject: Re: [TICTOC] Draft BOF description
To: Stewart Bryant <[email-masked]>
Cc: [email-masked]
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes;
	format=flowed

Hello;

I will ask again the questions I asked in San Diego :

What are the accuracy goals of this work, for both synchronization and
syntonization ?
What is the expected integration time ?
What is the expected geographical area over which these goals are likely
to be met ?

Is this effort designed to replicate or instantiate ITU G.8261 ? To
support TDMoIP ? Some other standard ?

In my experience, timing does not lend itself to a "let's make it as
good as possible" mode of development, as the most important question is
generally, what complications can I leave out and still meet my goals ?
(I derived the initial IERS standards for VLBI differential timing
analysis to be good to
10^-13 sec and 10^-15 s/s on a global scale; at that level,
complications abound.)

In order to be specific, I assume that one purpose here is meeting the
TDMoIP accuracy discussed in the ITU SG15, which is roughly 10^-6 sec
and 10^-8 s/s. Does that mesh with other people's expectations ?

I would be willing to participate in but not take the lead on writing
the requirements document.

Regards
Marshall

On Jan 10, 2007, at 12:31 PM, Stewart Bryant wrote:

> Here is a first cut at a BOF request for TICTOC. We need to flesh this

> out and Mark suggests that we need may need a start on requirements 
> and/or architecture.
>
> We need to get enough in place by 25th Jan so that the IAB and IESG 
> can discuss on 1st Feb.
>
> Yaakov Stein and I have agreed to do a first pass at the problem 
> statement. Is anyone prepared to start on a detailed requirements 
> document?
>
> Here is what I have so far on the BOF Description
>
>
> BOF description
>
> There is an emerging need to distribute high quality time and 
> frequency information over IP or MPLS packet switched networks.
> There are two principle drivers for this need:
>
> 1) Applications that previously received their timing (frequency) 
> service from TDM-based networks to which they were connected are now 
> migrating to packet connectivity. The most well known example of this 
> is the need for precision frequency at a mobile phone base station. 
> With the planned migration of the mobile phone network to the use of 
> packet technologies, a new method of providing the required high grade

> frequency reference is needed.
>
> [In the problem statement document we need to outline why the mobile 
> base station needs such timing, why other methods (GPS?) are not 
> suitable (or not preferred vs.
> an IP-based mechanism), etc. This is a good start, but requires a 
> pretty big leap of faith unless you happen to be familiar with the 
> problem. A secondary example might be useful as well.]
>
> 2) Applications that require precision time with a greater accuracy 
> than is currently available with NTP implementations. An example is 
> the measurement of one-way packet delay in modern packet switched 
> networks.
>
> [Note that we need to explain the issues with NTP as it exists today, 
> but we need to make it clear that at this stage we make no judgment 
> about the solution.
>
> From a number of conversations that I have had an enhanced NTP looks a

> good bet - however, I think that we need to be careful to put the 
> problem description before the solution choice]
>
> Other applications that would benefit from the provision of an 
> improved time service span a range of industries: financial, test and 
> measurement, government, industrial etc. The early work in these areas

> indicates that the availability of high accuracy time as a commodity 
> allows the use of techniques that were previously impossible.
> We can therefore expect that the provision of high quality time 
> through the network infrastructure will generate a spiral of new 
> innovative applications that will in turn make greater demands on the 
> quality of time delivered to the end-user.
>
> Three types of time service may potentially be needed, time, phase and

> frequency. A time service requires an absolute time reference; a phase

> service requires that two points in the network co-ordinate with each 
> other in a time sensitive way, but do not need wall-clock time; and a 
> frequency service is one that synchronize the frequencies of two or 
> more oscillators.
>
> The accuracy provided by the existing NTP implementations does not 
> satisfy the needs of the most demanding of the applications described 
> above.
>
> The new IEEE1588v2 protocol also addresses these needs, but has been 
> largely designed around a well controlled LAN environment, and 
> specifies hardware upgrades in order achieve high quality time 
> transfer.
>
> [There are claims that you can do frequency transfer without. Such 
> claims have not been widely tested as yet, and in any case if we 
> approached NTP in the same way we should be able to get the same 
> performance.]
>
> Synchronous Ethernet only satisfies the need for frequency 
> distribution, and even then only over a single physical Ethernet link.

> There is therefore a need to develop a time transfer protocol that has

> sufficient accuracy to support the new application demands over an IP 
> or MPLS network, that exhibits the robustness and scaling necessary in

> an Internet environment, and does not require hardware upgrades 
> throughout the network.
>
> [Comment from Mark:
> To some degree, the MPLS network requirements are a bit different than

> IP, and I would rather see them separated than lumped in together. I 
> see MPLS timing similar to IEEE1588 - e.g., a more "controlled SP 
> environment" analogous to the "controlled LAN environment" you 
> referred to before. This is quite different from something that will 
> work over the global internet (with IP necessarily implies).
>
> I think that is an aspect that we need to think about, because there 
> is a direct relationship between the degree of control that we have 
> over the network and the quality of time that we can deliver]
>
> [Note - I think that we should be clear that we would rule out the 
> protocol taking advantage of h/w changes, but the approach needs to be

> backwards compatible and needs a migration strategy]
>
> [Comment from Mark on the above
> Not to mention what is actually meant by "h/w changes" - I think you 
> will need some education on what that means here (again, more for the 
> ID).
>
> The BOF will assess the interest in developing methods of providing 
> time, phase and frequency services over IP or MPLS networks. If there 
> is sufficient interest, the working group development effort will 
> include mapping the requirements of the various applications, 
> estimating obtainable performance for various network configurations, 
> suggesting algorithms capable of attaining this performance, and 
> developing the required protocols to support these algorithms.
>
> [Do we want to say that the there efforts in ITU to specify methods of

> specifying the quality of frequency transfer, and the IETF should 
> cooperate with the ITU in that regard. Note that I think that we have 
> a sufficient overlap in attendees that we should be able to work 
> together quite well, and also note that the expertise of the two 
> organizations is complementary - the ITU have years of experience 
> specifying clock quality and clock distribution architectures, whilst 
> we have years of NTP and packet network/ distributed systems 
> expertise.
>
> By ITU I mean SG15/Q13]
>
> Agenda
> >
> 1) Description of applications space
> 2) Summary of current work in this area
> 3) Description of the problem that needs to be addressed
> 4) Proposed Charter for TICTOC working group
>
> [Note from Mark, we also need a proposed charter some time between 15 
> Jan and 1 Feb]
>
> - Stewart
>
> _______________________________________________
> TICTOC mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/tictoc

------------------------------

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

End of TICTOC Digest, Vol 6, Issue 9
************************************

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