idnits 2.17.1 draft-ietf-tictoc-ptp-enterprise-profile-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 5, 2013) is 3947 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE1588' ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TICTOC Working Group Doug Arnold 2 Internet Draft 3 Intended status: Standards Track Heiko Gerstung 4 Meinberg 5 Expires: January 2014 July 5, 2013 7 Enterprise Profile for the Precision Time Protocol 8 With Mixed Multicast and Unicast Messages 10 draft-ietf-tictoc-ptp-enterprise-profile-00.txt 12 Status of this Memo 13 This Internet-Draft is submitted in full conformance with the 14 provisions of BCP 78 and BCP 79. This document may not be 15 modified, and derivative works of it may not be created, except to 16 publish it as an RFC and to translate it into languages other than 17 English. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six 25 months and may be updated, replaced, or obsoleted by other 26 documents at any time. It is inappropriate to use Internet-Drafts 27 as reference material or to cite them other than as "work in 28 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 January 5, 2014. 38 Copyright Notice 39 Copyright (c) 2013 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with 47 respect to this document. Code Components extracted from this 48 document must include Simplified BSD License text as described in 49 Section 4.e of the Trust Legal Provisions and are provided without 50 warranty as described in the Simplified BSD License. 52 Abstract 53 This document describes a profile for the use of the Precision 54 Time Protocol in an IPV4 or IPv6 Enterprise information system 55 environment. The profile uses the End to End Delay Measurement 56 Mechanism, allows both multicast and unicast Delay Request and Delay 57 Response Messages. 59 Table of Contents 61 1. Introduction 2 62 2. Conventions used in this document 3 63 3. Technical Terms 3 64 4. Problem Statement 5 65 5. Network Technology 6 66 6. Time Transfer and Delay Measurement 7 67 6.1. Unicast Delay Measurement Mode 7 68 6.2. Multicast Delay Measurement Mode 8 69 6.3. Hybrid delay Measurement Mode 8 70 7. Default Message Rates 8 71 8. Timing Domains 8 72 9. Requirements for Master Clocks 8 73 10. Requirements for Slave Clocks 9 74 11. Requirements for Transparent Clocks 10 75 12. Management and Signaling Messages 10 76 13. Forbidden PTP Options 10 77 14. Interoperation with Other PTP Profiles 10 78 15. Security Considerations 11 79 16. IANA Considerations 11 80 17. References 11 81 17.1. Normative References 11 82 17.2. Informative References 12 83 18. Acknowledgments 12 85 1. Introduction 87 The Precision Time Protocol ("PTP"), standardized in IEEE 1588, 88 has been designed in its first version (IEEE 1588-2002) with the 89 goal to minimize configuration on the participating nodes. Network 90 communication was based solely on Multicast messages, which unlike 91 NTP did not require that a receiving node ("slave clock" in 92 [IEEE1588] needs to know the identity of the time sources in the 93 network (the Master Clocks). 95 The so-called "Best Master Clock Algorithm" ([IEEE1588] Clause 96 9.3), a mechanism that all participating PTP nodes must follow, 97 set up strict rules for all members of a PTP domain to determine 98 which node shall be the active sending time source (Master Clock). 99 Although the multicast communication model has advantages in 100 smaller networks, it complicated the application of PTP in larger 101 networks, for example in environments like IP based 102 telecommunication networks or financial data centers. It is 103 considered inefficient that, even if the content of a message 104 applies only to one receiver, it is forwarded by the underlying 105 network (IP) to all nodes, requiring them to spend network 106 bandwidth and other resources like CPU cycles to drop the message. 108 The second revision of the standard (IEEE 1588-2008) is the 109 current version (also known as PTPv2) and introduced the 110 possibility to use unicast communication between the PTP nodes in 111 order to overcome the limitation of using multicast messages for 112 the bi-directional information exchange between PTP nodes. The 113 unicast approach avoided that, in PTP domains with a lot of nodes, 114 devices had to throw away up to 99% of the received multicast 115 messages because they carried information for some other node. 116 PTPv2 also introduced so-called "PTP profiles" ([IEEE1588] Clause 117 19.3). This construct allows organizations to specify selections 118 of attribute values and optional features, simplifying the 119 configuration of PTP nodes for a specific application. Instead of 120 having to go through all possible parameters and configuration 121 options and individually set them up, selecting a profile on a PTP 122 node will set all the parameters that are specified in the profile 123 to a defined value. If a PTP profile definition allows multiple 124 values for a parameter, selection of the profile will set the 125 profile-specific default value for this parameter. Parameters not 126 allowing multiple values are set to the value defined in the PTP 127 profile. A number of PTP features and functions are optional and a 128 profile should also define which optional features of PTP are 129 required, permitted or prohibited. It is possible to extend the 130 PTP standard with a PTP profile by using the TLV mechanism of PTP 131 (see [IEEE1588] Clause 13.4), defining an optional Best Master 132 Clock Algorithm and a few other ways. PTP has its own management 133 protocol (defined in [IEEE1588] Clause 15.2) but allows a PTP 134 profile specify an alternative management mechanism, for example 135 SNMP. 137 2. Conventions used in this document 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 140 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 141 in this document are to be interpreted as described in RFC-2119 142 [RFC2119]. 144 In this document, these words will appear with that interpretation 145 only when in ALL CAPS. Lower case uses of these words are not to 146 be interpreted as carrying RFC-2119 significance. 148 3. Technical Terms 150 Acceptable Master Table: A PTP Slave Clock may maintain a list of 151 masters which it is willing to synchronize to. 153 Alternate Master: A PTP Master Clock, which is not the Best 154 Master, may act as a master with the Alternate Master flag set on 155 the messages it sends. 157 Announce message: Contains the master clock properties of a Master 158 clock. Used to determine the Best Master. 160 Best Master: A clock with a port in the master state, operating 161 consistently with the Best Master Clock Algorithm. 163 Best Master Clock Algorithm: A method for determining which state 164 a port of a PTP clock should be in. The algorithm works by 165 identifying which of several PTP Master capable clocks is the best 166 master. Clocks have priority to become the acting Grandmaster, 167 based on the properties each Master Clock sends in its Announce 168 Message. 170 Boundary Clock: A device with more than one PTP port. Generally 171 boundary clocks will have one port in slave state to receive 172 timing and then other ports in master state to re-distribute the 173 timing. 175 Clock Identity: In IEEE 1588-2008 this is an 64-bit number 176 assigned to each PTP clock which must be unique. Often the 177 Ethernet MAC address is used since there is already an 178 international infrastructure for assigning unique numbers to each 179 device manufactured. 181 End to End Delay Measurement Mechanism: A network delay 182 measurement mechanism in PTP facilitated by an exchange of 183 messages between a Master Clock and Slave Clock. 185 Grandmaster: the primary master clock within a domain of a PTP 186 system 188 IEEE 1588: The timing and synchronization standard which defines 189 PTP, and describes The node, system, and communication properties 190 necessary to support PTP. 192 Master clock: a clock with at least one port in the master state. 194 NTP: Network Time Protocol, defined by RFC 5905, see [NTP]. 196 Ordinary Clock: A clock that has a single Precision Time Protocol 197 (PTP) port in a domain and maintains the timescale used in the 198 domain. It may serve as a master clock, or be a slave clock. 200 Peer to Peer Delay Measurement Mechanism: A network delay 201 measurement mechanism in PTP facilitated by an exchange of 202 messages between adjacent devices in a network. 204 Preferred Master: A device intended to act primarily as the 205 Grandmaster of a PTP system, or as a back up to a Grandmaster. 207 PTP: The Precision Time Protocol, the timing and synchronization 208 protocol define by IEEE 1588. 210 PTP port: An interface of a PTP clock with the network. Note that 211 there may be multiple PTP ports running on one physical interface, 212 for example a Unicast slave which talks to several Grandmaster 213 clocks in parallel. 215 PTPv2: Refers specifically to the second version of PTP defined by 216 IEEE 1588-2008. 218 Rogue Master: A clock with a port in the master state, even though 219 it should not be in the master state according to the Best Master 220 Clock Algorithm, and does not set the alternate master flag. 222 Slave clock: a clock with at least one port in the slave state, 223 and no ports in the master state. 225 Slave Only Clock: An Ordinary clock which cannot become a Master 226 clock. 228 TLV: Type Length Value, a mechanism for extending messages in 229 networked communications. 231 Transparent Clock. A device that measures the time taken for a 232 PTP event message to transit the device and then updates the 233 message with a correction for this transit time. 235 Unicast Discovery: A mechanism for PTP slaves to establish a 236 unicast communication with PTP masters using a configures table of 237 master IP addresses and Unicast Message Negotiation. 239 Unicast Negotiation: A mechanism in PTP for Slave Clocks to 240 negotiate unicast Sync, announce and Delay Request Message Rates 241 from a Master Clock. 243 4. Problem Statement 245 This document describes a version of PTP intended to work in large 246 enterprise networks. Such networks are deployed, for example in 247 financial corporations. It is becoming increasingly common in 248 such networks to perform distributed time tagged measurements, 249 such as one-way packet latencies and cumulative delays on software 250 systems spread across multiple computers. Furthermore there is 251 often a desire to check the age of information time tagged by a 252 different machine. To perform these measurements it is necessary 253 to deliver a common precise time to multiple devices on a network. 255 Accuracy currently required can be as tight as within 1 256 microseconds to the Grandmaster. This profile does not specify 257 timing performance requirements, but such requirements explain why 258 the needs cannot always be met by NTP, as commonly implemented. 259 Such accuracy cannot usually be achieved with a traditional time 260 transfer such as NTP, without adding non-standard customizations 261 such as hardware time stamping, fast message rates, non-linear 262 servo loops, and on path support. These features are currently 263 part of PTP, or are allowed by it. Because PTP has a complex range 264 of features and options it is necessary to create a profile for 265 enterprise networks to achieve interoperability between equipment 266 manufactured by different vendors. 268 Although enterprise networks can be large, it is becoming 269 increasingly common to deploy multicast protocols, even across 270 multiple subnets. For this reason it is desired to make use of 271 multicast whenever the information going to many destinations is 272 the same. It is also advantageous to send information which is 273 unique to one device as a unicast message. The latter can be 274 essential as the number of PTP slaves becomes hundreds or 275 thousands. 277 PTP devices operating in these networks need to be robust. This 278 includes the ability to ignore PTP messages which can be 279 identified as improper, and to have redundant sources of time. 281 5. Network Technology 283 This PTP profile SHALL operate only in networks characterized by 284 UDP [RFC768] over either IPv4 [RFC791] or IPv6 [RFC2460], as 285 described by Annexes D and E in [IEEE1588] respectively. If a 286 network contains both IPv4 and IPv6, then they SHALL be treated as 287 separate communication paths. Clocks which communicate using IPv4 288 can interact with clocks using IPv6 if there is an intermediary 289 device which simultaneously communicates with both IP versions. A 290 boundary clock might perform this function, for example. A PTP 291 domain SHALL use either IPv4 or IPv6 over a communication path, 292 but not both. The PTP system MAY include switches and routers. 293 These devices MAY be transparent clocks, boundary clocks, or 294 neither, in any combination. PTP Clocks MAY be Preferred Masters, 295 Ordinary Clocks, or Boundary Clocks. The ordinary clocks may be 296 Slave Only Clocks, or be master capable. 298 Note that clocks SHOULD always be identified by their clock ID and 299 not the IP or Layer 2 address. This is important in IPv6 networks 300 since Transparent clocks are required to change the source address 301 of any packet which they alter. In IPv4 networks some clocks 302 might be hidden behind a NAT, which hides their IP addresses from 303 the rest of the network. Note also that the use of NATs may place 304 limitations on the topology of PTP networks, depending on the port 305 forwarding scheme employed. Details of implementing PTP with NATs 306 are out of scope of this document. 308 Similar to NTP, PTP makes the assumption that the one way network 309 delay for Sync Messages and Delay Response Messages are the same. 310 When this is not true it can cause errors in the transfer of time 311 from the Master to the Slave. It is up to system integrator to 312 design the network so that such effects do not prevent the PTP 313 system from meeting the timing requirements. The details of 314 network asymmetry are outside the scope of this document. See for 315 example, [G8271]. 317 6. Time Transfer and Delay Measurement 319 Master clocks, Transparent clocks and Boundary clocks MAY be 320 either one-step clocks or two-step clocks. Slave clocks MUST 321 support both behaviors. The End to End Delay Measurement Method 322 MUST be used. 324 Note that, in IP networks, Sync messages and Delay Request 325 messages exchanged between a master and slave do not necessarily 326 traverse the same physical path. Thus, wherever possible, the 327 network SHOULD be traffic engineered so that the forward and 328 reverse routes traverse the same physical path. Traffic 329 engineering techniques for path consistency are out of scope of 330 this document. 332 In all three of the delay measurement modes, Sync messages MUST 333 be sent as PTP event multicast messages (UDP port 319) to the PTP 334 primary IP address. Two step clocks SHALL send Follow-up 335 messages as PTP general messages (UDP port 320). Announce messages 336 MUST be sent as multicast messages (UDP port 320) to the PTP 337 primary address. The PTP primary IP address is 224.0.1.129 for 338 IPv4 and FF0X:0:0:0:0:0:0:181 for Ipv6. 340 6.1. Unicast Delay Measurement Mode 342 All Delay Request PTP event messages and Delay Response PTP 343 general messages MUST be sent as unicast messages. Unicast 344 Discovery and Unicast Message Negotiation options MUST NOT be 345 utilized. 347 6.2. Multicast Delay Measurement Mode 349 All Delay Request PTP event messages and Delay Response general 350 messages MUST be sent as multicast messages. 352 6.3. Hybrid delay Measurement Mode 354 Delay Request Messages MAY be sent as either multicast or unicast 355 PTP event messages. Master clocks SHALL respond to multicast Delay 356 Request messages with multicast Delay Response PTP general 357 messages. Master clocks SHALL respond to unicast Delay Request PTP 358 event messages with unicast Delay Response PTP general messages. 360 The default mode for Enterprise Profile PTP Master Clocks is 361 Hybrid Delay Measurement Mode. This allow for the use of Ordinary 362 clocks which do not support the Enterprise Profile, as long as 363 they are slave Only Clocks. 365 7. Default Message Rates 367 The Sync, Announce and Delay Request default message rates SHALL 368 each be once per second. The Sync and Delay Request message rates 369 MAY be set to other values, but not less than once every 128 370 seconds, and not more than 128 messages per second. The Announce 371 message rate SHALL NOT be changed from the default value. The 372 Announce Receipt Timeout Interval SHALL be three Announce 373 Intervals for Preferred Masters, and four Announce Intervals for 374 all other masters. 376 8. Timing Domains 378 All Master Clocks in the Enterprise Profile SHALL operate with the 379 PTP timing domain set in the range 0-3 when any part of the domain 380 is operating in either the Multicast Delay Measurement Mode, or 381 the Hybrid Delay Measurement Mode. The default timing domain for 382 operation with this configuration is Domain 0. All Master Clocks 383 in the Enterprise Profile SHOULD operate with the PTP timing 384 domain set in the range 40-60 when the entire domain is acting in 385 the Unicast Delay Measurement Mode. The default timing domain for 386 this configuration is Domain 40. If it is not known in advance 387 which modes will be operating in a domain, then domains 0-3 SHOULD 388 be used. 390 9. Requirements for Master Clocks 392 Master clocks SHALL obey the standard Best Master Clock Algorithm 393 from [IEEE1588]. Clocks which are master capable MAY act as 394 Alternate masters according to [IEEE1588]. Preferred Master 395 Clocks SHOULD operate as Alternate Masters when they are not the 396 Best Master. Using multiple masters can mitigate rogue master and 397 man-in-the-middle attacks such as delay attacks, packet 398 interception / manipulation attacks. Assuming the path to each 399 master is different, an attacker would have to attack more than 400 one path simultaneously. 402 The Announce Messages SHALL include a TLV which indicates that the 403 clock is operating in the Enterprise Profile. The TLV shall have 404 the following structure: 406 TLV Type (Enumeration16): ORGANIZATION_EXTENSION value = 0003 hex 408 Length Field (UInteger16): value = 2. The number of octets in the 409 Data Field 411 Organization Id (3 Octets): The Organization ID value for the IETF 412 assigned by IEEE = TBD 414 Organization SubType (Enumeration24) value = 000001hex (Enterprise 415 PTP Profile version 1) 417 Data Field, Delay Measurement Mode (Enumeration16): 419 Value 00hex = Multicast Delay Measurement Mode 421 Value 01hex = Unicast Delay Measurement Mode 423 Value 02hex = Hybrid Delay Measurement Mode 425 Values 03-FFhex = reserved for future use. 427 The TLV represents the Delay Request Mode of the Master, not 428 necessarily the Grandmaster. So for example, one port of a 429 Boundary clock could be set to Unicast Delay Measurement Mode, 430 while the rest of the network is Hybrid Delay Measurement Mode. 432 10. Requirements for Slave Clocks 434 Slave clocks MUST be able to operate properly in a network which 435 contains Alternate Masters. Slaves SHOULD make use of information 436 from the Alternate Masters in their clock control subsystems. 437 Slave Clocks MUST be able to operate properly in the presence of a 438 Rogue Master. Slaves SHOULD NOT Synchronize to a Rogue Master. 439 Slaves MAY use an Acceptable Master Table. If the Best Master is 440 not an Acceptable Master, but an Alternate Master is an Acceptable 441 Master, then the Slave SHOULD synchronize to the acceptable 442 Alternate Master. 444 Note that IEEE 1588-2008 requires slave clocks to support both 445 two-step or one-step Master clocks. See [IEEE1588], section 446 11.2. 448 Since Announce messages are sent as multicast messages in all 449 mode, slaves can obtain the IP addresses of master from the 450 Announce messages. Note that the IP source addresses of Sync and 451 Follow-up messages may have been replaced by the source addresses 452 of a transparent clock, so slaves MUST send Delay Request messages 453 to the IP address in the Announce message. Sync and Follow-up 454 messages can be correlated with the Announce message using the 455 clock ID, which is never altered by Transparent clocks. 457 11. Requirements for Transparent Clocks 459 Transparent clocks SHALL NOT change the transmission mode of an 460 Enterprise profile PTP message. For example a Transparent clock 461 SHALL NOT change a unicast message to a multicast message. 462 Transparent clocks SHALL NOT alter the Enterprise Profile TLV of 463 an Announce message, or any other part of an Announce message. 465 12. Management and Signaling Messages 467 PTP Management messages MAY be used. Any PTP management message 468 which is sent with the targetPortIdentity.clockIdentity set to all 469 1s (all clocks) MUST be sent as a multicast message. Management 470 messages with any other value of for the Clock Identity is 471 intended for a specific clock and MUST be sent as a unicast 472 message. Similarly, if any signaling messages are used they 473 MUST also be sent as unicast messages whenever the message is 474 intended for a specific clock. 476 13. Forbidden PTP Options 478 Clocks operating in the Enterprise Profile SHALL NOT use peer to 479 peer timing for delay measurement. Clocks operating in the 480 Enterprise Profile SHALL NOT use Unicast Message Negotiation to 481 determine message rates. Slave clocks operating in the Enterprise 482 Profile SHALL NOT use Unicast Discovery to establish connection to 483 Master clocks. Grandmaster Clusters are NOT ALLOWED. Clocks 484 operating in the Enterprise Profile SHALL NOT use Alternative Time 485 Scales. 487 14. Interoperation with Other PTP Profiles 489 Clocks operating in the Enterprise profile will not interoperate 490 with clocks operating in the Power Profile [C37.238], because the 491 Enterprise Profile requires the End to End Delay Measurement 492 Mechanism and the Power Profile requires the Peer to Peer Delay 493 Measurement Mechanism. 495 Clocks operating in the Enterprise profile will not interoperate 496 with clocks operating in the Telecom Profile for Frequency 497 Synchronization[G8265.1], because the Enterprise Profile forbids 498 Unicast Message Negotiation, and Unicast Discovery. These 499 features are part of the default manner of operation for the 500 Telecom Profile for Frequency Synchronization. 502 Clocks operating in the Enterprise profile will interoperate with 503 clocks operating in the default profile if the default profile 504 clocks operate on IPv4 or IPv6 networks, use the End to End Delay 505 Measurement Mechanism, and use management messages in unicast when 506 those messages are directed at a specific clock. If any of these 507 requirements are not met than Enterprise Profile clocks will not 508 interoperate with Default Profile Clocks. The Default Profile is 509 described in Annex J of [IEEE1588]. 511 Enterprise Profile Clocks will interoperate with clocks operating 512 in other profiles if the clocks in the other profiles obey the 513 rules of the Enterprise Profile. These rules MUST NOT be changed 514 to achieve interoperability with other profiles. 516 15. Security Considerations 518 Protocols used to transfer time, such as PTP and NTP can be 519 important to security mechanisms which use time windows for keys 520 and authorization. Passing time through the networks poses a 521 security risk since time can potentially be manipulated. 523 The use of multiple simultaneous masters, using the IEEE 1588 524 Alternate Master option can mitigate problems from rogue masters 525 and man-in-the-middle attacks. See sections 9 and 10. Additional 526 security mechanisms are outside the scope of this document. 528 16. IANA Considerations 530 There are no IANA requirements in this specification. 532 17. References 534 17.1. Normative References 536 [IEEE1588] IEEE std. 1588-2008, "IEEE Standard for a 537 Precision Clock Synchronization for Networked 538 Measurement and Control Systems." July, 2008. 540 [RFC768] Postel, J., "User Datagram Protocol," RFC 768, 541 August, 980. 543 [RFC791] "Internet Protocol DARPA Internet Program Protocol 544 Specification," RFC 791, September, 1981. 546 [RFC2119] Bradner, S., "Key words for use in RFCs to 547 Indicate Requirement Levels", BCP 14, RFC 2119, 548 March 1997. 550 [RFC2460] Deering, S., Hinden, R., "Internet Protocol, 551 Version 6 (IPv6) Specification," RFC 2460, 552 December, 1998. 554 17.2. Informative References 556 [C37.238] IEEE std. C37.238-2011, "IEEE Standard Profile for 557 Use of IEEE 1588 Precision Time Protocol in Power 558 System Applications," July 2011. 560 [G8265.1] ITU-T G.8265.1/Y.1365.1, "Precision time protocol 561 telecom profile for frequency synchronization," 562 October 2011. 564 [G8271] ITU-T G.8271/Y.1366, "Time and Phase 565 Synchronization Aspects of Packet Networks" 566 February, 2012. 568 [NTP] Mills, D., Martin, J., Burbank, J., Kasch, W., 569 "Network Time Protocol Version 4: Protocol and 570 Algorithms Specification," RFC 5905, June 2010. 572 18. Acknowledgments 574 The authors would like to thank members of IETF for reviewing and 575 providing feedback on this draft. 577 This document was prepared using 2-Word-v2.0.template.dot. 579 Authors' Addresses 581 Doug Arnold 582 3808 Sherbrook Dr. 583 Santa Rosa, CA 95404 584 USA 586 Email: doug.arnold2@gmail.com 588 Heiko Gerstung 589 Meinberg Funkuhren GmbH & Co. KG 590 Lange Wand 9 591 D-31812 Bad Pyrmont 592 Germany 594 Email: Heiko.gerstung@meinberg.de