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