idnits 2.17.1 draft-bryant-tictoc-probstat-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 663. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 674. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 681. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 687. 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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 574: '...ransfer services MUST be protected fro...' RFC 2119 keyword, line 581: '... SHOULD also be relatively lightweig...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 19, 2007) is 6299 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 (~~), 1 warning (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TICTOC S. Bryant 3 Internet-Draft Cisco Systems 4 Intended status: Informational Y(J). Stein 5 Expires: July 23, 2007 RAD Data Communications 6 January 19, 2007 8 TICTOC Problem Statement 9 draft-bryant-tictoc-probstat-00.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on July 23, 2007. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 This Internet draft describes a number of applications that require 43 accurate time and/or frequency, and elucidates difficulties related 44 to the transfer of high quality time and frequency across an IP or 45 MPLS Packet Switched Network. This issue is not addressed by any 46 currently chartered IETF working group, and we therefore propose the 47 formation of a new working group to be called Transmitting Timing 48 over IP Connections and Transfer of Clock (TICTOC). 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Applications . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2.1. Time Service Applications . . . . . . . . . . . . . . . . 3 55 2.2. Frequency Service Applications . . . . . . . . . . . . . . 4 56 3. Existing Time and Frequency Transfer Mechanisms . . . . . . . 7 57 3.1. Radio-based Timing Transfer Methods . . . . . . . . . . . 7 58 3.2. Dedicated Wire-based Timing Transfer Methods . . . . . . . 8 59 3.3. Transfer Using Packet Networks . . . . . . . . . . . . . . 9 60 3.3.1. The Packet Network Environment . . . . . . . . . . . . 11 61 4. Problems with Existing Solutions . . . . . . . . . . . . . . . 11 62 5. Other Forums Working in this Problem Space . . . . . . . . . . 12 63 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 64 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 65 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 66 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 67 10. Informative References . . . . . . . . . . . . . . . . . . . . 14 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 69 Intellectual Property and Copyright Statements . . . . . . . . . . 16 71 1. Introduction 73 There is an emerging need to distribute highly accurate time and 74 frequency information over IP and over MPLS packet switched networks 75 (PSNs). In this problem statement we give several examples of 76 applications that require time and/or frequency information, and 77 explain why their needs can not be satisfied by time/frequency 78 transfer over PSNs using existing protocols. We review these 79 existing protocols and the work being carried out in the IETF and in 80 other forums. Finally, we list the objectives of a proposed Working 81 Group. 83 2. Applications 85 2.1. Time Service Applications 87 There are many applications that need to know the time with greater 88 precision than provided by available mechanisms, such as the current 89 version of NTP [RFC1305]. These applications span a range of 90 industries: telecommunications, financial, test and measurement, 91 government, industrial etc. Preliminary studies indicate that the 92 availability of high accuracy time as a commodity enables use of 93 techniques that were previously considered impossible. We can, 94 therefore, expect that the provision of high quality time through the 95 network infrastructure will generate a spiral of new innovative 96 applications that will in turn make greater demands on the quality of 97 time delivered to the end-user. 99 The best-known example of an application that requires high quality 100 time in the telecommunications sector is the need to measure one-way 101 packet delay. Current implementations of NTP have accuracy of the 102 order of 10 milliseconds. When NTP is used to characterize packet 103 delay and packet delay variation, such a time-base cannot resolve any 104 two party event with a resolution of better than 20 milliseconds. 105 Contrast this with the characteristics of a 10 Gb/s link, 1 kilometer 106 long. On such a link, a minimum sized packet takes 50 nanoseconds to 107 send, and it takes 6 microseconds to traverse the link. The 108 performance of current NTP implementations is orders of magnitude 109 worse than the duration of network forwarding events, and clearly 110 insufficient to characterize them. 112 Although the measurement of the characteristics of a packet network 113 is the best-known telecommunications example, there are other 114 operational needs, notably synchronization at the MAC layer. The 115 cable industry has recently defined a new intra-PoP time transmission 116 mechanism for just this purpose (DOCSYS Timing Interface), and WiMAX 117 is looking for relative time delivery to its transmitter sites. 119 In the test and measurement and industrial sector there is a desire 120 to move from special purpose communications infrastructure with 121 calibrated wiring run back to a centralize controller, to a 122 distributed system, in which instructions are distributed in advance 123 to be executed at a predetermined time, and in which measurements are 124 taken remotely and communicated back to a common point for later 125 correlation and analysis. Two examples of this tendency are 126 described below. 128 In the printing industry there is a need to control operations in 129 multi-stand printing machines. The paper travels through these 130 machines at a speed of nearly 100 km/h. At these speeds, co- 131 ordination error of 1 microsecond between operations taking place at 132 different positions in the machine produces a 0.03mm color offset, 133 which is visible to the naked eye and results in an unacceptable 134 degradation in quality. 136 In the electrical power industry there is a need to improve the 137 measurement of power flows in order to monitor and predict usage 138 patterns. One proposal is to extensively deploy synchro-phasors in 139 the power network and to correlate their output to determine demand. 140 These devices need to be able to determine the time of measurement 141 with an accuracy of 1 microsecond. 143 More generally, there is growing interest in clock synchronization in 144 massively parallel sensor networks. Advances in wireless 145 communications have enabled the development of low power miniature 146 sensors that collect and disseminate data from their immediate 147 environment. Although each sensor has limited processing power, 148 through distributed processing the network becomes capable of 149 performing various tasks of data fusion, but only assuming a common 150 time base can be established. 152 The examples cited above are a small illustration of a trend that 153 will continue to grow as designers realize that better scaling can be 154 achieved with action-in-the-future, measure-and-correlate-later 155 approaches to systems design. 157 Closer to the core interests and expertise of the IETF there is an 158 emerging opinion that the availability of time as a commodity may 159 simplify the protocols that we use in distributed systems. 161 2.2. Frequency Service Applications 163 There are applications that require time with a greater precision 164 than can easily be provided using available mechanisms. Cellular 165 base-stations require a highly accurate frequency reference from 166 which they derive transmission frequencies and operational timing. 168 Conventionally GSM and WCDMA base stations obtain this reference 169 frequency by locking on to the E1/T1 that links them to the base 170 station controller. With the replacement of TDM links with Packet 171 Switched Networks (PSNs) such as Ethernet, IP or MPLS, this simple 172 method of providing a frequency reference is lost, and frequency 173 information must be made available in some other way. 175 Why must the frequency reference be so accurate? First and foremost 176 the requirement is derived from the need for the radio frequencies to 177 be accurate. Radio spectrum is a limited and valuable commodity that 178 needs to be used as efficiently as possible. In GSM, transmission 179 frequencies are allocated to a given cellular base station and its 180 neighbors in such fashion as to ensure that they do not interfere 181 with each other. If the radio network designer cannot rely on the 182 accuracy of these frequencies, the spacing between the frequencies 183 used by neighboring sites must be increased, with significant 184 economic consequences. 186 There is an additional requirement derived from the need for smooth 187 handover when a mobile station crosses from one cell to another. If 188 the radio system designer can not guarantee that the preparations 189 required for handover occur in a few milliseconds, then they must 190 allow the mobile station to consume frequency resources 191 simultaneously in both cells in order to avoid service disruption. 192 The preparations required involve agreement between the mobile and 193 base stations on the new frequencies and time offsets; these 194 agreements can be accomplished quickly when the two base stations' 195 frequency references are the same to a high degree of accuracy. 197 Another application requiring highly accurate frequency distribution 198 is TDM pseudowires. The PWE3 WG has produced three techniques for 199 emulating traditional low-rate (E1, T1, E3, T3) TDM services over 200 PSNs, namely SAToP [RFC4553], CESoPSN, and TDMoIP. The major 201 technical barrier to universal acceptance of TDM pseudowires is the 202 accuracy of its clock recovery. 204 TDM network standards for timing accuracy and stability are extremely 205 demanding. These requirements are not capriciously dictated by 206 standards bodies, rather they are critical to the proper functioning 207 of a high-speed TDM network. Consider a TDM receiver utilizing its 208 own clock when converting the physical signal back into a bit-stream. 209 If the receive clock runs at precisely the same rate as the source 210 clock, then the receiver need only determine the optimal sampling 211 phase. However, with any mismatch of clock rates, no matter how 212 small, bit slips will eventually occur. For example, if the receive 213 clock is slower than the source clock by one part per million (ppm), 214 then the receiver will output 999,999 bits for every 1,000,000 bits 215 sent, thus deleting one bit. Similarly, if the receive clock is 216 faster than the source clock by one part per billion (ppb), the 217 receiver will insert a spurious bit every billion bits. One bit slip 218 every million bits may seem acceptable at first glance, but 219 translates to a catastrophic two errors per second for a 2 Mb/s E1 220 signal. ITU-T recommendations permit a few bit slips per day for a 221 low-rate 64 kb/s channel, but strive to prohibit bit slips entirely 222 for higher-rate TDM signals. 224 In certain cases, such as "toll-bypass" or "carrier's carrier" links, 225 the endpoints of the TDM PW are full TDM networks, and timing may 226 (indeed must) be derived from the respective network clocks. Since 227 each of these clocks is highly accurate, they necessarily agree to 228 high order. However, TDM PWs are expected to increasingly replace 229 native TDM links delivering services from core networks towards 230 users, and here there is no alternative to provision of accurate 231 frequency information. 233 In this context there are two types of frequency distribution being 234 studied. In the first type the frequency reference used by the TDM 235 source is distributed downstream, as in the native TDM service. In 236 the "common clock" scenario highly accurate frequency information is 237 distributed from a central server to both ends of the emulated TDM 238 link. By placing in the protocol overhead timestamps based on the 239 common clock, the receiver can accurately recover the TDM source 240 clock. 242 While it is true that services designed for PSN (e.g. VoIP) 243 transport are less dependent on frequency accuracy, there are still 244 cases where such services need accurate frequency distribution. For 245 example, when interconnecting tradition telephones via VoIP links, 246 users expect these links to support legacy services, such as 247 facsimile and dial-up data modems. The optimal technique for 248 supporting these services is by provision of relay functions, e.g. 249 T.38 fax-relay and V.150 modem-relay, that terminate the analog 250 transmissions on both sides and transfer data content over the PSN. 251 However, provision of relay services is computationally expensive, 252 often requires expensive DSP-capable media gateways, and can only 253 support known modem types. In many deployments old fax machines or 254 proprietary data modems or secure voice telephones are used, and the 255 modulations and handshake protocols are not recognized by the relays 256 provided. In such cases the solution is to carry these transmissions 257 over "clear channel" or Voice Band Data (VBD), i.e. to send raw 258 samples of the audio in packets over the PSN. 260 The problem with clear channel transfer of data over PSNs is that the 261 end points expect a non-intrusive analog channel between them, over 262 which they implicitly transfer timing information. The receiver can 263 thus continually lock onto the transmitter's frequency, and the 264 transmission can continue for an unlimited period without 265 interruption. When employing clear channel, the frequency signal 266 seen by the receiver is influenced by the destination gateway's clock 267 used to convert the data samples back to analog form. If the source 268 and destination gateways' clocks do not agree to a high degree of 269 accuracy, the receiver does not properly lock onto the transmitter's 270 clock, leading to disruption of the data reception. In typical cases 271 a modem conversation transferred over clear channel may drop after 272 only several minutes, and fax reception may be interrupted after 273 several pages have been received. 275 3. Existing Time and Frequency Transfer Mechanisms 277 In this section we will discuss existing mechanisms for transfer of 278 time information, frequency information, or both. It should be noted 279 that a sufficiently accurate time transfer service may be used to 280 derive an accurate frequency transfer. Indeed, this is exactly what 281 happens in a GPS disciplined frequency standard. On the other hand, 282 an accurate frequency transfer service, while itself unable to 283 transfer absolute time, is usually used to support and improve the 284 performance of the time transfer service. Indeed, implementations of 285 NTP or IEEE 1588 clients can be considered to consist of two phases. 286 First, a local oscillator is locked to the server's frequency using 287 incoming information from the incoming packets, and then the local 288 time set based on the server's time and the propagation latency. By 289 maintaining a local frequency source, the client requires relatively 290 infrequent updates, and can continue functioning during short periods 291 of network outage. Moreover, it can be shown that this method 292 results in significantly better time transfer accuracy than methods 293 that do not discipline a local clock. 295 Time transfer mechanisms can be divided into three classes. The 296 first class consists of mechanisms that use radio frequency 297 transport, while the second mechanism uses dedicated "wires" (which 298 for our purposes include optical fibers). The third, which will be 299 our main focus, exploits a Packet Switched Network for transfer of 300 timing information. Advantages and disadvantages of these three 301 methods are discussed in the following subsections. 303 3.1. Radio-based Timing Transfer Methods 305 The transfer of time by radio transmission is one of the oldest 306 methods available, and is still the most accurate wide area method. 307 In particular, there are two navigation in wide use that can be used 308 for time transfer, The LOng RAnge Navigation (LORAN) terrestrial 309 radio system, and the Global Navigation Satellite System (GNSS). In 310 both cases the user needs to be able to receive the transmitted 311 signal, requiring access to a suitable antenna. In certain 312 situations, e.g. basement communications rooms and urban canyons, the 313 required signal may not be receivable. 315 Radio systems have high accuracy, far better than what we will later 316 see can be achieved by existing PSN technologies. However coverage 317 is limited; eLORAN for example only covers North America, and GPS 318 does not have good coverage near the poles. 320 Although civilian use is sanctioned, the GPS was developed and is 321 operated by the U.S. Department of Defense as a military system. For 322 this reason there are political concerns that rules out its use in 323 certain countries. The European Union is working on an alternative 324 system called Galileo, which will be run as a commercial enterprise. 325 In addition, GPS has some well-documented multi-hour outages, and is 326 considered vulnerable to jamming. One major PTT also reports that 327 they see a 2% per year failure rate for the antenna/receiver/ 328 clock-out chain. 330 While a radio-based timing service may be acceptable for some sites, 331 it is frequently impractical to use on a per equipment basis. Hence, 332 some form of local timing distribution is usually also required. 334 3.2. Dedicated Wire-based Timing Transfer Methods 336 The use of dedicated networks in the wide area does not scale well. 337 Such services were available in the past, but for reasons of cost and 338 accuracy have been superseded by GPS based solutions. 340 In the local area, one new technique is emerging as a mechanism for 341 time transport, namely DOCSIS Timing Interface / Telecommunications 342 Timing Interface (DTI/TTI). DTI was designed by DOCSIS for the 343 distribution of time in a cable head-end in support of media access 344 control. Time transfer is packet-based over a multi-stage hub and 345 spoke dedicated network. It uses a single twisted-pair in half- 346 duplex to eliminate inaccuracies due to the length differences 347 between the pairs in a multi-pair cable. TTI is a development of DTI 348 designed to provide synchronization in a telephone local office. 349 Accuracy for DTI is better than 5 nanoseconds and range is 100 feet 350 for DTI. This increases to 600 feet for TTI at some reduction in 351 packet rate and hence time quality. 353 The DTI/TTI approach is applicable for special applications, but the 354 need for a dedicated network imposes significant drawbacks for the 355 general time transfer case. 357 Synchronous Ethernet is a technique that has recently been proposed 358 for providing frequency distribution over Ethernet links. Modern 359 dedicated-media full-duplex Ethernet, in both copper and optical 360 physical layer variants, transmits continuously. One can thus elect 361 to derive the physical layer transmitter clock from a high quality 362 frequency reference, instead of the conventional 100 ppm crystal- 363 derived transmitter rate. The receiver at the other end of the link 364 automatically locks onto the physical layer clock of the received 365 signal, and thus itself gain access to a highly accurate and stable 366 frequency reference. Then, in TDM fashion, this receiver could lock 367 the transmission clock of its other ports to this frequency 368 reference. 370 The ITU-T is presently working on a specification for synchronous 371 Ethernet. Apart from some necessary higher layer packet based 372 configuration and OAM operations, the solution is entirely physical 373 layer, and has no impact on higher layers. 375 At first sight it would seem that the only application of synchronous 376 Ethernet was in frequency transfer (it has no intrinsic time transfer 377 mechanism). However, the quality of packet-based time transfer 378 mechanism can be considerably enhanced if used in conjunction with 379 synchronous Ethernet as a frequency reference. 381 3.3. Transfer Using Packet Networks 383 When using a PSN to transfer timing, a server sends timing 384 information in the form of packets to one or multiple clients. When 385 there are multiple clients, the timing packets may be multicast. 386 Software in the client recovers the frequency and/or time of the 387 server based on the packet arrival time and the packet contents. 389 There are two well-known protocols capable of running over a general- 390 purpose packet network, NTP [RFC1305], and IEEE 1588 [1588]. NTP is 391 the product of the IETF, and is currently undergoing revision to 392 version 4. IEEE 1588 (a product of the IEEE Test and Measurement 393 community) is specified in a limited first version, and the second 394 version (1588v2)is in the detailed design stage. 396 NTP is widely deployed, but existing implementations deliver accuracy 397 on the order of 10 milliseconds. This accuracy is not adequate for 398 the applications described above. NTP suffers from the fact that it 399 was designed to operate over the Internet, and the routers and 400 switches used in the best effort Internet make no special concessions 401 to NTP for preservation of time transfer accuracy. Furthermore, 402 typical update rates are low and can not be significantly increased 403 due to scalability issues in the server. In addition most NTP time 404 servers and time receivers have a relatively unsophisticated 405 implementation that further degrades the final time quality. 407 IEEE 1588v1 was a time transfer protocol that exclusively used a 408 fairly crude multicast technique. It is widely anticipated that wide 409 scale deployment of IEEE1588 will be based on 1588v2. The 410 information exchange component of IEEE 1588 is a protocol known as 411 Precision Time Protocol (PTP). 413 IEEE 1588v2 can be considered to consist of several components: 415 1. A configuration and control protocol 417 2. A time transfer protocol 419 3. A time correction protocol 421 4. Physical mapping 423 The configuration and control protocol is based on the multicast 424 approach of IEEE 1588v1 (multicast IP with recommended TTL=1, UDP, 425 IEEE1588 payload with equipment identifier in the payload). The 426 rationale for this approach was that the equipment needed to be "plug 427 and play" (no configuration), was required to map to physical media 428 other than Ethernet, and had to have a very low memory and processor 429 footprint. 431 The time transfer protocol is a standard two-way time transfer 432 approach used in other packet-based approaches. Like all such 433 approaches it is subject to inaccuracies due to variable store and 434 forward delays in the packet switches, and due to the assumption of 435 symmetric propagation delays. The time transfer packets (in both 436 directions) may be operated in a multicast or unicast mode. 438 The time correction protocol is used to correct for propagation, 439 store and forward delays in the packet switches. This again may be 440 operated multicast or unicast. This mechanism requires some level of 441 hop-by-hop hardware support. This mechanism may also be considered a 442 concept in its own right and may be adapted to enhance other packet 443 time transfer protocols such as NTP. 445 The base 1588 specification describes how the PTP operates over the 446 Ethernet/IP/UDP protocol stack. Annexes are planned that describe 447 PTP operation over pure layer 2 Ethernet, over IP without UDP, over 448 MPLS, and over a number of specialist media. 450 The mappings of interest for telecommunications are PTP over UDP/IP, 451 PTP over MPLS , and perhaps PTP over Ethernet, all in unicast mode 452 only. Issues of a suitable control management and OAM environment 453 for these applications are largely in abeyance, as are considerations 454 about the exact nature of the network environment. 456 It is also worth noting the existence of a second IEEE effort, IEEE 457 802.1AS. This group is specifying the protocol and procedures to 458 ensure synchronization across Bridged and Virtual Bridged Local Area 459 Networks for time sensitive applications such as audio and video. 460 For these LAN media the transmission delays are assumed to be fixed 461 and symmetrical. IEEE 802.1AS specifies the use of IEEE 1588 462 specifications where applicable in the context of IEEE Standards 463 802.1D and 802.1Q. Synchronization to an externally provided timing 464 signal (e.g., a recognized timing standard such as UTC or TAI) is not 465 part of this standard but is not precluded. IEEE 802.1AS will 466 specify how stations attached to bridged LANs to meet the respective 467 jitter, wander, and time synchronization requirements for time- 468 sensitive applications. 470 3.3.1. The Packet Network Environment 472 Packet delay variation, propagation asymmetry, and maximum 473 permissible packet rate all have a significant bearing on the 474 accuracy with which the client is able to determine absolute time. 475 Thus the network environment has a large bearing on the quality of 476 time that can be delivered. 478 Packet delay variation can to some extent be addressed by traffic 479 engineering, thus time transfer with a service provider network in 480 which suitable traffic engineering techniques had been applied might 481 reasonably be expected to deliver a higher quality time service than 482 can be achieved between two arbitrary hosts connected to the 483 Internet. Greater gains can probably be obtained by deploying 484 equipment that incorporates IEEE 1588 style on-the-fly packet 485 timestamp correction, or follow-up message mechanisms that report the 486 packet storage and forward delays to the client. However one can 487 only be sure that such techniques are available along the entire path 488 in a well-controlled environment. 490 The packet rate between the time-server and its client also has a 491 bearing on the quality of the time transfer, because at a higher rate 492 the smart filter has a better chance of extracting the "good" 493 packets. In a controlled environment it is possible to ensure that 494 there is adequate bandwidth, and that the server is not overloaded. 495 In such an environment the onus moves from protecting the server from 496 overload, to ensuring that the server can satisfy the needs of all of 497 the clients. 499 4. Problems with Existing Solutions 501 An obvious candidate for clock distribution is NTP or some upgrade 502 thereof. While the time resolution provided by NTP is extremely 503 good, the accuracy attainable by existing NTP implementations does 504 not satisfy the needs of the most demanding of the applications, 505 mainly due to update rate and the particular client/server method 506 employed. 508 The new IEEE 1588v2 protocol also addresses these needs, but has been 509 largely designed around a well-controlled LAN environment. A 1588 510 server in unicast mode needs to save state information for each 511 client, a solution that does not scale well to deployment sizes 512 envisioned. In addition, 1588 specifies hardware upgrades in order 513 to perform well in an IP network. 515 Synchronous Ethernet only satisfies the need for frequency 516 distribution, and even then only over one physical Ethernet link at a 517 time. In order to use synchronous Ethernet in a network, all network 518 elements must be upgraded to support synchronous operation at the 519 physical layer. Even when hardware can be upgraded, only frequency 520 is delivered, and there is still a need to develop a time transfer 521 protocol. 523 5. Other Forums Working in this Problem Space 525 The NTP WG is the IETF group working on time distribution, but is 526 presently only documenting NTPv4 and is not working on new algorithms 527 or protocols. It is expected that many participants of the NTP WG 528 will participate in the TICTOC effort. 530 The PWE3 WG has discussed frequency distribution for the TDM PW 531 application, however it is not chartered to develop protocols for 532 this purpose. It is expected that participants of the PWE3 WG who 533 were active in the TDM PW discussions will participate in the TICTOC 534 effort. 536 The work that is underway outside the IETF is either complementary to 537 this proposal, or less general than the proposal proposed by the 538 TICTOC work proposal. 540 The IEEE 1588 task force is working on a new version of their 541 protocol that will run over more types of PSNs, and is planning to 542 conclude its development work in the near future. The protocol to be 543 specified contains elements that will be of use in an IETF 544 environment, but is unlikely to be regarded as being a complete, 545 robust solution in such an environment. If the IEEE 1588 structure 546 is deemed to be a suitable platform, then the IETF could contribute 547 an Internet profile, including a complete distributed systems 548 environment suitable for our purposes. Alternatively, the IETF could 549 perhaps borrow some of the delay correction mechanisms and 550 incorporate them into a development of a new version of NTP. 552 In addition, IEEE 802.1AS is working on Timing and Synchronization 553 for Time-Sensitive Applications in Bridged Local Area Networks, 554 basing itself on the IEEE 1588 standard. 556 ITU-T SG15 Question 13 has produced Recommendation G.8261 "Timing and 557 synchronization aspects in packet networks" [G8261]. This 558 Recommendation defines requirements for various scenarios, outlines 559 the functionality of frequency distribution elements, and provides 560 measurement guidelines. It does not specify algorithms to be used 561 for attaining the performance needed. It does define requirements 562 for status synchronization messages, but does not otherwise define a 563 protocol (although work is in progress). To date the ITU-T has 564 focused on Ethernet infrastructure, but this is likely to extend to 565 an MPLS environment. Two new work items, G.paclock and G.pacmod 566 extend the work, and in particular, G.pacmod intends to introduce 567 time transfer. This is an area where the IETF, with its expertise in 568 IP and MPLS networks, may co-operate with the ITU. 570 6. Security Considerations 572 Time and frequency services are a significant element of network 573 infrastructure, and are critical for certain emerging applications. 574 Hence time and frequency transfer services MUST be protected from 575 being compromised. The most significant threat is a false time or 576 frequency server being accepted instead of a true one, thus enabling 577 a hacker to bring down critical services. 579 Any protection mechanism must be designed in such a way that it does 580 not degrade the quality of the time transfer. Such a mechanism 581 SHOULD also be relatively lightweight, as client restrictions often 582 dictate a low processing and memory footprint, and because the server 583 may have extensive fan-out. 585 7. Security Considerations 587 Timing distribution is highly sensitive to packet delay, and can thus 588 can deteriorate under congestion conditions. Furthermore the 589 disciplining of the client's oscillator (the sole component of 590 frequency transfer, and a critical component of time transfer) is a 591 function that should not be disrupted. When the service is disrupted 592 the client needs to go into "holdover" mode, and its accuracy will 593 consequently be degraded. Depending on the relative quality of the 594 client's clock and the required quality after disciplining, a 595 relatively high packet rate may be required. 597 Timing tranfer packets should always be sent using the highest class 598 of service, and when possible should be sent over a traffic 599 engineered path. 601 When the network goes into congestion it should try to avoid 602 discarding time transfer packets until the situation is critical. 603 Work performed by the IETF PWE3 WG on congestion would seem to be 604 applicable to this problem area. 606 8. IANA Considerations 608 No IANA actions are required as a result of the publication of this 609 document. 611 9. Acknowledgements 613 The authors wish to thank Laurent Montini for valuable comments. 615 10. Informative References 617 [1588] IEEE, "1588-2002 Standard for A Precision Clock 618 Synchronization Protocol for Networked Measurement and 619 Control Systems". 621 [G8261] ITU-T, "Recommendation G.8261/Y.1361 - Timing and 622 synchronization aspects in packet networks", May 2006. 624 [RFC1305] Mills, D., "Network Time Protocol (Version 3) 625 Specification, Implementation", RFC 1305, March 1992. 627 [RFC4553] Vainshtein, A. and YJ. Stein, "Structure-Agnostic Time 628 Division Multiplexing (TDM) over Packet (SAToP)", 629 RFC 4553, June 2006. 631 Authors' Addresses 633 Stewart Bryant 634 Cisco Systems 635 250 Longwater Ave., Green Park 636 Reading RG2 6GB 637 United Kingdom 639 Email: stbryant@cisco.com 640 Yaakov (Jonathan) Stein 641 RAD Data Communications 642 24 Raoul Wallenberg St., Bldg C 643 Tel Aviv 69719 644 ISRAEL 646 Phone: +972 3 645-5389 647 Email: yaakov_s@rad.com 649 Full Copyright Statement 651 Copyright (C) The IETF Trust (2007). 653 This document is subject to the rights, licenses and restrictions 654 contained in BCP 78, and except as set forth therein, the authors 655 retain all their rights. 657 This document and the information contained herein are provided on an 658 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 659 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 660 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 661 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 662 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 663 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 665 Intellectual Property 667 The IETF takes no position regarding the validity or scope of any 668 Intellectual Property Rights or other rights that might be claimed to 669 pertain to the implementation or use of the technology described in 670 this document or the extent to which any license under such rights 671 might or might not be available; nor does it represent that it has 672 made any independent effort to identify any such rights. Information 673 on the procedures with respect to rights in RFC documents can be 674 found in BCP 78 and BCP 79. 676 Copies of IPR disclosures made to the IETF Secretariat and any 677 assurances of licenses to be made available, or the result of an 678 attempt made to obtain a general license or permission for the use of 679 such proprietary rights by implementers or users of this 680 specification can be obtained from the IETF on-line IPR repository at 681 http://www.ietf.org/ipr. 683 The IETF invites any interested party to bring to its attention any 684 copyrights, patents or patent applications, or other proprietary 685 rights that may cover technology that may be required to implement 686 this standard. Please address the information to the IETF at 687 ietf-ipr@ietf.org. 689 Acknowledgment 691 Funding for the RFC Editor function is provided by the IETF 692 Administrative Support Activity (IASA).