Subject: RE: [TICTOC] Draft BOF description

From: "Sasha Vainshtein" <[email-masked]>
Date: Mon, 15 Jan 2007 14:49:21 +0200

Stewart and all,
I am interested to take part in preparation of the detailed requirements
document.

Please see also a couple of comments inline below.

Regards,
                 Sasha 

-----Original Message-----
From: Stewart Bryant [mailto:[email-masked]] 
Sent: Wednesday, January 10, 2007 7:32 PM
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 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.

[Sasha] I am not sure that "the measurement of one-way packet delay in
modern packet switched networks" per se counts as an application. Can we
possibly have another example?

[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.

[Sasha] Do we have an example of an application that requires phase
synchronization?

The accuracy provided by the existing NTP implementations does not
satisfy the needs of the most demanding of the applications described
above.

[Sasha] From the previous informal discussions I got an impression that
the main reason for insufficient accuracy is the limit placed on the
frequency of the NTP exchanges. Assuming that this is correct it is
worth, IMHO, to include this kind of restrictions into the requirements
document and also possibly in the BOF description?

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

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 15 Jan 2007 13:18:52 +0000

> possibly have another example?

Why not? There are plenty of folks that want to measure network
delay and jitter. The advantage of using it as the primary application
is that everyone at the IETF understands it.

However in a larger body of text I am preparing for a problem
statement draft I have also said:

===========

Although the measurement of the characteristics of a packet network is 
the best known telecommunications example, there are other operational 
needs, for to synchronise operations at the MAC layer. The cable 
industry recently defined a new intra-PoP time transmission mechanism 
for just this purpose (Docsys Timing Interface), and WiMAX is looking 
for relative time delivery to its transmitter sites.

In the test and measurement and industrial sector there is a desire to 
mover from purpose build communications infrastructure with calibrated 
wiring being run back to a centralize controller, to a distributed 
system, in which instructions are distributed in advance to be executed 
at a predetermined time, and in which measurements are taken remotely 
and communicated back to a common point for correlation and analysis. 
Two examples of this are described below.

In the printing industry there is a need to control operations in 
multi-stand printing machines. The paper travels through these machines 
with a speed of nearly 100Km/h. At these speeds a 1us co-ordination 
error between operations taking place at different places in the machine 
produces a 0.03mm color offset, which is visible to the naked eye and 
results in an unacceptable degradation in quality.

In the electrical power industry there is a need to improve the 
measurement of power flows. One proposal is to deploy synchrophasors 
widely in the network and correlate their output to determine demand. 
These devices need to be able to determine the time of measurement with 
an accuracy of 1us.

The examples cited above are a small illustration of a trend that will 
continue to grow as engineers realize the better scaling that can be 
achieved with the action in the future, measure and correlate later 
approach to systems design.

=============

The above examples are very high level summary of the detailed
description of the problem space provided by John Eidson in
his new book on IEEE1588.

> [Sasha] Do we have an example of an application that requires phase

I tend to use the term phase sync when I should really say non-wallclock
time. Most of the automation and instrumentation applications only need
all components to have the same time. Reference to UTC and a short
rollover time are not important.

> document and also possibly in the BOF description?

No, there are also issues with path asymetry, and variations in
store and forward time.

Some vendors claim to be able to do good frequency transfer under
such conditions, but I am not aware of anyone claiming high quality
time transfer.

If anyone thinks that we can correct these errors end to end in
such a way that we can also do good time transfer I would be interested
in a description of the approach and the parameters of their
assumption.