RE: [TICTOC] TICTOC and telecom applications
"Sasha Vainshtein" <Sasha@AXERRA.com> Mon, 19 March 2007 18:17 UTC
Return-path: <tictoc-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTMQa-00012b-B6; Mon, 19 Mar 2007 14:17:52 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTMOD-0000Lo-QS for tictoc@ietf.org; Mon, 19 Mar 2007 14:15:25 -0400
Received: from mx100.qos.net.il ([80.74.96.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTMBh-0002dB-Ig for tictoc@ietf.org; Mon, 19 Mar 2007 14:02:41 -0400
Received: from webmail.axerra.com (HELO mail.axerra.com) ([80.74.100.75]) by out2.qos.net.il with ESMTP; 19 Mar 2007 20:02:47 +0200
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ao8CALps/kVQSmRL/2dsb2JhbACDCCU
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [TICTOC] TICTOC and telecom applications
Date: Mon, 19 Mar 2007 20:02:12 +0200
Message-ID: <D849FF14B5E0B142ADFC9A92C509E9BBC7FDA4@tlv2.iprad.local>
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
Thread-Topic: [TICTOC] TICTOC and telecom applications
Thread-Index: Acdp+VnqlCc7EyccRBSdGYUcx0JxqQATwkXw
From: Sasha Vainshtein <Sasha@AXERRA.com>
To: "Stefano Ruffini (RM/ERI)" <stefano.ruffini@ericsson.com>, stbryant@cisco.com, yaakov_s@rad.com
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 81468ae926437b8bac20657ee05e0894
Cc: tictoc@ietf.org
X-BeenThere: tictoc@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Timing over IP Connection and Transfer of Clock BOF <tictoc.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tictoc>, <mailto:tictoc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/tictoc>
List-Post: <mailto:tictoc@ietf.org>
List-Help: <mailto:tictoc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tictoc>, <mailto:tictoc-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0417191832=="
Errors-To: tictoc-bounces@ietf.org
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:stefano.ruffini@ericsson.com] Sent: Monday, March 19, 2007 9:37 AM To: tictoc@ietf.org 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> ) . 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 <file://www.ericsson.com> Office: +39 06 7258 9892 Fax: +39 06 7258 3940 Mobile: +39 335 7462601 Email: stefano.ruffini@ericsson.com 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 TICTOC@ietf.org https://www1.ietf.org/mailman/listinfo/tictoc
- [TICTOC] TICTOC and telecom applications Stefano Ruffini (RM/ERI)
- RE: [TICTOC] TICTOC and telecom applications Sasha Vainshtein