Subject: [TICTOC] TICTOC and telecom applications

From: "Stefano Ruffini \(RM/ERI\)" <[email-masked]>
Date: Mon, 19 Mar 2007 08:36:48 +0100

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: +39 06 7258 9892
Fax: +39 06 7258 3940
Mobile: +39 335 7462601
Email: [email-masked]	

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/tictoc

---

From: "Sasha Vainshtein" <[email-masked]>
Date: Mon, 19 Mar 2007 20:02:12 +0200

Hi all,
I share Stefano's concerns regarding clarification in the TICROC problem
statement draft.
 
Specifically I'd like to point to the following issues:

1.	Separation between the time and frequency distribution
applications. The distinction between the two includes:

	*	Different client applications (discussed in the draft to
some extent)
	*	Different interface to the client applications and, as a
consequence, different migration scenarios:

		*	Client applications requiring precise frequency
distribution and receiving clock over a TDM interface may continue using
the same interface while the clock is been transferred to a suitable
edge device over a PSN. The corresponding migration scenario can be seen
in the diagram below. 
		*	Client applications requiring precise time
synchronization and receiving time from GPS will have to be modified to
be able to receive time from the PSN as shown in the diagram below. 

	*	Different accuracy metrics and, as a consequence,
possibly different design objectives

2.	The role of the intermediate network nodes in the frequency and
time distribution

	*	To the best of my understanding, ability of TDM networks
to distribute high-precision frequency is based on the following:

		*	High sampling rate (the bit rate of the TDM
interface). 
		*	Tightly controlled characteristics of the
interface (jitter and wander)
		*	Presence of the so-called central clock unit in
each node. This unit is responsible for forcing the same clock (received
from an external clock source or recovered from one of the interfaces)
to all the interfaces of the node. Lack of a similar unit in a typical
IP/MPLS router explains why frequency cannot be distributed across an IP
network comprised of routers interconnected over SONET/SDH links

	*	To the best of my understanding "HW assists" (boundary
and transparent clocks) proposed in IEEE1588 are to some extent
equivalents of the central clock unit 
	*	As noted by Stefano, without these assists NTPv4 and
1588 can be expected to provide similar results

3.	Distribution over dedicated/private networks vs. distribution
over the public Internet: This has been discussed in detail in Stefano's
message.

Hopefully these notes will be useful.
 
Regards,
                 Sasha

________________________________

From: Stefano Ruffini (RM/ERI) [mailto:[email-masked]] 
Sent: Monday, March 19, 2007 9:37 AM
To: [email-masked]
Subject: [TICTOC] TICTOC and telecom applications

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
<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
<http://tf.nist.gov/seminars/ATIS/ATIS.html> ) .

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 <file://www.ericsson.com>         Office: +39 06 7258
9892
Fax: +39 06 7258 3940
Mobile: +39 335 7462601
Email: [email-masked]