TICTOC S. Rodrigues
Internet-Draft Zarlink Semiconductor
Intended status: Informational K. Lindqvist
Expires: September 3, 2009 Netnod
March 02, 2009
TICTOC Requirement
draft-rodrigues-lindqvist-tictoc-req-02.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and 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 September 3, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
Distribution of high precision time and frequency over the Internet
and special purpose IP networks is becoming more and more needed as
Rodrigues & Lindqvist Expires September 3, 2009 [Page 1]
Internet-Draft TICTOC March 2009
IP networks replace legacy networks and as new applications with need
for frequency and time are developed on the Internet. The IETF
formed the TICTOC working group to address the problem and perform an
analysis on existing solutions and the needs. This document
summarizes application needs, as described and agreed on at an TICTOC
interim meeting held in Paris from June 16 to 18, 2008.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Applications Requirements . . . . . . . . . . . . . . . . . . 3
3.1. Cellular Backhauling . . . . . . . . . . . . . . . . . . . 3
3.1.1. Cellular Backaul Requirements . . . . . . . . . . . . 4
3.2. Circuit Emulation . . . . . . . . . . . . . . . . . . . . 9
3.2.1. Circuit Emulation Requirements . . . . . . . . . . . . 9
3.3. Test and Measurement . . . . . . . . . . . . . . . . . . . 11
3.3.1. Test and Measurement Requirements . . . . . . . . . . 12
3.4. Industrial Automation . . . . . . . . . . . . . . . . . . 15
3.4.1. Industrial Automation Requirements . . . . . . . . . . 16
3.5. ToD/ Internet . . . . . . . . . . . . . . . . . . . . . . 18
3.5.1. ToD/Internet Requirements . . . . . . . . . . . . . . 19
3.6. Networking . . . . . . . . . . . . . . . . . . . . . . . . 21
3.6.1. Networking Requirements . . . . . . . . . . . . . . . 21
3.7. Legal Time . . . . . . . . . . . . . . . . . . . . . . . . 23
3.7.1. Legal Time Requirements . . . . . . . . . . . . . . . 23
3.8. Metrology . . . . . . . . . . . . . . . . . . . . . . . . 25
3.8.1. Metrology Requirements . . . . . . . . . . . . . . . . 25
3.9. Sensor . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.9.1. Sensors Requirements . . . . . . . . . . . . . . . . . 27
4. Network Dependencies . . . . . . . . . . . . . . . . . . . . . 29
5. Network Topology . . . . . . . . . . . . . . . . . . . . . . . 30
6. Security Considerations . . . . . . . . . . . . . . . . . . . 30
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30
9. Informative References . . . . . . . . . . . . . . . . . . . . 31
Appendix A. Existing Time and Frequency Transfer Mechanisms . . . 31
A.1. Radio-based Timing Transfer Methods . . . . . . . . . . . 32
A.2. Dedicated Wire-based Timing Transfer Methods . . . . . . . 33
A.3. Transfer Using Packet Networks . . . . . . . . . . . . . . 34
A.3.1. NTP summary description . . . . . . . . . . . . . . . 34
A.3.2. IEEE1588 summary description . . . . . . . . . . . . . 34
Appendix B. Other Forums Working in this Problem Space . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37
Rodrigues & Lindqvist Expires September 3, 2009 [Page 2]
Internet-Draft TICTOC March 2009
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
requirements where 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 considered are:
o GSM
o Mobile 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 September 3, 2009 [Page 3]
Internet-Draft TICTOC March 2009
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 Backaul Requirements
The requirements for the Cellular Backhauling is summarized in the
table 1.
Editor's note: This table was discussed at the Dublin meeting; need
input from the group to fill in the blanks.
Rodrigues & Lindqvist Expires September 3, 2009 [Page 4]
Internet-Draft TICTOC March 2009
Cellular Backhaul Requirements
+-----------+-------+--------+---------+--------+---------+---------+
| Requireme | GSM/U | UMTS | Mobile | LTE | CDMA200 | TD-SCDM |
| nts | MTS | TDD | Wimax | | 0 | A |
| | FDD | | (5) | | | |
+-----------+-------+--------+---------+--------+---------+---------+
| Synchroni | frequ | phase | phase | phase | phase | phase |
| zation | ency | alignm | alignme | alignm | alignme | alignme |
| type | | ent | nt | ent | nt | nt |
| (e.g. | | | | | | |
| time, | | | | | | |
| frequenc | | | | | | |
| yor phase | | | | | | |
| ) | | | | | | |
| --------- | ----- | ------ | ------ | ------ | ------ | ------- |
| Frequency | 50-25 | 50-250 | 15 ppb | 50-250 | 50-250 | 50-250 |
| stability | 0ppb | ppb | | ppb | ppb (1) | ppb (1) |
| | (1) | (1) | | (1) | | |
| --------- | ----- | ------ | ------ | ------ | ------ | ------- |
| Frequency | 50-25 | 50-250 | 15 ppb | 50-250 | 50-250 | 50-250 |
| accuracy | 0ppb | ppb | | ppb | ppb (1) | ppb (1) |
| | (1) | (1) | | (1) | | |
| --------- | ----- | ------ | ------ | ------ | ------ | ------- |
| Uncalibra | | | | | | |
| ted | | | | | | |
| time/tim | | | | | | |
| estabilit | | | | | | |
| y | | | | | | |
| --------- | ----- | ------ | ------ | ------ | ------ | ------- |
| Uncalibra | NA | The | The | From | The | The |
| ted | | phase | phase | 1us to | pilot | phase |
| time/tim | | alignm | alignme | 50us | time | alignme |
| eaccuracy | | ent of | nt of | (2, 3) | alignme | nt of |
| | | neigh | neighb | | nt erro | neighb |
| | | bourin | ouring | | rshould | ouring |
| | | g base | base | | be les | base |
| | | stat | stati | | sthan | stati |
| | | ions | onsshal | | 3us an | onsshal |
| | | sha | l be | | dshall | l be |
| | | ll be | with | | be les | with |
| | | wit | in 1 us | | sthan | in 3us |
| | | hin2.5 | | | 10us(c | |
| | | us. | | | ompared | |
| | | | | | to | |
| | | | | | syste | |
| | | | | | m time) | |
| --------- | ----- | ------ | ------ | ------ | ------ | ------- |
Rodrigues & Lindqvist Expires September 3, 2009 [Page 5]
Internet-Draft TICTOC March 2009
| Stabiliza | As | As | As soon | As | As soon | As soon |
| tion time | soon | soon | as | soon | as | as |
| | as | as | possibl | as | possibl | possibl |
| | possi | possib | e | possib | e | e |
| | ble | le | | le | | |
| --------- | ----- | ------ | ------ | ------ | ------ | ------- |
| Jitter on | Depen | Depend | | Depend | Depends | Depends |
| recovered | ds on | son th | | son th | on the | on the |
| timing | the | eoscil | | eoscil | oscilla | oscilla |
| signal | osci | lator | | lator | tor | tor |
| | llato | stab | | stab | stabil | stabil |
| | r sta | ility | | ility | ity | ity |
| | bilit | | | | | |
| | y | | | | | |
| --------- | ----- | ------ | ------ | ------ | ------ | ------- |
| Wander on | Depen | Depend | | Depend | Depends | Depends |
| recovered | ds on | son th | | son th | on the | on the |
| timing | the | eoscil | | eoscil | oscilla | oscilla |
| signal | osci | lator | | lator | tor | tor |
| | llato | stab | | stab | stabil | stabil |
| | r sta | ility | | ility | ity | ity |
| | bilit | | | | | |
| | y | | | | | |
| --------- | ----- | ------ | ------ | ------ | ------ | ------- |
| What | | | | | | |
| expected | | | | | | |
| network | | | | | | |
| character | | | | | | |
| istics | | | | | | |
| (WAN, | | | | | | |
| LAN, MAN | | | | | | |
| ,private, | | | | | | |
| public, | | | | | | |
| etc)? | | | | | | |
| --------- | ----- | ------ | ------ | ------ | ------ | ------- |
Rodrigues & Lindqvist Expires September 3, 2009 [Page 6]
Internet-Draft TICTOC March 2009
| Does the | No | No (4) | No (4) | No (4) | No (4) | No (4) |
| applicati | (4) | | | | | |
| on | | | | | | |
| requires | | | | | | |
| security | | | | | | |
| ?(if so, | | | | | | |
| which | | | | | | |
| one: | | | | | | |
| authenti | | | | | | |
| cation, | | | | | | |
| encrypt | | | | | | |
| ion, | | | | | | |
| tracea | | | | | | |
| bility, | | | | | | |
| other | | | | | | |
| s) | | | | | | |
| --------- | ----- | ------ | ------ | ------ | ------ | ------- |
| Reliabili | | | | | | |
| ty | | | | | | |
| requirem | | | | | | |
| ents (e.g | | | | | | |
| . fault | | | | | | |
| toleran | | | | | | |
| ce) | | | | | | |
| --------- | ----- | ------ | ------ | ------ | ------ | ------- |
| Traceabil | | | | | System | |
| ity to a | | | | | Time, | |
| specific | | | | | synchro | |
| clock, | | | | | nous to | |
| clock | | | | | UTC | |
| quality, | | | | | time | |
| path, | | | | | (excep | |
| time | | | | | tfor | |
| | | | | | leap | |
| | | | | | second | |
| | | | | | s)and | |
| | | | | | uses | |
| | | | | | the | |
| | | | | | same | |
| | | | | | time | |
| | | | | | origi | |
| | | | | | n as GP | |
| | | | | | S time. | |
| | | | | | (6) | |
| --------- | ----- | ------ | ------ | ------ | ------ | ------- |
| Holdover | | | | | | |
| requireme | | | | | | |
| nt | | | | | | |
Rodrigues & Lindqvist Expires September 3, 2009 [Page 7]
Internet-Draft TICTOC March 2009
| --------- | ----- | ------ | ------ | ------ | ------ | ------- |
| Cost | | | | | | |
| (consumer | | | | | | |
| , | | | | | | |
| enterpri | | | | | | |
| se, | | | | | | |
| carrier | | | | | | |
| ) | | | | | | |
| --------- | ----- | ------ | ------ | ------ | ------ | ------- |
| Auto-conf | No | No | No | No | No | No |
| iguration | | | | | | |
| (plug an | | | | | | |
| dplay) | | | | | | |
| --------- | ----- | ------ | ------ | ------ | ------ | ------- |
| Manageabi | | | | | | |
| lity (how | | | | | | |
| much | | | | | | |
| effort | | | | | | |
| the | | | | | | |
| operator | | | | | | |
| needs to | | | | | | |
| put in t | | | | | | |
| omanage | | | | | | |
| this | | | | | | |
| applicat | | | | | | |
| ion?) - | | | | | | |
| In-band | | | | | | |
| or | | | | | | |
| out-of- | | | | | | |
| band of | | | | | | |
| protoc | | | | | | |
| ol (MIBs? | | | | | | |
| ) | | | | | | |
| --------- | ----- | ------ | ------ | ------ | ------ | ------- |
| Scale and | | | | | | |
| scalabili | | | | | | |
| ty | | | | | | |
+-----------+-------+--------+---------+--------+---------+---------+
Table 1
Note (1) This is requirement in the air interface. In practice more
accurate frequency is required at the input. For example OBSAI RP1
defines 16 ppb
Note (2) : no precise phase accuracy requirements defined in
standard. The actual requirement will depend on implementation and
network scenario.
Rodrigues & Lindqvist Expires September 3, 2009 [Page 8]
Internet-Draft TICTOC March 2009
Note (3) : In general LTE TDD systems may be defined to operate with
10-50 microseconds phase accuracy by making some limitations on the
deployment (e.g. cell range), and radio frame configuration, however
further investigation are required. When no assumption possible,
microsecond or sub-microsecond requirement would apply.
Note (4) assumes a private network
Note (5) 1024 OFDM carriers, BW 10 MHz, Cyclic prefix ratio 1:8, RF
carrier 3.5 GHz
Note (6) 3GPP2, C.S0010-B version 2.0, 2004
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 [RFC5087]. 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.
3.2.1. Circuit Emulation Requirements
The requirements for the Circuit Emulation is summarized in the table
2.
Rodrigues & Lindqvist Expires September 3, 2009 [Page 9]
Internet-Draft TICTOC March 2009
Editor's note: This table was discussed at the Dublin meeting; need
input from the group to fill in the blanks.
Circuit Emulation
+-------------------------------------+-----------------------------+
| Requirements | Circuit Emulation |
+-------------------------------------+-----------------------------+
| Synchronization type (e.g. time, | frequency |
| frequency or phase) | |
| --------------------------- | --------------------------- |
| Frequency stability | N/A |
| --------------------------- | --------------------------- |
| Frequency accuracy | N/A |
| --------------------------- | --------------------------- |
| Uncalibrated time/time stability | N/A |
| --------------------------- | --------------------------- |
| Uncalibrated time/time accuracy | N/A |
| --------------------------- | --------------------------- |
| Stabilization time | |
| --------------------------- | --------------------------- |
| Jitter on recovered timing signal | G.8261/G.823/G.824 |
| --------------------------- | --------------------------- |
| Wander on recovered timing signal | G.8261/G.823/G.824 |
| --------------------------- | --------------------------- |
| What expected network | |
| characteristics (WAN, LAN, MAN, | |
| private, public, etc)? | |
| --------------------------- | --------------------------- |
| Does the application requires | No |
| security? (if so, which one: | |
| authentication, encryption, | |
| traceability, others) | |
| --------------------------- | --------------------------- |
| Reliability requirements (e.g. | N/A |
| fault tolerance) | |
| --------------------------- | --------------------------- |
| Traceability to a specific clock, | |
| clock quality, path, time | |
| --------------------------- | --------------------------- |
| Holdover requirement | Yes |
| --------------------------- | --------------------------- |
| Cost (consumer, enterprise, | |
| carrier) | |
| --------------------------- | --------------------------- |
| Auto-configuration (plug and play) | No |
| --------------------------- | --------------------------- |
Rodrigues & Lindqvist Expires September 3, 2009 [Page 10]
Internet-Draft TICTOC March 2009
| Manageability (how much effort the | |
| operator needs to put in to manage | |
| this application?) - In-band or | |
| out-of-band of protocol (MIBs?) | |
| --------------------------- | --------------------------- |
| Scale and scalability | |
+-------------------------------------+-----------------------------+
Table 2
3.3. Test and Measurement
Note: The application information and the requirements for this
section was provided by the LXI Consortium Technical Committee.
In the test and measurement 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.
Test and Measurement (T&M) is a very diverse industry and as would be
expected, requirements vary widely with the application. However the
vast majority of the newer instruments and systems make use of LAN
technology and many have a connection to the local enterprise network
for data transfer, or monitoring and control.
Because of the increasingly heavy use of LAN technology in T&M
instruments and systems, we are dependent on the availability of
network infrastructure, e.g. bridges, and low level silicon, e.g.
PHYs and PHY/MAC, that supports not only T&M connectivity (data
transport) but increasingly timing and frequency transfer support as
well.
Furthermore T&M is going to require this support not only for the
existing 10/100/1000 BaseT technology but on the newer high
throughput LAN technology under development. While most instruments
produce data at modest rates, many can source or sink data at rates
well in excess of 40Gsamples/s. In addition, the time and phase
coherence requirements on the data transport, e.g. LAN, typically
are tighter on the high data rate instruments.
The other major headache in the use of LAN in T&M is latency and
jitter because it compromises the determinism needed for some
applications. One of the promises of LAN-based precise time is that
in many circumstances precise time can be used to overcome latency
Rodrigues & Lindqvist Expires September 3, 2009 [Page 11]
Internet-Draft TICTOC March 2009
issues. For example, for many data acquisition applications the
ability to precisely and accurately timestamp data at the collection
point makes LAN latency and jitter a non-issue.
Many T&M applications are localized, often to a bench or rack of
equipment. The LAN will be local and private although there is often
a connection to the local enterprise network. It is not uncommon in
such applications to include a rubidium oscillator to provide a
phase-coherent stable frequency source to critical instrumentation
such as counters, scopes, signal generators and analyzers. In many
cases the LAN, in principle, could fill the frequency distribution
role if the LAN technology supported it. In these systems time
transfer is becoming important first for timestamping data to
facilitate data management and post acquisition processing, and in
some cases as part of the control structure. The precise time
specifications vary from milliseconds for general applications to
nanoseconds for the most critical.
There is an important class of applications where time, and sometimes
frequency traceable to international standards is required, generally
due to regulatory issues, e.g. testing of medical, safety critical or
military devices. The ability to deliver traceable time and
frequency over the network to the enterprise would be a big help in
these applications.
There are also T&M applications that are widely distributed due to
the nature of the device or system being measured. Environmental
measurement systems, surveillance, SCADA systems, and the
telecommunication system itself are examples. Timestamping data is
an essential requirement to overcome the communication latency and
jitter issues. The specific timing requirements clearly cover a wide
range. Environmental and SCADA is typically a ms. However to really
instrument a telecom system will require timing at least on the order
of a packet length or better. Even more extreme are timing for RF
test ranges (which can cover several miles), long-baseline
interferometry, and RF surveillance where the time accuracy must be
on the order of ns. In some cases public networks will be used if
the time distribution is adequate.
3.3.1. Test and Measurement Requirements
The requirements for the Test and Measurement are summarized in the
table 4. Where appropriate both the low and high end of the
requirements spectrum are given to illustrate the breadth of
requirements for the application areas discussed. Note that
typically the applications with the most demanding requirements are
also the high dollar value applications and in many cases the most
critical in terms of the cost of failure, e.g. failure of a
Rodrigues & Lindqvist Expires September 3, 2009 [Page 12]
Internet-Draft TICTOC March 2009
surveillance system, monitoring of telecommunications, military test
systems where either the operational cost of downtime or the cost of
the device being tested are high.
Test and Measurement
+-----------------------------+-------------------------------------+
| Requirements | Remote Telco |
+-----------------------------+-------------------------------------+
| Synchronization type (e.g. | Time: ms to ns- high value |
| time, frequency or phase) | applications will open up as this |
| | spec improves. Frequency: part in |
| | 109 minimum, 1011 desirable and |
| | with the lowest phase noise |
| | obtainable for critical |
| | applications. |
| --------------------------- | --------------------------- |
| Frequency stability | When applicable (high end RF) the |
| | lowest phase noise possible in the |
| | short term, long term consistent |
| | with accuracy and calibration |
| | intervals- better than 1 ppm/year |
| | desirable |
| --------------------------- | --------------------------- |
| Frequency accuracy | Generally consistency across the |
| | system is more important than |
| | absolute accuracy. For calibration |
| | applications at least 1ppm |
| --------------------------- | --------------------------- |
| Uncalibrated time/time | Short term from fractional ms to ns |
| stability | or better. Long term comparable to |
| | GPS distributed time. |
| --------------------------- | --------------------------- |
| Uncalibrated time/time | Usually self-consistency |
| accuracy | requirements are tighter: ms to ns |
| | system wide. Absolute accuracy |
| | (traceable) is probably ms to 100 |
| | ns. |
| --------------------------- | --------------------------- |
| Stabilization time | Not usually important. Many time |
| | critical instruments themselves |
| | need minutes to hours to stabilize. |
| | However stabilization times greater |
| | than a few minutes will reduce the |
| | number of practical wide-area |
| | applications |
| --------------------------- | --------------------------- |
Rodrigues & Lindqvist Expires September 3, 2009 [Page 13]
Internet-Draft TICTOC March 2009
| Jitter on recovered timing | In the most critical applications, |
| signal | the lowest phase noise achievable, |
| | in terms of TIE less than the |
| | stability requirement. |
| --------------------------- | --------------------------- |
| Wander on recovered timing | Modest for most measurements. For |
| signal | surveillance, long baseline, and |
| | similar less than the required |
| | stability over the duration of the |
| | test. |
| --------------------------- | --------------------------- |
| What expected network | Most are private or enterprise LAN. |
| characteristics (WAN, LAN, | Large scale applications will |
| MAN, private, public, etc)? | benefit from using the public |
| | telecommunications networks. |
| --------------------------- | --------------------------- |
| Does the application | To date timing security |
| requires security? (if so, | requirements have been rare with |
| which one: authentication, | the possible exception of |
| encryption, traceability, | measurement systems with legal |
| others) | requirements. Data security is |
| | more important when the public |
| | networks are involved. |
| --------------------------- | --------------------------- |
| Reliability requirements | Has not been an issue to date in |
| (e.g. fault tolerance) | most systems. |
| --------------------------- | --------------------------- |
| Traceability to a specific | Traceability to a path means that |
| clock, clock quality, path, | if there is on-path support we want |
| time | to trace the path. Can also help |
| | to avoid time loops. Traceability |
| | is needed to establish NIST |
| | traceability. T&M will expect that |
| | public networks solve the timing |
| | loop problem. T&M end systems are |
| | typically strictly hierarchical |
| | networks without multiple paths. |
| --------------------------- | --------------------------- |
| Holdover requirement | Has not been an issue to date- but |
| | as T&M increasingly is integrated |
| | into operational systems it will |
| | become more important. Telecom |
| | requirements are probably |
| | sufficient. |
| --------------------------- | --------------------------- |
| Cost (consumer, enterprise, | In most T&M systems component cost |
| carrier) | is very important. In many, |
| | operational cost is important. |
Rodrigues & Lindqvist Expires September 3, 2009 [Page 14]
Internet-Draft TICTOC March 2009
| --------------------------- | --------------------------- |
| Auto-configuration (plug | Very important. T&M customers to |
| and play) | date would prefer to avoid any |
| | network related configuration. |
| --------------------------- | --------------------------- |
| Manageability (how much | As little as possible operator |
| effort the operator needs | interaction. However visibility |
| to put in to manage this | into system performance, including |
| application?) - In-band or | timing, is very important both |
| out-of-band of protocol | operationally and during debug and |
| (MIBs?) | commissioning. |
| --------------------------- | --------------------------- |
| Scale and scalability | T&M systems range from small |
| | systems with perhaps 2 or 3 |
| | instruments to large scale data |
| | acquisition with thousands of end |
| | devices. The physical scale of T&M |
| | systems varies widely from a few |
| | instruments on a bench to a few |
| | instruments separated by miles, and |
| | from several thousand instruments |
| | and sensors concentrated on a local |
| | device such as a jet engine to |
| | several thousand spread over many |
| | miles in environmental monitoring, |
| | or monitoring the |
| | telecommunications system. In all |
| | cases it is very common for these |
| | systems to grow as additional test |
| | requirements are imposed so |
| | scalability is importan |
+-----------------------------+-------------------------------------+
Table 3
3.4. Industrial Automation
In the 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. One example of
this tendency is 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
Rodrigues & Lindqvist Expires September 3, 2009 [Page 15]
Internet-Draft TICTOC March 2009
degradation in quality.
3.4.1. Industrial Automation Requirements
The requirements for the Industrial Automation are summarized in the
table 4.
Editor's note: This table was discussed at the Dublin meeting; need
input from the group to fill in the blanks.
Rodrigues & Lindqvist Expires September 3, 2009 [Page 16]
Internet-Draft TICTOC March 2009
Industrial Automation
+-------------------------------------+-----------------------------+
| Requirements | Remote Telco |
+-------------------------------------+-----------------------------+
| Synchronization type (e.g. time, | |
| frequency or phase) | |
| --------------------------- | --------------------------- |
| Frequency stability | |
| --------------------------- | --------------------------- |
| Frequency accuracy | |
| --------------------------- | --------------------------- |
| Uncalibrated time/time stability | |
| --------------------------- | --------------------------- |
| Uncalibrated time/time accuracy | |
| --------------------------- | --------------------------- |
| Stabilization time | |
| --------------------------- | --------------------------- |
| Jitter on recovered timing signal | |
| --------------------------- | --------------------------- |
| Wander on recovered timing signal | |
| --------------------------- | --------------------------- |
| What expected network | |
| characteristics (WAN, LAN, MAN, | |
| private, public, etc)? | |
| --------------------------- | --------------------------- |
| Does the application requires | |
| security? (if so, which one: | |
| authentication, encryption, | |
| traceability, others) | |
| --------------------------- | --------------------------- |
| Reliability requirements (e.g. | |
| fault tolerance) | |
| --------------------------- | --------------------------- |
| Traceability to a specific clock, | |
| clock quality, path, time | |
| --------------------------- | --------------------------- |
| Holdover requirement | |
| --------------------------- | --------------------------- |
| Cost (consumer, enterprise, | |
| carrier) | |
| --------------------------- | --------------------------- |
| Auto-configuration (plug and play) | |
| --------------------------- | --------------------------- |
| Manageability (how much effort the | |
| operator needs to put in to manage | |
| this application?) - In-band or | |
| out-of-band of protocol (MIBs?) | |
Rodrigues & Lindqvist Expires September 3, 2009 [Page 17]
Internet-Draft TICTOC March 2009
| --------------------------- | --------------------------- |
| Scale and scalability | |
+-------------------------------------+-----------------------------+
Table 4
3.5. ToD/ Internet
General time distribution 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.
Internet TOD is used is important to the maintenance of IT
infrastrucute in an organization. Generally the larger an
organization becomes, the more important time synchronization is.
Time synchronization is critical for the following: 1. Server and
router log file entry time tags 2. "Date modified" attributes for
files 3. Chron job scheduling 4. Security protocol with limited
time windows for key exchange.
Server and Router log file time tag accuracy is essential to network
diagnostic tools. Such tools are used to determine the root cause of
a network failure or security breach. Often it is important to
determine the order in which certain events occur amongst a number of
network devices. The "Date modified" fields of files may also be
part of this type of analysis.
Often Chron jobs perform operations on files depending on the times
in the "Date modified" attributes files. These files might reside on
more than one computer or server.
Many security protocols, such as Kerberos, depend on authentication
"tickets" which expire after a short time. This means that an
authenticating server gives a ticket to a client, which the client
can send to another server for some service which requires
authentication. The time limit is intended to reduce the threat of
the "Man in the middle attack." To work the two servers need to have
clocks synchronized to a time error which is smaller than the ticket
time out period. To increase security there is a desire to reduce
the ticket time interval. As the time interval becomes shorter the
need for server clock agreement is increased. The trend over time is
to reduce the ticket time out period.
Rodrigues & Lindqvist Expires September 3, 2009 [Page 18]
Internet-Draft TICTOC March 2009
3.5.1. ToD/Internet Requirements
The requirements for the ToD/Internet is summarized in the table 6.
Editor's note: This table was discussed at the Dublin meeting; need
input from the group to fill in the blanks.
Rodrigues & Lindqvist Expires September 3, 2009 [Page 19]
Internet-Draft TICTOC March 2009
ToD/Internet Requirements
+---------------------------------+---------------------------------+
| Requirements | ToD/Internet |
+---------------------------------+---------------------------------+
| Synchronization type (e.g. | time |
| time, frequency or phase) | |
| --------------------------- | --------------------------- |
| Frequency stability | no requirement |
| --------------------------- | --------------------------- |
| Frequency accuracy | no requirement |
| --------------------------- | --------------------------- |
| Uncalibrated time/time | no requirement |
| stability | |
| --------------------------- | --------------------------- |
| Uncalibrated time/time accuracy | 10 ms |
| --------------------------- | --------------------------- |
| Stabilization time | 1 hour |
| --------------------------- | --------------------------- |
| Jitter on recovered timing | 100 ms |
| signal | |
| --------------------------- | --------------------------- |
| Wander on recovered timing | 10 ms |
| signal | |
| --------------------------- | --------------------------- |
| What expected network | All network types |
| characteristics (WAN, LAN, MAN, | |
| private, public, etc)? | |
| --------------------------- | --------------------------- |
| Does the application requires | Authentication sometimes used |
| security? (if so, which one: | |
| authentication, encryption, | |
| traceability, others) | |
| --------------------------- | --------------------------- |
| Reliability requirements (e.g. | high availability. Clients |
| fault tolerance) | must see multiple servers |
| --------------------------- | --------------------------- |
| Traceability to a specific | Not important |
| clock, clock quality, path, | |
| time | |
| --------------------------- | --------------------------- |
| Holdover requirement | 1 hour to 1 year. Depends on |
| | server redundancy architecture |
| --------------------------- | --------------------------- |
| Cost (consumer, enterprise, | 0 - $10,000 USD (1) |
| carrier) | |
| --------------------------- | --------------------------- |
Rodrigues & Lindqvist Expires September 3, 2009 [Page 20]
Internet-Draft TICTOC March 2009
| Auto-configuration (plug and | No |
| play) | |
| --------------------------- | --------------------------- |
| Manageability (how much effort | 30-90 minutes to configure a |
| the operator needs to put in to | new server, 5 minutes to |
| manage this application?) - | configure a new client. Almost |
| In-band or out-of-band of | no management after initial |
| protocol (MIBs?) | deployment. |
| --------------------------- | --------------------------- |
| Scale and scalability | system must cover entire IT |
| | infrastructure of organization. |
| | Any 1 server will cover 1 |
| | building or campus. |
+---------------------------------+---------------------------------+
Table 5
(1) The free option implies pointing all clients at ntp servers
available on the public internet.
3.6. Networking
Editor's note: need more info on this application.
3.6.1. Networking Requirements
The requirements for the Networking SLA and Network CDR are
summarized in the table 5.
Editor's note: This table was discussed at the Dublin meeting; need
input from the group to fill in the blanks.
Rodrigues & Lindqvist Expires September 3, 2009 [Page 21]
Internet-Draft TICTOC March 2009
Networking SLA and Network CDR Requirements
+--------------------------------+-------------------+--------------+
| Requirements | Networking SLA | Network CDR |
+--------------------------------+-------------------+--------------+
| Synchronization type (e.g. | | |
| time, frequency or phase) | | |
| ---------------------------- | ----------------- | ------------ |
| Frequency stability | | |
| ---------------------------- | ----------------- | ------------ |
| Frequency accuracy | | |
| ---------------------------- | ----------------- | ------------ |
| Uncalibrated time/time | | |
| stability | | |
| ---------------------------- | ----------------- | ------------ |
| Uncalibrated time/time | | |
| accuracy | | |
| ---------------------------- | ----------------- | ------------ |
| Stabilization time | | |
| ---------------------------- | ----------------- | ------------ |
| Jitter on recovered timing | | |
| signal | | |
| ---------------------------- | ----------------- | ------------ |
| Wander on recovered timing | | |
| signal | | |
| ---------------------------- | ----------------- | ------------ |
| What expected network | | |
| characteristics (WAN, LAN, | | |
| MAN, private, public, etc)? | | |
| ---------------------------- | ----------------- | ------------ |
| Does the application requires | | |
| security? (if so, which one: | | |
| authentication, encryption, | | |
| traceability, others) | | |
| ---------------------------- | ----------------- | ------------ |
| Reliability requirements (e.g. | | |
| fault tolerance) | | |
| ---------------------------- | ----------------- | ------------ |
| Traceability to a specific | | |
| clock, clock quality, path, | | |
| time | | |
| ---------------------------- | ----------------- | ------------ |
| Holdover requirement | | |
| ---------------------------- | ----------------- | ------------ |
| Cost (consumer, enterprise, | | |
| carrier) | | |
| ---------------------------- | ----------------- | ------------ |
Rodrigues & Lindqvist Expires September 3, 2009 [Page 22]
Internet-Draft TICTOC March 2009
| Auto-configuration (plug and | | |
| play) | | |
| ---------------------------- | ----------------- | ------------ |
| Manageability (how much effort | | |
| the operator needs to put in | | |
| to manage this application?) - | | |
| In-band or out-of-band of | | |
| protocol (MIBs?) | | |
| ---------------------------- | ----------------- | ------------ |
| Scale and scalability | | |
+--------------------------------+-------------------+--------------+
Table 6
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
traceable 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 Dublin meeting; need
input from the group to fill in the blanks.
Rodrigues & Lindqvist Expires September 3, 2009 [Page 23]
Internet-Draft TICTOC March 2009
Legal Time Requirements
+-------------------------------------+-----------------------------+
| Requirements | Legal Time |
+-------------------------------------+-----------------------------+
| Synchronization type (e.g. time, | |
| frequency or phase) | |
| --------------------------- | --------------------------- |
| Frequency stability | |
| --------------------------- | --------------------------- |
| Frequency accuracy | |
| --------------------------- | --------------------------- |
| Uncalibrated time/time stability | |
| --------------------------- | --------------------------- |
| Uncalibrated time/time accuracy | |
| --------------------------- | --------------------------- |
| Stabilization time | |
| --------------------------- | --------------------------- |
| Jitter on recovered timing signal | |
| --------------------------- | --------------------------- |
| Wander on recovered timing signal | |
| --------------------------- | --------------------------- |
| What expected network | |
| characteristics (WAN, LAN, MAN, | |
| private, public, etc)? | |
| --------------------------- | --------------------------- |
| Does the application requires | |
| security? (if so, which one: | |
| authentication, encryption, | |
| traceability, others) | |
| --------------------------- | --------------------------- |
| Reliability requirements (e.g. | |
| fault tolerance) | |
| --------------------------- | --------------------------- |
| Traceability to a specific clock, | |
| clock quality, path, time | |
| --------------------------- | --------------------------- |
| Holdover requirement | |
| --------------------------- | --------------------------- |
| Cost (consumer, enterprise, | |
| carrier) | |
| --------------------------- | --------------------------- |
| Auto-configuration (plug and play) | |
| --------------------------- | --------------------------- |
| Manageability (how much effort the | |
| operator needs to put in to manage | |
| this application?) - In-band or | |
| out-of-band of protocol (MIBs?) | |
Rodrigues & Lindqvist Expires September 3, 2009 [Page 24]
Internet-Draft TICTOC March 2009
| --------------------------- | --------------------------- |
| Scale and scalability | |
+-------------------------------------+-----------------------------+
Table 7
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 Dublin meeting; need
input from the group to fill in the blanks.
Rodrigues & Lindqvist Expires September 3, 2009 [Page 25]
Internet-Draft TICTOC March 2009
Metrology Requirements
+-------------------------------------+-----------------------------+
| Requirements | Metrology |
+-------------------------------------+-----------------------------+
| Synchronization type (e.g. time, | |
| frequency or phase) | |
| --------------------------- | --------------------------- |
| Frequency stability | |
| --------------------------- | --------------------------- |
| Frequency accuracy | |
| --------------------------- | --------------------------- |
| Uncalibrated time/time stability | |
| --------------------------- | --------------------------- |
| Uncalibrated time/time accuracy | |
| --------------------------- | --------------------------- |
| Stabilization time | |
| --------------------------- | --------------------------- |
| Jitter on recovered timing signal | |
| --------------------------- | --------------------------- |
| Wander on recovered timing signal | |
| --------------------------- | --------------------------- |
| What expected network | |
| characteristics (WAN, LAN, MAN, | |
| private, public, etc)? | |
| --------------------------- | --------------------------- |
| Does the application requires | |
| security? (if so, which one: | |
| authentication, encryption, | |
| traceability, others) | |
| --------------------------- | --------------------------- |
| Reliability requirements (e.g. | |
| fault tolerance) | |
| --------------------------- | --------------------------- |
| Traceability to a specific clock, | |
| clock quality, path, time | |
| --------------------------- | --------------------------- |
| Holdover requirement | |
| --------------------------- | --------------------------- |
| Cost (consumer, enterprise, | |
| carrier) | |
| --------------------------- | --------------------------- |
| Auto-configuration (plug and play) | |
| --------------------------- | --------------------------- |
| Manageability (how much effort the | |
| operator needs to put in to manage | |
| this application?) - In-band or | |
| out-of-band of protocol (MIBs?) | |
Rodrigues & Lindqvist Expires September 3, 2009 [Page 26]
Internet-Draft TICTOC March 2009
| --------------------------- | --------------------------- |
| Scale and scalability | |
+-------------------------------------+-----------------------------+
Table 8
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 Dublin meeting; need
input from the group to fill in the blanks.
Rodrigues & Lindqvist Expires September 3, 2009 [Page 27]
Internet-Draft TICTOC March 2009
Sensor Requirements
+-------------------------------------+-----------------------------+
| Requirements | Sensor |
+-------------------------------------+-----------------------------+
| Synchronization type (e.g. time, | |
| frequency or phase) | |
| --------------------------- | --------------------------- |
| Frequency stability | |
| --------------------------- | --------------------------- |
| Frequency accuracy | |
| --------------------------- | --------------------------- |
| Uncalibrated time/time stability | |
| --------------------------- | --------------------------- |
| Uncalibrated time/time accuracy | |
| --------------------------- | --------------------------- |
| Stabilization time | |
| --------------------------- | --------------------------- |
| Jitter on recovered timing signal | |
| --------------------------- | --------------------------- |
| Wander on recovered timing signal | |
| --------------------------- | --------------------------- |
| What expected network | |
| characteristics (WAN, LAN, MAN, | |
| private, public, etc)? | |
| --------------------------- | --------------------------- |
| Does the application requires | |
| security? (if so, which one: | |
| authentication, encryption, | |
| traceability, others) | |
| --------------------------- | --------------------------- |
| Reliability requirements (e.g. | |
| fault tolerance) | |
| --------------------------- | --------------------------- |
| Traceability to a specific clock, | |
| clock quality, path, time | |
| --------------------------- | --------------------------- |
| Holdover requirement | |
| --------------------------- | --------------------------- |
| Cost (consumer, enterprise, | |
| carrier) | |
| --------------------------- | --------------------------- |
| Auto-configuration (plug and play) | |
| --------------------------- | --------------------------- |
| Manageability (how much effort the | |
| operator needs to put in to manage | |
| this application?) - In-band or | |
| out-of-band of protocol (MIBs?) | |
Rodrigues & Lindqvist Expires September 3, 2009 [Page 28]
Internet-Draft TICTOC March 2009
| --------------------------- | --------------------------- |
| Scale and scalability | |
+-------------------------------------+-----------------------------+
Table 9
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. Therefore, time transfer protocols should not assume
the availability of on path support, but utilizes 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.
Rodrigues & Lindqvist Expires September 3, 2009 [Page 29]
Internet-Draft TICTOC March 2009
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.
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
Rodrigues & Lindqvist Expires September 3, 2009 [Page 30]
Internet-Draft TICTOC March 2009
O'Donoghue, Laurent Montini, Greg Dowd, Doug Arnald and the LXI
Consortium Technical Committee for input on this draft.
9. Informative References
[1588] IEEE, "1588-2002 Standard for A Precision Clock
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.
[RFC5087] Stein, Y(J)., Shashoua, R., Insler, R., and M. Anavi,
"Time Division Multiplexing over IP (TDMoIP)", RFC 5087,
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
Rodrigues & Lindqvist Expires September 3, 2009 [Page 31]
Internet-Draft TICTOC March 2009
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
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 systems 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
Rodrigues & Lindqvist Expires September 3, 2009 [Page 32]
Internet-Draft TICTOC March 2009
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.
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.
Rodrigues & Lindqvist Expires September 3, 2009 [Page 33]
Internet-Draft TICTOC March 2009
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.
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. PTP (a product of the IEEE Test and Measurement
community) is specified in a limited first version (1588-2002), and
the second version (1588-2008)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
The information exchange component of IEEE 1588 is a protocol known
as Precision Time Protocol (PTP). PTP version 1 (1588-2002) was a
time transfer protocol that exclusively used multicast technique and
it was primarily developed for Industtrial Automation and Test and
Measurement applications. It is widely anticipated that wide scale
deployment of PTP will be based on PTP version 2 (1588-2008).
IEEE Std 1588-2008 can be considered to consist of several
components:
1. A configuration and control protocol
Rodrigues & Lindqvist Expires September 3, 2009 [Page 34]
Internet-Draft TICTOC March 2009
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 IEEE Std 1588-2002 (multicast IP with recommended TTL=1,
UDP, PTP payload with equipment identifier in the payload). The
rationale for this approach was that the equipment needed to be "plug
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. IEEE Std 1588-2008 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 IEEE Std 1588-2008, 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 IEEE Std 1588-2008 specification describes how the PTP operates
over the Ethernet/IP/UDP protocol stack. It 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. They may operate in
unicast or multicast. 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
Rodrigues & Lindqvist Expires September 3, 2009 [Page 35]
Internet-Draft TICTOC March 2009
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
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 approved the version 2 of the IEEE 1588 protocol (IEEE Std
1588- 2008) 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,
Rodrigues & Lindqvist Expires September 3, 2009 [Page 36]
Internet-Draft TICTOC March 2009
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.
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 September 3, 2009 [Page 37]