idnits 2.17.1 draft-ietf-tictoc-requirements-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 18 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (July 5, 2009) is 5406 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 1305 (Obsoleted by RFC 5905) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TICTOC S. Rodrigues 3 Internet-Draft Zarlink Semiconductor 4 Intended status: Informational K. Lindqvist 5 Expires: January 6, 2010 Netnod 6 July 5, 2009 8 TICTOC Requirement 9 draft-ietf-tictoc-requirements-00.txt 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on January 6, 2010. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents in effect on the date of 41 publication of this document (http://trustee.ietf.org/license-info). 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. 45 Abstract 47 Distribution of high precision time and frequency over the Internet 48 and special purpose IP networks is becoming more and more needed as 49 IP networks replace legacy networks and as new applications with need 50 for frequency and time are developed on the Internet. The IETF 51 formed the TICTOC working group to address the problem and perform an 52 analysis on existing solutions and the needs. This document 53 summarizes application needs, as described and agreed on at an TICTOC 54 interim meeting held in Paris from June 16 to 18, 2008. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Applications Requirements . . . . . . . . . . . . . . . . . . 3 61 3.1. Cellular Backhauling . . . . . . . . . . . . . . . . . . . 3 62 3.1.1. Cellular Backhauling . . . . . . . . . . . . . . . . . 4 63 3.1.2. Cellular Backhaul Requirements Summary . . . . . . . . 10 64 3.2. Circuit Emulation . . . . . . . . . . . . . . . . . . . . 11 65 3.2.1. Circuit Emulation Requirements . . . . . . . . . . . . 11 66 3.2.2. Circuit Emulation Requirements Summary . . . . . . . . 12 67 3.3. Test and Measurement . . . . . . . . . . . . . . . . . . . 12 68 3.3.1. Test and Measurement Requirements . . . . . . . . . . 14 69 3.4. Industrial Automation . . . . . . . . . . . . . . . . . . 16 70 3.4.1. Industrial Automation Requirements . . . . . . . . . . 16 71 3.5. ToD/ Internet . . . . . . . . . . . . . . . . . . . . . . 17 72 3.5.1. ToD/Internet Requirements . . . . . . . . . . . . . . 17 73 3.6. Networking . . . . . . . . . . . . . . . . . . . . . . . . 18 74 3.6.1. Networking SLA Requirements . . . . . . . . . . . . . 18 75 3.6.2. Networking CDR Requirements . . . . . . . . . . . . . 19 76 3.7. Legal Uses of Time . . . . . . . . . . . . . . . . . . . . 20 77 3.7.1. Legal Uses of Time Requirements . . . . . . . . . . . 20 78 3.8. Metrology . . . . . . . . . . . . . . . . . . . . . . . . 21 79 3.8.1. Metrology Requirements . . . . . . . . . . . . . . . . 21 80 3.9. Sensor Networks . . . . . . . . . . . . . . . . . . . . . 22 81 3.9.1. Sensors Networks Requirements . . . . . . . . . . . . 23 82 4. Network Dependencies . . . . . . . . . . . . . . . . . . . . . 23 83 5. Network Topology . . . . . . . . . . . . . . . . . . . . . . . 24 84 6. Security Considerations . . . . . . . . . . . . . . . . . . . 24 85 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 86 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25 87 9. Informative References . . . . . . . . . . . . . . . . . . . . 25 88 Appendix A. Existing Time and Frequency Transfer Mechanisms . . . 26 89 A.1. Radio-based Timing Transfer Methods . . . . . . . . . . . 27 90 A.2. Dedicated Wire-based Timing Transfer Methods . . . . . . . 27 91 A.3. Transfer Using Packet Networks . . . . . . . . . . . . . . 28 92 A.3.1. NTP summary description . . . . . . . . . . . . . . . 29 93 A.3.2. IEEE1588 summary description . . . . . . . . . . . . . 29 94 Appendix B. Other Forums Working in this Problem Space . . . . . 30 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 97 1. Introduction 99 There is an emerging need to distribute highly accurate time and 100 frequency information over IP and over MPLS packet switched networks 101 (PSNs). In this draft, the requirements for transporting accurate 102 time and/or frequency are addressed. 104 2. Terminology 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in [RFC2119] 110 3. Applications Requirements 112 There are many applications that need synchronization. Some 113 applications only need frequency; for others a combination of 114 frequency and time of day or phase may be required. At the TICTOC 115 interim meeting, it was agreed that these applications be grouped 116 based on what was believed to be common requirements, and where the 117 requirements where distinct from each other. This section describes 118 these applications (or groups of applications) that was agreed on at 119 the TICTOC interim meeting. 121 3.1. Cellular Backhauling 123 Within Cellular backhauling, there are several applications that need 124 to be considered. Some of these applications only require frequency 125 information, others require time-of-day, and others require phase. 126 The cellular backhauling applications to be considered are: 128 o GSM 130 o Mobile Wimax 132 o LTE 134 o UMTS FDD 136 o UMTS TDD 138 o CDMA2000 140 o TD-SCDMA 142 Conventionally GSM and UMTS FDD base stations obtain this reference 143 frequency by locking on to the E1/T1 that links them to the base 144 station controller. With the replacement of TDM links with Packet 145 Switched Networks (PSNs) such as Ethernet, IP or MPLS, this simple 146 method of providing a frequency reference is lost, and frequency 147 information must be made available in some other way. 149 The synchronization requirement is derived from the need for the 150 radio frequencies to be accurate. Radio spectrum is a limited and 151 valuable commodity that needs to be used as efficiently as possible. 152 In GSM, transmission frequencies are allocated to a given cellular 153 base station and its neighbours in such fashion as to ensure that 154 they do not interfere with each other. If the radio network designer 155 cannot rely on the accuracy of these frequencies, the spacing between 156 the frequencies used by neighbouring sites must be increased, with 157 significant economic consequences. 159 There is an additional requirement derived from the need for smooth 160 handover when a mobile station crosses from one cell to another. If 161 the radio system designer can not guarantee that the preparations 162 required for handover occur in a few milliseconds, then they must 163 allow the mobile station to consume frequency resources 164 simultaneously in both cells in order to avoid service disruption. 165 The preparations required involve agreement between the mobile and 166 base stations on the new frequencies and time offsets; these 167 agreements can be accomplished quickly when the two base stations' 168 frequency references are the same to a high degree of accuracy. 170 3.1.1. Cellular Backhauling 172 The requirements for the "Cellular Backhauling" are depicted in the 173 following sections. 175 3.1.1.1. GSM/UMTS FDD 177 The requirements for the GSM/UMTS FDD are as follows: 179 Synchronization Type (e.g. time, frequency or phase): frequency 180 Frequency stability: 50-250 ppb (1) 181 Frequency accuracy : 50-250 ppb (1) 182 Uncalibrated time/time stability: 183 Uncalibrated time/time accuracy: NA 184 Stabilization Time : As soon as possible 185 Jitter on recovered timing signal: Depends on the oscillator stability 186 Wander on recovered timing signal: Depends on the oscillator stability 187 What expected network characteristics 188 (WAN, LAN, MAN, private, public, etc)?: 189 Does the application require security? (if so, which one: 190 authentication, encryption, traceability, others): No (2) 191 Reliability requirements (e.g. fault tolerance): 192 Traceability to a specific clock, clock quality, path, time: 193 Holdover requirement: 194 Cost (consumer, enterprise, carrier): 195 Auto-configuration (plug and play): No 196 Manageability (how much effort the operator needs to put in to manage 197 this application?) - In-band or out-of-band of protocol (MIBs?): 198 Scale and scalability: 200 Note (1) This is requirement in the air interface. In practice more 201 accurate frequency is required at the input. For example OBSAI RP1 202 defines 16 ppb 204 Note (2) assumes a private network 206 3.1.1.2. UMTS TDD 208 The requirements for the UMTS TDD are as follows: 210 Synchronization Type (e.g. time, frequency or phase): phase alignment 211 Frequency stability: 50-250 ppb (1) 212 Frequency accuracy : 50-250 ppb (1) 213 Uncalibrated time/time stability: 214 Uncalibrated time/time accuracy: The phase alignment of neighbouring 215 base stations shall be within 2.5us 216 Stabilization Time : As soon as possible 217 Jitter on recovered timing signal: Depends on the oscillator stability 218 Wander on recovered timing signal: Depends on the oscillator stability 219 What expected network characteristics (WAN, LAN, MAN, private, public, 220 etc)?: 221 Does the application require security? (if so, which one: 222 authentication, encryption, traceability, others): No (2) 223 Reliability requirements (e.g. fault tolerance): 224 Traceability to a specific clock, clock quality, path, time: 225 Holdover requirement: 226 Cost (consumer, enterprise, carrier): 227 Auto-configuration (plug and play): No 228 Manageability (how much effort the operator needs to put in to manage 229 this application?) - In-band or out-of-band of protocol (MIBs?): 230 Scale and scalability: 232 Note (1) This is requirement in the air interface. In practice more 233 accurate frequency is required at the input. For example OBSAI RP1 234 defines 16 ppb 236 Note (2) assumes a private network 238 3.1.1.3. Mobile Wimax 240 The requirements for the Mobile Wimax (1) are as follows: 242 Synchronization Type (e.g. time, frequency or phase): phase alignment 243 Frequency stability: 15 ppb 244 Frequency accuracy : 15 ppb 245 Uncalibrated time/time stability: 246 Uncalibrated time/time accuracy: The phase alignment of neighbouring 247 base stations shall be within 1us 248 Stabilization Time : As soon as possible 249 Jitter on recovered timing signal: 250 Wander on recovered timing signal: 251 What expected network characteristics (WAN, LAN, MAN, private, public, 252 etc)?: 253 Does the application require security? (if so, which one: 254 authentication, encryption, traceability, others): No (2) 255 Reliability requirements (e.g. fault tolerance): 256 Traceability to a specific clock, clock quality, path, time: 257 Holdover requirement: 258 Cost (consumer, enterprise, carrier): 259 Auto-configuration (plug and play): No 260 Manageability (how much effort the operator needs to put in to manage 261 this application?) - In-band or out-of-band of protocol (MIBs?): 262 Scale and scalability: 264 Note (1) 1024 OFDM carriers, BW 10 MHz, Cyclic prefix ratio 1:8, RF 265 carrier 3.5 GHz 267 Note (2) assumes a private network 269 3.1.1.4. LTE 271 The requirements for the LTE are as follows: 273 Synchronization Type (e.g. time, frequency or phase): phase alignment 274 Frequency stability: 50-250 ppb (1) 275 Frequency accuracy : 50-250 ppb (1) 276 Uncalibrated time/time stability: 277 Uncalibrated time/time accuracy: From 1us to 50us (2, 3) 278 Stabilization Time : As soon as possible 279 Jitter on recovered timing signal: Depends on the oscillator stability 280 Wander on recovered timing signal: Depends on the oscillator stability 281 What expected network characteristics (WAN, LAN, MAN, private, public, 282 etc)?: 283 Does the application require security? (if so, which one: 284 authentication, encryption, traceability, others): No (4) 285 Reliability requirements (e.g. fault tolerance): 286 Traceability to a specific clock, clock quality, path, time: 287 Holdover requirement: 288 Cost (consumer, enterprise, carrier): 289 Auto-configuration (plug and play): No 290 Manageability (how much effort the operator needs to put in to manage 291 this application?) - In-band or out-of-band of protocol (MIBs?): 292 Scale and scalability: 294 Note (1) This is requirement in the air interface. In practice more 295 accurate frequency is required at the input. For example OBSAI RP1 296 defines 16 ppb 298 Note (2) : no precise phase accuracy requirements defined in 299 standard. The actual requirement will depend on implementation and 300 network scenario. 302 Note (3) : In general LTE TDD systems may be defined to operate with 303 10-50 microseconds phase accuracy by making some limitations on the 304 deployment (e.g. cell range), and radio frame configuration, however 305 further investigations are required. When no assumption possible, 306 microsecond or sub-microsecond requirement would apply. 308 Note (4) assumes a private network 310 3.1.1.5. CDMA2000 312 The requirements for the CDMA2000 are as follows: 314 Synchronization Type (e.g. time, frequency or phase): phase alignment 315 Frequency stability: 50-250 ppb (1) 316 Frequency accuracy : 50-250 ppb (1) 317 Uncalibrated time/time stability: 318 Uncalibrated time/time accuracy: The pilot time alignment error should 319 be less than 3us and shall be less than 10us(compared to system 320 time) 321 Stabilization Time : As soon as possible 322 Jitter on recovered timing signal: Depends on the oscillator stability 323 Wander on recovered timing signal: Depends on the oscillator stability 324 What expected network characteristics (WAN, LAN, MAN, private, public, 325 etc)?: 326 Does the application require security? (if so, which one: 327 authentication, encryption, traceability, others): No (2) 328 Reliability requirements (e.g. fault tolerance): 329 Traceability to a specific clock, clock quality, path, time: System Time, 330 synchronous to UTC time (except for leap seconds) and uses the same 331 time origin as GPS time. (3) 332 Holdover requirement: 333 Cost (consumer, enterprise, carrier): 334 Auto-configuration (plug and play): No 335 Manageability (how much effort the operator needs to put in to manage 336 this application?) - In-band or out-of-band of protocol (MIBs?): 337 Scale and scalability: 339 Note (1) This is requirement in the air interface. In practice more 340 accurate frequency is required at the input. For example OBSAI RP1 341 defines 16 ppb 343 Note (2) assumes a private network 345 Note (3) 3GPP2, C.S0010-B version 2.0, 2004 347 3.1.1.6. TD-SCDMA 349 The requirements for the TD-SCDMA are as follows: 351 Synchronization Type (e.g. time, frequency or phase): phase alignment 352 Frequency stability: 50-250 ppb (1) 353 Frequency accuracy : 50-250 ppb (1) 354 Uncalibrated time/time stability: 355 Uncalibrated time/time accuracy: The phase alignment of neighbouring 356 base stations shall be within 3us 357 Stabilization Time : As soon as possible 358 Jitter on recovered timing signal: Depends on the oscillator stability 359 Wander on recovered timing signal: Depends on the oscillator stability 360 What expected network characteristics (WAN, LAN, MAN, private, public, 361 etc)?: 362 Does the application require security? (if so, which one: 363 authentication, encryption, traceability, others): No (2) 364 Reliability requirements (e.g. fault tolerance): 365 Traceability to a specific clock, clock quality, path, time: 366 Holdover requirement: 367 Cost (consumer, enterprise, carrier): 368 Auto-configuration (plug and play): No 369 Manageability (how much effort the operator needs to put in to manage 370 this application?) - In-band or out-of-band of protocol (MIBs?): 371 Scale and scalability: 373 Note (1) This is requirement in the air interface. In practice more 374 accurate frequency is required at the input. For example OBSAI RP1 375 defines 16 ppb 377 Note (2) assumes a private network 379 3.1.2. Cellular Backhaul Requirements Summary 381 Based on the sections above, the following can be summarized for the 382 cellular backhaul applications. Two families of technologies can be 383 identified: 385 o Those only requiring the recovery of an accurate and stable 386 frequency synchronization signal as a reference for the radio 387 signal (e.g. GSM, UMTS FDD, LTE FDD). In this case the 388 requirement ranges between 15 ppb (Wimax) and 250 ppb (UMTS Home 389 Base Stations). This requirement is applicable on the air 390 interface. In practice more accurate frequency on the long term 391 is required at the input of the Base Stations (e.g. 16 ppb might 392 be required for applications operating with 50 ppb) 394 o Mobile technologies that in addition to frequency synchronization, 395 also need phase synchronization. This is the case for the TDD 396 technologies such as UMTS TDD. The requirement in this case 397 ranges between 2.5 microseconds (phase error between Base 398 Stations) to several tens of microseconds that could be sufficient 399 for some LTE TDD configurations. There is also a case (CDMA2000) 400 that in addition to phase synchronization also requires the 401 distribution of accurate time of day (3 microseconds max error 402 during normal operation). 404 3.2. Circuit Emulation 406 The PWE3 WG has produced three techniques for emulating traditional 407 low-rate (E1, T1, E3, T3) TDM services over PSNs, namely SAToP 408 [RFC4553], CESoPSN [RFC5086], and TDMoIP [RFC5087]. The Network 409 Synchronization reference model and deployment scenarios for 410 emulation of TDM services have been described in [RFC4197], Section 411 4.3. The major technical challenge for TDM pseudowires is the 412 accuracy of its clock recovery. 414 TDM network standards for timing accuracy and stability are extremely 415 demanding. These requirements are not capriciously dictated by 416 standards bodies, rather they are critical to the proper functioning 417 of a high-speed TDM network. Consider a TDM receiver utilizing its 418 own clock when converting the physical signal back into a bit-stream. 419 If the receive clock runs at precisely the same rate as the source 420 clock, then the receiver need only determine the optimal sampling 421 phase. However, with any mismatch of clock rates, no matter how 422 small, bit slips will eventually occur. For example, if the receive 423 clock is slower than the source clock by one part per million (ppm), 424 then the receiver will output 999,999 bits for every 1,000,000 bits 425 sent, thus deleting one bit. Similarly, if the receive clock is 426 faster than the source clock by one part per billion (ppb), the 427 receiver will insert a spurious bit every billion bits. One bit slip 428 every million bits may seem acceptable at first glance, but 429 translates to a catastrophic two errors per second for a 2 Mb/s E1 430 signal. ITU-T recommendations permit a few bit slips per day for a 431 low-rate 64 kb/s channel, but strive to prohibit bit slips entirely 432 for higher-rate TDM signals. 434 3.2.1. Circuit Emulation Requirements 436 The requirements for the Circuit Emulation are as follows: 438 Synchronization Type (e.g. time, frequency or phase): frequency 439 Frequency stability: NA 440 Frequency accuracy : NA 441 Uncalibrated time/time stability: NA 442 Uncalibrated time/time accuracy: NA 443 Stabilization Time : 444 Jitter on recovered timing signal: G.8261/G.823/G.824 445 Wander on recovered timing signal: G.8261/G.823/G.824 446 What expected network characteristics (WAN, LAN, MAN, private, public, 447 etc)?: 448 Does the application require security? (if so, which one: 449 authentication, encryption, traceability, others): No 450 Reliability requirements (e.g. fault tolerance): NA 451 Traceability to a specific clock, clock quality, path, time: 452 Holdover requirement: Yes 453 Cost (consumer, enterprise, carrier): 454 Auto-configuration (plug and play): No 455 Manageability (how much effort the operator needs to put in to manage 456 this application?) - In-band or out-of-band of protocol (MIBs?): 457 Scale and scalability: 459 3.2.2. Circuit Emulation Requirements Summary 461 The Circuit Emulation application requires the receiver to recover 462 the same long term frequency accuracy as the original TDM signal. 463 The phase noise (jitter and wander) of the recovered signal has to be 464 limited according to the relevant ITU-T recommendation (e.g. G.823). 465 There are no requirements on phase or time synchronization in this 466 case. 468 3.3. Test and Measurement 470 Note: The application information and the requirements for this 471 section was provided by the LXI Consortium Technical Committee. 473 In the test and measurement sector there is a desire to move from 474 special purpose communications infrastructure with calibrated wiring 475 run back to a centralize controller, to a distributed system, in 476 which instructions are distributed in advance to be executed at a 477 predetermined time, and in which measurements are taken remotely and 478 communicated back to a common point for later correlation and 479 analysis. 481 Test and Measurement (T&M) is a very diverse industry and as would be 482 expected, requirements vary widely with the application. However the 483 vast majority of the newer instruments and systems make use of LAN 484 technology and many have a connection to the local enterprise network 485 for data transfer, or monitoring and control. 487 Because of the increasingly heavy use of LAN technology in T&M 488 instruments and systems, we are dependent on the availability of 489 network infrastructure, e.g. bridges, and low level silicon, e.g. 490 PHYs and PHY/MAC, that supports not only T&M connectivity (data 491 transport) but increasingly timing and frequency transfer support as 492 well. 494 Furthermore T&M is going to require this support not only for the 495 existing 10/100/1000 BaseT technology but on the newer high 496 throughput LAN technology under development. While most instruments 497 produce data at modest rates, many can source or sink data at rates 498 well in excess of 40Gsamples/s. In addition, the time and phase 499 coherence requirements on the data transport, e.g. LAN, typically 500 are tighter on the high data rate instruments. 502 The other major headache in the use of LAN in T&M is latency and 503 jitter because it compromises the determinism needed for some 504 applications. One of the promises of LAN-based precise time is that 505 in many circumstances precise time can be used to overcome latency 506 issues. For example, for many data acquisition applications the 507 ability to precisely and accurately timestamp data at the collection 508 point makes LAN latency and jitter a non-issue. 510 Many T&M applications are localized, often to a bench or rack of 511 equipment. The LAN will be local and private although there is often 512 a connection to the local enterprise network. It is not uncommon in 513 such applications to include a rubidium oscillator to provide a 514 phase-coherent stable frequency source to critical instrumentation 515 such as counters, scopes, signal generators and analyzers. In many 516 cases the LAN, in principle, could fill the frequency distribution 517 role if the LAN technology supported it. In these systems time 518 transfer is becoming important first for timestamping data to 519 facilitate data management and post acquisition processing, and in 520 some cases as part of the control structure. The precise time 521 specifications vary from milliseconds for general applications to 522 nanoseconds for the most critical. 524 There is an important class of applications where time, and sometimes 525 frequency traceable to international standards is required, generally 526 due to regulatory issues, e.g. testing of medical, safety critical or 527 military devices. The ability to deliver traceable time and 528 frequency over the network to the enterprise would be a big help in 529 these applications. 531 There are also T&M applications that are widely distributed due to 532 the nature of the device or system being measured. Environmental 533 measurement systems, surveillance, SCADA systems, and the 534 telecommunication system itself are examples. Timestamping data is 535 an essential requirement to overcome the communication latency and 536 jitter issues. The specific timing requirements clearly cover a wide 537 range. Environmental and SCADA is typically a ms. However to really 538 instrument a telecom system will require timing at least on the order 539 of a packet length or better. Even more extreme are timing for RF 540 test ranges (which can cover several miles), long-baseline 541 interferometry, and RF surveillance where the time accuracy must be 542 on the order of ns. In some cases public networks will be used if 543 the time distribution is adequate. 545 3.3.1. Test and Measurement Requirements 547 The requirements for the Test and Measurement are summarized in this 548 section. Where appropriate both the low and high end of the 549 requirements spectrum are given to illustrate the breadth of 550 requirements for the application areas discussed. Note that 551 typically the applications with the most demanding requirements are 552 also the high dollar value applications and in many cases the most 553 critical in terms of the cost of failure, e.g. failure of a 554 surveillance system, monitoring of telecommunications, military test 555 systems where either the operational cost of downtime or the cost of 556 the device being tested is high. 558 The requirements for the Test and Measurement are as follows: 560 Synchronization Type (e.g. time, frequency or phase): Time: ms to ns - 561 high value applications will open up as this spec improves. 562 Frequency: part in 10^9 minimum, 10^11 desirable and with the 563 lowest phase noise obtainable for critical applications. 564 Frequency stability: When applicable (high end RF) the lowest phase 565 noise possible in the short term, long term consistent with 566 accuracy and calibration intervals- better than 1 567 ppm/year desirable. 568 Frequency accuracy : Generally consistency across the system is 569 more important than absolute accuracy. For calibration 570 applications at least 1ppm. 571 Uncalibrated time/time stability: Short term from fractional 572 ms to ns or better. Long term comparable to GPS 573 distributed time . 574 Uncalibrated time/time accuracy: Usually self-consistency 575 requirements are tighter: ms to ns system wide. 576 Absolute accuracy (traceable) is probably ms to 100 ns. 577 Stabilization Time : Not usually important. Many times critical 578 instruments themselves need minutes to hours to stabilize. 579 However stabilization times greater than a few minutes will 580 reduce the number of practical wide-area applications. 581 Jitter on recovered timing signal: In the most critical applications, 582 the lowest phase noise achievable, in terms of TIE less than 583 the stability requirement. 584 Wander on recovered timing signal: Modest for most measurements. 585 For surveillance, long baseline, and similar less than the 586 required stability over the duration of the test. 587 What expected network characteristics (WAN, LAN, MAN, private, public, 588 etc)?: Most are private or enterprise LAN. Large scale 589 applications will benefit from using the public 590 telecommunications networks. 591 Does the application require security? (if so, which one: 592 authentication, encryption, traceability, others): To date 593 timing security requirements have been rare with the possible 594 exception of measurement systems with legal requirements. 595 Data security is more important when the public networks 596 are involved. 597 Reliability requirements (e.g. fault tolerance): Has not been an 598 issue to date in most systems. 599 Traceability to a specific clock, clock quality, path, time: 600 Traceability to a path means that if there is on-path support 601 we want to trace the path. Can also help to avoid time loops. 602 Traceability is needed to establish NIST traceability. T&M will 603 expect that public networks solve the timing loop problem. T&M 604 end systems are typically strictly hierarchical networks without 605 multiple paths. 606 Holdover requirement: Has not been an issue to date- but as T&M 607 increasingly is integrated into operational systems it will 608 become more important. Telecom requirements are probably 609 sufficient. 610 Cost (consumer, enterprise, carrier): In most T&M systems component 611 cost is very important. In many, operational cost is important. 612 Auto-configuration (plug and play): Very important. T&M customers to 613 date would prefer to avoid any network related configuration. 614 Manageability (how much effort the operator needs to put in to manage 615 this application?) - In-band or out-of-band of protocol 616 (MIBs?): As little as possible operator interaction. However 617 visibility into system performance, including timing, is 618 very important both operationally and during debug and 619 commissioning. 620 Scale and scalability: T&M systems range from small systems with 621 perhaps 2 or 3 instruments to large scale data acquisition 622 with thousands of end devices. The physical scale of T&M 623 systems varies widely from a few instruments on a 624 bench to a few instruments separated by miles, and from 625 several thousand instruments and sensors concentrated 626 on a local device such as a jet engine to several thousand 627 spread over many miles in environmental monitoring, or 628 monitoring the telecommunications system. In all cases 629 it is very common for these systems to grow as 630 additional test requirements are imposed so scalability is 631 important. 633 3.4. Industrial Automation 635 In the industrial sector there is a desire to move from special 636 purpose communications infrastructure with calibrated wiring run back 637 to a centralize controller, to a distributed system. One example of 638 this tendency is described below. 640 In the printing industry there is a need to control operations in 641 multi-stand printing machines. The paper travels through these 642 machines at a speed of nearly 100 km/h. At these speeds, co- 643 ordination error of 1 microsecond between operations taking place at 644 different positions in the machine produces a 0.03mm color offset, 645 which is visible to the naked eye and results in an unacceptable 646 degradation in quality. 648 3.4.1. Industrial Automation Requirements 650 The requirements for the Industrial Automation are summarized as 651 follows. 653 Synchronization Type (e.g. time, frequency or phase): 654 Frequency stability: 655 Frequency accuracy : 656 Uncalibrated time/time stability: 657 Uncalibrated time/time accuracy: 658 Stabilization Time : 659 Jitter on recovered timing signal: 660 Wander on recovered timing signal: 661 What expected network characteristics (WAN, LAN, MAN, private, public, 662 etc)?: 663 Does the application require security? (if so, which one: 664 authentication, encryption, traceability, others): 665 Reliability requirements (e.g. fault tolerance): 666 Traceability to a specific clock, clock quality, path, time: 667 Holdover requirement: 668 Cost (consumer, enterprise, carrier): 669 Auto-configuration (plug and play): 670 Manageability (how much effort the operator needs to put in to manage 671 this application?) - In-band or out-of-band of protocol (MIBs?): 672 Scale and scalability: 674 3.5. ToD/ Internet 676 General time distribution over the Internet or IP networks, is often 677 called Time of Day or Wall-clock. Most existing use cases are using 678 NTP over the Internet with low precision requirements. However, new 679 applications are arising that require higher precision rates than 680 what is currently available. 682 Internet TOD is important to the maintenance of IT infrastructure in 683 an organization. Generally the larger an organization becomes, the 684 more important time synchronization is. Time synchronization is 685 critical for the following: 1. Server and router log file entry time 686 tags 2. "Date modified" attributes for files 3. Chron job 687 scheduling 4. Security protocol with limited time windows for key 688 exchange. 690 Server and Router log file time tag accuracy is essential to network 691 diagnostic tools. Such tools are used to determine the root cause of 692 a network failure or security breach. Often it is important to 693 determine the order in which certain events occur amongst a number of 694 network devices. The "Date modified" fields of files may also be 695 part of this type of analysis. 697 Often Chron jobs perform operations on files depending on the times 698 in the "Date modified" attributes files. These files might reside on 699 more than one computer or server. 701 Many security protocols, such as Kerberos, depend on authentication 702 "tickets" which expire after a short time. This means that an 703 authenticating server gives a ticket to a client, which the client 704 can send to another server for some service which requires 705 authentication. The time limit is intended to reduce the threat of 706 the "Man in the middle attack." To work the two servers need to have 707 clocks synchronized to a time error which is smaller than the ticket 708 time out period. To increase security there is a desire to reduce 709 the ticket time interval. As the time interval becomes shorter the 710 need for server clock agreement is increased. The trend over time is 711 to reduce the ticket time out period. 713 3.5.1. ToD/Internet Requirements 715 The requirements for the ToD/Internet are summarized as follows: 717 Synchronization Type (e.g. time, frequency or phase): time 718 Frequency stability: no requirement 719 Frequency accuracy : no requirement 720 Uncalibrated time/time stability: no requirement 721 Uncalibrated time/time accuracy: 10 ms 722 Stabilization Time : 1 hour 723 Jitter on recovered timing signal: 100 ms 724 Wander on recovered timing signal: 10 ms 725 What expected network characteristics (WAN, LAN, MAN, private, public, 726 etc)?: All network types 727 Does the application require security? (if so, which one: 728 authentication, encryption, traceability, others): Authentication 729 sometimes used 730 Reliability requirements (e.g. fault tolerance): high availability. 731 Clients must see multiple servers 732 Traceability to a specific clock, clock quality, path, time: 733 Not important 734 Holdover requirement: 1 hour to 1 year. Depends on server redundancy 735 architecture 736 Cost (consumer, enterprise, carrier): 0 - $10,000 USD (1) 737 Auto-configuration (plug and play): 738 Manageability (how much effort the operator needs to put in to manage 739 this application?) - In-band or out-of-band of protocol (MIBs?): 740 30-90 minutes to configure a new server, 5 minutes to configure 741 a new client. Almost no management after initial deployment. 742 Scale and scalability: system must cover entire IT infrastructure of 743 organization. Any 1 server will cover 1 building or campus. 745 (1) The free option implies pointing all clients at ntp servers 746 available on the public internet. 748 3.6. Networking 750 Editor's note: need more info on this application. 752 3.6.1. Networking SLA Requirements 754 The requirements for the Networking SLA are summarized as follows: 756 Synchronization Type (e.g. time, frequency or phase): 757 Frequency stability: 758 Frequency accuracy : 759 Uncalibrated time/time stability: 760 Uncalibrated time/time accuracy: 761 Stabilization Time : 762 Jitter on recovered timing signal: 763 Wander on recovered timing signal: 764 What expected network characteristics (WAN, LAN, MAN, private, public, 765 etc)?: 766 Does the application require security? (if so, which one: 767 authentication, encryption, traceability, others): 768 Reliability requirements (e.g. fault tolerance): 769 Traceability to a specific clock, clock quality, path, time: 770 Holdover requirement: 771 Cost (consumer, enterprise, carrier): 772 Auto-configuration (plug and play): 773 Manageability (how much effort the operator needs to put in to manage 774 this application?) - In-band or out-of-band of protocol (MIBs?): 775 Scale and scalability: 777 3.6.2. Networking CDR Requirements 779 The requirements for the Network CDR are summarized as follows: 781 Synchronization Type (e.g. time, frequency or phase): 782 Frequency stability: 783 Frequency accuracy : 784 Uncalibrated time/time stability: 785 Uncalibrated time/time accuracy: 786 Stabilization Time : 787 Jitter on recovered timing signal: 788 Wander on recovered timing signal: 789 What expected network characteristics (WAN, LAN, MAN, private, public, 790 etc)?: 791 Does the application require security? (if so, which one: 792 authentication, encryption, traceability, others): 793 Reliability requirements (e.g. fault tolerance): 794 Traceability to a specific clock, clock quality, path, time: 795 Holdover requirement: 796 Cost (consumer, enterprise, carrier): 797 Auto-configuration (plug and play): 798 Manageability (how much effort the operator needs to put in to manage 799 this application?) - In-band or out-of-band of protocol (MIBs?): 800 Scale and scalability: 802 3.7. Legal Uses of Time 804 With legal uses of time is meant the cases where high precision wall- 805 clock is needed, just as in the ToD case, but with where the time 806 source is traceable to UTC in a secure manner, i.e. through a 807 certificate chain. It's also important for the legal-time case that 808 the certificate chain is set-up so that it provides for an audit 809 trail, where the ToD provided at any given moment can be traced to a 810 known source or standard (i.e. a national timescale or time 811 laboratory). One typical application that would benefit from high 812 accuracy legal time is event correlation in computer systems logs, 813 and similar applications. 815 3.7.1. Legal Uses of Time Requirements 817 There are timing applications for which accuracy and other 818 characteristics are legally mandated, such as: 820 o Pay-by-time services (e.g., parking meters, taxicab meters, coin- 821 operated laundries), 823 o First-arrival succeeds applications (e.g., races, stock-market 824 exchanges), 826 o Devices that require accurate frequency for calibration (e.g., 827 police radar, RF broadcast). 829 For such applications the legal requirements usually dictate both 830 precision and accuracy, and frequently also traceability and security 831 considerations. There also may be requirements for keeping of logs 832 for some amount of time, for certification of correct operation by 833 qualified personnel, and specification of the national timing 834 standard to be used. 836 Due to the large number of disparate applications covered by legal 837 uses of time, it is not useful to attempt to codify all the possible 838 requirements in a table, however, the following is a typical subset 839 of requirements. 841 Synchronization Type (e.g. time, frequency or phase): usually time, 842 some frequency 843 Frequency stability: 844 Frequency accuracy : 100 ppm 845 Uncalibrated time/time stability: 846 Uncalibrated time/time accuracy: from 10s of ms to better than 1 second 847 Stabilization Time : 848 Jitter on recovered timing signal: 849 Wander on recovered timing signal: 850 What expected network characteristics (WAN, LAN, MAN, private, public, 851 etc)?: private well-engineered IP networks, public Internet 852 Does the application require security? (if so, which one: definitely 853 authentication, encryption, traceability, others): 854 Reliability requirements (e.g. fault tolerance): Yes, but not always 855 specified 856 Traceability to a specific clock, clock quality, path, time: to national 857 standard 858 Holdover requirement: 859 Cost (consumer, enterprise, carrier): 860 Auto-configuration (plug and play): 861 Manageability (how much effort the operator needs to put in to manage 862 this application?) - In-band or out-of-band of protocol (MIBs?): 863 Scale and scalability: usually not an issue 865 3.8. Metrology 867 Metrology for time and frequency is today mostly using tailored 868 equipment and cabling for time/frequency transfer when doing 869 laboratory work. However, in the future, using IP over existing 870 networks in the laboratories would allow for greater flexibility and 871 reuse of existing infrastructure rather than building out more 872 special purpose infrastructure. 874 3.8.1. Metrology Requirements 876 We should distinguish between "primary" metrology of time and 877 frequency performed in national metrology laboratories and some other 878 timing centers (which deals with highly accurate and stable frequency 879 standards, typically cesium standards and hydrogen masers and which 880 ensures synchronization with a nanosecond accuracy) and applied 881 metrology that mainly calibrates oscillators and clocks used as 882 "secondary" standards in research organizations and industry. The 883 use of time and frequency transfer in packet networks is limited in 884 "primary" metrology, as it operates with frequency accuracy and 885 stability in the order of 1e-14 and better and time accuracy in 886 nanoseconds (1 ns represents 1 foot of the light path in vacuum). In 887 turn, time and frequency transfer through packet networks is quite 888 challenging for applied metrology - it can profit from any 889 improvement of transfer accuracy, therefore the values in table 8 890 should be considered as minimum target values. Whenever possible, 891 accuracy of distributed time should be better then time accuracy 892 provided by a GPS receiver. Short distance application (over LAN) 893 usually require better accuracy than long distance application using 894 WAN. 896 Note: some applications might belong into both metrology and 897 measurement application groups. 899 The requirements for the Metrology are summarized as follows: 901 Synchronization Type (e.g. time, frequency or phase): Time and 902 frequency 903 Frequency stability: 1 ppb, lowest possible phase noise 904 Frequency accuracy : 1 ppb 905 Uncalibrated time/time stability: Lowest possible phase noise 906 Uncalibrated time/time accuracy: 1 us 907 Stabilization Time : Not important, 1 hour is acceptable 908 Jitter on recovered timing signal: 1 us 909 Wander on recovered timing signal: 1 us 910 What expected network characteristics (WAN, LAN, MAN, private, 911 public, etc)?: Any that can offer required parameters 912 Does the application require security? (if so, which one: 913 authentication, encryption, traceability, others): 914 Authentication is required when public networks are used 915 Reliability requirements (e.g. fault tolerance): Low fault 916 tolerance, user should know whether expected parameters 917 were assured or not 918 Traceability to a specific clock, clock quality, path, time: Very 919 important 920 Holdover requirement: 921 Cost (consumer, enterprise, carrier): Cost should correspond with 922 provided parameters 923 Auto-configuration (plug and play): Important at client side 924 Manageability (how much effort the operator needs to put in to 925 manage this application?) - In-band or out-of-band of 926 protocol (MIBs?): Both provider and customer should accept 927 network related configuration, long distribution path might 928 require calibration 929 Scale and scalability: 931 3.9. Sensor Networks 933 More generally, there is growing interest in clock synchronization in 934 massively parallel sensor networks. Advances in wireless 935 communications have enabled the development of low power miniature 936 sensors that collect and disseminate data from their immediate 937 environment. Although each sensor has limited processing power, 938 through distributed processing the network becomes capable of 939 performing various tasks of data fusion, but only assuming a common 940 time base can be established. 942 3.9.1. Sensors Networks Requirements 944 The requirements for the Sensor are summarized as follows. 946 Synchronization Type (e.g. time, frequency or phase): time 947 Frequency stability: 1% 948 Frequency accuracy : 1000ppm 949 Uncalibrated time/time stability: 1 part per hundred 950 Uncalibrated time/time accuracy: 1 second 951 Stabilization Time : intermediate 952 Jitter on recovered timing signal: several seconds up to 1 milliHz 953 Wander on recovered timing signal: less than one second above 1 milliHz 954 What expected network characteristics (WAN, LAN, MAN, private, public, 955 etc)?: distributed hop-to-hop network 956 Does the application require security? (if so, which one: 957 authentication, encryption, traceability, others): authentication, 958 encryption 959 Reliability requirements (e.g. fault tolerance): intermediate 960 Traceability to a specific clock, clock quality, path, time: one master 961 Holdover requirement: 1% wander per 10 days 962 Cost (consumer, enterprise, carrier): depends on application, from very 963 low to intermediate 964 Auto-configuration (plug and play): strong requirement as there are 965 many sensors 966 Manageability (how much effort the operator needs to put in to manage 967 this application?) - In-band or out-of-band of protocol 968 (MIBs?): in-band, self organizing, little to no storage on device 969 Scale and scalability: must scale to 1000s of intercommunicating sensors 971 4. Network Dependencies 973 When using packet networks to transfer timing, packet delay 974 variation, propagation asymmetry, and maximum permissible packet rate 975 all have a significant bearing on the accuracy with which the client 976 is able to determine absolute time. Thus the network environment has 977 a large bearing on the quality of time that can be delivered. 979 Timing distribution is highly sensitive to packet delay variation, 980 and thus can deteriorate under congestion conditions. Furthermore 981 the disciplining of the client's oscillator (the sole component of 982 frequency transfer, and a critical component of time transfer) is a 983 function that should not be disrupted. When the service is disrupted 984 the client needs to go into "holdover" mode, and its accuracy will 985 consequently be degraded. Depending on the relative quality of the 986 client's clock and the required quality after disciplining, a 987 relatively high packet rate may be required. 989 Packet delay variation can to some extent be addressed by traffic 990 engineering, thus time transfer within a constrained network 991 environment might reasonably be expected to deliver a higher quality 992 time service than can be achieved between two arbitrary hosts 993 connected to the Internet. Greater gains can probably be obtained by 994 deploying equipment that incorporates IEEE 1588 style on-the-fly 995 packet timestamp correction (or any other form of on-path support), 996 or follow-up message mechanisms that report the packet storage and 997 forward delays to the client. However one can only be sure that such 998 techniques are available along the entire path in a well-controlled 999 environment. Therefore, time transfer protocols should not assume 1000 the availability of on path support, but utilizes it where available. 1002 The packet rate between the time-server and its client also has a 1003 bearing on the quality of the time transfer, because at a higher rate 1004 the smart filter has a better chance of extracting the "good" 1005 packets. How the packet rate relates to the accuracy is dependent on 1006 the filter algorithm in use. In a controlled environment it is 1007 possible to ensure that there is adequate bandwidth, and that the 1008 server is not overloaded. In such an environment the onus moves from 1009 protecting the server from overload, to ensuring that the server can 1010 satisfy the needs of all of the clients. 1012 Congested and overloaded paths might influence the quality of timing 1013 transfer. In a constrained network environment, it's assumed that a 1014 service provider will ensure that packet delivery is done in 1015 according to the timing transfer needs of the network operator. 1017 5. Network Topology 1019 Editor's note: This section needs to be discussed. 1021 6. Security Considerations 1023 Time and frequency services are a significant element of network 1024 infrastructure, and are critical for certain emerging applications. 1025 Hence time and frequency transfer services MUST be protected from 1026 being compromised, and for some of the applications described above 1027 such as legal time, the ability to provide and audit trail to the 1028 timing source. One possible threat is a false time or frequency 1029 server being accepted instead of a true one, thus enabling an 1030 attacker to alter the time and frequency service provided. Other 1031 possible scenarios are to be able to distinguish between trusted 1032 clients and non-trusted clients when providing service. 1034 Any protection mechanism must be designed in such a way that it does 1035 not degrade the quality of the time transfer. Such a mechanism 1036 SHOULD also be relatively lightweight, as client restrictions often 1037 dictate a low processing and memory footprint, and because the server 1038 may have extensive fan-out. 1040 The following authentication mechanisms need to be considered: 1042 1. of server by client (depending on the application) 1044 2. of client by server (depending on the application) 1046 3. transactions (depending on the application) 1048 7. IANA Considerations 1050 No IANA actions are required as a result of the publication of this 1051 document. 1053 8. Acknowledgements 1055 The authors wish to thank Stewart Bryant, Yaakov Stein, Karen 1056 O'Donoghue, Laurent Montini, Antti Pietilainen, Stefano Ruffini, 1057 Vladimir Smotlacha, Greg Dowd, Doug Arnold and the LXI Consortium 1058 Technical Committee for input on this draft. 1060 9. Informative References 1062 [1588] IEEE, "1588-2002 Standard for A Precision Clock 1063 Synchronization Protocol for Networked Measurement and 1064 Control Systems". 1066 [G8261] ITU-T, "Recommendation G.8261/Y.1361 - Timing and 1067 synchronization aspects in packet networks", April 2008. 1069 [G8262] ITU-T, "Recommendation G.8262/Y.1362 - Timing 1070 Characteristics of Synchronous Ethernet Equipment Slave 1071 Clock (EEC)", August 2007. 1073 [G8264] ITU-T, "Recommendation G.8264/Y.1364 - Distribution of 1074 timing through packet networks", 2008. 1076 [RFC1305] Mills, D., "Network Time Protocol (Version 3) 1077 Specification, Implementation", RFC 1305, March 1992. 1079 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1080 Requirement Levels", BCP 14, RFC 2119, March 1997. 1082 [RFC4197] Riegel, M., "Requirements for Edge-to-Edge Emulation of 1083 Time Division Multiplexed (TDM) Circuits over Packet 1084 Switching Networks", RFC 4197, October 2005. 1086 [RFC4553] Vainshtein, A. and YJ. Stein, "Structure-Agnostic Time 1087 Division Multiplexing (TDM) over Packet (SAToP)", 1088 RFC 4553, June 2006. 1090 [RFC5086] Vainshtein, A., Sasson, I., Metz, E., Frost, T., and P. 1091 Pate, "Structure-Aware Time Division Multiplexed (TDM) 1092 Circuit Emulation Service over Packet Switched Network 1093 (CESoPSN)", RFC 5086, December 2007. 1095 [RFC5087] Stein, Y(J)., Shashoua, R., Insler, R., and M. Anavi, 1096 "Time Division Multiplexing over IP (TDMoIP)", RFC 5087, 1097 December 2007. 1099 Appendix A. Existing Time and Frequency Transfer Mechanisms 1101 In this section we will discuss existing mechanisms for transfer of 1102 time information, frequency information, or both. It should be noted 1103 that a sufficiently accurate time transfer service may be used to 1104 derive an accurate frequency transfer. Indeed, this is exactly what 1105 happens in a GPS disciplined frequency standard. On the other hand, 1106 an accurate frequency transfer service, while itself unable to 1107 transfer absolute time, is usually used to support and improve the 1108 performance of the time transfer service. Indeed, implementations of 1109 NTP or IEEE 1588 clients can be considered to consist of two phases. 1110 First, a local oscillator is locked to the server's frequency using 1111 incoming information from the incoming packets, and then the local 1112 time set based on the server's time and the propagation latency. By 1113 maintaining a local frequency source, the client requires relatively 1114 infrequent updates, and can continue functioning during short periods 1115 of network outage. Moreover, it can be shown that this method 1116 results in significantly better time transfer accuracy than methods 1117 that do not discipline a local clock. 1119 Time transfer mechanisms can be divided into three classes. The 1120 first class consists of mechanisms that use radio frequency 1121 transport, while the second mechanism uses dedicated "wires" (which 1122 for our purposes include optical fibers). The third, which will be 1123 our main focus, exploits a Packet Switched Network for transfer of 1124 timing information. Advantages and disadvantages of these three 1125 methods are discussed in the following subsections. 1127 A.1. Radio-based Timing Transfer Methods 1129 The transfer of time by radio transmission is one of the oldest 1130 methods available, and is still the most accurate wide area method. 1131 In particular, there are two navigation systems in wide use that can 1132 be used for time transfer, The LOng RAnge Navigation (LORAN) 1133 terrestrial radio system, and the Global Navigation Satellite System 1134 (GNSS). In both cases the user needs to be able to receive the 1135 transmitted signal, requiring access to a suitable antenna. In 1136 certain situations, e.g. basement communications rooms and urban 1137 canyons, the required signal may not be receivable. 1139 Radio systems have high accuracy, far better than what we will later 1140 see can be achieved by existing PSN technologies. However coverage 1141 is limited; eLORAN for example only covers North America, and GPS 1142 does not have good coverage near the poles. 1144 Although civilian use is sanctioned, the GPS was developed and is 1145 operated by the U.S. Department of Defense as a military system. For 1146 this reason there are political concerns that rules out its use in 1147 certain countries. The European Union is working on an alternative 1148 system called Galileo, which will be run as a commercial enterprise. 1149 In addition, GPS has some well-documented multi-hour outages, and is 1150 considered vulnerable to jamming. One major PTT also reports that 1151 they see a 2% per year failure rate for the antenna/receiver/ 1152 clock-out chain. 1154 While a radio-based timing service may be acceptable for some sites, 1155 it is frequently impractical to use on a per equipment basis. Hence, 1156 some form of local timing distribution is usually also required. 1158 A.2. Dedicated Wire-based Timing Transfer Methods 1160 The use of dedicated networks in the wide area does not scale well. 1161 Such services were available in the past, but for reasons of cost and 1162 accuracy have been superseded by GPS based solutions. 1164 In the local area, one new technique is emerging as a mechanism for 1165 time transport, namely DOCSIS Timing Interface(DTI). DTI was 1166 designed by DOCSIS for the distribution of time in a cable head-end 1167 in support of media access control. Time transfer is packet-based 1168 over a multi-stage hub and spoke dedicated network. It uses a single 1169 twisted-pair in half-duplex to eliminate inaccuracies due to the 1170 length differences between the pairs in a multi-pair cable. 1172 The DTI approach is applicable for special applications, but the need 1173 for a dedicated network imposes significant drawbacks for the general 1174 time transfer case. 1176 Synchronous Ethernet is a technique that has recently been approved 1177 by ITU-T, it provides frequency distribution over Ethernet links. 1178 Modern dedicated-media full-duplex Ethernet, in both copper and 1179 optical physical layer variants, transmits continuously. One can 1180 thus elect to derive the physical layer transmitter clock from a high 1181 quality frequency reference, instead of the conventional 100 ppm 1182 crystal-derived transmitter rate. The receiver at the other end of 1183 the link automatically locks onto the physical layer clock of the 1184 received signal, and thus itself gain access to a highly accurate and 1185 stable frequency reference. Then, in TDM fashion, this receiver 1186 could lock the transmission clock of its other ports to this 1187 frequency reference. Apart from some necessary higher layer packet 1188 based configuration and OAM operations to transport synchronization 1189 status messaging, the solution is entirely physical layer, and has no 1190 impact on higher layers. 1192 At first sight it would seem that the only application of Synchronous 1193 Ethernet was in frequency transfer (it has no intrinsic time transfer 1194 mechanism). However, the quality of packet-based time transfer 1195 mechanism can be considerably enhanced if used in conjunction with 1196 Synchronous Ethernet as a frequency reference. 1198 A.3. Transfer Using Packet Networks 1200 When using a PSN to transfer timing, a server sends timing 1201 information in the form of packets to one or multiple clients. When 1202 there are multiple clients, the timing packets may be multicast. 1203 Software/hardware in the client recovers the frequency and/or time of 1204 the server based on the packet arrival time and the packet contents. 1206 There are two well-known protocols capable of running over a general- 1207 purpose packet network, NTP [RFC1305], and IEEE 1588 [1588]. NTP is 1208 the product of the IETF, and is currently undergoing revision to 1209 version 4. PTP (a product of the IEEE Test and Measurement 1210 community) is specified in a limited first version (1588-2002), and 1211 the second version (1588-2008)was approved recently. 1213 It is important that NTP, IEEE-1588 or any other future packet based 1214 time transfer mechanism do not break each other if they run in the 1215 same network. 1217 A.3.1. NTP summary description 1219 NTP is widely deployed, but existing implementations deliver accuracy 1220 on the order of 10 milliseconds. This accuracy is not adequate for 1221 the applications described above. Current NTP suffers from the fact 1222 that it was designed to operate over the Internet, and the routers 1223 and switches make no special concessions to NTP for preservation of 1224 time transfer accuracy. Furthermore, typical update rates are low 1225 and can not be significantly increased due to scalability issues in 1226 the server. In addition most NTP time servers and time receivers 1227 have a relatively unsophisticated implementation that further 1228 degrades the final time quality. However, proprietary NTP 1229 implementations that use other algorithms and update-rates have 1230 proved that NTP packet formats can be used for higher accuracy. 1232 A.3.2. IEEE1588 summary description 1234 The information exchange component of IEEE 1588 is a protocol known 1235 as Precision Time Protocol (PTP). PTP version 1 (1588-2002) was a 1236 time transfer protocol that exclusively used multicast technique and 1237 it was primarily developed for Industrial Automation and Test and 1238 Measurement applications. It is widely anticipated that wide scale 1239 deployment of PTP will be based on PTP version 2 (1588-2008). 1241 IEEE Std 1588-2008 can be considered to consist of several 1242 components: 1244 1. A configuration and control protocol 1246 2. A time transfer protocol 1248 3. A time correction protocol 1250 4. Physical mapping 1252 The configuration and control protocol is based on the multicast 1253 approach of IEEE Std 1588-2002 (multicast IP with recommended TTL=1, 1254 UDP, PTP payload with equipment identifier in the payload). The 1255 rationale for this approach was that the equipment needed to be "plug 1256 and play" (no configuration), was required to map to physical media 1257 other than Ethernet, and had to have a very low memory and processor 1258 footprint. IEEE Std 1588-2008 includes Unicast messages. 1260 The time transfer protocol is a standard two-way time transfer 1261 approach used in other packet-based approaches. Like all such 1262 approaches it is subject to inaccuracies due to variable store and 1263 forward delays in the packet switches, and due to the assumption of 1264 symmetric propagation delays. For IEEE Std 1588-2008, the time 1265 transfer packets (in both directions) may be operated in a multicast 1266 or unicast mode. 1268 The time correction protocol is used to correct for propagation, 1269 store and forward delays in the packet switches. This again may be 1270 operated multicast or unicast. This mechanism requires some level of 1271 hop-by-hop hardware support. This mechanism may also be considered a 1272 concept in its own right and may be adapted to enhance other packet 1273 time transfer protocols such as NTP. 1275 The IEEE Std 1588-2008 specification describes how the PTP operates 1276 over the Ethernet/IP/UDP protocol stack. It includes annexes that 1277 describe PTP operation over pure layer 2 Ethernet, and over a number 1278 of specialist media. 1280 The mappings of interest for telecommunications are PTP over UDP/IP, 1281 PTP over MPLS , and perhaps PTP over Ethernet. They may operate in 1282 unicast or multicast. Issues of a suitable control management and 1283 OAM environment for these applications are largely in abeyance, as 1284 are considerations about the exact nature of the network environment. 1286 It is also worth noting the existence of a second IEEE effort, IEEE 1287 802.1AS. This group is specifying the protocol and procedures to 1288 ensure synchronization across Bridged and Virtual Bridged Local Area 1289 Networks for time sensitive applications such as audio and video. 1290 For these LAN media the transmission delays are assumed to be fixed 1291 and symmetrical. IEEE 802.1AS specifies the use of IEEE 1588 1292 specifications where applicable in the context of IEEE Standards 1293 802.1D and 802.1Q. Synchronization to an externally provided timing 1294 signal (e.g., a recognized timing standard such as UTC or TAI) is not 1295 part of this standard but is not precluded. IEEE 802.1AS will 1296 specify how stations attached to bridged LANs to meet the respective 1297 jitter, wander, and time synchronization requirements for time- 1298 sensitive applications. 1300 Appendix B. Other Forums Working in this Problem Space 1302 The NTP WG is the IETF group working on time distribution, but is 1303 presently only documenting NTPv4 and is not working on new algorithms 1304 or protocols. It is expected that many participants of the NTP WG 1305 will participate in the TICTOC effort. 1307 The PWE3 WG has discussed frequency distribution for the TDM PW 1308 application, however it is not chartered to develop protocols for 1309 this purpose. It is expected that participants of the PWE3 WG who 1310 were active in the TDM PW discussions will participate in the TICTOC 1311 effort. 1313 The IEEE approved the version 2 of the IEEE 1588 protocol (IEEE Std 1314 1588- 2008) that will run over more types of PSNs. The protocol to 1315 be specified contains elements that will be of use in an IETF 1316 environment, but is unlikely to be regarded as being a complete, 1317 robust solution in such an environment. If the IEEE 1588 structure 1318 is deemed to be a suitable platform, then the IETF could contribute 1319 an Internet profile, including a complete distributed systems 1320 environment suitable for our purposes. Alternatively, the IETF could 1321 perhaps borrow some of the delay correction mechanisms and 1322 incorporate them into a development of a new version of NTP. 1324 In addition, IEEE 802.1AS is working on Timing and Synchronization 1325 for Time-Sensitive Applications in Bridged Local Area Networks, 1326 basing itself on the IEEE 1588 standard. 1328 ITU-T SG15 Question 13 has produced Recommendation G.8261 "Timing and 1329 synchronization aspects in packet networks" [G8261]. This 1330 Recommendation defines requirements for various scenarios, outlines 1331 the functionality of frequency distribution elements, and provides 1332 measurement guidelines. It does not specify algorithms to be used 1333 for attaining the performance needed. ITU-T has also consented 1334 G.8262 "Timing Characteristics of Synchronous Ethernet Equipment 1335 Slave Clock (EEC)" [G8262], and G.8264 "Distribution of timing 1336 through packet networks" [G8264]. G.8262 specifies the requirements 1337 for Synchronous Ethernet clocks and G.8264 defines the protocol for 1338 Synchronization Status Message (SSM) for Synchronous Ethernet. To 1339 date the ITU-T has focused on Ethernet infrastructure, but this is 1340 likely to extend to an MPLS environment. Two new work items, 1341 G.paclock.bis and G.pacmod.bis extend the work, and in particular, 1342 G.pacmod.bis intends to introduce time transfer. The scope for 1343 G.paclock.bis is to define the requirements for packet-based clocks. 1344 This is an area where the IETF, with its expertise in IP and MPLS 1345 networks, may co-operate with the ITU. 1347 Authors' Addresses 1349 Silvana Rodrigues 1350 Zarlink Semiconductor 1351 400 March Road 1352 Ottawa K2K 3H4 1353 Canada 1355 Phone: +1 613 2707258 1356 Email: silvana.rodrigues@zarlink.com 1357 Kurti Erik Lindqvist 1358 Netnod 1359 Bellmansgatan 30 1360 Stockholm S-118 47 1361 Sweden 1363 Phone: +46 708 30 60 01 1364 Email: kurtis@kurtis.pp.se