idnits 2.17.1 draft-ietf-tictoc-ptp-enterprise-profile-21.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 == 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 [RFC6241]. -- The document date (31 August 2021) is 959 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' Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TICTOC Working Group D.A. Arnold 3 Internet-Draft Meinberg-USA 4 Intended status: Standards Track H.G. Gerstung 5 Expires: 4 March 2022 Meinberg 6 31 August 2021 8 Enterprise Profile for the Precision Time Protocol With Mixed Multicast 9 and Unicast Messages 10 draft-ietf-tictoc-ptp-enterprise-profile-21 12 Abstract 14 This document describes a profile for the use of the Precision Time 15 Protocol in an IPV4 or IPv6 Enterprise information system 16 environment. The profile uses the End to End Delay Measurement 17 Mechanism, allows both multicast and unicast Delay Request and Delay 18 Response Messages. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on 4 March 2022. 37 Copyright Notice 39 Copyright (c) 2021 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 (https://trustee.ietf.org/ 44 license-info) in effect on the date of publication of this document. 45 Please review these documents carefully, as they describe your rights 46 and restrictions with respect to this document. Code Components 47 extracted from this document must include Simplified BSD License text 48 as described in Section 4.e of the Trust Legal Provisions and are 49 provided without warranty as described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 55 3. Technical Terms . . . . . . . . . . . . . . . . . . . . . . . 4 56 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 6 57 5. Network Technology . . . . . . . . . . . . . . . . . . . . . 7 58 6. Time Transfer and Delay Measurement . . . . . . . . . . . . . 7 59 7. Default Message Rates . . . . . . . . . . . . . . . . . . . . 9 60 8. Requirements for Master Clocks . . . . . . . . . . . . . . . 9 61 9. Requirements for Slave Clocks . . . . . . . . . . . . . . . . 9 62 10. Requirements for Transparent Clocks . . . . . . . . . . . . . 10 63 11. Requirements for Boundary Clocks . . . . . . . . . . . . . . 10 64 12. Management and Signaling Messages . . . . . . . . . . . . . . 10 65 13. Forbidden PTP Options . . . . . . . . . . . . . . . . . . . . 10 66 14. Interoperation with IEEE 1588 Default Profile . . . . . . . . 10 67 15. Profile Identification . . . . . . . . . . . . . . . . . . . 11 68 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 69 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 70 18. Security Considerations . . . . . . . . . . . . . . . . . . . 11 71 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 72 19.1. Normative References . . . . . . . . . . . . . . . . . . 12 73 19.2. Informative References . . . . . . . . . . . . . . . . . 12 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 76 1. Introduction 78 The Precision Time Protocol ("PTP"), first standardized in IEEE 1588, 79 has been designed in its first version (IEEE 1588-2002) with the goal 80 to minimize configuration on the participating nodes. Network 81 communication was based solely on multicast messages, which unlike 82 NTP did not require that a receiving node ("slave clock") in 83 IEEE 1588-2019 [IEEE1588] needs to know the identity of the time 84 sources in the network (the Master Clocks). This document describes 85 clock roles and port states using the terms master and slave in order 86 to correspond to the terms used in IEEE 1588, on which this document 87 is based. There is an active project in the IEEE to select 88 alternative terms. When this project is completed, then master and 89 slave will be replaced with the new alternative terms in an update to 90 this document. 92 The "Best Master Clock Algorithm" (IEEE 1588-2019 [IEEE1588] 93 Subclause 9.3), a mechanism that all participating PTP nodes must 94 follow, set up strict rules for all members of a PTP domain to 95 determine which node shall be the active sending time source (Master 96 Clock). Although the multicast communication model has advantages in 97 smaller networks, it complicated the application of PTP in larger 98 networks, for example in environments like IP based telecommunication 99 networks or financial data centers. It is considered inefficient 100 that, even if the content of a message applies only to one receiver, 101 it is forwarded by the underlying network (IP) to all nodes, 102 requiring them to spend network bandwidth and other resources, such 103 as CPU cycles, to drop the message. 105 The third edition of the standard (IEEE 1588-2019) defines PTPv2.1 106 and includes the possibility to use unicast communication between the 107 PTP nodes in order to overcome the limitation of using multicast 108 messages for the bi-directional information exchange between PTP 109 nodes. The unicast approach avoided that, in PTP domains with a lot 110 of nodes, devices had to throw away more than 99% of the received 111 multicast messages because they carried information for some other 112 node. PTPv2.1 also includes PTP profiles (IEEE 1588-2019 [IEEE1588] 113 subclause 20.3). This construct allows organizations to specify 114 selections of attribute values and optional features, simplifying the 115 configuration of PTP nodes for a specific application. Instead of 116 having to go through all possible parameters and configuration 117 options and individually set them up, selecting a profile on a PTP 118 node will set all the parameters that are specified in the profile to 119 a defined value. If a PTP profile definition allows multiple values 120 for a parameter, selection of the profile will set the profile- 121 specific default value for this parameter. Parameters not allowing 122 multiple values are set to the value defined in the PTP profile. 123 Many PTP features and functions are optional, and a profile should 124 also define which optional features of PTP are required, permitted, 125 or prohibited. It is possible to extend the PTP standard with a PTP 126 profile by using the TLV mechanism of PTP (see IEEE 1588-2019 127 [IEEE1588] subclause 13.4), defining an optional Best Master Clock 128 Algorithm and a few other ways. PTP has its own management protocol 129 (defined in IEEE 1588-2019 [IEEE1588] subclause 15.2) but allows a 130 PTP profile specify an alternative management mechanism, for example 131 NETCONF. 133 2. Requirements Language 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 137 document are to be interpreted as described in RFC 2119 [RFC2119]. 139 3. Technical Terms 141 * Acceptable Master Table: A PTP Slave Clock may maintain a list of 142 masters which it is willing to synchronize to. 144 * Alternate Master: A PTP Master Clock, which is not the Best 145 Master, may act as a master with the Alternate Master flag set on 146 the messages it sends. 148 * Announce message: Contains the Master Clock properties of a Master 149 Clock. Used to determine the Best Master. 151 * Best Master: A clock with a port in the master state, operating 152 consistently with the Best Master Clock Algorithm. 154 * Best Master Clock Algorithm: A method for determining which state 155 a port of a PTP clock should be in. The algorithm works by 156 identifying which of several PTP Master capable clocks is the best 157 master. Clocks have priority to become the acting Grandmaster, 158 based on the properties each Master Clock sends in its Announce 159 Message. 161 * Boundary Clock: A device with more than one PTP port. Generally 162 boundary Clocks will have one port in slave state to receive 163 timing and then other ports in master state to re-distribute the 164 timing. 166 * Clock Identity: In IEEE 1588-2019 this is a 64-bit number assigned 167 to each PTP clock which must be unique. Often it is derived from 168 the Ethernet MAC address, since there is already an international 169 infrastructure for assigning unique numbers to each device 170 manufactured. 172 * Domain: Every PTP message contains a domain number. Domains are 173 treated as separate PTP systems in the network. Clocks, however, 174 can combine the timing information derived from multiple domains. 176 * End to End Delay Measurement Mechanism: A network delay 177 measurement mechanism in PTP facilitated by an exchange of 178 messages between a Master Clock and Slave Clock. 180 * Grandmaster: the primary Master Clock within a domain of a PTP 181 system 183 * IEEE 1588: The timing and synchronization standard which defines 184 PTP, and describes the node, system, and communication properties 185 necessary to support PTP. 187 * Master Clock: a clock with at least one port in the master state. 189 * NTP: Network Time Protocol, defined by RFC 5905, see RFC 5905 190 [RFC5905] 192 * Ordinary Clock: A clock that has a single Precision Time Protocol 193 (PTP) port in a domain and maintains the timescale used in the 194 domain. It may serve as a Master Clock, or be a slave clock. 196 * Peer to Peer Delay Measurement Mechanism: A network delay 197 measurement mechanism in PTP facilitated by an exchange of 198 messages between adjacent devices in a network. 200 * Preferred Master: A device intended to act primarily as the 201 Grandmaster of a PTP system, or as a back up to a Grandmaster. 203 * PTP: The Precision Time Protocol, the timing and synchronization 204 protocol defined by IEEE 1588. 206 * PTP port: An interface of a PTP clock with the network. Note that 207 there may be multiple PTP ports running on one physical interface, 208 for example, a unicast slave which talks to several Grandmaster 209 clocks in parallel. 211 * PTPv2.1: Refers specifically to the third version of PTP defined 212 by IEEE 1588-2019. 214 * Rogue Master: A clock with a port in the master state, even though 215 it should not be in the master state according to the Best Master 216 Clock Algorithm, and does not set the alternate master flag. 218 * Slave clock: a clock with at least one port in the slave state, 219 and no ports in the master state. 221 * Slave Only Clock: An Ordinary Clock which cannot become a Master 222 Clock. 224 * TLV: Type Length Value, a mechanism for extending messages in 225 networked communications. 227 * Transparent Clock. A device that measures the time taken for a 228 PTP event message to transit the device and then updates the 229 message with a correction for this transit time. 231 * Unicast Discovery: A mechanism for PTP slaves to establish a 232 unicast communication with PTP masters using a configures table of 233 master IP addresses and Unicast Message Negotiation. 235 * Unicast Negotiation: A mechanism in PTP for Slave Clocks to 236 negotiate unicast Sync, announce and Delay Request Message Rates 237 from a Master Clock. 239 4. Problem Statement 241 This document describes a version of PTP intended to work in large 242 enterprise networks. Such networks are deployed, for example, in 243 financial corporations. It is becoming increasingly common in such 244 networks to perform distributed time tagged measurements, such as 245 one-way packet latencies and cumulative delays on software systems 246 spread across multiple computers. Furthermore, there is often a 247 desire to check the age of information time tagged by a different 248 machine. To perform these measurements, it is necessary to deliver a 249 common precise time to multiple devices on a network. Accuracy 250 currently required in the Financial Industry range from 100 251 microseconds to 100 nanoseconds to the Grandmaster. This profile 252 does not specify timing performance requirements, but such 253 requirements explain why the needs cannot always be met by NTP, as 254 commonly implemented. Such accuracy cannot usually be achieved with 255 a traditional time transfer such as NTP, without adding non-standard 256 customizations such as hardware time stamping, and on path support. 257 These features are currently part of PTP, or are allowed by it. 258 Because PTP has a complex range of features and options it is 259 necessary to create a profile for enterprise networks to achieve 260 interoperability between equipment manufactured by different vendors. 262 Although enterprise networks can be large, it is becoming 263 increasingly common to deploy multicast protocols, even across 264 multiple subnets. For this reason, it is desired to make use of 265 multicast whenever the information going to many destinations is the 266 same. It is also advantageous to send information which is unique to 267 one device as a unicast message. The latter can be essential as the 268 number of PTP slaves becomes hundreds or thousands. 270 PTP devices operating in these networks need to be robust. This 271 includes the ability to ignore PTP messages which can be identified 272 as improper, and to have redundant sources of time. 274 Interoperability among independent implementations of this PTP 275 profile has been demonstrated at the ISPCS Plugfest ISPCS [ISPCS]. 277 5. Network Technology 279 This PTP profile SHALL operate only in networks characterized by UDP 280 RFC 768 [RFC0768] over either IPv4 RFC 791 [RFC0791] or IPv6 RFC 8200 281 [RFC8200], as described by Annexes D and E in IEEE 1588 [IEEE1588] 282 respectively. If a network contains both IPv4 and IPv6, then they 283 SHALL be treated as separate communication paths. Clocks which 284 communicate using IPv4 can interact with clocks using IPv6 if there 285 is an intermediary device which simultaneously communicates with both 286 IP versions. A Boundary Clock might perform this function, for 287 example. A PTP domain SHALL use either IPv4 or IPv6 over a 288 communication path, but not both. The PTP system MAY include 289 switches and routers. These devices MAY be Transparent Clocks, 290 boundary Clocks, or neither, in any combination. PTP Clocks MAY be 291 Preferred Masters, Ordinary Clocks, or Boundary Clocks. The Ordinary 292 Clocks may be Slave Only Clocks, or be master capable. 294 Note that clocks SHOULD always be identified by their clock ID and 295 not the IP or Layer 2 address. This is important in IPv6 networks 296 since Transparent Clocks are required to change the source address of 297 any packet which they alter. In IPv4 networks some clocks might be 298 hidden behind a NAT, which hides their IP addresses from the rest of 299 the network. Note also that the use of NATs may place limitations on 300 the topology of PTP networks, depending on the port forwarding scheme 301 employed. Details of implementing PTP with NATs are out of scope of 302 this document. 304 PTP, like NTP, assumes that the one-way network delay for Sync 305 Messages and Delay Response Messages are the same. When this is not 306 true it can cause errors in the transfer of time from the Master to 307 the Slave. It is up to the system integrator to design the network 308 so that such effects do not prevent the PTP system from meeting the 309 timing requirements. The details of network asymmetry are outside 310 the scope of this document. See for example, ITU-T G.8271 [G8271]. 312 6. Time Transfer and Delay Measurement 314 Master Clocks, Transparent Clocks and Boundary Clocks MAY be either 315 one-step clocks or two-step clocks. Slave clocks MUST support both 316 behaviors. The End to End Delay Measurement Method MUST be used. 318 Note that, in IP networks, Sync messages and Delay Request messages 319 exchanged between a master and slave do not necessarily traverse the 320 same physical path. Thus, wherever possible, the network SHOULD be 321 traffic engineered so that the forward and reverse routes traverse 322 the same physical path. Traffic engineering techniques for path 323 consistency are out of scope of this document. 325 Sync messages MUST be sent as PTP event multicast messages (UDP port 326 319) to the PTP primary IP address. Two step clocks SHALL send 327 Follow-up messages as PTP general messages (UDP port 320). Announce 328 messages MUST be sent as multicast messages (UDP port 320) to the PTP 329 primary address. The PTP primary IP address is 224.0.1.129 for IPv4 330 and FF0X:0:0:0:0:0:0:181 for Ipv6, where X can be a value between 0x0 331 and 0xF, see IEEE 1588 [IEEE1588] Annex E, Section E.3. 333 Delay Request Messages MAY be sent as either multicast or unicast PTP 334 event messages. Master Clocks SHALL respond to multicast Delay 335 Request messages with multicast Delay Response PTP general messages. 336 Master Clocks SHALL respond to unicast Delay Request PTP event 337 messages with unicast Delay Response PTP general messages. This 338 allow for the use of Ordinary Clocks which do not support the 339 Enterprise Profile, if they are slave Only Clocks. 341 Clocks SHOULD include support for multiple domains. The purpose is 342 to support multiple simultaneous masters for redundancy. Leaf 343 devices (non-forwarding devices) can use timing information from 344 multiple masters by combining information from multiple 345 instantiations of a PTP stack, each operating in a different domain. 346 Redundant sources of timing can be ensembled, and/or compared to 347 check for faulty Master Clocks. The use of multiple simultaneous 348 masters will help mitigate faulty masters reporting as healthy, 349 network delay asymmetry, and security problems. Security problems 350 include man-in-the-middle attacks such as delay attacks, packet 351 interception / manipulation attacks. Assuming the path to each 352 master is different, failures malicious or otherwise would have to 353 happen at more than one path simultaneously. Whenever feasible, the 354 underlying network transport technology SHOULD be configured so that 355 timing messages in different domains traverse different network 356 paths. 358 7. Default Message Rates 360 The Sync, Announce and Delay Request default message rates SHALL each 361 be once per second. The Sync and Delay Request message rates MAY be 362 set to other values, but not less than once every 128 seconds, and 363 not more than 128 messages per second. The Announce message rate 364 SHALL NOT be changed from the default value. The Announce Receipt 365 Timeout Interval SHALL be three Announce Intervals for Preferred 366 Masters, and four Announce Intervals for all other masters. 368 The logMessageInterval carried in the unicast Delay Response message 369 MAY be set to correspond to the master ports preferred message 370 period, rather than 7F, which indicates message periods are to be 371 negotiated. Note that negotiated message periods are not allowed, 372 see forbidden PTP options (Section 13). 374 8. Requirements for Master Clocks 376 Master Clocks SHALL obey the standard Best Master Clock Algorithm 377 from IEEE 1588 [IEEE1588]. PTP systems using this profile MAY 378 support multiple simultaneous Grandmasters if each active Grandmaster 379 is operating in a different PTP domain. 381 A port of a clock SHALL NOT be in the master state unless the clock 382 has a current value for the number of UTC leap seconds. 384 If a unicast negotiation signaling message is received it SHALL be 385 ignored. 387 9. Requirements for Slave Clocks 389 Slave clocks MUST be able to operate properly in a network which 390 contains multiple Masters in multiple domains. Slaves SHOULD make 391 use of information from the all Masters in their clock control 392 subsystems. Slave Clocks MUST be able to operate properly in the 393 presence of a Rogue Master. Slaves SHOULD NOT Synchronize to a 394 Master which is not the Best Master in its domain. Slaves will 395 continue to recognize a Best Master for the duration of the Announce 396 Time Out Interval. Slaves MAY use an Acceptable Master Table. If a 397 Master is not an Acceptable Master, then the Slave MUST NOT 398 synchronize to it. Note that IEEE 1588-2019 requires slave clocks to 399 support both two-step or one-step Master clocks. See IEEE 1588 400 [IEEE1588], subClause 11.2. 402 Since Announce messages are sent as multicast messages slaves can 403 obtain the IP addresses of a master from the Announce messages. Note 404 that the IP source addresses of Sync and Follow-up messages may have 405 been replaced by the source addresses of a Transparent Clock, so, 406 slaves MUST send Delay Request messages to the IP address in the 407 Announce message. Sync and Follow-up messages can be correlated with 408 the Announce message using the clock ID, which is never altered by 409 Transparent Clocks in this profile. 411 10. Requirements for Transparent Clocks 413 Transparent Clocks SHALL NOT change the transmission mode of an 414 Enterprise Profile PTP message. For example, a Transparent Clock 415 SHALL NOT change a unicast message to a multicast message. 416 Transparent Clocks SHOULD support multiple domains. Transparent 417 Clocks which syntonize to the master clock will need to maintain 418 separate clock rate offsets for each of the supported domains. 420 11. Requirements for Boundary Clocks 422 Boundary Clocks SHOULD support multiple simultaneous PTP domains. 423 This will require them to maintain servo loops for each of the 424 domains supported, at least in software. Boundary Clocks MUST NOT 425 combine timing information from different domains. 427 12. Management and Signaling Messages 429 PTP Management messages MAY be used. Management messages intended 430 for a specific clock, i.e. the IEEE 1588 [IEEE1588] defined attribute 431 targetPortIdentity.clockIdentity is not set to All 1s, MUST be sent 432 as a unicast message. Similarly, if any signaling messages are used 433 they MUST also be sent as unicast messages whenever the message is 434 intended for a specific clock. 436 13. Forbidden PTP Options 438 Clocks operating in the Enterprise Profile SHALL NOT use peer to peer 439 timing for delay measurement. Grandmaster Clusters are NOT ALLOWED. 440 The Alternate Master option is also NOT ALLOWED. Clocks operating in 441 the Enterprise Profile SHALL NOT use Alternate Timescales. Unicast 442 discovery and unicast negotiation SHALL NOT be used. 444 14. Interoperation with IEEE 1588 Default Profile 446 Clocks operating in the Enterprise Profile will interoperate with 447 clocks operating in the Default Profile described in IEEE 1588 448 [IEEE1588] Annex J.3. This variant of the Default Profile uses the 449 End to End Delay Measurement Mechanism. In addition, the Default 450 Profile would have to operate over IPv4 or IPv6 networks, and use 451 management messages in unicast when those messages are directed at a 452 specific clock. If either of these requirements are not met than 453 Enterprise Profile clocks will not interoperate with Annex J.3 454 Default Profile Clocks. The Enterprise Profile will not interoperate 455 with the Annex J.4 variant of the Default Profile which requires use 456 of the Peer to Peer Delay Measurement Mechanism. 458 Enterprise Profile Clocks will interoperate with clocks operating in 459 other profiles if the clocks in the other profiles obey the rules of 460 the Enterprise Profile. These rules MUST NOT be changed to achieve 461 interoperability with other profiles. 463 15. Profile Identification 465 The IEEE 1588 standard requires that all profiles provide the 466 following identifying information. 468 PTP Profile: 469 Enterprise Profile 470 Version: 1.0 471 Profile identifier: 00-00-5E-00-01-00 473 This profile was specified by the IETF 475 A copy may be obtained at 476 https://datatracker.ietf.org/wg/tictoc/documents 478 16. Acknowledgements 480 The authors would like to thank members of IETF for reviewing and 481 providing feedback on this draft. 483 This document was initially prepared using 2-Word-v2.0.template.dot 484 and has later been converted manually into xml format using an 485 xml2rfc template. 487 17. IANA Considerations 489 There are no IANA requirements in this specification. 491 18. Security Considerations 493 Protocols used to transfer time, such as PTP and NTP can be important 494 to security mechanisms which use time windows for keys and 495 authorization. Passing time through the networks poses a security 496 risk since time can potentially be manipulated. The use of multiple 497 simultaneous masters, using multiple PTP domains can mitigate 498 problems from rogue masters and man-in-the-middle attacks. See 499 sections 9 and 10. Additional security mechanisms are outside the 500 scope of this document. 502 PTP native management messages SHOULD not be used, due to the lack of 503 a security mechanism for this option. Secure management can be 504 obtained using standard management mechanisms which include security, 505 for example NETCONF NETCONF [RFC6241]. 507 General security considerations of time protocols are discussed in 508 RFC 7384 [RFC7384]. 510 19. References 512 19.1. Normative References 514 [IEEE1588] Institute of Electrical and Electronics Engineers, "IEEE 515 std. 1588-2019, "IEEE Standard for a Precision Clock 516 Synchronization for Networked Measurement and Control 517 Systems."", November 2019, . 519 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 520 DOI 10.17487/RFC0768, August 1980, 521 . 523 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 524 DOI 10.17487/RFC0791, September 1981, 525 . 527 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 528 Requirement Levels", BCP 14, RFC 2119, 529 DOI 10.17487/RFC2119, March 1997, 530 . 532 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 533 (IPv6) Specification", STD 86, RFC 8200, 534 DOI 10.17487/RFC8200, July 2017, 535 . 537 19.2. Informative References 539 [G8271] International Telecommunication Union, "ITU-T G.8271/ 540 Y.1366, "Time and Phase Synchronization Aspects of Packet 541 Networks"", February 2012, . 543 [ISPCS] Arnold, D.A., "Plugfest Report", October 2017, 544 . 546 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 547 "Network Time Protocol Version 4: Protocol and Algorithms 548 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 549 . 551 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 552 and A. Bierman, Ed., "Network Configuration Protocol 553 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 554 . 556 [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in 557 Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384, 558 October 2014, . 560 Authors' Addresses 562 Doug Arnold 563 Meinberg-USA 564 3 Concord Rd 565 Shrewsbury, Massachusetts 01545 566 United States of America 568 Email: doug.arnold@meinberg-usa.com 570 Heiko Gerstung 571 Meinberg 572 Lange Wand 9 573 31812 Bad Pyrmont 574 Germany 576 Email: heiko.gerstung@meinberg.de