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