idnits 2.17.1 draft-stein-tictoc-modules-01.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 790. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 801. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 808. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 814. 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 (April 9, 2008) is 5858 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. -------------------------------------------------------------------------------- 2 TICTOC Y(J). Stein 3 Internet-Draft RAD Data Communications 4 Intended status: Informational S. Bryant 5 Expires: October 11, 2008 Cisco Systems 6 K. O'Donoghue 7 US Navy 8 April 9, 2008 10 TICTOC Modules 11 draft-stein-tictoc-modules-01.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 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on October 11, 2008. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2008). 42 Abstract 44 This Internet draft proposes the modularization of TICTOC 45 (Transmitting Timing over IP Connections and Transfer of Clock) work. 46 In particular, it breaks the work down into individual modules 47 (deliverables) that need to be developed. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Frequency Layer . . . . . . . . . . . . . . . . . . . . . . . 5 53 2.1. Local Oscillator and Digital Synthesizers . . . . . . . . 5 54 2.2. Frequency Distribution Protocols . . . . . . . . . . . . . 6 55 2.3. Packet Select/Discard Algorithms . . . . . . . . . . . . . 7 56 2.4. Frequency Acquisition Algorithms . . . . . . . . . . . . . 8 57 2.5. Frequency Presentation . . . . . . . . . . . . . . . . . . 9 58 3. Time Layer . . . . . . . . . . . . . . . . . . . . . . . . . . 9 59 3.1. Time Distribution Protocols . . . . . . . . . . . . . . . 9 60 3.2. Ranging . . . . . . . . . . . . . . . . . . . . . . . . . 11 61 3.3. Time Presentation . . . . . . . . . . . . . . . . . . . . 12 62 4. Other Modules . . . . . . . . . . . . . . . . . . . . . . . . 12 63 4.1. Security Mechanisms . . . . . . . . . . . . . . . . . . . 12 64 4.2. Autodiscovery and Master Clock Selection . . . . . . . . . 13 65 4.3. OAM, SSM, and Performance Monitoring . . . . . . . . . . . 14 66 4.4. Path Selection . . . . . . . . . . . . . . . . . . . . . . 15 67 4.5. On-path Support . . . . . . . . . . . . . . . . . . . . . 15 68 4.6. Network Management . . . . . . . . . . . . . . . . . . . . 16 69 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 70 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 71 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 72 8. Informative References . . . . . . . . . . . . . . . . . . . . 16 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 74 Intellectual Property and Copyright Statements . . . . . . . . . . 18 76 [Editor's Note: The present version of this draft contains references 77 to work to be performed by the TICTOC working group. This language 78 has been included in order to help with the chartering of this 79 working group, and will be removed in the next revision.] 81 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 82 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 83 document are to be interpreted as described in [RFC2119]. 85 1. Introduction 87 In this document the term "timing" will be used to refer to recovery 88 of frequency and/or time (wall-clock). 90 The most general TICTOC system can be logically decomposed into two 91 layers, corresponding to the distribution and presentation of 92 frequency and time, respectively, In Figure 1 we depict these layers, 93 and the top-level modules in these layers, for a TICTOC client. 94 Specific TICTOC systems may consist of either or both layers. For 95 example, if time is required but frequency is available from a 96 physical layer mechanism, then the frequency layer is omitted. On 97 the other hand, if time is not required for the application, then 98 only the frequency layer may be present. 100 Network 101 | 102 v 103 +------+-------+ +--------------+ 104 | Frequency | | Frequency | 105 | Acquisition +------)-------+ Presentation +-----)------ 106 | | | | 107 +------+-------+ +--------------+ 108 | 109 v 110 | 111 +------+-------+ +--------------+ 112 | Time | | Time | 113 | Acquisition +------)-------+ Presentation +-----)------ 114 | | | | 115 +--------------+ +--------------+ 117 Figure 1. Generic TICTOC client 119 Referring to Figure 1, the frequency acquisition module is 120 responsible for recovery of frequency information distributed over a 121 packet switched network (PSN), such as IP or MPLS. This distribution 122 is accomplished by use of a frequency distribution protocol. The 123 frequency distributed may be derived from an international standard, 124 or may be an arbitrary frequency needed at some remote location. If 125 the value of the frequency itself is needed, then the output of this 126 module is input to the frequency presentation module that formats the 127 frequency according to application needs. Note that this format may 128 be numeric prepared for display, or may take analog form and be used 129 for locking or disciplining other analog frequencies. When time is 130 needed, the frequency information is sent to the time acquisition 131 module. 133 Even if the frequency itself is not needed, time acquisition almost 134 always requires a stable frequency reference. This reference may be 135 acquired from the frequency acquisition layer, or may be obtained via 136 some other means, such as an accurate local frequency reference, or 137 from a non-PSN mechanism for frequency distribution (e.g., GPS, 138 SONET/SDH). 140 From the acquired or otherwise available frequency, we may derive 141 arbitrary time (also known as "phase") by mathematical means. If the 142 frequency reference is traceable to an international standard, then 143 arbitrary time means a sequence of time values that are synchronous 144 with true (wall-clock, UTC) time, but with an arbitrary offset. The 145 purpose of the time acquisition module is to enable multiple TICTOC 146 clients to share a single offset, and thus to agree as to marking of 147 phase values. Such marked phases values are all that is required for 148 certain applications, such as where multiple time-aware agents need 149 to interact (e.g., systems employing Time Division Multiple Access 150 systems). 152 When the time markings distributed by the time distribution protocol 153 are traceable to an international standard, the TICTOC clients are 154 said to have acquired wall-clock time. These wall-clock values are 155 formatted for use by the intended application by the time 156 presentation module. 158 The remainder of this document further subdivides these modules and 159 identifies the submodules needed for timing distribution. Submodule 160 may require one or more protocols, a set of processing algorithms, 161 and implementations. Descriptions of these protocols, algorithms, 162 and reference implementations are the TICTOC deliverables. 164 The frequency acquisition module may be subdivided into the following 165 submodules. Not all need to be present in all implementations. 166 Those that need not be developed by TICTOC are marked by an asterisk. 167 o local oscillator (*) 168 o digital synthesizer (*) 169 o timestamp generation (not required if packets are sent at constant 170 rate) 171 o frequency distribution protocol 172 o packet selection/discard algorithms 173 o frequency acquisition algorithms 174 o disciplining/adaptation/clock adjustment 176 The time acquisition module may be subdivided into the following 177 submodules. Not all need to be present in all implementations. 178 o time distribution protocol 179 o ranging 180 o timestamp generation (already mentioned) 182 In addition, various generic modules may be needed, for either 183 frequency distribution, time distribution, or both. 184 o security 185 o autodiscovery and master clock selection 186 o OAM, synchronization status messaging, and performance monitoring 187 o path selection and/or self-organization 188 o on-path support 189 o network management 191 2. Frequency Layer 193 There are applications that require an accurate frequency reference, 194 but do not require knowledge of absolute time. In addition, it is 195 often wise to acquire frequency for applications that require 196 absolute time but do not directly use frequency. 198 TICTOC is concerned with the network frequency transfer using packet 199 technology. Frequency may be transferred across a network using the 200 physical layer, such as through the use of a synchronous network 201 interface (for example synchronous Ethernet [G8262]). The use of the 202 physical layer may produce a higher quality frequency reference than 203 achievable using packet based network frequency transfer, but is 204 outside the scope of this document. 206 2.1. Local Oscillator and Digital Synthesizers 208 TICTOC masters and clients both need local sources of frequency. For 209 masters, this may be provided by high quality Cesium clock with 210 extremely good long term accuracy, or by an atomic clock with 211 somewhat lower accuracy, but which is disciplined by comparison with 212 a better clock (e.g., by GPS). Note that a pure frequency master 213 that does not need to know time can be standalone. 215 For clients, the local oscillator is usually a quartz crystal 216 oscillators. Such oscillators may be stable, special cut crystals 217 with double oven and temperature compensation, or lowly inexpensive 218 crystals. In either case the frequency derived from these 219 oscillators needs to be adjusted by the TICTOC frequency acquisition 220 module. This adjustment can be electronic (e.g., changing the 221 control voltage of a voltage controlled oscillator). 223 However, it is common practice not to directly adjust the physical 224 oscillator, or even to directly use the oscillator's frequency. 225 Instead, a digital synthesizer fed by the oscillator provides the 226 required output frequency. Changing parameters of the digital 227 synthesizer changes the output frequency in the required way. It is 228 important for the digital synthesizer not to introduce too much 229 jitter, and for the changing of parameters to be done in such fashion 230 as to minimize transients. 232 Disciplining of the local oscillator, or setting the parameters of 233 the digital synthesizer, is based on the arrival times of received 234 frequency distribution protocol packets, and the information 235 contained in them. When, for whatever reason, frequency distribution 236 packets are not received, the frequency layer is said to be in 237 "holdover mode". In holdover mode the local oscillator or 238 synthesizer is still used as usual, but it is no longer disciplined 239 based on new information from the distribution protocol (although it 240 may still be adapted, if the acquisition module has models that have 241 been trained during periods that the frequency distribution packets 242 were received). 244 2.2. Frequency Distribution Protocols 246 The protocol used to distribute frequency across the packet network 247 may be the same protocol used for time distribution, or may be an 248 independent protocol. The important design consideration is that the 249 protocol used is optimized for that purpose, and not compromised by 250 the need to fulfill a dual role. 252 Frequency distribution protocols are "one way", i.e. only require 253 information transfer from the master (where the frequency is known) 254 to the client. In particular, frequency distribution protocols can 255 be broadcast or multicast to many clients, without the master needing 256 to know the client identities. Frequency distribution protocols may 257 even operate when there is no return path available. Exceptions to 258 this rule are control messages sent by the client requesting 259 commencing or termination of the frequency distribution service, or 260 changing its parameters (e.g., update rate). 262 Frequency distribution protocols can be broadcast, multicast or 263 unicast. Multicast transmission conserves network bandwidth, while 264 unicast transmission is often more desirable. 266 Ideally the frequency distribution protocol should be decoupled from 267 the algorithm used to derive the local reference frequency, and the 268 packets sent should only contain information that is physically 269 meaningful without reference to a particular algorithm. For example, 270 if the master sends packets at a constant rate as measured by the 271 frequency reference, then the existence of the packet itself is the 272 only physically meaningful information, and the packet should contain 273 nothing but headers required for packet delivery. If the packets are 274 not sent at a constant rate, they should contain nothing but a 275 sufficiently precise timestamp. The use of extension mechanisms for 276 carrying additional information may be considered for specific cases. 278 The TICTOC Working Group will select a suitable network frequency 279 transfer protocol. This may be based on an existing protocol, 280 although that is not to be considered a requirement. 282 The basic TICTOC architecture itself should not be strongly bound to 283 the frequency distribution protocol. It should be possible to 284 upgrade or completely replace this protocol (e.g., to improve 285 accuracy), or to optimize the transfer for a different network 286 environment, without redesigning the TICTOC architecture. 288 2.3. Packet Select/Discard Algorithms 290 In the simplest networks all frequency distribution packets received 291 are used by the frequency acquisition algorithms to derive 292 corrections to the local oscillator. A major problem with frequency 293 acquisition in complex networks is the elimination of frequency 294 distribution packets that, if used by the acquisition algorithms, 295 would degrade the quality of the recovered frequency. Such packets 296 are variously called outliers, falsetickers, etc. 298 There are several reasons for such unreliable packets. First, 299 malfeasants may deliberately inject false packets in order to impair 300 the TICTOC client's frequency recovery. We will discuss security 301 mechanisms below. Second, PDV distributions for complex networks can 302 be long tailed, leading to extremely misleading results. Third, 303 various network degradations, e.g., congestion and reroute events, 304 can lead to bizarre information being received. 306 Furthermore, even typical packets may have experienced significant 307 delay variation, making them less suitable for exploitation than the 308 small fraction of packets that may have experienced almost no delay 309 (and thus minimal delay variation). When there is a significant 310 fraction of packets that experience essentially no delay, it is 311 reasonable to discard all others (assuming that after this decimation 312 the sampling rate is still sufficiently high). 314 2.4. Frequency Acquisition Algorithms 316 Observed arrival times of frequency distribution protocol packets are 317 influenced by two phenomena: time behavior of the local oscillator as 318 compared to the master oscillator, and network delay behavior (PDV). 319 The former behavior needs to be tracked, while the latter needs to be 320 filtered out. In order to eliminate the effects of PDV, frequency 321 acquisition algorithms perform some sort of averaging and/or 322 filtering, in an attempt to recover the frequency at which packets 323 were sent. Since simple averaging would take too long to 324 sufficiently eliminate the stochastic components, by which time the 325 frequency difference between local oscillator and master oscillator 326 would have changed, more efficient "control loops" are employed. 327 Control loops are nonlinear mechanisms, and are thus able to "lock 328 onto" frequencies, rather than simply removing stochastic noise. 329 Conventional control loops include the Phase Locked Loop (PLLs), the 330 Frequency Locked Loops (FLL), and combinations of the two. 332 Delay variation effects can be quite complex and traffic dependent. 333 There are obvious effects such as queuing indeterminacy leading to 334 stochastic PDV, and congestion leading to packet loss. There are 335 also more subtle effects, for example multiple plesiochronous flows 336 (e.g. TDM pseudowires) traversing forwarding elements can cause slow 337 "beating" effects, generating low frequency wander that is difficult 338 to eliminate. Another example is the batch processing effect 339 introduced by some forwarders in which the first of a series of 340 packets experiences greater latency that later packets. 342 Modern algorithms attempt to model the time behavior of local 343 oscillator as compared to the master oscillator, and/or the network 344 behavior. More complex algorithms may attempt blind separation of 345 the contribution of the two effects. 347 Traditionally the focus on frequency acquisition algorithm design has 348 been on the client. However it is possible to mitigate some of the 349 aforementioned effects by modulating the packet generation rate of 350 the master. Thus TICTOC algorithm modules may describe the client 351 and the server components, and may require matching of these 352 algorithms to achieve optimal performance. 354 Frequency acquisition algorithms need to be optimized such that 355 network bandwidth consumed by the frequency distribution protocol is 356 minimized. Furthermore, these algorithms are required to be robust 357 to network degradations such as packet delay, packet loss, packet 358 delay variation (PDV) and infrequent stepwise changes in network 359 traversal latencies (e.g., due to reroute events or network loading 360 changes). 362 The TICTOC Working Group may specify a reference algorithm, but the 363 TICTOC architecture will enable vendors to employ proprietary 364 algorithms. It will also be possible to upgrade the reference 365 algorithm in the future. 367 2.5. Frequency Presentation 369 In general, the output of the frequency acquisition module needs to 370 be reformatted before use. In some cases the reference frequency 371 distributed across the network is different from the frequency needed 372 by the local application; in such cases a digital synthesizer can be 373 employed to convert the acquired frequency to the desired one. 374 Sometimes it is not frequency itself that is required, but a sequence 375 of equally separated times; in such cases the sequence of time 376 "ticks" is generated from the acquired frequency (once again, a 377 digital synthesizer is ideal for this). 379 3. Time Layer 381 In general the time layer is fed accurate frequency from the 382 frequency layer. There are applications that require accurate time, 383 but do not need to acquire frequency over the PSN. For example: 384 o if the update rate is high and the time resolution required is low 385 o if highly accurate frequency is available locally 386 o if frequency is distributed by means external to the PSN (e.g. 387 GPS, LORAN, WWV) 388 o if frequency is available by means of the network physical layer 389 (e.g. PoS, SyncE). 390 In such cases the frequency input in Figure 1 is provided by the 391 alternative frequency source, rather than the frequency layer. 393 The TICTOC two layer decomposition is a conceptual one, and may not 394 be easily identifiable in all implementations. For example, when 395 using a pure PLL frequency acquisition module, true "frequency" is 396 never derived, only relative phase. Similarly, tracking mechanisms 397 may simultaneously model frequency and time, reducing convergence 398 time by adjusting both simultaneously, rather than first acquiring 399 frequency, and afterwards time. However, even in these cases the 400 decomposition is a useful one. 402 3.1. Time Distribution Protocols 404 The purpose of the time distribution protocol is to calibrate a 405 sequence of phase events generated by the local oscillator or digital 406 synthesizer, thus converting arbitrary offset phase values into wall- 407 clock values. This is done by sending packets containing timestamps 408 from the master (where the time is known) to the TICTOC client. In 409 order for the timestamp to accurately indicate the time that the 410 packet was actually injected into the network (rather than some 411 earlier time when the packet was formed, separated by a stochastic 412 time delay from the injection time), the timestamp should be 413 generated by the networking hardware. When this is not possible, the 414 stochastic delay should be minimized. The IEEE 1588 protocol has a 415 follow-up message, to indicate the actual injection time of the 416 previous packet. 418 The timestamp in the time distribution protocol packet indicates the 419 time that the master injected this packet into the network. On the 420 other hand, the client receives this same packet after the 421 propagation delay, i.e. the time taken to traverse the packet 422 network. Were this time to be accurately known, the timestamp could 423 be corrected, and the precise time known. Estimation of the 424 traversal time is called ranging, and will be discussed below. The 425 IEEE 1588 protocol has an optional mechanism (transparent clocks) 426 whereby forwarding delays, and even individual link delays are 427 measured and compensated, thus leading to precise knowledge of the 428 traversal delay. However, this mechanism requires upgrading of all 429 intermediate network elements. 431 Due to the requirement of traversal delay measurement, time 432 distribution protocols are generally bidirectional, that is, they 433 require a bidirectional channel, require both master and client to 434 send and receive messages, and usually assume symmetric (or known 435 asymmetry) propagation times. Unlike frequency distribution, time 436 distribution can not be entirely multicast, due to the ranging 437 requirement. 439 There are two well-known protocols capable of running over a general- 440 purpose packet network, NTP [RFC1305], and IEEE 1588 [1588]. NTP is 441 the product of the IETF, and is currently undergoing revision to 442 version 4. IEEE 1588 is a product of the IEEE Test and Measurement 443 community. It is presently specified in a limited first version, 444 while the second version (1588v2) is soon to be a standard. IEEE 445 1588v2 has a profiling mechanism enabling organizations to specify 446 required and prohibited options, ranges and defaults of attribute 447 values, and optional features, while maintaining interoperability. 449 The protocol used to transfer the reference frequency across the 450 network may be the same protocol that is used to transfer time. The 451 overriding design consideration is that frequency and time 452 distribution protocols be optimised for their purpose, and not 453 compromised by the need to fulfill a dual role. 455 The TICTOC Working Group will select a suitable time distribution 456 transfer protocol or protocols. There are three options here: 457 o a new or alternative version of NTP, to be called NTPv5 458 o a profile of 1588 459 o a completely new protocol. 460 The selection will be made by producing a set of specific 461 requirements for the TICTOC timing distribution protocol, and by a 462 disinterested evaluation of each of these options in light of these 463 requirements. The requirements will be based on the applications 464 listed in the TICTOC problem statement. If neither of the first two 465 options fulfill the requirements, then the third option will be 466 chosen. Even if the first two options equally fulfill the 467 requirements one of them will be chosen as the mandatory protocol, 468 and the use of the other will be permissible under specific 469 circumstances. 471 The TICTOC architecture itself should not be bound to the specific 472 time distribution protocol. It should be possible to upgrade, or 473 replace this protocol, for example to improved the quality of the 474 transfer, or to optimize the transfer for a different network 475 environment, without redesigning the entire TICTOC architecture. 477 3.2. Ranging 479 To transfer time it is necessary to know the time of flight of time 480 of packets from the time server to the client. The accuracy of time 481 at the client can be no better than the accuracy provide by the 482 ranging mechanism. Some ranging mechanisms require or can exploit 483 special hardware assistance by intermediate network elements, such as 484 IEEE 1588 transparent clocks [1588] . 486 A typical ranging mechanism functions by exchanging timestamps 487 between master and client. For example, the master sends an initial 488 timestamped packet. When this packet arrives at the client its 489 arrival time (in terms of the local clock) is recorded. After some 490 amount of time the client sends a response packet back to the master, 491 containing the initial timestamp (in terms of the master clock), and 492 the packet arrival and retransmission times (in terms of the client 493 clock). When this packet is received by the master a fourth 494 timestamp is generated (in terms of the master clock). Since the 495 second and third timestamps are both in terms of the client clock, 496 their difference - representing the amount of time the client 497 hesitated between receipt of the initial packet and sending the 498 response packet - is readily computed. This difference can be 499 subtracted from the difference between the fourth and first 500 timestamps, to yield the sum of propagation times. Under the 501 assumption of symmetry, the one-way time is half this sum. Note that 502 since the difference between third and fourth timestamps is short, 503 possible frequency inaccuracy of the client has little deleterious 504 effect. 506 Various variations on this basic four-timestamp method are possible. 507 In the three timestamp method the client sends the time difference 508 (e.g., generated by resetting a timer upon packet arrival) rather 509 than the two timestamps. When symmetry is not a valid assumption, 510 additional information (e.g., ratio or difference between expected 511 propagation delays) can be used to extract the one-way delay. 513 Ranging accuracy is reduced by deviation from expected asymmetry in 514 the network. Mechanisms to avoid asymmetry at the network layer (for 515 example using MPLS RSVP-TE paths, or the use of the peer-to-peer 516 mechanism described in IEEE1588v2 are useful, as is the ability to 517 correct asymmetry in the physical connection through the use of 518 external calibration. 520 3.3. Time Presentation 522 In general, the output of the time acquisition module needs to be 523 reformatted before use. Formatting includes translation between 524 different representations (e.g., from seconds after a given date to 525 date and time), changing time zones, etc. When the time needs to be 526 displayed, e.g., on a computer or mobile device, further processing 527 is often required, such as identification of day of week, translation 528 to other calendars (e.g., Hebrew, Islamic, Chinese), conversion 529 between TAI and UTC, and flagging of holidays and special dates. 531 4. Other Modules 533 4.1. Security Mechanisms 535 Time and frequency services are a significant element of network 536 infrastructure, and are critical for certain emerging applications. 537 Hence time and frequency transfer services MUST be protected from 538 being compromised. The most significant threats are false timing 539 servers distributing purposely misleading timing packets, and man in 540 the middle tampering with valid timing packets. Both threats would 541 enable a malfeasant to mislead TICTOC clients, and to bring down 542 critical services. 544 Based on the aforementioned threats, one can conclude that 545 confidentiality and replay protection are usually not needed (and in 546 many cases not possible), but source authentication and integrity 547 protection are vital. In general, it is the master that needs to be 548 authenticated to the server, although in certain cases it may be 549 needed to authenticate the client to the master. Applying IPsec 550 Authentication Header (AH) mechanisms to all timing packets is not 551 feasible, due to the computational resources consumed by public key 552 cryptography algorithms. Adoption of IPsec would impact time 553 acquisition accuracy, and would lead to new methods for malfeasants 554 to disrupt the timing distribution protocols by exhausting resources 555 and denial of service from TICTOC clients. Furthermore, certificates 556 used to authenticate packets have lifetimes that must be enforced for 557 secure use. Certification of time packets themselves can thus lead 558 to circular dependence and to attacks that invalidate valid time 559 packets and substitute invalid ones. 561 NTP implementations provided an authentication protocol called 562 Autokey. Autokey utilizes public key algorithms to encrypt cookies, 563 symmetric key message digests for integrity, and digital signatures 564 for source authentication. 566 Any security mechanism must be designed in such a way that it does 567 not degrade the quality of the time transfer. Such a mechanism 568 SHOULD also be relatively lightweight, as client restrictions often 569 dictate a low processing and memory footprint, and because the server 570 may have extensive fan-out. The mechanism also SHOULD not require 571 excessive storage of client state in the master, nor significantly 572 increase bandwidth consumption. 574 4.2. Autodiscovery and Master Clock Selection 576 The topology of presently deployed synchronization networks is 577 universally manually configured. This requires manual or management- 578 plane configuration of master-client relationships, as well as 579 preconfigured fallback behaviors. This strategy is workable for SDH 580 networks, where there are a relatively small number of network 581 elements that require such configuration, and all elements are 582 controlled by a single entity. In packet switched network scenarios 583 there may be a very large number of independent network elements 584 requiring timing, making automatic mechanisms important. Such 585 autodiscovery, automatic master selection algorithms, and perhaps 586 control plane protocols to support these features, are an important 587 TICTOC deliverable. 589 There are application scenarios where it is desirable for clocks to 590 advertise their service, and for clients to automatically select a 591 clock with the required accuracy and path characteristics. The 592 optimum advertising method may depend on the environment and the 593 application. For example a host may be best served by finding a 594 suitable clock (or set of clocks) through a DHCP parameter, whist a 595 provider edge may find it more convenient to discover the available 596 clock through BGP. 598 The TICTOC Working Group will specify the required clock 599 characteristics and identify the set of clock and client 600 characteristics and the application characteristics that influence 601 the optimum method of clock discovery. It will then specify one or 602 more methods of clock autodiscovery together with associated 603 applicability information. 605 Once a TICTOC client has discovered potential TICTOC masters, it must 606 choose how to derive its clock from one or more of them. This choice 607 can be aided using two types of information: 608 o claims made by the potential masters as to the accuracy of its 609 local clock (see OAM and SSM below) 610 o analysis of the stability of frequency recovered from the 611 potential masters. 612 One tactic that a TICTOC client may employ is to individually choose 613 which master to use based on this information. Even if statically 614 configured to use a particular master, a client may be allowed to 615 make independent decisions when the master becomes unavailable or 616 sends synchronization status messages indicating a fault condition. 618 A second tactic is not to make a hard decision at all, but rather to 619 perform weighted ensemble averaging of frequencies recovered from all 620 available masters. The weightings, once again, may be based on 621 claims made by the masters or by monitoring of frequency stability. 623 Using either tactic, it is important to ensure that "timing loops" 624 are not formed. A timing loop is an erroneous topology that causes 625 locking onto frequencies not traceable to a high quality source. 626 Loops are avoided by ensuring that the frequency distribution paths 627 form a tree. 629 Yet another method is not to decide on a timing distribution tree at 630 all, but rather to enable self-organization of independently acting 631 intelligent agents. In such cases the meaning of master and client 632 becomes blurred, as all agents exchange timing information with a 633 subset neighbors that have been discovered. This method may be 634 driven by timing acquisition algorithms that guarantee global 635 convergence of the timing agents, meaning that over time the average 636 timing error decreases, although a given agent's error may sometimes 637 increase. 639 4.3. OAM, SSM, and Performance Monitoring 641 In order to ensure continuity and connectivity of the path from the 642 master to the client, and the reverse path when needed, an 643 Operations, Administration, and Maintenance protocol may be needed. 644 When the master sends timing distribution packets at a constant rate, 645 faults are detected by the client after a few interpacket times; when 646 the rate is variable, the problem is detected after a few times the 647 maximum interpacket interval. However, in either case the master may 648 be unaware of the problem. 650 Synchronization Status Messages (SSMs) were traditionally used in TDM 651 networks to indicate the accuracy of the source upon which an 652 incoming TDM link based its timing, and to notify the remote site of 653 clock failures. Timing distribution protocols generally have similar 654 functions. 656 Performance monitoring is important to ensure the proper operation of 657 timing systems, and may be integrated into OAM mechanisms. 659 4.4. Path Selection 661 In infrastructure applications it may be possible for TICTOC to seek 662 co-operation from routing elements to optimize the path through the 663 network in order to obtain a better quality of time and frequency 664 transfer that is possible when the timing distribution protocol 665 operates independent of the network layer. 667 At the simplest level this is use of paths that can support the 668 required quality of service, and have the lowest congestion impact. 669 However it is also possible for the network layer to be a proactive 670 partner in the transfer process. For example paths may be selected 671 that are explicitly chosen to be symmetric, or paths may be selected 672 such that all are capable of supporting physical frequency transfer 673 (for example synchronous Ethernet), or nodes may be selected such 674 that they are all capable of supporting transparent clock. 676 In addition to having to deal with degradation of service due to 677 congestion, TICTOC must not add to the problem. Thus, TICTOC timing 678 distribution protocols MUST be able to act in a TCP friendly way, 679 even at the expense of minor degradation of performance. In such 680 cases, it may be required for the master to inform the client of the 681 change in operating conditions. 683 4.5. On-path Support 685 The TICTOC architecture will be commensurate with the public 686 Internet, and the timing distribution protocol chosen will be able to 687 function over general packet switched networks. 689 In some cases on-path support (for example IEEE 1588 transparent 690 clock) may be needed in order to obtain the required frequency or 691 time accuracy. Such on-path support cannot be expected to be 692 universally available over the public Internet, and it is not a goal 693 of the TICTOC working group to propose augmentation of basic 694 forwarding elements. However, such on-path support may be provided 695 on service provider or enterprise networks, and in such cases TICTOC 696 protocols should be able to exploit it. 698 In networks with on-path support, it may be that the optimum path for 699 time transfer is not congruent with the optimum path for data 700 transfer. By using special-purpose IP addresses, and making routing 701 aware of the required path characteristics and address attributes, it 702 is possible to construct paths within the network that maintain the 703 required time transfer characteristics. 705 The TICTOC Working Group will specify the required path 706 characteristics and work with the ISIS and OSPF Working Groups to 707 specify the necessary routing extensions to support these 708 requirements. 710 TICTOC traffic may need to traverse NATs and firewalls. 712 4.6. Network Management 714 As for all network infrastructure mechanisms, timing distribution 715 systems SHOULD be managed. This implies provision of management 716 agents in TICTOC masters and clients, and definition of the 717 appropriate MIBs. 719 5. Security Considerations 721 This document proposes modularization of the work of a proposed 722 Working Group, and thus does not, in itself, raise security concerns. 723 Security aspects of TICTOC have been addressed above. 725 6. IANA Considerations 727 No IANA actions are required as a result of the publication of this 728 document. 730 7. Acknowledgements 732 The authors wish to thank Alon Geva, Gabriel Zigelboim, and Laurent 733 Montini for invaluable comments. 735 8. Informative References 737 [1588] IEEE, "1588-2002 Standard for A Precision Clock 738 Synchronization Protocol for Networked Measurement and 739 Control Systems". 741 [G8262] ITU-T, "G.8262 - Timing characteristics of synchronous 742 ethernet equipment slave clock (EEC)". 744 [RFC1305] Mills, D., "Network Time Protocol (Version 3) 745 Specification, Implementation", RFC 1305, March 1992. 747 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 748 Requirement Levels", BCP 14, RFC 2119, March 1997. 750 Authors' Addresses 752 Yaakov (Jonathan) Stein 753 RAD Data Communications 754 24 Raoul Wallenberg St., Bldg C 755 Tel Aviv 69719 756 ISRAEL 758 Phone: +972 3 645-5389 759 Email: yaakov_s@rad.com 761 Stewart Bryant 762 Cisco Systems 763 250 Longwater Ave., Green Park 764 Reading RG2 6GB 765 United Kingdom 767 Email: stbryant@cisco.com 769 Karen O'Donoghue 770 US Navy 771 Code B35, NSWCDD, 17320 Dahlgren Rd. 772 Dahlgren, VA 22448 774 Email: karen.odonoghue@navy.mil 776 Full Copyright Statement 778 Copyright (C) The IETF Trust (2008). 780 This document is subject to the rights, licenses and restrictions 781 contained in BCP 78, and except as set forth therein, the authors 782 retain all their rights. 784 This document and the information contained herein are provided on an 785 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 786 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 787 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 788 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 789 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 790 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 792 Intellectual Property 794 The IETF takes no position regarding the validity or scope of any 795 Intellectual Property Rights or other rights that might be claimed to 796 pertain to the implementation or use of the technology described in 797 this document or the extent to which any license under such rights 798 might or might not be available; nor does it represent that it has 799 made any independent effort to identify any such rights. Information 800 on the procedures with respect to rights in RFC documents can be 801 found in BCP 78 and BCP 79. 803 Copies of IPR disclosures made to the IETF Secretariat and any 804 assurances of licenses to be made available, or the result of an 805 attempt made to obtain a general license or permission for the use of 806 such proprietary rights by implementers or users of this 807 specification can be obtained from the IETF on-line IPR repository at 808 http://www.ietf.org/ipr. 810 The IETF invites any interested party to bring to its attention any 811 copyrights, patents or patent applications, or other proprietary 812 rights that may cover technology that may be required to implement 813 this standard. Please address the information to the IETF at 814 ietf-ipr@ietf.org. 816 Acknowledgment 818 Funding for the RFC Editor function is provided by the IETF 819 Administrative Support Activity (IASA).