TICTOC S. Rodrigues Internet-Draft Zarlink Semiconductor Intended status: Informational K. Lindqvist Expires: January 8, 2009 Netnod July 7, 2008 TICTOC Requirement draft-rodrigues-lindqvist-tictoc-req-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 8, 2009. Abstract Distribution of high precision time and frequency over the Internet and special purpose IP networks is becoming more and more needed as IP networks replace legacy networks and applications and as new applications with need for frequency and time are developed on the Internet. The IETF formed the TICTOC workinggroup to address the problem and perform an analysis on existing solutions and the needs. This document summarises application needs, as described and agreed on at an TICTOC interim meeting held in Paris from June 16 to 18, 2008. Rodrigues & Lindqvist Expires January 8, 2009 [Page 1] Internet-Draft TICTOC July 2008 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Applications Requirements . . . . . . . . . . . . . . . . . . 3 3.1. Cellular Backhauling . . . . . . . . . . . . . . . . . . . 3 3.1.1. Cellular Backhaul Requirements . . . . . . . . . . . . 4 3.2. Circuit Emulation . . . . . . . . . . . . . . . . . . . . 6 3.2.1. Circuit Emulation requirements . . . . . . . . . . . . 7 3.3. Remote Telco . . . . . . . . . . . . . . . . . . . . . . . 9 3.3.1. Remote Telco requirements . . . . . . . . . . . . . . 9 3.4. Instrumentation and Measurement, Industrial Automation, and Power . . . . . . . . . . . . . . . . . . 11 3.4.1. Instrumentation and Measurement, Industrial Automation, and Power Requirements . . . . . . . . . . 11 3.5. Networking . . . . . . . . . . . . . . . . . . . . . . . . 13 3.5.1. Networking . . . . . . . . . . . . . . . . . . . . . . 13 3.6. ToD/ Internet . . . . . . . . . . . . . . . . . . . . . . 15 3.6.1. ToD/Internet . . . . . . . . . . . . . . . . . . . . . 15 3.7. Legal Time . . . . . . . . . . . . . . . . . . . . . . . . 17 3.7.1. Legal Time requirements . . . . . . . . . . . . . . . 17 3.8. Metrology . . . . . . . . . . . . . . . . . . . . . . . . 19 3.8.1. Metrology requirements . . . . . . . . . . . . . . . . 19 3.9. Sensor . . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.9.1. Sensors requirements . . . . . . . . . . . . . . . . . 21 4. Network Dependencies . . . . . . . . . . . . . . . . . . . . . 23 5. Network Topology . . . . . . . . . . . . . . . . . . . . . . . 24 6. Security Considerations . . . . . . . . . . . . . . . . . . . 24 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 9. Informative References . . . . . . . . . . . . . . . . . . . . 24 Appendix A. Existing Time and Frequency Transfer Mechanisms . . . 25 A.1. Radio-based Timing Transfer Methods . . . . . . . . . . . 26 A.2. Dedicated Wire-based Timing Transfer Methods . . . . . . . 27 A.3. Transfer Using Packet Networks . . . . . . . . . . . . . . 27 A.3.1. NTP summary description . . . . . . . . . . . . . . . 28 A.3.2. IEEE1588 summary description . . . . . . . . . . . . . 28 Appendix B. Other Forums Working in this Problem Space . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 Intellectual Property and Copyright Statements . . . . . . . . . . 32 Rodrigues & Lindqvist Expires January 8, 2009 [Page 2] Internet-Draft TICTOC July 2008 1. Introduction There is an emerging need to distribute highly accurate time and frequency information over IP and over MPLS packet switched networks (PSNs). In this draft, the requirements for transporting accurate time and/or frequency are addressed. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 3. Applications Requirements There are many applications that need synchronization. Some applications only need frequency; for others a combination of frequency and time of day or phase may be required. At the TICTOC interim meeting, it was agreed that these applications be grouped based on what was believed to be common requirements, and where the requiremetns were distinct from each other. This section describes these applications (or groups of applications) that was agreed on at the TICTOC interim meeting. 3.1. Cellular Backhauling Within Cellular backhauling, there are several applications that need to be considered. Some of these applications only require frequency information, others require time-of-day, and others require phase. The cellular backhauling applications to be consiredered are: o GSM o Wimax o LTE o UMTS FDD o UMTS TDD o CDMA2000 o TD-SCDMA Conventionally GSM and UMTS FDD base stations obtain this reference Rodrigues & Lindqvist Expires January 8, 2009 [Page 3] Internet-Draft TICTOC July 2008 frequency by locking on to the E1/T1 that links them to the base station controller. With the replacement of TDM links with Packet Switched Networks (PSNs) such as Ethernet, IP or MPLS, this simple method of providing a frequency reference is lost, and frequency information must be made available in some other way. The synchronization requirement is derived from the need for the radio frequencies to be accurate. Radio spectrum is a limited and valuable commodity that needs to be used as efficiently as possible. In GSM, transmission frequencies are allocated to a given cellular base station and its neighbors in such fashion as to ensure that they do not interfere with each other. If the radio network designer cannot rely on the accuracy of these frequencies, the spacing between the frequencies used by neighboring sites must be increased, with significant economic consequences. There is an additional requirement derived from the need for smooth handover when a mobile station crosses from one cell to another. If the radio system designer can not guarantee that the preparations required for handover occur in a few milliseconds, then they must allow the mobile station to consume frequency resources simultaneously in both cells in order to avoid service disruption. The preparations required involve agreement between the mobile and base stations on the new frequencies and time offsets; these agreements can be accomplished quickly when the two base stations' frequency references are the same to a high degree of accuracy. 3.1.1. Cellular Backhaul Requirements The requirements for the Cellular Backhauling is summarized in the table 1. Editor's note: This table was discussed at the interim meeting, but it has not been agreed on, therefore is left in blank. The requirements listed in the table and the definitions of the terms need to be addressed as they have not been agreed on. Rodrigues & Lindqvist Expires January 8, 2009 [Page 4] Internet-Draft TICTOC July 2008 Cellular Backhaul Requirements +---------------+--------+--------+-------+-----+---------+---------+ | Requirements | GSM/UM | UMTS | Wimax | LTE | CDMA200 | TD-SCDM | | | TS FDD | TDD | | | 0 | A | +---------------+--------+--------+-------+-----+---------+---------+ | Time Type | | | | | | | | ------------- | ------ | ------ | ----- | --- | ------ | ------- | | Time | | | | | | | | Resolution | | | | | | | | ------------- | ------ | ------ | ----- | --- | ------ | ------- | | Client's time | | | | | | | | resolution | | | | | | | | ------------- | ------ | ------ | ----- | --- | ------ | ------- | | Freq | | | | | | | | stability | | | | | | | | ------------- | ------ | ------ | ----- | --- | ------ | ------- | | freq accuracy | | | | | | | | ------------- | ------ | ------ | ----- | --- | ------ | ------- | | time/phase | | | | | | | | stability | | | | | | | | ------------- | ------ | ------ | ----- | --- | ------ | ------- | | time/phase | | | | | | | | accuracy | | | | | | | | ------------- | ------ | ------ | ----- | --- | ------ | ------- | | time/acquisit | | | | | | | | ion time | | | | | | | | ------------- | ------ | ------ | ----- | --- | ------ | ------- | | service | | | | | | | | jitter | | | | | | | | ------------- | ------ | ------ | ----- | --- | ------ | ------- | | service | | | | | | | | wander | | | | | | | | ------------- | ------ | ------ | ----- | --- | ------ | ------- | | asymmetry | | | | | | | | ------------- | ------ | ------ | ----- | --- | ------ | ------- | | constrained | | | | | | | | network | | | | | | | | ------------- | ------ | ------ | ----- | --- | ------ | ------- | | on-path | | | | | | | | support | | | | | | | | ------------- | ------ | ------ | ----- | --- | ------ | ------- | | clients/serve | | | | | | | | r | | | | | | | | ------------- | ------ | ------ | ----- | --- | ------ | ------- | | update rate | | | | | | | | ------------- | ------ | ------ | ----- | --- | ------ | ------- | Rodrigues & Lindqvist Expires January 8, 2009 [Page 5] Internet-Draft TICTOC July 2008 | server | | | | | | | | authenticatio | | | | | | | | n | | | | | | | | ------------- | ------ | ------ | ----- | --- | ------ | ------- | | client | | | | | | | | authenticatio | | | | | | | | n | | | | | | | | ------------- | ------ | ------ | ----- | --- | ------ | ------- | | transaction | | | | | | | | authenticatio | | | | | | | | n | | | | | | | | ------------- | ------ | ------ | ----- | --- | ------ | ------- | | backwards | | | | | | | | compatibility | | | | | | | +---------------+--------+--------+-------+-----+---------+---------+ Table 1 3.2. Circuit Emulation The PWE3 WG has produced three techniques for emulating traditional low-rate (E1, T1, E3, T3) TDM services over PSNs, namely SAToP [RFC4553], CESoPSN [RFC5086], and TDMoIP. The Network Synchronization reference model and deployment scenarios for emulation of TDM services have been described in [RFC4197], Section 4.3. The major technical challenge for TDM pseudowires is the accuracy of its clock recovery. TDM network standards for timing accuracy and stability are extremely demanding. These requirements are not capriciously dictated by standards bodies, rather they are critical to the proper functioning of a high-speed TDM network. Consider a TDM receiver utilizing its own clock when converting the physical signal back into a bit-stream. If the receive clock runs at precisely the same rate as the source clock, then the receiver need only determine the optimal sampling phase. However, with any mismatch of clock rates, no matter how small, bit slips will eventually occur. For example, if the receive clock is slower than the source clock by one part per million (ppm), then the receiver will output 999,999 bits for every 1,000,000 bits sent, thus deleting one bit. Similarly, if the receive clock is faster than the source clock by one part per billion (ppb), the receiver will insert a spurious bit every billion bits. One bit slip every million bits may seem acceptable at first glance, but translates to a catastrophic two errors per second for a 2 Mb/s E1 signal. ITU-T recommendations permit a few bit slips per day for a low-rate 64 kb/s channel, but strive to prohibit bit slips entirely for higher-rate TDM signals. Rodrigues & Lindqvist Expires January 8, 2009 [Page 6] Internet-Draft TICTOC July 2008 3.2.1. Circuit Emulation requirements The requirements for the Circuit Emulation is summarized in the table 2. Editor's note: This table was discussed at the interim meeting, but it has not been agreed on, therefore is left in blank. The requirements listed in the table and the definitions of the terms need to be addressed as they have not been agreed on. Rodrigues & Lindqvist Expires January 8, 2009 [Page 7] Internet-Draft TICTOC July 2008 Circuit Emulation +-----------------------------+-----------------------------+ | Requirements | Circuit Emulation | +-----------------------------+-----------------------------+ | Time Type | | | --------------------------- | --------------------------- | | Time Resolution | | | --------------------------- | --------------------------- | | Client's time resolution | | | --------------------------- | --------------------------- | | Freq stability | | | --------------------------- | --------------------------- | | freq accuracy | | | --------------------------- | --------------------------- | | time/phase stability | | | --------------------------- | --------------------------- | | time/phase accuracy | | | --------------------------- | --------------------------- | | time/acquisition time | | | --------------------------- | --------------------------- | | service jitter | | | --------------------------- | --------------------------- | | service wander | | | --------------------------- | --------------------------- | | asymmetry | | | --------------------------- | --------------------------- | | constrained network | | | --------------------------- | --------------------------- | | on-path support | | | --------------------------- | --------------------------- | | clients/server | | | --------------------------- | --------------------------- | | update rate | | | --------------------------- | --------------------------- | | server authentication | | | --------------------------- | --------------------------- | | client authentication | | | --------------------------- | --------------------------- | | transaction authentication | | | --------------------------- | --------------------------- | | backwards compatibility | | +-----------------------------+-----------------------------+ Table 2 Rodrigues & Lindqvist Expires January 8, 2009 [Page 8] Internet-Draft TICTOC July 2008 3.3. Remote Telco Editor's note: need more info on this application. 3.3.1. Remote Telco requirements The requirements for the Remote Telco is summarized in the table 3. Editor's note: This table was discussed at the interim meeting, but it has not been agreed on, therefore is left in blank. The requirements listed in the table and the definitions of the terms need to be addressed as they have not been agreed on. Rodrigues & Lindqvist Expires January 8, 2009 [Page 9] Internet-Draft TICTOC July 2008 Remote Telco +-----------------------------+-----------------------------+ | Requirements | Remote Telco | +-----------------------------+-----------------------------+ | Time Type | | | --------------------------- | --------------------------- | | Time Resolution | | | --------------------------- | --------------------------- | | Client's time resolution | | | --------------------------- | --------------------------- | | Freq stability | | | --------------------------- | --------------------------- | | freq accuracy | | | --------------------------- | --------------------------- | | time/phase stability | | | --------------------------- | --------------------------- | | time/phase accuracy | | | --------------------------- | --------------------------- | | time/acquisition time | | | --------------------------- | --------------------------- | | service jitter | | | --------------------------- | --------------------------- | | service wander | | | --------------------------- | --------------------------- | | asymmetry | | | --------------------------- | --------------------------- | | constrained network | | | --------------------------- | --------------------------- | | on-path support | | | --------------------------- | --------------------------- | | clients/server | | | --------------------------- | --------------------------- | | update rate | | | --------------------------- | --------------------------- | | server authentication | | | --------------------------- | --------------------------- | | client authentication | | | --------------------------- | --------------------------- | | transaction authentication | | | --------------------------- | --------------------------- | | backwards compatibility | | +-----------------------------+-----------------------------+ Table 3 Rodrigues & Lindqvist Expires January 8, 2009 [Page 10] Internet-Draft TICTOC July 2008 3.4. Instrumentation and Measurement, Industrial Automation, and Power In the test and measurement and industrial sector there is a desire to move from special purpose communications infrastructure with calibrated wiring 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 later correlation and analysis. Two examples of this tendency 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 at a speed of nearly 100 km/h. At these speeds, co- ordination error of 1 microsecond between operations taking place at different positions 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 in order to monitor and predict usage patterns. One proposal is to extensively deploy synchro-phasors in the power network and to correlate their output to determine demand. These devices need to be able to determine the time of measurement with an accuracy of 1 microsecond. 3.4.1. Instrumentation and Measurement, Industrial Automation, and Power Requirements The requirements for the Instrumentation and Measurement, Industrial Automation, and Power Requirements are summarized in the table 4. Editor's note: This table was discussed at the interim meeting, but it has not been agreed on, therefore is left in blank. The requirements listed in the table and the definitions of the terms need to be addressed as they have not been agreed on. Rodrigues & Lindqvist Expires January 8, 2009 [Page 11] Internet-Draft TICTOC July 2008 Instrumentation and Measurement, Industrial Automation, and Power Requirements Requirements +----------------+--------------------------+-------------+---------+ | Requirements | Instrumentation/measurem | Industrial | Power | | | ent | Automation | | +----------------+--------------------------+-------------+---------+ | Time Type | | | | | -------------- | ----------------------- | ----------- | ------- | | Time | | | | | Resolution | | | | | -------------- | ----------------------- | ----------- | ------- | | Client's time | | | | | resolution | | | | | -------------- | ----------------------- | ----------- | ------- | | Freq stability | | | | | -------------- | ----------------------- | ----------- | ------- | | freq accuracy | | | | | -------------- | ----------------------- | ----------- | ------- | | time/phase | | | | | stability | | | | | -------------- | ----------------------- | ----------- | ------- | | time/phase | | | | | accuracy | | | | | -------------- | ----------------------- | ----------- | ------- | | time/acquisiti | | | | | on time | | | | | -------------- | ----------------------- | ----------- | ------- | | service jitter | | | | | -------------- | ----------------------- | ----------- | ------- | | service wander | | | | | -------------- | ----------------------- | ----------- | ------- | | asymmetry | | | | | -------------- | ----------------------- | ----------- | ------- | | constrained | | | | | network | | | | | -------------- | ----------------------- | ----------- | ------- | | on-path | | | | | support | | | | | -------------- | ----------------------- | ----------- | ------- | | clients/server | | | | | -------------- | ----------------------- | ----------- | ------- | | update rate | | | | | -------------- | ----------------------- | ----------- | ------- | | server | | | | | authentication | | | | | -------------- | ----------------------- | ----------- | ------- | Rodrigues & Lindqvist Expires January 8, 2009 [Page 12] Internet-Draft TICTOC July 2008 | client | | | | | authentication | | | | | -------------- | ----------------------- | ----------- | ------- | | transaction | | | | | authentication | | | | | -------------- | ----------------------- | ----------- | ------- | | backwards | | | | | compatibility | | | | +----------------+--------------------------+-------------+---------+ Table 4 3.5. Networking Editor's note: need more info on this application. 3.5.1. Networking The requirements for the Newtworking SLA and Network CDR are summarized in the table 5. Editor's note: This table was discussed at the interim meeting, but it has not been agreed on, therefore is left in blank. The requirements listed in the table and the definitions of the terms need to be addressed as they have not been agreed on. Rodrigues & Lindqvist Expires January 8, 2009 [Page 13] Internet-Draft TICTOC July 2008 Newtworking SLA and Network CDR Requirements +------------------------------+-------------------+--------------+ | Requirements | Newtworking SLA | Network CDR | +------------------------------+-------------------+--------------+ | Time Type | | | | ---------------------------- | ----------------- | ------------ | | Time Resolution | | | | ---------------------------- | ----------------- | ------------ | | Client's time resolution | | | | ---------------------------- | ----------------- | ------------ | | Freq stability | | | | ---------------------------- | ----------------- | ------------ | | freq accuracy | | | | ---------------------------- | ----------------- | ------------ | | time/phase stability | | | | ---------------------------- | ----------------- | ------------ | | time/phase accuracy | | | | ---------------------------- | ----------------- | ------------ | | time/acquisition time | | | | ---------------------------- | ----------------- | ------------ | | service jitter | | | | ---------------------------- | ----------------- | ------------ | | service wander | | | | ---------------------------- | ----------------- | ------------ | | asymmetry | | | | ---------------------------- | ----------------- | ------------ | | constrained network | | | | ---------------------------- | ----------------- | ------------ | | on-path support | | | | ---------------------------- | ----------------- | ------------ | | clients/server | | | | ---------------------------- | ----------------- | ------------ | | update rate | | | | ---------------------------- | ----------------- | ------------ | | server authentication | | | | ---------------------------- | ----------------- | ------------ | | client authentication | | | | ---------------------------- | ----------------- | ------------ | | transaction authentication | | | | ---------------------------- | ----------------- | ------------ | | backwards compatibility | | | +------------------------------+-------------------+--------------+ Table 5 Rodrigues & Lindqvist Expires January 8, 2009 [Page 14] Internet-Draft TICTOC July 2008 3.6. ToD/ Internet General time distriubtion over the Internet or IP networks, is often called Time of Day or Wall-clock. Most existing use cases are using NTP over the Internet with low precision requirements. However, new applications are arising that require higher precision rates than what is currently available. The users of Internet time 3.6.1. ToD/Internet The requirements for the ToD/Internet is summarized in the table 6. Editor's note: This table was discussed at the interim meeting, but it has not been agreed on, therefore is left in blank. The requirements listed in the table and the definitions of the terms need to be addressed as they have not been agreed on. Rodrigues & Lindqvist Expires January 8, 2009 [Page 15] Internet-Draft TICTOC July 2008 ToD/Internet Requirements +-----------------------------+-----------------------------+ | Requirements | ToD/Internet | +-----------------------------+-----------------------------+ | Time Type | | | --------------------------- | --------------------------- | | Time Resolution | | | --------------------------- | --------------------------- | | Client's time resolution | | | --------------------------- | --------------------------- | | Freq stability | | | --------------------------- | --------------------------- | | freq accuracy | | | --------------------------- | --------------------------- | | time/phase stability | | | --------------------------- | --------------------------- | | time/phase accuracy | | | --------------------------- | --------------------------- | | time/acquisition time | | | --------------------------- | --------------------------- | | service jitter | | | --------------------------- | --------------------------- | | service wander | | | --------------------------- | --------------------------- | | asymmetry | | | --------------------------- | --------------------------- | | constrained network | | | --------------------------- | --------------------------- | | on-path support | | | --------------------------- | --------------------------- | | clients/server | | | --------------------------- | --------------------------- | | update rate | | | --------------------------- | --------------------------- | | server authentication | | | --------------------------- | --------------------------- | | client authentication | | | --------------------------- | --------------------------- | | transaction authentication | | | --------------------------- | --------------------------- | | backwards compatibility | | +-----------------------------+-----------------------------+ Table 6 Rodrigues & Lindqvist Expires January 8, 2009 [Page 16] Internet-Draft TICTOC July 2008 3.7. Legal Time With legal time is meant the cases where high precision wall-clock is needed, just as in the ToD case, but with where the time source is tracable to UTC in a secure manner, i.e through a certificate chain. It's also important for the legal-time case that the certificate chain is set-up so that it provides for an audit trail, where the ToD provided at any given moment can be traced to a known source or standard (i.e a national timescale or time laboratory). One typical application that would benefit from high accuracy legal time is event correlation in computer systems logs, and similar applications. 3.7.1. Legal Time requirements The requirements for the Legal Time is summarized in the table 7. Editor's note: This table was discussed at the interim meeting, but it has not been agreed on, therefore is left in blank. The requirements listed in the table and the definitions of the terms need to be addressed as they have not been agreed on. Rodrigues & Lindqvist Expires January 8, 2009 [Page 17] Internet-Draft TICTOC July 2008 Legal Time requirements +-----------------------------+-----------------------------+ | Requirements | Legal Time | +-----------------------------+-----------------------------+ | Time Type | | | --------------------------- | --------------------------- | | Time Resolution | | | --------------------------- | --------------------------- | | Client's time resolution | | | --------------------------- | --------------------------- | | Freq stability | | | --------------------------- | --------------------------- | | freq accuracy | | | --------------------------- | --------------------------- | | time/phase stability | | | --------------------------- | --------------------------- | | time/phase accuracy | | | --------------------------- | --------------------------- | | time/acquisition time | | | --------------------------- | --------------------------- | | service jitter | | | --------------------------- | --------------------------- | | service wander | | | --------------------------- | --------------------------- | | asymmetry | | | --------------------------- | --------------------------- | | constrained network | | | --------------------------- | --------------------------- | | on-path support | | | --------------------------- | --------------------------- | | clients/server | | | --------------------------- | --------------------------- | | update rate | | | --------------------------- | --------------------------- | | server authentication | | | --------------------------- | --------------------------- | | client authentication | | | --------------------------- | --------------------------- | | transaction authentication | | | --------------------------- | --------------------------- | | backwards compatibility | | +-----------------------------+-----------------------------+ Table 7 Rodrigues & Lindqvist Expires January 8, 2009 [Page 18] Internet-Draft TICTOC July 2008 3.8. Metrology Metrology for time and frequency is today mostly using tailored equipment and cabling for time/frequency transfer when doing laboratory work. However, in the future, using IP over existing networks in the laboratories would allow for greater flexibility and reuse of existing infrastructure rather than building out more special purpose infrastructure. 3.8.1. Metrology requirements The requirements for the Metrology is summarized in the table 8. Editor's note: This table was discussed at the interim meeting, but it has not been agreed on, therefore is left in blank. The requirements listed in the table and the definitions of the terms need to be addressed as they have not been agreed on. Rodrigues & Lindqvist Expires January 8, 2009 [Page 19] Internet-Draft TICTOC July 2008 Metrology requirements +-----------------------------+-----------------------------+ | Requirements | Metrology | +-----------------------------+-----------------------------+ | Time Type | | | --------------------------- | --------------------------- | | Time Resolution | | | --------------------------- | --------------------------- | | Client's time resolution | | | --------------------------- | --------------------------- | | Freq stability | | | --------------------------- | --------------------------- | | freq accuracy | | | --------------------------- | --------------------------- | | time/phase stability | | | --------------------------- | --------------------------- | | time/phase accuracy | | | --------------------------- | --------------------------- | | time/acquisition time | | | --------------------------- | --------------------------- | | service jitter | | | --------------------------- | --------------------------- | | service wander | | | --------------------------- | --------------------------- | | asymmetry | | | --------------------------- | --------------------------- | | constrained network | | | --------------------------- | --------------------------- | | on-path support | | | --------------------------- | --------------------------- | | clients/server | | | --------------------------- | --------------------------- | | update rate | | | --------------------------- | --------------------------- | | server authentication | | | --------------------------- | --------------------------- | | client authentication | | | --------------------------- | --------------------------- | | transaction authentication | | | --------------------------- | --------------------------- | | backwards compatibility | | +-----------------------------+-----------------------------+ Table 8 Rodrigues & Lindqvist Expires January 8, 2009 [Page 20] Internet-Draft TICTOC July 2008 3.9. Sensor More generally, there is growing interest in clock synchronization in massively parallel sensor networks. Advances in wireless communications have enabled the development of low power miniature sensors that collect and disseminate data from their immediate environment. Although each sensor has limited processing power, through distributed processing the network becomes capable of performing various tasks of data fusion, but only assuming a common time base can be established. 3.9.1. Sensors requirements The requirements for the Sensor is summarized in the table 9. Editor's note: This table was discussed at the interim meeting, but it has not been agreed on, therefore is left in blank. The requirements listed in the table and the definitions of the terms need to be addressed as they have not been agreed on. Rodrigues & Lindqvist Expires January 8, 2009 [Page 21] Internet-Draft TICTOC July 2008 Sensor requirements +-----------------------------+-----------------------------+ | Requirements | Sensor | +-----------------------------+-----------------------------+ | Time Type | | | --------------------------- | --------------------------- | | Time Resolution | | | --------------------------- | --------------------------- | | Client's time resolution | | | --------------------------- | --------------------------- | | Freq stability | | | --------------------------- | --------------------------- | | freq accuracy | | | --------------------------- | --------------------------- | | time/phase stability | | | --------------------------- | --------------------------- | | time/phase accuracy | | | --------------------------- | --------------------------- | | time/acquisition time | | | --------------------------- | --------------------------- | | service jitter | | | --------------------------- | --------------------------- | | service wander | | | --------------------------- | --------------------------- | | asymmetry | | | --------------------------- | --------------------------- | | constrained network | | | --------------------------- | --------------------------- | | on-path support | | | --------------------------- | --------------------------- | | clients/server | | | --------------------------- | --------------------------- | | update rate | | | --------------------------- | --------------------------- | | server authentication | | | --------------------------- | --------------------------- | | client authentication | | | --------------------------- | --------------------------- | | transaction authentication | | | --------------------------- | --------------------------- | | backwards compatibility | | +-----------------------------+-----------------------------+ Table 9 Rodrigues & Lindqvist Expires January 8, 2009 [Page 22] Internet-Draft TICTOC July 2008 4. Network Dependencies When using packet networks to transfer timing, packet delay variation, propagation asymmetry, and maximum permissible packet rate all have a significant bearing on the accuracy with which the client is able to determine absolute time. Thus the network environment has a large bearing on the quality of time that can be delivered. Timing distribution is highly sensitive to packet delay variation, and can thus can deteriorate under congestion conditions. Furthermore the disciplining of the client's oscillator (the sole component of frequency transfer, and a critical component of time transfer) is a function that should not be disrupted. When the service is disrupted the client needs to go into "holdover" mode, and its accuracy will consequently be degraded. Depending on the relative quality of the client's clock and the required quality after disciplining, a relatively high packet rate may be required. Packet delay variation can to some extent be addressed by traffic engineering, thus time transfer within a constrained network environment might reasonably be expected to deliver a higher quality time service than can be achieved between two arbitrary hosts connected to the Internet. Greater gains can probably be obtained by deploying equipment that incorporates IEEE 1588 style on-the-fly packet timestamp correction (or any other form of on-path support), or follow-up message mechanisms that report the packet storage and forward delays to the client. However one can only be sure that such techniques are available along the entire path in a well-controlled environment. Therefor, time transfer protocols should not assume the availability of on path support, but utilise it where available. The packet rate between the time-server and its client also has a bearing on the quality of the time transfer, because at a higher rate the smart filter has a better chance of extracting the "good" packets. How the packet rate relates to the accuracy is dependent on the filter algorithm in use. In a controlled environment it is possible to ensure that there is adequate bandwidth, and that the server is not overloaded. In such an environment the onus moves from protecting the server from overload, to ensuring that the server can satisfy the needs of all of the clients. Congested and overloaded paths might influence the quality of timing transfer. In a constrained network environment, it's assumed that a service provider will ensure that packet delivery is done in according to the timing transfer needs of the network operator. Rodrigues & Lindqvist Expires January 8, 2009 [Page 23] Internet-Draft TICTOC July 2008 5. Network Topology Editor's note: This section needs to be discussed. 6. Security Considerations Time and frequency services are a significant element of network infrastructure, and are critical for certain emerging applications. Hence time and frequency transfer services MUST be protected from being compromised, and for some of the applications described above such as legal time, the ability to provide and audit trail to the timing source. One possible threat is a false time or frequency server being accepted instead of a true one, thus enabling an attacker to alter the time and frequency service provided. Other possible scenarios are to be able to distinguish between trusted clients and non-trusted clients when providing service. Any protection mechanism must be designed in such a way that it does not degrade the quality of the time transfer. Such a mechanism SHOULD also be relatively lightweight, as client restrictions often dictate a low processing and memory footprint, and because the server may have extensive fan-out. The following authentication mechanism need to be considered: 1. of server by client (depending on the application) 2. of client by server (depending on the application) 3. transactions (depending on the application) 7. IANA Considerations No IANA actions are required as a result of the publication of this document. 8. Acknowledgements The authors wish to thank Stewart Bryant, Yaakov Stein, Karen O'Donoghue and Laurent Montini for input on this draft. 9. Informative References [1588] IEEE, "1588-2002 Standard for A Precision Clock Rodrigues & Lindqvist Expires January 8, 2009 [Page 24] Internet-Draft TICTOC July 2008 Synchronization Protocol for Networked Measurement and Control Systems". [G8261] ITU-T, "Recommendation G.8261/Y.1361 - Timing and synchronization aspects in packet networks", April 2008. [G8262] ITU-T, "Recommendation G.8262/Y.1362 - Timing Characteristics of Synchronous Ethernet Equipment Slave Clock (EEC)", August 2007. [G8264] ITU-T, "Recommendation G.8264/Y.1364 - Distribution of timing through packet networks", 2008. [RFC1305] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation", RFC 1305, March 1992. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4197] Riegel, M., "Requirements for Edge-to-Edge Emulation of Time Division Multiplexed (TDM) Circuits over Packet Switching Networks", RFC 4197, October 2005. [RFC4553] Vainshtein, A. and YJ. Stein, "Structure-Agnostic Time Division Multiplexing (TDM) over Packet (SAToP)", RFC 4553, June 2006. [RFC5086] Vainshtein, A., Sasson, I., Metz, E., Frost, T., and P. Pate, "Structure-Aware Time Division Multiplexed (TDM) Circuit Emulation Service over Packet Switched Network (CESoPSN)", RFC 5086, December 2007. Appendix A. Existing Time and Frequency Transfer Mechanisms In this section we will discuss existing mechanisms for transfer of time information, frequency information, or both. It should be noted that a sufficiently accurate time transfer service may be used to derive an accurate frequency transfer. Indeed, this is exactly what happens in a GPS disciplined frequency standard. On the other hand, an accurate frequency transfer service, while itself unable to transfer absolute time, is usually used to support and improve the performance of the time transfer service. Indeed, implementations of NTP or IEEE 1588 clients can be considered to consist of two phases. First, a local oscillator is locked to the server's frequency using incoming information from the incoming packets, and then the local time set based on the server's time and the propagation latency. By Rodrigues & Lindqvist Expires January 8, 2009 [Page 25] Internet-Draft TICTOC July 2008 maintaining a local frequency source, the client requires relatively infrequent updates, and can continue functioning during short periods of network outage. Moreover, it can be shown that this method results in significantly better time transfer accuracy than methods that do not discipline a local clock. Time transfer mechanisms can be divided into three classes. The first class consists of mechanisms that use radio frequency transport, while the second mechanism uses dedicated "wires" (which for our purposes include optical fibers). The third, which will be our main focus, exploits a Packet Switched Network for transfer of timing information. Advantages and disadvantages of these three methods are discussed in the following subsections. A.1. Radio-based Timing Transfer Methods The transfer of time by radio transmission is one of the oldest methods available, and is still the most accurate wide area method. In particular, there are two navigation in wide use that can be used for time transfer, The LOng RAnge Navigation (LORAN) terrestrial radio system, and the Global Navigation Satellite System (GNSS). In both cases the user needs to be able to receive the transmitted signal, requiring access to a suitable antenna. In certain situations, e.g. basement communications rooms and urban canyons, the required signal may not be receivable. Radio systems have high accuracy, far better than what we will later see can be achieved by existing PSN technologies. However coverage is limited; eLORAN for example only covers North America, and GPS does not have good coverage near the poles. Although civilian use is sanctioned, the GPS was developed and is operated by the U.S. Department of Defense as a military system. For this reason there are political concerns that rules out its use in certain countries. The European Union is working on an alternative system called Galileo, which will be run as a commercial enterprise. In addition, GPS has some well-documented multi-hour outages, and is considered vulnerable to jamming. One major PTT also reports that they see a 2% per year failure rate for the antenna/receiver/ clock-out chain. While a radio-based timing service may be acceptable for some sites, it is frequently impractical to use on a per equipment basis. Hence, some form of local timing distribution is usually also required. Rodrigues & Lindqvist Expires January 8, 2009 [Page 26] Internet-Draft TICTOC July 2008 A.2. Dedicated Wire-based Timing Transfer Methods The use of dedicated networks in the wide area does not scale well. Such services were available in the past, but for reasons of cost and accuracy have been superseded by GPS based solutions. In the local area, one new technique is emerging as a mechanism for time transport, namely DOCSIS Timing Interface(DTI). DTI was designed by DOCSIS for the distribution of time in a cable head-end in support of media access control. Time transfer is packet-based over a multi-stage hub and spoke dedicated network. It uses a single twisted-pair in half-duplex to eliminate inaccuracies due to the length differences between the pairs in a multi-pair cable. The DTI approach is applicable for special applications, but the need for a dedicated network imposes significant drawbacks for the general time transfer case. Synchronous Ethernet is a technique that has recently been approved by ITU-T, it provides frequency distribution over Ethernet links. Modern dedicated-media full-duplex Ethernet, in both copper and optical physical layer variants, transmits continuously. One can thus elect to derive the physical layer transmitter clock from a high quality frequency reference, instead of the conventional 100 ppm crystal-derived transmitter rate. The receiver at the other end of the link automatically locks onto the physical layer clock of the received signal, and thus itself gain access to a highly accurate and stable frequency reference. Then, in TDM fashion, this receiver could lock the transmission clock of its other ports to this frequency reference. Apart from some necessary higher layer packet based configuration and OAM operations to transport synchronization status messaging, the solution is entirely physical layer, and has no impact on higher layers. At first sight it would seem that the only application of synchronous Ethernet was in frequency transfer (it has no intrinsic time transfer mechanism). However, the quality of packet-based time transfer mechanism can be considerably enhanced if used in conjunction with synchronous Ethernet as a frequency reference. A.3. Transfer Using Packet Networks When using a PSN to transfer timing, a server sends timing information in the form of packets to one or multiple clients. When there are multiple clients, the timing packets may be multicast. Software/hardware in the client recovers the frequency and/or time of the server based on the packet arrival time and the packet contents. Rodrigues & Lindqvist Expires January 8, 2009 [Page 27] Internet-Draft TICTOC July 2008 There are two well-known protocols capable of running over a general- purpose packet network, NTP [RFC1305], and IEEE 1588 [1588]. NTP is the product of the IETF, and is currently undergoing revision to version 4. IEEE 1588 (a product of the IEEE Test and Measurement community) is specified in a limited first version, and the second version (1588v2)was approved recently. It is important that NTP, IEEE-1588 or any other future packet based time transfer mechanism do not break each other if they run in the same network. A.3.1. NTP summary description NTP is widely deployed, but existing implementations deliver accuracy on the order of 10 milliseconds. This accuracy is not adequate for the applications described above. Current NTP suffers from the fact that it was designed to operate over the Internet, and the routers and switches make no special concessions to NTP for preservation of time transfer accuracy. Furthermore, typical update rates are low and can not be significantly increased due to scalability issues in the server. In addition most NTP time servers and time receivers have a relatively unsophisticated implementation that further degrades the final time quality. However, proprietary NTP implementations that use other algorithms and update-rates have proved that NTP packet formats can be used for higher accuracy. A.3.2. IEEE1588 summary description IEEE 1588v1 was a time transfer protocol that exclusively used a fairly crude multicast technique. It is widely anticipated that wide scale deployment of IEEE1588 will be based on 1588v2. The information exchange component of IEEE 1588 is a protocol known as Precision Time Protocol (PTP). IEEE 1588v2 can be considered to consist of several components: 1. A configuration and control protocol 2. A time transfer protocol 3. A time correction protocol 4. Physical mapping The configuration and control protocol is based on the multicast approach of IEEE1588 v1 (multicast IP with recommended TTL=1, UDP, IEEE1588 payload with equipment identifier in the payload). The rationale for this approach was that the equipment needed to be "plug Rodrigues & Lindqvist Expires January 8, 2009 [Page 28] Internet-Draft TICTOC July 2008 and play" (no configuration), was required to map to physical media other than Ethernet, and had to have a very low memory and processor footprint. IEEE1588 v2 includes Unicast messages. The time transfer protocol is a standard two-way time transfer approach used in other packet-based approaches. Like all such approaches it is subject to inaccuracies due to variable store and forward delays in the packet switches, and due to the assumption of symmetric propagation delays. For IEEE1588 v2, the time transfer packets (in both directions) may be operated in a multicast or unicast mode. The time correction protocol is used to correct for propagation, store and forward delays in the packet switches. This again may be operated multicast or unicast. This mechanism requires some level of hop-by-hop hardware support. This mechanism may also be considered a concept in its own right and may be adapted to enhance other packet time transfer protocols such as NTP. The base 1588 specification describes how the PTP operates over the Ethernet/IP/UDP protocol stack. IEEE1588 v2 includes annexes that describe PTP operation over pure layer 2 Ethernet, and over a number of specialist media. The mappings of interest for telecommunications are PTP over UDP/IP, PTP over MPLS , and perhaps PTP over Ethernet, all in unicast mode only. Issues of a suitable control management and OAM environment for these applications are largely in abeyance, as are considerations about the exact nature of the network environment. It is also worth noting the existence of a second IEEE effort, IEEE 802.1AS. This group is specifying the protocol and procedures to ensure synchronization across Bridged and Virtual Bridged Local Area Networks for time sensitive applications such as audio and video. For these LAN media the transmission delays are assumed to be fixed and symmetrical. IEEE 802.1AS specifies the use of IEEE 1588 specifications where applicable in the context of IEEE Standards 802.1D and 802.1Q. Synchronization to an externally provided timing signal (e.g., a recognized timing standard such as UTC or TAI) is not part of this standard but is not precluded. IEEE 802.1AS will specify how stations attached to bridged LANs to meet the respective jitter, wander, and time synchronization requirements for time- sensitive applications. Appendix B. Other Forums Working in this Problem Space The NTP WG is the IETF group working on time distribution, but is Rodrigues & Lindqvist Expires January 8, 2009 [Page 29] Internet-Draft TICTOC July 2008 presently only documenting NTPv4 and is not working on new algorithms or protocols. It is expected that many participants of the NTP WG will participate in the TICTOC effort. The PWE3 WG has discussed frequency distribution for the TDM PW application, however it is not chartered to develop protocols for this purpose. It is expected that participants of the PWE3 WG who were active in the TDM PW discussions will participate in the TICTOC effort. The IEEE 1588 approved a new version of the IEEE 1588 protocol that will run over more types of PSNs. The protocol to be specified contains elements that will be of use in an IETF environment, but is unlikely to be regarded as being a complete, robust solution in such an environment. If the IEEE 1588 structure is deemed to be a suitable platform, then the IETF could contribute an Internet profile, including a complete distributed systems environment suitable for our purposes. Alternatively, the IETF could perhaps borrow some of the delay correction mechanisms and incorporate them into a development of a new version of NTP. In addition, IEEE 802.1AS is working on Timing and Synchronization for Time-Sensitive Applications in Bridged Local Area Networks, basing itself on the IEEE 1588 standard. ITU-T SG15 Question 13 has produced Recommendation G.8261 "Timing and synchronization aspects in packet networks" [G8261]. This Recommendation defines requirements for various scenarios, outlines the functionality of frequency distribution elements, and provides measurement guidelines. It does not specify algorithms to be used for attaining the performance needed. ITU-T has also consented G.8262 "Timing Characteristics of Synchronous Ethernet Equipment Slave Clock (EEC)" [G8262], and G.8264 "Distribution of timing through packet networks" [G8264]. G.8262 specifies the requirements for Synchronous Ethernet clocks and G.8264 defines the protocol for Synchronization Status Message (SSM) for Synchronous Ethernet. To date the ITU-T has focused on Ethernet infrastructure, but this is likely to extend to an MPLS environment. Two new work items, G.paclock.bis and G.pacmod.bis extend the work, and in particular, G.pacmod.bis intends to introduce time transfer. The scope for G.paclock.bis is to define the requirements for packet-based clocks. This is an area where the IETF, with its expertise in IP and MPLS networks, may co-operate with the ITU. Rodrigues & Lindqvist Expires January 8, 2009 [Page 30] Internet-Draft TICTOC July 2008 Authors' Addresses Silvana Rodrigues Zarlink Semiconductor 400 March Road Ottawa K2K 3H4 Canada Phone: +1 613 2707258 Email: silvana.rodrigues@zarlink.com Kurti Erik Lindqvist Netnod Bellmansgatan 30 Stockholm S-118 47 Sweden Phone: +46 708 30 60 01 Email: kurtis@kurtis.pp.se Rodrigues & Lindqvist Expires January 8, 2009 [Page 31] Internet-Draft TICTOC July 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Rodrigues & Lindqvist Expires January 8, 2009 [Page 32]