[TICTOC] TICTOC and telecom applications

["Stefano Ruffini \(RM/ERI\)" <[e-mail]>]

Hello ,

I  would like to provide some thoughts from a Telecom perspective
concerning the TICTOC Problem Statement
(http://www.ietf.org/internet-drafts/draft-bryant-tictoc-probstat-00.txt
)  also based on outcome from last WSTS 07
(http://tf.nist.gov/seminars/ATIS/ATIS.html) .

In general I agree that it will be important that this work will be
coordinated with the ongoing activities within ITU-T SG15 Q13.
Information on the ongoing work is provided in the TICTOC Problem
Statement (section 5 ) .

Coming to the Telecom needs , these can be summarized in terms of
frequency needs and time needs as also highlighted in the TICTOC
Problem Statement. 
And it is important to clarify that in some cases only frequency is
needed. GSM Bases station is one of example application requiring
accurate frequency only (50 ppb on the radio interface). Others (e.g.
WCDMA TDD) would need both.

To achieve frequency synchronization in order to of 50 ppb is clearly an
easier tasks if compared with applications that need accurate time
and/or phase in the order of few microseconds. E.g. asymmetry in the
network has no impact on the achievable performances.

As shown at the WSTS 07, both NTP or IEEE1588 protocols are expected to
provide similar characteristics in an end-to-end application (that is
without considering additional features in the intermediate nodes such
as IEEE1588 Transparent Clocks).
Solutions using packets to support Telecom needs are in fact impacted by
packet delay variation in a similar way (either using RTP, NTP, IEEE1588
packets).
And the handling of the packet delay variation is clearly the key aspect
with respect to the performance that can be achieved with these
methodologies (as with any other adaptive method) .
It should be noted that details on handling of the packet delay
variation (e.g. filtering algorithm) is not defined into IEEE1588.

The performance of timing transfer methodologies using IEEE1588 packets
or NTP packets are of course related to several parameters not
necessarily described in the related specifications: oscillator quality,
filtering algorithm. 

Packet rate is also an important parameter as this is strictly related
to the requirements on the local oscillator. In this respect IEEE1588 is
beeing updated (v2) to allow higher packet rate if compared with v1.
The limitation on packet rate in NTP is important in an open environment
(eg. public NTP Server) and when using the traditional algorithm to
recover time of day so to guarantee a proper interworking.

In a telecom environment the clients that can have access to a specific
time server must be limited via proper network planning. 
In this case the NTP clients can send higher packet rate as there is a
full control on the clients that can have access to a specific Time
Server (this aspect could be clarified by simply adding notes in the
relevant specifications).

>From this respect also the separation of the NTP protocol definition
from the NTP algorithm aspects (including packet rate) would clarify the
use of NTP in some specific application. 

There can be packet network environments were especially in order to
guarantee accurate phase or time (in the order of few microseconds),
support in the intermediate nodes may be of vital importance.
Transparent Clocks/ Boundary clocks (and NTP cascaded Time server?) can
be considered in this case.

Final comments related to some clarifications that may be considered in
the TICTOC Problem Statement in section 3.3. "Transfer Using Packet
Networks " .

When referring to the NTP existing implementation (e.g."NTP is widely
deployed, but existing implementations deliver accuracy on the order of
10 milliseconds. "), it should be clarified that these are the
traditional Time of Day implementation (e.g. SW realizations, over
public internet, using public Time servers, using the algorithm provided
in RFC 1305, etc.)
Different realizations and deployments using the same NTP protocol may
be inplemented  providing different characteristics (e.g. in terms of
frequency distribution only). These may include HW implementations,
higher packet rates in a controlled environment, proper filtering
algorithm, etc..
Based on comments provided above, the statement, "Furthermore, typical
update rates are low and can not be significantly increased due to
scalability issues in the server. ", may be further expanded clarifying
that this is applicable to the traditional realizations and deployments.

With respect to scalability, the NTP strata level concept may be
considered to provide scalability to NTP based implementation.

Based on the above discussion some of the topics described in the TICTOC
Problem Statement may be considered to be better clarified.

Best Regards
Stefano Ruffini

Stefano Ruffini
Ericsson Network Synchronization Center
Marconi S.p.A.
Ericsson Global Product Center - Italy
Via Anagnina, 203 
00118, Rome, Italy
www.ericsson.com	Office: [phone]
Fax: [phone]
Mobile: [phone]
Email: [e-mail]	


This communication is confidential and intended solely for the
addressee(s). Any unauthorized review, use, disclosure or distribution
is prohibited. If you believe this message has been sent to you in
error, please notify the sender by replying to this transmission and
delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption,
interception, unauthorized amendment, tampering and viruses, and we only
send and receive emails on the basis that we are not liable for any such
corruption, interception, amendment, tampering or viruses or any
consequences thereof.

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