Subject: [TICTOC] Draft BOF description

From: Stewart Bryant <[email-masked]>
Date: Wed, 10 Jan 2007 17:31:36 +0000

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

---

From: "Krishna Sankar \(ksankar\)" <[email-masked]>
Date: Wed, 10 Jan 2007 09:43:54 -0800

I can pitch in and work towards the requirement document. 

Cheers
<k/>

> -----Original Message-----
> From: Stewart Bryant (stbryant) 
> Sent: Wednesday, January 10, 2007 9:32 AM
> To: [email-masked]
> Subject: [TICTOC] Draft BOF description
> 
> 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 
> We need to get enough in place by 25th Jan so that the IAB 
> and IESG can discuss on 1st Feb.
> 
> problem statement. Is anyone prepared to start on a detailed 
> requirements document?
> 
> 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.
> 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 
> 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 
> 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]
> 
> 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 
> [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
>  >
> [Note from Mark, we also need a proposed charter some time 
> between 15 Jan and 1 Feb]
> 
> - Stewart
>

---

From: Marshall Eubanks <[email-masked]>
Date: Mon, 15 Jan 2007 10:58:41 -0500

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:

> service from TDM-based networks to which they were connected are  
> now migrating to packet connectivity. The most well known example of
> 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

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 15 Jan 2007 16:20:06 +0000

Marshall Eubanks wrote:

> What are the accuracy goals of this work, for both synchronization  and 
> syntonization ?
> goals ? 

Sure you have to know what you can acheive in a
particular network environment - i.e. is this network and
this technique good enough and reliable enough to serve
this need ... but... there is a very large range of applications
that need time and the result is a range of requirements that
range from NTP style 10ms to rather better than we can expect
to do ns. From a rough survey of the applications it looks
like we need to get from 10ms class to 1us class to satisfy
the majority of the demand. However unlike the original
assumptions make in the NTP design, I think that we can
make requirements on the network to achieve high end
performance.

(I derived the initial IERS standards for VLBI differential

I am not familiar with either of those FLAs

> 
> 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 ?

Support for Circuit Emulation and Mobile Phone base stations are
the two primary drivers for frequency. I think that PDV measurement
is the poster child for time, but as I mentioned in my earlier
message today there are end user applications that also need
time in the 1us class.

> the requirements document.

Thanks

Stewart

---

From: Marshall Eubanks <[email-masked]>
Date: Mon, 15 Jan 2007 12:24:24 -0500

Dear Stewart;

On Jan 15, 2007, at 11:20 AM, Stewart Bryant wrote:

>> What are the accuracy goals of this work, for both  
>> synchronization  and syntonization ?
>> 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

Global relativistic synchronization effects start coming at 4 . 10^-7  
sec, assuming that your network is restricted to be on the surface of  
the Earth, so they shouldn't be ignored even at the microsecond  
level, if you want the domain of your synchronization to be global.  
Things are worse if parts of your network are on an airplane, or in  
LEO; note also that time dilation effects for LEO are order 6 *  
10^-10 s/s, and 10^-8 in deep space.

> I am not familiar with either of those FLAs

Here is the paper referred to

http://www.iers.org/documents/publications/tn/tn32/tn32_109.pdf

Regards
Marshall

>
>> 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.
>
> Thanks
>
> Stewart