idnits 2.17.1 draft-ietf-tictoc-ptp-enterprise-profile-12.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 2 longer pages, the longest (page 6) being 61 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 52 instances of lines with control characters in the document. == 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 == 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: PTP native management messages SHOULD not be used, due to the lack of a security mechanism for this option. Secure management can be obtained using standard management mechanisms which include security, for example NETCONF [NETCONF]. -- Couldn't find a document date in the document -- date freshness check skipped. 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' Summary: 1 error (**), 0 flaws (~~), 4 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 Meinberg-USA 3 Intended status: Standards Track Heiko Gerstung 4 Meinberg 5 Expires: June 30, 2019 7 Enterprise Profile for the Precision Time Protocol 8 With Mixed Multicast and Unicast Messages 10 draft-ietf-tictoc-ptp-enterprise-profile-12.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 31, 2019. 38 Copyright Notice 39 Copyright (c) 2018 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 54 This document describes a profile for the use of the Precision 55 Time Protocol in an IPV4 or IPv6 Enterprise information system 56 environment. The profile uses the End to End Delay Measurement 57 Mechanism, allows both multicast and unicast Delay Request and Delay 58 Response Messages. 60 Table of Contents 62 1. Introduction 2 63 2. Conventions used in this document 3 64 3. Technical Terms 3 65 4. Problem Statement 5 66 5. Network Technology 6 67 6. Time Transfer and Delay Measurement 7 68 7. Default Message Rates 8 69 8. Requirements for Master Clocks 8 70 9. Requirements for Slave Clocks 8 71 10. Requirements for Transparent Clocks 9 72 11. Requirements for Boundary Clocks 9 73 12. Management and Signaling Messages 9 74 13. Forbidden PTP Options 9 75 14. Interoperation with Other PTP Profiles 10 76 15. Profile Identification 10 77 16. Security Considerations 10 78 17. IANA Considerations 10 79 18. References 11 80 18.1. Normative References 11 81 18.2. Informative References 11 82 19. Acknowledgments 11 83 20. Authors addresses 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 "Best Master Clock Algorithm" ([IEEE1588] Subclause 9.3), a 96 mechanism that all participating PTP nodes must follow, set up 97 strict rules for all members of a PTP domain to determine which 98 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, such as CPU cycles, to drop the 107 message. 109 The second revision of the standard (IEEE 1588-2008) is the 110 current version (also known as PTPv2) and introduced the 111 possibility to use unicast communication between the PTP nodes in 112 order to overcome the limitation of using multicast messages for 113 the bi-directional information exchange between PTP nodes. The 114 unicast approach avoided that, in PTP domains with a lot of nodes, 115 devices had to throw away more than 99% of the received multicast 116 messages because they carried information for some other node. 117 PTPv2 also introduced PTP profiles ([IEEE1588] subclause 19.3). 118 This construct allows organizations to specify selections of 119 attribute values and optional features, simplifying the 120 configuration of PTP nodes for a specific application. Instead of 121 having to go through all possible parameters and configuration 122 options and individually set them up, selecting a profile on a PTP 123 node will set all the parameters that are specified in the profile 124 to a defined value. If a PTP profile definition allows multiple 125 values for a parameter, selection of the profile will set the 126 profile-specific default value for this parameter. Parameters not 127 allowing multiple values are set to the value defined in the PTP 128 profile. Many PTP features and functions are optional, and a 129 profile should also define which optional features of PTP are 130 required, permitted, or prohibited. It is possible to extend the 131 PTP standard with a PTP profile by using the TLV mechanism of PTP 132 (see [IEEE1588] subclause 13.4), defining an optional Best Master 133 Clock Algorithm and a few other ways. PTP has its own management 134 protocol (defined in [IEEE1588] subclause 15.2) but allows a PTP 135 profile specify an alternative management mechanism, for example 136 SNMP. 138 2. Conventions used in this document 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 141 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 142 in this document are to be interpreted as described in RFC-2119 143 [RFC2119]. 145 In this document, these words will appear with that interpretation 146 only when in ALL CAPS. Lower case uses of these words are not to 147 be interpreted as carrying RFC-2119 significance. 149 3. Technical Terms 151 Acceptable Master Table: A PTP Slave Clock may maintain a list of 152 masters which it is willing to synchronize to. 154 Alternate Master: A PTP Master Clock, which is not the Best 155 Master, may act as a master with the Alternate Master flag set on 156 the messages it sends. 158 Announce message: Contains the Master Clock properties of a Master 159 Clock. Used to determine the Best Master. 161 Best Master: A clock with a port in the master state, operating 162 consistently with the Best Master Clock Algorithm. 164 Best Master Clock Algorithm: A method for determining which state 165 a port of a PTP clock should be in. The algorithm works by 166 identifying which of several PTP Master capable clocks is the best 167 master. Clocks have priority to become the acting Grandmaster, 168 based on the properties each Master Clock sends in its Announce 169 Message. 171 Boundary Clock: A device with more than one PTP port. Generally 172 boundary Clocks will have one port in slave state to receive 173 timing and then other ports in master state to re-distribute the 174 timing. 176 Clock Identity: In IEEE 1588-2008 this is a 64-bit number 177 assigned to each PTP clock which must be unique. Often it is 178 derived from the Ethernet MAC address, since there is already an 179 international infrastructure for assigning unique numbers to each 180 device manufactured. 182 Domain: Every PTP message contains a domain number. Domains are 183 treated as separate PTP systems in the network. Clocks, however, 184 can combine the timing information derived from multiple domains. 186 End to End Delay Measurement Mechanism: A network delay 187 measurement mechanism in PTP facilitated by an exchange of 188 messages between a Master Clock and Slave Clock. 190 Grandmaster: the primary Master Clock within a domain of a PTP 191 system 193 IEEE 1588: The timing and synchronization standard which defines 194 PTP, and describes the node, system, and communication properties 195 necessary to support PTP. 197 Master Clock: a clock with at least one port in the master state. 199 NTP: Network Time Protocol, defined by RFC 5905, see [NTP]. 201 Ordinary Clock: A clock that has a single Precision Time Protocol 202 (PTP) port in a domain and maintains the timescale used in the 203 domain. It may serve as a Master Clock, or be a slave clock. 205 Peer to Peer Delay Measurement Mechanism: A network delay 206 measurement mechanism in PTP facilitated by an exchange of 207 messages between adjacent devices in a network. 209 Preferred Master: A device intended to act primarily as the 210 Grandmaster of a PTP system, or as a back up to a Grandmaster. 212 PTP: The Precision Time Protocol, the timing and synchronization 213 protocol defined by IEEE 1588. 215 PTP port: An interface of a PTP clock with the network. Note that 216 there may be multiple PTP ports running on one physical interface, 217 for example, a unicast slave which talks to several Grandmaster 218 clocks in parallel. 220 PTPv2: Refers specifically to the second version of PTP defined by 221 IEEE 1588-2008. 223 Rogue Master: A clock with a port in the master state, even though 224 it should not be in the master state according to the Best Master 225 Clock Algorithm, and does not set the alternate master flag. 227 Slave clock: a clock with at least one port in the slave state, 228 and no ports in the master state. 230 Slave Only Clock: An Ordinary Clock which cannot become a Master 231 Clock. 233 TLV: Type Length Value, a mechanism for extending messages in 234 networked communications. 236 Transparent Clock. A device that measures the time taken for a 237 PTP event message to transit the device and then updates the 238 message with a correction for this transit time. 240 Unicast Discovery: A mechanism for PTP slaves to establish a 241 unicast communication with PTP masters using a configures table of 242 master IP addresses and Unicast Message Negotiation. 244 Unicast Negotiation: A mechanism in PTP for Slave Clocks to 245 negotiate unicast Sync, announce and Delay Request Message Rates 246 from a Master Clock. 248 4. Problem Statement 250 This document describes a version of PTP intended to work in large 251 enterprise networks. Such networks are deployed, for example, in 252 financial corporations. It is becoming increasingly common in such 253 networks to perform distributed time tagged measurements, such as 254 one-way packet latencies and cumulative delays on software 255 systems spread across multiple computers. Furthermore, there is 256 often a desire to check the age of information time tagged by a 257 different machine. To perform these measurements, it is necessary 258 to deliver a common precise time to multiple devices on a network. 259 Accuracy currently required in the Financial Industry range from 260 100 microseconds to 100 nanoseconds to the Grandmaster. This 261 profile does not specify timing performance requirements, but such 262 requirements explain why the needs cannot always be met by NTP, as 263 commonly implemented. Such accuracy cannot usually be achieved with 264 a traditional time transfer such as NTP, without adding 265 non-standard customizations such as hardware time stamping, and on 266 path support. These features are currently part of PTP, or are 267 allowed by it. Because PTP has a complex range of features and 268 options it is necessary to create a profile for enterprise 269 networks to achieve interoperability between equipment 270 manufactured by different vendors. 272 Although enterprise networks can be large, it is becoming 273 increasingly common to deploy multicast protocols, even across 274 multiple subnets. For this reason, it is desired to make use of 275 multicast whenever the information going to many destinations is 276 the same. It is also advantageous to send information which is 277 unique to one device as a unicast message. The latter can be 278 essential as the number of PTP slaves becomes hundreds or 279 thousands. 281 PTP devices operating in these networks need to be robust. This 282 includes the ability to ignore PTP messages which can be 283 identified as improper, and to have redundant sources of time. 285 Interoperability among independent implementations of this PTP 286 profile has been demonstrated at the ISPCS Plugfest [ISPCS]. 288 5. Network Technology 290 This PTP profile SHALL operate only in networks characterized by 291 UDP [RFC768] over either IPv4 [RFC791] or IPv6 [RFC8200], as 292 described by Annexes D and E in [IEEE1588] respectively. If a 293 network contains both IPv4 and IPv6, then they SHALL be treated as 294 separate communication paths. Clocks which communicate using IPv4 295 can interact with clocks using IPv6 if there is an intermediary 296 device which simultaneously communicates with both IP versions. A 297 Boundary Clock might perform this function, for example. A PTP 298 domain SHALL use either IPv4 or IPv6 over a communication path, 299 but not both. The PTP system MAY include switches and routers. 300 These devices MAY be Transparent Clocks, boundary Clocks, or 301 neither, in any combination. PTP Clocks MAY be Preferred Masters, 302 Ordinary Clocks, or Boundary Clocks. The Ordinary Clocks may be 303 Slave Only Clocks, or be master capable. 305 Note that clocks SHOULD always be identified by their clock ID and 306 not the IP or Layer 2 address. This is important in IPv6 networks 307 since Transparent Clocks are required to change the source address 308 of any packet which they alter. In IPv4 networks some clocks 309 might be hidden behind a NAT, which hides their IP addresses from 310 the rest of the network. Note also that the use of NATs may place 311 limitations on the topology of PTP networks, depending on the port 312 forwarding scheme employed. Details of implementing PTP with NATs 313 are out of scope of this document. 315 PTP, like NTP, assumes that the one-way network delay for Sync 316 Messages and Delay Response Messages are the same. When this is 317 not true it can cause errors in the transfer of time from the 318 Master to the Slave. It is up to the system integrator to design 319 the network so that such effects do not prevent the PTP system 320 from meeting the timing requirements. The details of 321 network asymmetry are outside the scope of this document. See for 322 example, [G8271]. 324 6. Time Transfer and Delay Measurement 326 Master Clocks, Transparent Clocks and Boundary Clocks MAY be 327 either one-step clocks or two-step clocks. Slave clocks MUST 328 support both behaviors. The End to End Delay Measurement Method 329 MUST be used. 331 Note that, in IP networks, Sync messages and Delay Request 332 messages exchanged between a master and slave do not necessarily 333 traverse the same physical path. Thus, wherever possible, the 334 network SHOULD be traffic engineered so that the forward and 335 reverse routes traverse the same physical path. Traffic 336 engineering techniques for path consistency are out of scope of 337 this document. 339 Sync messages MUST be sent as PTP event multicast messages (UDP 340 port 319) to the PTP primary IP address. Two step clocks SHALL 341 send Follow-up messages as PTP general messages (UDP port 320). 342 Announce messages MUST be sent as multicast messages (UDP port 320) 343 to the PTP primary address. The PTP primary IP address is 344 224.0.1.129 for IPv4 and FF0X:0:0:0:0:0:0:181 for Ipv6, where X can 345 be a value between 0x0 and 0xF, see [IEEE1588] Annex E, Section 346 E.3. 348 Delay Request Messages MAY be sent as either multicast or unicast 349 PTP event messages. Master Clocks SHALL respond to multicast Delay 350 Request messages with multicast Delay Response PTP general 351 messages. Master Clocks SHALL respond to unicast Delay Request PTP 352 event messages with unicast Delay Response PTP general messages. 353 This allow for the use of Ordinary Clocks which do not support the 354 Enterprise Profile, if they are slave Only Clocks. 356 Clocks SHOULD include support for multiple domains. The purpose is 357 to support multiple simultaneous masters for redundancy. Leaf 358 devices (non-forwarding devices) can use timing information from 359 multiple masters by combining information from multiple 360 instantiations of a PTP stack, each operating in a different 361 domain. Redundant sources of timing can be ensembled, and/or 362 compared to check for faulty Master Clocks. The use of multiple 363 simultaneous masters will help mitigate faulty masters reporting as 364 healthy, network delay asymmetry, and security problems. Security 365 problems include man-in-the-middle attacks such as delay attacks, 366 packet interception / manipulation attacks. Assuming the path to 367 each master is different, failures malicious or otherwise would 368 have to happen at more than one path simultaneously. Whenever 369 feasible, the underlying network transport technology SHOULD be 370 configured so that timing messages in different domains traverse 371 different network paths. 373 7. Default Message Rates 375 The Sync, Announce and Delay Request default message rates SHALL 376 each be once per second. The Sync and Delay Request message rates 377 MAY be set to other values, but not less than once every 128 378 seconds, and not more than 128 messages per second. The Announce 379 message rate SHALL NOT be changed from the default value. The 380 Announce Receipt Timeout Interval SHALL be three Announce 381 Intervals for Preferred Masters, and four Announce Intervals for 382 all other masters. 384 The logMessageInterval carried in the unicast Delay Response 385 message MAY be set to correspond to the master ports preferred 386 message period, rather than 7F, which indicates message periods 387 are to be negotiated. Note that negotiated message periods are not 388 allowed, see section 13. 390 8. Requirements for Master Clocks 392 Master Clocks SHALL obey the standard Best Master Clock Algorithm 393 from [IEEE1588]. PTP systems using this profile MAY support 394 multiple simultaneous Grandmasters if each active Grandmaster is 395 operating in a different PTP domain. 397 A port of a clock SHALL NOT be in the master state unless the 398 clock has a current value for the number of UTC leap 399 seconds. 401 If a unicast negotiation signaling message is received it SHALL 402 be ignored. 404 9. Requirements for Slave Clocks 406 Slave clocks MUST be able to operate properly in a network which 407 contains multiple Masters in multiple domains. Slaves SHOULD make 408 use of information from the all Masters in their clock control 409 subsystems. Slave Clocks MUST be able to operate properly in the 410 presence of a Rogue Master. Slaves SHOULD NOT Synchronize to a 411 Master which is not the Best Master in its domain. Slaves will 412 continue to recognize a Best Master for the duration of the 413 Announce Time Out Interval. Slaves MAY use an Acceptable Master 414 Table. If a Master is not an Acceptable Master, then the Slave 415 MUST NOT synchronize to it. Note that IEEE 1588-2008 requires 416 slave clocks to support both two-step or one-step Master clocks. 417 See [IEEE1588], subClause 11.2. 419 Since Announce messages are sent as multicast messages slaves can 420 obtain the IP addresses of a master from the Announce messages. 421 Note that the IP source addresses of Sync and Follow-up messages 422 may have been replaced by the source addresses of a Transparent 423 Clock, so, slaves MUST send Delay Request messages to the IP 424 address in the Announce message. Sync and Follow-up messages can 425 be correlated with the Announce message using the clock ID, which 426 is never altered by Transparent Clocks in this profile. 428 10. Requirements for Transparent Clocks 430 Transparent Clocks SHALL NOT change the transmission mode of an 431 Enterprise Profile PTP message. For example, a Transparent Clock 432 SHALL NOT change a unicast message to a multicast message. 433 Transparent Clocks SHOULD support multiple domains. Transparent 434 Clocks which syntonize to the master clock will need to maintain 435 separate clock rate offsets for each of the supported domains. 437 11. Requirements for Boundary Clocks 439 Boundary Clocks SHOULD support multiple simultaneous PTP domains. 440 This will require them to maintain servo loops for each of the 441 domains supported, at least in software. Boundary Clocks MUST NOT 442 combine timing information from different domains. 444 12. Management and Signaling Messages 446 PTP Management messages MAY be used. Management 447 messages intended for a specific clock, i.e. the [IEEE1588] defined 448 attribute targetPortIdentity.clockIdentity is not set to All 1's, 449 MUST be sent as a unicast message. Similarly, if any signaling 450 messages are used they MUST also be sent as unicast messages 451 whenever the message is intended for a specific clock. 453 13. Forbidden PTP Options 455 Clocks operating in the Enterprise Profile SHALL NOT use peer to 456 peer timing for delay measurement. Grandmaster Clusters are NOT 457 ALLOWED. The Alternate Master option is also NOT ALLOWED. Clocks 458 operating in the Enterprise Profile SHALL NOT use Alternate 459 Timescales. Unicast discovery and unicast negotiation SHALL NOT be 460 used. 462 14. Interoperation with IEEE 1588 Default Profile 464 Clocks operating in the Enterprise Profile will interoperate with 465 clocks operating in the Default Profile described in [IEEE1588] 466 Annex J.3. This variant of the Default Profile uses the End to End 467 Delay Measurement Mechanism. In addition, the Default Profile 468 would have to operate over IPv4 or IPv6 networks, and use 469 management messages in unicast when those messages are directed at 470 a specific clock. If either of these requirements are not met than 471 Enterprise Profile clocks will not interoperate with Annex J.3 472 Default Profile Clocks. The Enterprise Profile will not 473 interoperate with the Annex J.4 variant of the Default Profile 474 which requires use of the Peer to Peer Delay Measurement Mechanism. 476 Enterprise Profile Clocks will interoperate with clocks operating 477 in other profiles if the clocks in the other profiles obey the 478 rules of the Enterprise Profile. These rules MUST NOT be changed 479 to achieve interoperability with other profiles. 481 15. Profile Identification 483 The IEEE 1588 standard requires that all profiles provide the 484 following identifying information. 486 PTP Profile: 487 Enterprise Profile 488 Version: 1.0 489 Profile identifier: 00-00-5E-00-01-00 491 This profile was specified by the IETF 493 A copy may be obtained at 494 https://datatracker.ietf.org/wg/tictoc/documents 496 16. Security Considerations 498 Protocols used to transfer time, such as PTP and NTP can be 499 important to security mechanisms which use time windows for keys 500 and authorization. Passing time through the networks poses a 501 security risk since time can potentially be manipulated. 502 The use of multiple simultaneous masters, using multiple PTP 503 domains can mitigate problems from rogue masters and 504 man-in-the-middle attacks. See sections 9 and 10. Additional 505 security mechanisms are outside the scope of this document. 507 PTP native management messages SHOULD not be used, due to the lack 508 of a security mechanism for this option. Secure management can be 509 obtained using standard management mechanisms which include 510 security, for example NETCONF [NETCONF]. 512 General security considerations of time protocols are discussed in 513 [RFC7384]. 515 17. IANA Considerations 517 There are no IANA requirements in this specification. 519 18. References 521 18.1. Normative References 523 [IEEE1588] IEEE std. 1588-2008, "IEEE Standard for a 524 Precision Clock Synchronization for Networked 525 Measurement and Control Systems." July, 2008. 526 [RFC768] Postel, J., "User Datagram Protocol," RFC 768, 527 August, 980. 529 [RFC791] "Internet Protocol DARPA Internet Program Protocol 530 Specification," RFC 791, September, 1981. 532 [RFC2119] Bradner, S., "Key words for use in RFCs to 533 Indicate Requirement Levels", BCP 14, RFC 2119, 534 March 1997. 536 [RFC8200] Deering, S., Hinden, R., "Internet Protocol, 537 Version 6 (IPv6) Specification," RFC 8200, 538 July, 2017. 540 18.2. Informative References 542 [G8271] ITU-T G.8271/Y.1366, "Time and Phase 543 Synchronization Aspects of Packet Networks" 544 February, 2012. 546 [ISPCS] Arnold, D., et. al. "Plugfest Report," 547 International Symposium on Precision Clock 548 Synchronization for Measurement, Control and 549 Communications, Monterey, CA, October, 2017. 551 [NETCONF] Ens, R., et. al., "Network Configuration Protocol 552 (NETCONF)," RFC 6241, June, 2011. 554 [NTP] Mills, D., Martin, J., Burbank, J., Kasch, W., 555 "Network Time Protocol Version 4: Protocol and 556 Algorithms Specification," RFC 5905, June 2010. 558 [RFC7384] Mizrahi, T., "Security Requirements of Time 559 Protocols in Packet Switched Networks," RFC 7384, 560 October, 2014. 562 19. Acknowledgments 564 The authors would like to thank members of IETF for reviewing and 565 providing feedback on this draft. 567 This document was initially prepared using 568 2-Word-v2.0.template.dot. 570 20. Authors' Addresses 572 Doug Arnold 573 Meinberg USA 574 929 Salem End Road 575 Framingham, MA 01702 576 USA 578 Email: doug.arnold@meinberg-usa.com 580 Heiko Gerstung 581 Meinberg Funkuhren GmbH & Co. KG 582 Lange Wand 9 583 D-31812 Bad Pyrmont 584 Germany 586 Email: heiko.gerstung@meinberg.de