idnits 2.17.1 draft-stein-tictoc-modules-03.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 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 977. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 988. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 995. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1001. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: Any security mechanism must be designed in such a way that it does not degrade the quality of the time transfer. Such a mechanism SHOULD also be relatively lightweight, as client restrictions often dictate a low processing and memory footprint, and because the server may have extensive fan-out. The mechanism also SHOULD not require excessive storage of client state in the master, nor significantly increase bandwidth consumption. -- 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 (03 Nov 2008) is 5653 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: 1 error (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TICTOC Tim Frost 2 INTERNET-DRAFT Greg Dowd 3 Intended Status: Informational Symmetricom 5 Karen O'Donoghue 6 US Navy 8 Expires: 03 May 2009 03 Nov 2008 10 Architecture for the Transmission of Timing over Packet Networks 11 draft-stein-tictoc-modules-03.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware have 17 been or will be disclosed, and any of which he or she becomes aware will 18 be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering Task 21 Force (IETF), its areas, and its working groups. Note that other groups 22 may also distribute working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference material 27 or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/1id-abstracts.html 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on May 03, 2009. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2008) 41 Abstract 43 This Internet draft proposes an architecture for the transmission of 44 timing over packet networks. It identifies the major functional 45 components, and maps the current solutions onto this framework. 47 Table of Contents 49 1. Introduction 3 50 1.1. TICTOC Layers 3 51 1.2. Generic TICTOC Client 4 52 1.3. TICTOC Functional Modules 5 53 2. Frequency Layer 7 54 2.1. Local Oscillator and Frequency Synthesizers 7 55 2.2. Frequency Distribution Protocols 8 56 2.3. Frequency Acquisition Algorithms 8 57 2.3.1. Packet Selection and Discard Algorithms 9 58 2.3.2. Filtering and Control Servos 9 59 2.3.3. Server Contribution 10 60 2.3.4. Reference Algorithm 10 61 2.4. Frequency Presentation 10 62 3. Time Layer 11 63 3.1. Time Distribution Protocols 11 64 3.2. Ranging 13 65 3.3. Time Presentation 13 66 4. Generic Modules 15 67 4.1. Security Mechanisms 15 68 4.2. Autodiscovery and Master Clock Selection 15 69 4.3. Redundancy and Fail-Over Mechanisms 17 70 4.4. OAM, SSM, and Performance Monitoring 17 71 4.5. Network Management 17 72 4.6. Application profiles 17 73 5. Network Support 18 74 5.1. Path Selection 18 75 5.2. Network and Traffic Engineering 18 76 5.3. Service Level Specifications and QoS settings 19 77 5.4. Routing considerations 19 78 5.5. On-path Support 20 79 6. Security Considerations 20 80 7. IANA Considerations 20 81 8. Acknowledgements 20 82 INFORMATIVE REFERENCES 21 83 AUTHORS' ADDRESSES 21 85 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 87 document are to be interpreted as described in [RFC2119]. 89 1. Introduction 91 In this document the term "timing" will be used to refer to recovery of 92 frequency and/or time (wall-clock). 94 There is an emerging need to distribute highly accurate time and 95 frequency information over IP and over MPLS packet switched networks 96 (PSNs). A variety of applications require time and/or frequency 97 information to a precision which existing protocols cannot supply. 99 Several other groups are working on related issues. For example, the NTP 100 Working Group in IETF is working on an upgrade of the long-standing 101 Network Time Protocol [RFC1305]. The IEEE has recently revised its 102 Precision Time Protocol (PTP) [IEEE1588]. The ITU-T has defined 103 Synchronous Ethernet, a physical layer technology for transfer of 104 frequency across native Ethernet [G.8261, G.8262]. 106 However, none of these efforts are sufficient by themselves to create a 107 complete and robust time and frequency transfer ecosystem in the IP and 108 MPLS network environment. The TICTOC (Timing over IP Connections and 109 Transmission of Clock) Working Group was created to develop solutions 110 that meet the needs of the various applications for timing over packet 111 networks. 113 This draft attempts to define an architecture for a TICTOC system, 114 identifying the various functional components, and considering the 115 support required from the network in order to assist the timing 116 recovery. 118 1.1. TICTOC Layers 120 The most general TICTOC system can be logically decomposed into two 121 layers, corresponding to the distribution of frequency and time, 122 respectively, carried over the network by a timing protocol as shown 123 in Figure 1. Examples of such timing protocols include Network Time 124 Protocol (NTP) [RFC1305] and Precision Time Protocol (PTP) 125 [IEEE1588]. 127 Specific TICTOC systems may consist of either or both layers. For 128 example, if time is not required for the application, then only the 129 frequency layer may be present. 131 In some cases there may be additional support from the network to 132 assist the timing distribution. For example, it may be possible to 133 use a physical layer technology such as Synchronous Ethernet to 134 distribute an accurate frequency. In this case, the timing protocol 135 is only required to distribute time. Other examples of network 136 support may include specific QoS settings for the timing protocol 137 flow, and routing constraints to ensure an optimum path. 139 |-------------------| |-------------------| 140 | Time distribution | | Time distribution | 141 |-------------------| |-------------------| 142 | Frequency distr. | | Frequency distr. | 143 |-------------------| |-------------------| 144 | Timing protocol | | Timing Protocol | 145 |-------------------| |-------------------| 146 | UDP | | UDP | 147 |-------------------| |-------------------| 148 | IP | | IP | 149 |-------------------| |-------------------| 150 | Layer 2 | | Layer 2 | 151 |-------------------| |-------------------| 152 | Layer 1 | | Layer 1 | 153 |-------------------| |-------------------| 154 | ---------- | 155 | / \ | 156 -------------| Network |------------- 157 \ / 158 \---------/ 160 Figure 1. TICTOC Layers 162 1.2. Generic TICTOC Client 164 Figure 2 shows a generic TICTOC client, consisting of separate 165 frequency and time acquisition modules, and the presentation modules 166 for each. 168 Network 169 | 170 v 171 +------+-------+ +--------------+ 172 | Frequency | | Frequency | 173 | Acquisition +----->-----+ Presentation +----->----- 174 | | | | 175 +------+-------+ +--------------+ 176 | 177 v 178 | 179 +------+-------+ +--------------+ 180 | Time | | Time | 181 | Acquisition +----->-----+ Presentation +----->----- 182 | | | | 183 +--------------+ +--------------+ 185 Figure 2. Generic TICTOC client 187 The frequency acquisition module is responsible for recovery of 188 frequency information distributed over a packet switched network 189 (PSN), such as IP or MPLS. This distribution is accomplished by use 190 of a frequency distribution protocol. The frequency distributed may 191 be derived from an international standard, or may be an arbitrary 192 frequency needed at some remote location. If the value of the 193 frequency itself is needed, then the output of this module is input 194 to the frequency presentation module that formats the frequency 195 according to application needs. Note that this format may be numeric 196 prepared for display, or may take analog form and be used for locking 197 or disciplining other analog frequencies. When time is needed, the 198 frequency information is sent to the time acquisition module. 200 Even if the frequency itself is not needed, time acquisition almost 201 always requires a stable frequency reference. This reference may be 202 acquired from the frequency acquisition layer, or may be obtained via 203 some other means, such as an accurate local frequency reference, or 204 from a non-PSN mechanism for frequency distribution (e.g., GPS, 205 SONET/SDH). 207 From the acquired or otherwise available frequency, we may derive 208 arbitrary time (also known as "phase") by mathematical means. If the 209 frequency reference is traceable to an international standard, then 210 arbitrary time means a sequence of time values that are synchronous 211 with true (wall-clock, UTC) time, but with an arbitrary offset. The 212 purpose of the time acquisition module is to enable multiple TICTOC 213 clients to share a single offset, and thus to agree as to marking of 214 phase values. Such marked phases values are all that is required for 215 certain applications, such as where multiple time-aware agents need 216 to interact (e.g., systems employing Time Division Multiple Access 217 systems). 219 When the time markings distributed by the time distribution protocol 220 are traceable to an international standard, the TICTOC clients are 221 said to have acquired wall-clock time. These wall-clock values are 222 formatted for use by the intended application by the time 223 presentation module. 225 1.3. TICTOC Functional Modules 227 The remainder of this document further subdivides these modules and 228 identifies the sub-modules needed for timing distribution. Sub- 229 modules may require one or more protocols, a set of processing 230 algorithms, and implementations. 231 The frequency acquisition module may be subdivided into the following 232 sub-modules. Not all need to be present in all implementations. 233 o local oscillator 234 o frequency generator (typically a digital synthesizer) 235 o timestamp generator 236 (not required if packets are sent at constant rate) 237 o frequency distribution protocol 238 o frequency acquisition algorithms 239 (may include packet selection algorithms, oscillator 240 disciplining and frequency adjustment techniques) 242 The time acquisition module may be subdivided into the following 243 additional sub-modules. Not all need to be present in all 244 implementations. 245 o time distribution protocol 246 o ranging algorithms 247 o clock adjustment techniques 248 o timestamp generation (already mentioned) 250 In addition, various generic modules may be needed, for either 251 frequency distribution, time distribution, or both. 252 o security 253 o autodiscovery and master clock selection 254 o redundancy and fail-over mechanisms 255 o OAM, synchronization status messaging, and performance 256 monitoring 257 o network management 258 o application profiles 260 Any timing protocols should operate over the general internet without 261 requiring specific support from the network. However, when operated 262 over a specific, managed network where support is available, the 263 accuracy of the time and frequency distribution will be enhanced. 264 Examples of network support include: 265 o path selection and/or self-organization 266 o network and traffic engineering for optimum transport of timing 267 protocols 268 o service level specifications and QoS settings 269 o routing considerations 270 o on-path support, e.g. PTP boundary or transparent clocks 272 2. Frequency Layer 274 There are applications that require an accurate frequency reference, but 275 do not require knowledge of absolute time. In addition, it is often 276 wise to acquire frequency for applications that require absolute time 277 but do not directly use frequency. 279 TICTOC is concerned with the network frequency transfer using packet 280 technology. Frequency may be transferred across a network using the 281 physical layer, such as through the use of a synchronous network 282 interface (for example Synchronous Ethernet [G.8262]). The use of the 283 physical layer may produce a higher quality frequency reference than 284 achievable using packet based network frequency transfer, but is outside 285 the scope of this document. 287 2.1. Local Oscillator and Frequency Synthesizers 289 TICTOC masters and clients both need local sources of frequency. For 290 masters, this may be provided by high quality Cesium clock with 291 extremely good long term accuracy, or by an atomic clock with 292 somewhat lower accuracy, but which is disciplined by comparison with 293 a better clock (e.g., by GPS). 295 Note that a pure frequency master that does not need to know time can 296 be standalone. 298 For clients, the local oscillator is usually a quartz crystal 299 oscillators. Such oscillators may be stable, special cut crystals 300 with double oven and temperature compensation, or lowly inexpensive 301 crystals. In either case the frequency derived from these 302 oscillators needs to be adjusted by the TICTOC frequency acquisition 303 module. This adjustment can be electronic (e.g. changing the control 304 voltage of a voltage controlled oscillator). 306 However, it is common practice not to directly adjust the physical 307 oscillator, or even to directly use the oscillator's frequency. 308 Instead, a digital synthesizer fed by the oscillator provides the 309 required output frequency. Changing parameters of the digital 310 synthesizer changes the output frequency in the required way. It is 311 important for the digital synthesizer not to introduce too much 312 jitter, and for the changing of parameters to be done in such fashion 313 as to minimize transients. 315 Disciplining of the local oscillator, or setting the parameters of 316 the digital synthesizer, is based on the arrival times of received 317 frequency distribution protocol packets, and the information 318 contained in them. When, for whatever reason, frequency distribution 319 packets are not received, the frequency layer is said to be in 320 "holdover mode". In holdover mode the local oscillator or 321 synthesizer is still used as usual, but it is no longer disciplined 322 based on new information from the distribution protocol (although it 323 may still be adapted, if the acquisition module has models that have 324 been trained during periods that the frequency distribution packets 325 were received). 327 2.2. Frequency Distribution Protocols 329 The protocol used to distribute frequency across the packet network 330 may be the same protocol used for time distribution, or may be an 331 independent protocol. The important design consideration is that the 332 protocol used is optimized for that purpose, and not compromised by 333 the need to fulfill a dual role. 335 Frequency distribution protocols are "one way", i.e. only require 336 information transfer from the master (where the frequency is known) 337 to the client. In particular, frequency distribution protocols can 338 be broadcast or multicast to many clients, without the master needing 339 to know the client identities. Frequency distribution protocols may 340 even operate when there is no return path available. Exceptions to 341 this rule are control messages sent by the client requesting 342 commencing or termination of the frequency distribution service, or 343 changing its parameters (e.g., update rate). 345 Frequency distribution protocols can be broadcast, multicast or 346 unicast. Multicast transmission conserves network bandwidth since 347 timing packets may be distributed to multiple clients or slaves. 348 However, unicast transmission is often more desirable, since it 349 avoids the multicast replication operation in each switch or router, 350 which may add variable delay. 352 The TICTOC architecture is modular, and not bound to the frequency 353 distribution protocol. It is possible to use different frequency 354 distribution methods for different applications and environments, 355 e.g. the use of physical layer frequency distribution protocols such 356 as Synchronous Ethernet. 358 2.3. Frequency Acquisition Algorithms 360 A TICTOC client needs to be able to recover the original timebase (or 361 frequency reference) of the master or server. In general it achieves 362 this by comparing the arrival time of packets with the original 363 sending time. From this it can determine the relationship between the 364 local timebase and the master timebase. 366 Observed arrival times of frequency distribution protocol packets are 367 influenced by two phenomena: 368 o frequency drift of the local oscillator relative to the master 369 oscillator (typically caused by temperature and voltage 370 fluctuations, and by aging phenomena) 371 o variation in delay of timing packets through the packet network 372 (PDV). 374 The former behavior needs to be tracked and compensated, while the 375 latter needs to be filtered out. In order to eliminate the effects 376 of PDV, frequency acquisition algorithms perform some sort of 377 averaging and/or filtering, in an attempt to recover the frequency at 378 which packets were sent. Typically this involves two steps: 379 o packet selection and discard algorithms 380 o filtering and control servos to "lock onto" the sending 381 frequency 383 2.3.1. Packet Selection and Discard Algorithms 385 In the simplest networks all frequency distribution packets 386 received are used by the frequency acquisition algorithms to 387 derive corrections to the local oscillator. A major problem with 388 frequency acquisition in complex networks is the elimination of 389 frequency distribution packets that, if used by the acquisition 390 algorithms, would degrade the quality of the recovered frequency. 391 Such packets are variously called outliers, falsetickers, etc. 393 There are several reasons for such unreliable packets. First, 394 malfeasants may deliberately inject false packets in order to 395 impair the TICTOC client's frequency recovery. We will discuss 396 security mechanisms below. Second, PDV distributions for complex 397 networks can be long tailed, leading to extremely misleading 398 results. Third, various network degradations, e.g., congestion 399 and reroute events, can lead to bizarre information being 400 received. 402 Furthermore, even typical packets may have experienced significant 403 delay variation, making them less suitable for exploitation than 404 the small fraction of packets that may have experienced almost no 405 delay (and thus minimal delay variation). When there is a 406 significant fraction of packets that experience essentially no 407 delay, it is reasonable to discard all others (assuming that after 408 this decimation the sampling rate is still sufficiently high). 410 2.3.2. Filtering and Control Servos 412 Since simple averaging would take too long to sufficiently 413 eliminate the stochastic components, by which time the frequency 414 difference between local oscillator and master oscillator would 415 have changed, more efficient "control loops" are employed. 416 Control loops are nonlinear mechanisms, and are thus able to "lock 417 onto" frequencies, rather than simply removing stochastic noise. 418 Conventional control loops include the Phase Locked Loop (PLLs), 419 the Frequency Locked Loops (FLL), and combinations of the two. 421 Delay variation effects can be quite complex and traffic 422 dependent. There are obvious effects such as queuing indeterminacy 423 leading to stochastic PDV, and congestion leading to packet loss. 424 There are also more subtle effects, for example multiple 425 plesiochronous flows (e.g. TDM pseudowires) traversing forwarding 426 elements can cause slow "beating" effects, generating low 427 frequency wander that is difficult to eliminate. Another example 428 is the batch processing effect introduced by some forwarders in 429 which the first of a series of packets experiences greater latency 430 that later packets. 432 Modern algorithms attempt to model the time behavior of local 433 oscillator as compared to the master oscillator, and/or the 434 network behavior. More complex algorithms may attempt blind 435 separation of the contribution of the two effects. 437 2.3.3. Server Contribution 439 Traditionally the focus on frequency acquisition algorithm design 440 has been on the client. However it is possible to mitigate some 441 of the aforementioned effects by modulating the packet generation 442 rate of the master. Thus TICTOC algorithm modules may describe 443 the client and the server components, and may require matching of 444 these algorithms to achieve optimal performance. 446 2.3.4. Reference Algorithm 448 Current technologies differ in how much of the algorithm is 449 defined. NTP defines the clock recovery algorithm completely, 450 while PTP only defines the on-the-wire protocol, leaving the clock 451 recovery algorithms undefined. Ultimately, multiple algorithms 452 may be required to suit different network environments and 453 application requirements. 455 Next-generation frequency acquisition algorithms need to be 456 optimized such that network bandwidth consumed by the frequency 457 distribution protocol is minimized. Furthermore, these algorithms 458 are required to be robust to network degradations such as packet 459 delay, packet loss, packet delay variation (PDV) and infrequent 460 stepwise changes in network traversal latencies (e.g., due to 461 reroute events or network loading changes). 463 It may be necessary to specify a reference algorithm for 464 comparison and validation purposes, but the TICTOC architecture 465 will enable vendors to employ proprietary algorithms. It will 466 also be possible to upgrade the reference algorithm in the future. 468 2.4. Frequency Presentation 469 In general, the output of the frequency acquisition module needs to 470 be reformatted before use. In some cases the reference frequency 471 distributed across the network is different from the frequency needed 472 by the local application; in such cases a digital synthesizer can be 473 employed to convert the acquired frequency to the desired one. 474 Sometimes it is not frequency itself that is required, but a sequence 475 of equally separated times; in such cases the sequence of time 476 "ticks" is generated from the acquired frequency (once again, digital 477 synthesizer is ideal for this). 479 3. Time Layer 481 In general the time layer is fed accurate frequency from the frequency 482 layer. There are applications that require accurate time, but do not 483 need to acquire frequency over the PSN. For example: 484 o if the update rate is high and the time resolution required 485 is low 486 o if highly accurate frequency is available locally 487 o if frequency is distributed by means external to the PSN 488 (e.g. GPS, LORAN, WWV) 489 o if frequency is available by means of the network physical 490 layer (e.g. PoS, SyncE). 492 In such cases the frequency input in Figure 2 is provided by the 493 alternative frequency source, rather than the frequency layer. The 494 TICTOC two layer decomposition is a conceptual one, and may not be 495 easily identifiable in all implementations. For example, when using a 496 pure PLL frequency acquisition module, true "frequency" is never 497 derived, only relative phase. Similarly, tracking mechanisms may 498 simultaneously model frequency and time, reducing convergence time by 499 adjusting both simultaneously, rather than first acquiring frequency, 500 and afterwards time. However, even in these cases the decomposition is 501 a useful one. 503 3.1. Time Distribution Protocols 505 The purpose of the time distribution protocol is to calibrate a 506 sequence of phase events generated by the local oscillator or digital 507 synthesizer, thus converting arbitrary offset phase values into wall- 508 clock values. This is done by sending packets containing timestamps 509 from the master (where the time is known) to the TICTOC client. In 510 order for the timestamp to accurately indicate the time that the 511 packet was actually injected into the network (rather than some 512 earlier time when the packet was formed, separated by a stochastic 513 time delay from the injection time), the timestamp should be 514 generated by the networking hardware. Providing any checksums or 515 CRCs can be updated on-the-fly, this hardware-generated timestamp may 516 be directly inserted into the packet. Alternatively, a subsequent 517 packet can be used to carry the measured injection time, as in the 518 PTP follow-up message. Where hardware assistance to measure the 519 injection time accurately is not available, the stochastic delay 520 should be minimized. 522 The timestamp in the time distribution protocol packet indicates the 523 time that the master injected this packet into the network. On the 524 other hand, the client receives this same packet after the 525 propagation delay, i.e. the time taken to traverse the packet 526 network. Were this time to be accurately known, the timestamp could 527 be corrected, and the precise time known. Estimation of the 528 traversal time is called ranging, and will be discussed below. PTP 529 has an optional mechanism (transparent clocks) whereby forwarding 530 delays, and even individual link delays are measured and compensated, 531 thus leading to precise knowledge of the traversal delay. However, 532 this mechanism requires upgrading of all intermediate network 533 elements. 535 Due to the requirement of traversal delay measurement, time 536 distribution protocols are generally bidirectional, that is, they 537 require a bidirectional channel, require both master and client to 538 send and receive messages, and usually assume symmetric (or known 539 asymmetry) propagation times. Unlike frequency distribution, time 540 distribution can not be entirely multicast, due to the ranging 541 requirement. 543 There are two well-known protocols capable of running over a general- 544 purpose packet network, NTP [RFC1305], and PTP [IEEE1588]. NTP is 545 the product of the IETF, and is currently undergoing revision to 546 version 4. PTP is a product of the IEEE Test and Measurement 547 community, and has recently been revised to better accommodate 548 telecommunication applications. The new version has a profiling 549 mechanism enabling organizations to specify required and prohibited 550 options, ranges and defaults of attribute values, and optional 551 features, while maintaining interoperability. 553 The protocol used to transfer the reference frequency across the 554 network may be the same protocol that is used to transfer time. The 555 overriding design consideration is that frequency and time 556 distribution protocols be optimized for their purpose, and not 557 compromised by the need to fulfill a dual role. 559 The TICTOC architecture itself is not bound to a specific time 560 distribution protocol. It is possible to upgrade, or replace this 561 protocol, for example to improved the quality of the transfer, or to 562 optimize the transfer for a different network environment, without 563 redesigning the entire TICTOC architecture. 565 3.2. Ranging 567 To transfer time it is necessary to know the time of flight of 568 packets from the time server to the client. The accuracy of time at 569 the client can be no better than the accuracy provide by the ranging 570 mechanism. Some ranging mechanisms require or can exploit special 571 hardware assistance by intermediate network elements, such as PTP 572 transparent clocks [IEEE1588]. 574 A typical ranging mechanism functions by exchanging timestamps 575 between master and client. For example, the master sends an initial 576 timestamped packet. When this packet arrives at the client its 577 arrival time (in terms of the local clock) is recorded. After some 578 amount of time the client sends a response packet back to the master, 579 containing the initial timestamp (in terms of the master clock), and 580 the packet arrival and retransmission times (in terms of the client 581 clock). When this packet is received by the master a fourth 582 timestamp is generated (in terms of the master clock). Since the 583 second and third timestamps are both in terms of the client clock, 584 their difference - representing the amount of time the client 585 hesitated between receipt of the initial packet and sending the 586 response packet - is readily computed. This difference can be 587 subtracted from the difference between the fourth and first 588 timestamps, to yield the sum of propagation times. Under the 589 assumption of symmetry, the one-way time is half this sum. Note that 590 since the difference between third and fourth timestamps is short, 591 possible frequency inaccuracy of the client has little deleterious 592 effect. 594 Various variations on this basic four-timestamp method are possible. 595 In the three timestamp method the client sends the time difference 596 (e.g., generated by resetting a timer upon packet arrival) rather 597 than the two timestamps. When symmetry is not a valid assumption, 598 additional information (e.g., ratio or difference between expected 599 propagation delays) can be used to extract the one-way delay. 601 Ranging accuracy is reduced by deviation from expected asymmetry in 602 the network. Mechanisms to avoid asymmetry at the network layer are 603 useful (for example using MPLS RSVP-TE paths, or the use of the peer- 604 to-peer mechanism described in IEEE1588), as is the ability to 605 correct asymmetry in the physical connection through the use of 606 external calibration. 608 3.3. Time Presentation 610 In general, the output of the time acquisition module needs to be 611 reformatted before use. Formatting includes translation between 612 different representations (e.g., from seconds after a given date to 613 date and time), changing time zones, etc. When the time needs to be 614 displayed, e.g., on a computer or mobile device, further processing 615 is often required, such as identification of day of week, translation 616 to other calendars (e.g., Hebrew, Islamic, Chinese), conversion 617 between TAI and UTC, and flagging of holidays and special dates. 619 4. Generic Modules 621 4.1. Security Mechanisms 623 Time and frequency services are a significant element of network 624 infrastructure, and are critical for certain emerging applications. 625 Hence time and frequency transfer services MUST be protected from 626 being compromised. The most significant threats are false timing 627 servers distributing purposely misleading timing packets, and man in 628 the middle tampering with valid timing packets. Both threats would 629 enable a malfeasant to mislead TICTOC clients, and to bring down 630 critical services. 632 Based on the aforementioned threats, one can conclude that 633 confidentiality and replay protection are usually not needed (and in 634 many cases not possible), but source authentication and integrity 635 protection are vital. In general, it is the master that needs to be 636 authenticated to the server, although in certain cases it may be 637 needed to authenticate the client to the master. 639 Applying IPsec Authentication Header (AH) mechanisms to all timing 640 packets is not feasible, due to the computational resources consumed 641 by public key cryptography algorithms. Adoption of IPsec would 642 impact time acquisition accuracy, and would lead to new methods for 643 malfeasants to disrupt the timing distribution protocols by 644 exhausting resources and denial of service from TICTOC clients. 645 Furthermore, certificates used to authenticate packets have lifetimes 646 that must be enforced for secure use. Certification of time packets 647 themselves can thus lead to circular dependence and to attacks that 648 invalidate valid time packets and substitute invalid ones. NTP 649 implementations provided an authentication protocol called Autokey. 650 Autokey utilizes public key algorithms to encrypt cookies, symmetric 651 key message digests for integrity, and digital signatures for source 652 authentication. 654 Any security mechanism must be designed in such a way that it does 655 not degrade the quality of the time transfer. Such a mechanism 656 SHOULD also be relatively lightweight, as client restrictions often 657 dictate a low processing and memory footprint, and because the server 658 may have extensive fan-out. The mechanism also SHOULD not require 659 excessive storage of client state in the master, nor significantly 660 increase bandwidth consumption. 662 4.2. Autodiscovery and Master Clock Selection 664 The topology of presently deployed synchronization networks is 665 universally manually configured. This requires manual or management- 666 plane configuration of master-client relationships, as well as 667 preconfigured fallback behaviors. This strategy is workable for SDH 668 networks, where there are a relatively small number of network 669 elements that require such configuration, and all elements are 670 controlled by a single entity. In packet switched network scenarios 671 there may be a very large number of independent network elements 672 requiring timing, making automatic mechanisms important. Such 673 autodiscovery, automatic master selection algorithms, and perhaps 674 control plane protocols to support these features, are important 675 features of the TICTOC architecture. 677 There are application scenarios where it is desirable for clocks to 678 advertise their service, and for clients to automatically select a 679 clock with the required accuracy and path characteristics. The 680 optimum advertising method may depend on the environment and the 681 application. For example a host may be best served by finding a 682 suitable clock (or set of clocks) through a DHCP parameter, whist a 683 provider edge may find it more convenient to discover the available 684 clock through BGP. 686 Once a TICTOC client has discovered potential TICTOC masters, it must 687 choose how to derive its clock from one or more of them. This choice 688 can be aided using two types of information: 689 o claims made by the potential masters as to the accuracy of its 690 local clock (see OAM and SSM below) 691 o analysis of the stability of frequency recovered from the 692 potential masters. 694 One tactic that a TICTOC client may employ is to individually choose 695 which master to use based on this information. Even if statically 696 configured to use a particular master, a client may be allowed to 697 make independent decisions when the master becomes unavailable or 698 sends synchronization status messages indicating a fault condition. 700 A second tactic is not to make a hard decision at all, but rather to 701 perform weighted ensemble averaging of frequencies recovered from all 702 available masters. The weightings, once again, may be based on 703 claims made by the masters or by monitoring of frequency stability. 705 Using either tactic, it is important to ensure that "timing loops" 706 are not formed. A timing loop is an erroneous topology that causes 707 locking onto frequencies not traceable to a high quality source. 708 Loops are avoided by ensuring that the frequency distribution paths 709 form a tree. 711 Yet another method is not to decide on a timing distribution tree at 712 all, but rather to enable self-organization of independently acting 713 intelligent agents. In such cases the meaning of master and client 714 becomes blurred, as all agents exchange timing information with a 715 subset neighbors that have been discovered. This method may be 716 driven by timing acquisition algorithms that guarantee global 717 convergence of the timing agents, meaning that over time the average 718 timing error decreases, although a given agent's error may sometimes 719 increase. 721 4.3. Redundancy and Fail-Over Mechanisms 723 Since synchronization is a critical function in many network 724 applications, operators conventionally protect it from single points 725 of failure. Redundant sources of synchronization are normally 726 provisioned, connected via diverse paths to prevent loss of 727 synchronization at the end station. 729 This is also required in packet synchronization. It may be necessary 730 to provision alternative paths, or techniques such as fast re-route 731 to ensure that connection between a time server and client devices is 732 not lost for too long. 734 4.4. OAM, SSM, and Performance Monitoring 736 In order to ensure continuity and connectivity of the path from the 737 master to the client, and the reverse path when needed, an 738 Operations, Administration, and Maintenance protocol may be needed. 739 When the master sends timing distribution packets at a constant rate, 740 faults are detected by the client after a few interpacket times; when 741 the rate is variable, the problem is detected after a few times the 742 maximum interpacket interval. However, in either case the master may 743 be unaware of the problem. 745 Synchronization Status Messages (SSMs) were traditionally used in TDM 746 networks to indicate the accuracy of the source upon which an 747 incoming TDM link based its timing, and to notify the remote site of 748 clock failures. Timing distribution protocols generally have similar 749 functions. 751 Performance monitoring is important to ensure the proper operation of 752 timing systems, and may be integrated into OAM mechanisms. 754 4.5. Network Management 756 As for all network infrastructure mechanisms, timing distribution 757 systems SHOULD be managed. This implies provision of management 758 agents in TICTOC masters and clients, and definition of the 759 appropriate MIBs. 761 4.6. Application profiles 763 PTP defines the concept of "profiles", defining the attributes and 764 options of the protocol required to support a given application. The 765 concept is extensible to other timing protocols, to ensure 766 interoperable components of a timing system. 768 Profiles are developed by standards organizations or other industry 769 bodies. For example, a "Telecom Profile" is currently under 770 definition by the ITU-T. The TICTOC working group will need to 771 specify the profile for the particular applications under its remit. 773 5. Network Support 775 5.1. Path Selection 777 In infrastructure applications it may be possible for TICTOC devices 778 to seek co-operation from routing elements to optimize the path 779 through the network in order to obtain a better quality of time and 780 frequency transfer that is possible when the timing distribution 781 protocol operates independent of the network layer. 783 At the simplest level this is use of paths that can support the 784 required quality of service, and have the lowest congestion impact. 785 However it is also possible for the network layer to be a proactive 786 partner in the transfer process. For example paths may be selected 787 on the basis of their symmetry, or such that all are capable of 788 supporting physical frequency transfer (for example Synchronous 789 Ethernet), or nodes may be selected such that they are all capable of 790 supporting transparent clock. 792 In addition to having to deal with degradation of service due to 793 congestion, TICTOC must not add to the problem. Thus, TICTOC timing 794 distribution protocols MUST be able to act in a TCP friendly way, 795 even at the expense of minor degradation of performance. In such 796 cases, it may be required for client to be informed of the change in 797 operating conditions. 799 5.2. Network and Traffic Engineering 801 Every network element (e.g. router or switch) in a packet network 802 adds varying amounts of delay to the packet. This variation is 803 typically correlated to the load on that network element at the time, 804 and especially to the shared load on the output port. 806 Therefore, there is some maximum limit on both the traffic load and 807 the number of network elements that a packet timing flow can traverse 808 before being degraded beyond the point at which the recovered time or 809 frequency is outside of the specification for the given application. 811 This maximum limit will change depending on: 812 o stringency of the application requirements 813 o stability and environment of the local oscillator at the 814 time/frequency client device 815 o traffic load in the network 816 o topology of the network 817 o physical layer aspects of the network. 819 When planning a time/frequency distribution service over a managed 820 network, the network planner must take these considerations into 821 account. These will influence the appropriate locations for the 822 time/frequency servers and any on-path support elements that may be 823 deployed. 825 Traffic engineering may be used to control the traffic load in the 826 network on the routes used by the timing flows. This may help to 827 control the delay variation in the timing flow, and hence improve the 828 performance of the clock recovered by the client. 830 5.3. Service Level Specifications and QoS settings 832 The traditional approach to specifying network performance has been 833 to define a series of metrics such as packet loss and packet delay 834 variation. However, these metrics are not good predictors of how a 835 packet timing scheme is going to perform. For instance, the packet 836 delay variation metric is too abstract, since it doesn't take into 837 account the distribution of delays, or the correlation of delays over 838 a longer interval. 840 Recent research has examined the application to PDV of new metrics 841 borrowed from synchronization standards such as TDEV and a modified 842 version called minTDEV [minTDEV]. The goal is to define a metric 843 that is both measurable and capable of continuous monitoring. This 844 can then form the basis of a service level specification for a 845 network capable of running time/frequency distribution to a given 846 performance level. 848 Further, the network operator needs to know how to tune the network 849 to stay within the specified limit, since no operator is going to 850 sign up to a service level specification that he has no control over. 851 Appropriate QoS settings and techniques must be deployed to ensure 852 the timing packets are forwarded through the routers in the optimum 853 way. 855 5.4. Routing considerations 857 The basic method for calculating a time offset of a remote slave 858 connected over a packet network makes an assumption that the network 859 delays in each direction are the same. Any asymmetry between the 860 forward and reverse directions yields an error in the time offset 861 estimation. 863 While there may be various inferences that an algorithm can make 864 concerning the size of that asymmetry, there are no currently known 865 techniques for directly calculating its magnitude. Therefore it is 866 important that the routing is constrained to make the packet flow 867 take the same path in each direction. This in itself will not 868 guarantee that the time delay is the same in each direction, but it 869 should minimize any difference. 871 5.5. On-path Support 873 The TICTOC architecture will be commensurate with the public 874 Internet, and the timing distribution protocol chosen will be able to 875 function over general packet switched networks. 877 In some cases on-path support (for example PTP transparent clocks) 878 may be needed in order to obtain the required frequency or time 879 accuracy. Such on-path support cannot be expected to be universally 880 available over the public Internet, and it is not a goal of the 881 TICTOC working group to propose augmentation of basic forwarding 882 elements. However, such on-path support may be provided on service 883 provider or enterprise networks, and in such cases TICTOC protocols 884 should be able to exploit it. 886 In networks with on-path support, it may be that the optimum path for 887 time transfer is not congruent with the optimum path for data 888 transfer. By using special-purpose IP addresses, and making routing 889 aware of the required path characteristics and address attributes, it 890 is possible to construct paths within the network that maintain the 891 required time transfer characteristics. 893 The TICTOC Working Group will specify the required path 894 characteristics and work with the ISIS and OSPF Working Groups to 895 specify the necessary routing extensions to support these 896 requirements. 898 TICTOC traffic may need to traverse NATs and firewalls. 900 6. Security Considerations 902 Security aspects of TICTOC have been addressed above. 904 7. IANA Considerations 906 No IANA actions are required as a result of the publication of this 907 document. 909 8. Acknowledgements 911 The authors wish to thank Yaakov Stein and Stewart Bryant for their 912 contributions in the development of this document, and also Alon Geva, 913 Gabriel Zigelboim, and Laurent Montini for invaluable comments. 915 INFORMATIVE REFERENCES 917 [IEEE1588] IEEE, "Standard for A Precision Clock Synchronization 918 Protocol for Networked Measurement and Control 919 Systems", IEEE1588-2008. 921 [G.8261] ITU-T, "Timing and Synchronization Aspects in Packet 922 Networks", G.8261, April 2008 924 [G.8262] ITU-T, "Timing characteristics of synchronous Ethernet 925 equipment slave clock (EEC)", G.8262, August 2007 927 [RFC1305] Mills, D., "Network Time Protocol (Version 3) 928 Specification, Implementation", RFC 1305, March 1992. 930 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 931 Requirement Levels", BCP 14, RFC 2119, March 1997. 933 [minTDEV] G. Zampetti and L. Cosart, "Definition of minTDEV", 934 COM15-C363-E, Contribution to ITU-T Study Group 15, 935 Question 13, May 2007 937 AUTHORS' ADDRESSES 939 Tim Frost, 940 Symmetricom Inc., 941 Tamerton Road, 942 Roborough, 943 Plymouth, PL6 7BQ, 944 United Kingdom. 945 Email: tfrost@symmetricom.com 947 Greg Dowd, 948 Symmetricom Inc., 949 2300 Orchard Parkway, 950 San Jose, 951 CA 95112, 952 USA. 953 Email: gdowd@symmetricom.com 955 Karen O'Donoghue 956 US Navy 957 Code B35, NSWCDD, 958 17320 Dahlgren Rd. 959 Dahlgren, 960 VA 22448, 961 USA. 962 Email: karen.odonoghue@navy.mil 963 Full Copyright Statement 965 Copyright (C) The IETF Trust (2008). 967 This document is subject to the rights, licenses and restrictions 968 contained in BCP 78, and except as set forth therein, the authors retain 969 all their rights. 971 This document and the information contained herein are provided on an 972 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR 973 IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE 974 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 975 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 976 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 977 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 979 Intellectual Property Statement 981 The IETF takes no position regarding the validity or scope of any 982 Intellectual Property Rights or other rights that might be claimed to 983 pertain to the implementation or use of the technology described in this 984 document or the extent to which any license under such rights might or 985 might not be available; nor does it represent that it has made any 986 independent effort to identify any such rights. Information on the 987 procedures with respect to rights in RFC documents can be found in BCP 988 78 and BCP 79. 990 Copies of IPR disclosures made to the IETF Secretariat and any 991 assurances of licenses to be made available, or the result of an attempt 992 made to obtain a general license or permission for the use of such 993 proprietary rights by implementers or users of this specification can be 994 obtained from the IETF on-line IPR repository at 995 http://www.ietf.org/ipr. 997 The IETF invites any interested party to bring to its attention any 998 copyrights, patents or patent applications, or other proprietary rights 999 that may cover technology that may be required to implement this 1000 standard. Please address the information to the IETF at ietf- 1001 ipr@ietf.org. 1003 Acknowledgement 1005 Funding for the RFC Editor function is provided by the Internet Society.