idnits 2.17.1 draft-ietf-tictoc-ptp-enterprise-profile-05.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 (Feb 4, 2015) is 3362 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE1588' ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TICTOC Working Group Doug Arnold 2 Internet Draft Meinberg-USA 3 Intended status: Standards Track Heiko Gerstung 4 Meinberg 5 Expires: August 4, 2015 Feb 4, 2015 7 Enterprise Profile for the Precision Time Protocol 8 With Mixed Multicast and Unicast Messages 10 draft-ietf-tictoc-ptp-enterprise-profile-05.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 Agust 4, 2015. 38 Copyright Notice 39 Copyright (c) 2015 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 9 71 10. Requirements for Transparent Clocks 9 72 11. Requirements for Boundary Clocks 10 73 12. Management and Signaling Messages 10 74 13. Forbidden PTP Options 10 75 14. Interoperation with Other PTP Profiles 10 76 15. Security Considerations 11 77 16. IANA Considerations 11 78 17. References 11 79 17.1. Normative References 11 80 17.2. Informative References 12 81 18. Acknowledgments 12 82 19. Authors addresses 12 84 1. Introduction 86 The Precision Time Protocol ("PTP"), standardized in IEEE 1588, 87 has been designed in its first version (IEEE 1588-2002) with the 88 goal to minimize configuration on the participating nodes. Network 89 communication was based solely on multicast messages, which unlike 90 NTP did not require that a receiving node ("slave clock") in 91 [IEEE1588] needs to know the identity of the time sources in the 92 network (the Master Clocks). 94 The so-called "Best Master Clock Algorithm" ([IEEE1588] Clause 95 9.3), a mechanism that all participating PTP nodes must follow, 96 set up strict rules for all members of a PTP domain to determine 97 which node shall be the active sending time source (Master Clock). 98 Although the multicast communication model has advantages in 99 smaller networks, it complicated the application of PTP in larger 100 networks, for example in environments like IP based 101 telecommunication networks or financial data centers. It is 102 considered inefficient that, even if the content of a message 103 applies only to one receiver, it is forwarded by the underlying 104 network (IP) to all nodes, requiring them to spend network 105 bandwidth and other resources like CPU cycles to drop the message. 107 The second revision of the standard (IEEE 1588-2008) is the 108 current version (also known as PTPv2) and introduced the 109 possibility to use unicast communication between the PTP nodes in 110 order to overcome the limitation of using multicast messages for 111 the bi-directional information exchange between PTP nodes. The 112 unicast approach avoided that, in PTP domains with a lot of nodes, 113 devices had to throw away up to 99% of the received multicast 114 messages because they carried information for some other node. 115 PTPv2 also introduced so-called "PTP profiles" ([IEEE1588] Clause 116 19.3). This construct allows organizations to specify selections 117 of attribute values and optional features, simplifying the 118 configuration of PTP nodes for a specific application. Instead of 119 having to go through all possible parameters and configuration 120 options and individually set them up, selecting a profile on a PTP 121 node will set all the parameters that are specified in the profile 122 to a defined value. If a PTP profile definition allows multiple 123 values for a parameter, selection of the profile will set the 124 profile-specific default value for this parameter. Parameters not 125 allowing multiple values are set to the value defined in the PTP 126 profile. A number of PTP features and functions are optional and a 127 profile should also define which optional features of PTP are 128 required, permitted or prohibited. It is possible to extend the 129 PTP standard with a PTP profile by using the TLV mechanism of PTP 130 (see [IEEE1588] Clause 13.4), defining an optional Best Master 131 Clock Algorithm and a few other ways. PTP has its own management 132 protocol (defined in [IEEE1588] Clause 15.2) but allows a PTP 133 profile specify an alternative management mechanism, for example 134 SNMP. 136 2. Conventions used in this document 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 139 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 140 in this document are to be interpreted as described in RFC-2119 141 [RFC2119]. 143 In this document, these words will appear with that interpretation 144 only when in ALL CAPS. Lower case uses of these words are not to 145 be interpreted as carrying RFC-2119 significance. 147 3. Technical Terms 149 Acceptable Master Table: A PTP Slave Clock may maintain a list of 150 masters which it is willing to synchronize to. 152 Alternate Master: A PTP Master Clock, which is not the Best 153 Master, may act as a master with the Alternate Master flag set on 154 the messages it sends. 156 Announce message: Contains the master clock properties of a Master 157 clock. Used to determine the Best Master. 159 Best Master: A clock with a port in the master state, operating 160 consistently with the Best Master Clock Algorithm. 162 Best Master Clock Algorithm: A method for determining which state 163 a port of a PTP clock should be in. The algorithm works by 164 identifying which of several PTP Master capable clocks is the best 165 master. Clocks have priority to become the acting Grandmaster, 166 based on the properties each Master Clock sends in its Announce 167 Message. 169 Boundary Clock: A device with more than one PTP port. Generally 170 boundary clocks will have one port in slave state to receive 171 timing and then other ports in master state to re-distribute the 172 timing. 174 Clock Identity: In IEEE 1588-2008 this is a 64-bit number 175 assigned to each PTP clock which must be unique. Often the 176 Ethernet MAC address is used since there is already an 177 international infrastructure for assigning unique numbers to each 178 device manufactured. 180 Domain: Every PTP message contains a domain number. Domains are 181 treated as separate PTP systems in the network. Slaves, however, 182 can combine the timing information derived from multiple domains. 184 End to End Delay Measurement Mechanism: A network delay 185 measurement mechanism in PTP facilitated by an exchange of 186 messages between a Master Clock and Slave Clock. 188 Grandmaster: the primary master clock within a domain of a PTP 189 system 191 IEEE 1588: The timing and synchronization standard which defines 192 PTP, and describes The node, system, and communication properties 193 necessary to support PTP. 195 Master clock: a clock with at least one port in the master state. 197 NTP: Network Time Protocol, defined by RFC 5905, see [NTP]. 199 Ordinary Clock: A clock that has a single Precision Time Protocol 200 (PTP) port in a domain and maintains the timescale used in the 201 domain. It may serve as a master clock, or be a slave clock. 203 Peer to Peer Delay Measurement Mechanism: A network delay 204 measurement mechanism in PTP facilitated by an exchange of 205 messages between adjacent devices in a network. 207 Preferred Master: A device intended to act primarily as the 208 Grandmaster of a PTP system, or as a back up to a Grandmaster. 210 PTP: The Precision Time Protocol, the timing and synchronization 211 protocol define by IEEE 1588. 213 PTP port: An interface of a PTP clock with the network. Note that 214 there may be multiple PTP ports running on one physical interface, 215 for example a unicast slave which talks to several Grandmaster 216 clocks in parallel. 218 PTPv2: Refers specifically to the second version of PTP defined by 219 IEEE 1588-2008. 221 Rogue Master: A clock with a port in the master state, even though 222 it should not be in the master state according to the Best Master 223 Clock Algorithm, and does not set the alternate master flag. 225 Slave clock: a clock with at least one port in the slave state, 226 and no ports in the master state. 228 Slave Only Clock: An Ordinary clock which cannot become a Master 229 clock. 231 TLV: Type Length Value, a mechanism for extending messages in 232 networked communications. 234 Transparent Clock. A device that measures the time taken for a 235 PTP event message to transit the device and then updates the 236 message with a correction for this transit time. 238 Unicast Discovery: A mechanism for PTP slaves to establish a 239 unicast communication with PTP masters using a configures table of 240 master IP addresses and Unicast Message Negotiation. 242 Unicast Negotiation: A mechanism in PTP for Slave Clocks to 243 negotiate unicast Sync, announce and Delay Request Message Rates 244 from a Master Clock. 246 4. Problem Statement 248 This document describes a version of PTP intended to work in large 249 enterprise networks. Such networks are deployed, for example, in 250 financial corporations. It is becoming increasingly common in such 251 networks to perform distributed time tagged measurements, such as 252 one-way packet latencies and cumulative delays on software 253 systems spread across multiple computers. Furthermore there is 254 often a desire to check the age of information time tagged by a 255 different machine. To perform these measurements it is necessary 256 to deliver a common precise time to multiple devices on a network. 257 Accuracy currently required in the Financial Industry range from 258 100 microseconds to 500 nanoseconds to the Grandmaster. This 259 profile does not specify timing performance requirements, but such 260 requirements explain why the needs cannot always be met by NTP, as 261 commonly implemented. Such accuracy cannot usually be achieved with 262 a traditional time transfer such as NTP, without adding 263 non-standard customizations such as hardware time stamping, and on 264 path support. These features are currently part of PTP, or are 265 allowed by it. Because PTP has a complex range of features and 266 options it is necessary to create a profile for enterprise 267 networks to achieve interoperability between equipment 268 manufactured by different vendors. 270 Although enterprise networks can be large, it is becoming 271 increasingly common to deploy multicast protocols, even across 272 multiple subnets. For this reason it is desired to make use of 273 multicast whenever the information going to many destinations is 274 the same. It is also advantageous to send information which is 275 unique to one device as a unicast message. The latter can be 276 essential as the number of PTP slaves becomes hundreds or 277 thousands. 279 PTP devices operating in these networks need to be robust. This 280 includes the ability to ignore PTP messages which can be 281 identified as improper, and to have redundant sources of time. 283 5. Network Technology 285 This PTP profile SHALL operate only in networks characterized by 286 UDP [RFC768] over either IPv4 [RFC791] or IPv6 [RFC2460], as 287 described by Annexes D and E in [IEEE1588] respectively. If a 288 network contains both IPv4 and IPv6, then they SHALL be treated as 289 separate communication paths. Clocks which communicate using IPv4 290 can interact with clocks using IPv6 if there is an intermediary 291 device which simultaneously communicates with both IP versions. A 292 boundary clock might perform this function, for example. A PTP 293 domain SHALL use either IPv4 or IPv6 over a communication path, 294 but not both. The PTP system MAY include switches and routers. 295 These devices MAY be transparent clocks, boundary clocks, or 296 neither, in any combination. PTP Clocks MAY be Preferred Masters, 297 Ordinary Clocks, or Boundary Clocks. The ordinary clocks may be 298 Slave Only Clocks, or be master capable. 300 Note that clocks SHOULD always be identified by their clock ID and 301 not the IP or Layer 2 address. This is important in IPv6 networks 302 since Transparent clocks are required to change the source address 303 of any packet which they alter. In IPv4 networks some clocks 304 might be hidden behind a NAT, which hides their IP addresses from 305 the rest of the network. Note also that the use of NATs may place 306 limitations on the topology of PTP networks, depending on the port 307 forwarding scheme employed. Details of implementing PTP with NATs 308 are out of scope of this document. 310 Similar to NTP, PTP makes the assumption that the one way network 311 delay for Sync Messages and Delay Response Messages are the same. 312 When this is not true it can cause errors in the transfer of time 313 from the Master to the Slave. It is up to the system integrator to 314 design the network so that such effects do not prevent the PTP 315 system from meeting the timing requirements. The details of 316 network asymmetry are outside the scope of this document. See for 317 example, [G8271]. 319 6. Time Transfer and Delay Measurement 321 Master clocks, Transparent clocks and Boundary clocks MAY be 322 either one-step clocks or two-step clocks. Slave clocks MUST 323 support both behaviors. The End to End Delay Measurement Method 324 MUST be used. 326 Note that, in IP networks, Sync messages and Delay Request 327 messages exchanged between a master and slave do not necessarily 328 traverse the same physical path. Thus, wherever possible, the 329 network SHOULD be traffic engineered so that the forward and 330 reverse routes traverse the same physical path. Traffic 331 engineering techniques for path consistency are out of scope of 332 this document. 334 Sync messages MUST be sent as PTP event multicast messages (UDP 335 port 319) to the PTP primary IP address. Two step clocks SHALL 336 send Follow-up messages as PTP general messages (UDP port 320). 337 Announce messages MUST be sent as multicast messages (UDP port 320) 338 to the PTP primary address. The PTP primary IP address is 339 224.0.1.129 for IPv4 and FF0X:0:0:0:0:0:0:181 for Ipv6, where X can 340 be a value between 0x0 and 0xF, see [IEEE1588] Annex E, Section 341 E.3. 343 Delay Request Messages MAY be sent as either multicast or unicast 344 PTP event messages. Master clocks SHALL respond to multicast Delay 345 Request messages with multicast Delay Response PTP general 346 messages. Master clocks SHALL respond to unicast Delay Request PTP 347 event messages with unicast Delay Response PTP general messages. 348 This allow for the use of Ordinary clocks which do not support the 349 Enterprise Profile, as long as they are slave Only Clocks. 351 Clocks SHOULD include support for multiple domains. The purpose is 352 to support multiple simultaneous masters for redundancy. Leaf 353 devices (non-forwarding devices) can use timing information from 354 multiple masters by combining information from multiple 355 instantiations of a PTP stack, each operating in a different 356 domain. Redundant sources of timing can be ensembled, and/or 357 compared to check for faulty master clocks. The use of multiple 358 simultaneous masters will help mitigate faulty masters reporting as 359 healthy, network delay asymmetry, and security problems. Security 360 problems include man-in-the-middle attacks such as delay attacks, 361 packet interception / manipulation attacks. Assuming the path to 362 each master is different, failures malicious or otherwise would 363 have to happen at more than one path simultaneously. Whenever 364 feasible, the underlying network transport technology SHOULD be 365 configured so that timing messages in different domains traverse 366 different network paths. 368 7. Default Message Rates 370 The Sync, Announce and Delay Request default message rates SHALL 371 each be once per second. The Sync and Delay Request message rates 372 MAY be set to other values, but not less than once every 128 373 seconds, and not more than 128 messages per second. The Announce 374 message rate SHALL NOT be changed from the default value. The 375 Announce Receipt Timeout Interval SHALL be three Announce 376 Intervals for Preferred Masters, and four Announce Intervals for 377 all other masters. Unicast Discovery and Unicast Message 378 Negotiation options MUST NOT be utilized. 380 8. Requirements for Master Clocks 382 Master clocks SHALL obey the standard Best Master Clock Algorithm 383 from [IEEE1588]. PTP systems using this profile MAY support 384 multiple simultaneous Grandmasters as long as each active 385 Grandmaster is operating in a different PTP domain. 387 A port of a clock SHALL NOT be in the master state unless the 388 clock has a current value for the number of UTC leap 389 seconds. A clock with a port in the master state SHOULD indicate 390 the maximum adjustment to its internal clock within one sync 391 interval. The maximum phase adjustment is indicated in the 392 Enterprise Profile announce TLV field for Maximum Phase Adjustment. 394 The Announce Messages SHALL include a TLV which indicates that the 395 clock is operating in the Enterprise Profile. The TLV shall have 396 the following structure: 398 TLV Type (Enumeration16): ORGANIZATION_EXTENSION value = 0003 hex 400 Length Field (UInteger16): value = 10. The number of TLV octets 402 Organization Unique Identifier (3 Octets): The Organization ID 403 value for IETF assigned by IEEE = 00005Ehex 405 IETF Profile number (UInteger8): value = 1 407 Revision number (UInteger8): value = 1 409 Port Number (UInteger16): The Port Number of the port transmitting 410 the TLV. The all-ones Port Number, with value FFFFhex, is used to 411 indicate that the identified profile is applicable to all ports on 412 the clock. 414 Maximum Absolute Phase Adjustment Value within one sync interval 415 (UInteger16): value 416 Maximum Phase Adjustment Units (Enumeration8): 417 Value 0 = unknown 418 Value 1 = seconds 419 Value 3 = milliseconds 420 Value 6 = microseconds 421 Value 9 = nanoseconds 422 Value 12 = picoseconds 423 Value 15 = femtoseconds 424 All other values reserved for future use 426 Slaves can use the Maximum Phase Adjustment to determine if the 427 clock is slewing to rapidly for the applications which are of 428 interest. For example if the clock set by slave is used to 429 measure time intervals then it might be desired that that the 430 amount which the time changes during the intervals is limited. 432 9. Requirements for Slave Clocks 434 Slave clocks MUST be able to operate properly in a network which 435 contains multiple Masters in multiple domains. Slaves SHOULD make 436 use of information from the all Masters in their clock control 437 subsystems. Slave Clocks MUST be able to operate properly in the 438 presence of a Rogue Master. Slaves SHOULD NOT Synchronize to a 439 Master which is not the Best Master in its domain. Slaves will 440 continue to recognize a Best Master for the duration of the 441 Announce Time Out Interval. Slaves MAY use an Acceptable Master 442 Table. If a Master is not an Acceptable Master, then the Slave 443 MUST NOT synchronize to it. Note that IEEE 1588-2008 requires 444 slave clocks to support both two-step or one-step Master clocks. 445 See [IEEE1588], section 11.2. 447 Since Announce messages are sent as multicast messages slaves can 448 obtain the IP addresses of master from the Announce messages. Note 449 that the IP source addresses of Sync and Follow-up messages may 450 have been replaced by the source addresses of a transparent clock, 451 so slaves MUST send Delay Request messages to the IP address in the 452 Announce message. Sync and Follow-up messages can be correlated 453 with the Announce message using the clock ID, which is never 454 altered by Transparent clocks in this profile. 456 10. Requirements for Transparent Clocks 458 Transparent clocks SHALL NOT change the transmission mode of an 459 Enterprise Profile PTP message. For example a Transparent clock 460 SHALL NOT change a unicast message to a multicast message. 461 Transparent clocks SHALL NOT alter the Enterprise Profile TLV of 462 an Announce message, or any other part of an Announce message. 463 Transparent Clocks SHOULD support multiple domains. Transparent 464 Clocks which syntonize to the master clock will need to maintain 465 separate clock rate offsets for each of the supported domains. 467 11. Requirements for Boundary Clocks 469 Boundary Clocks SHOULD support multiple simultaneous PTP domains. 470 This will require them to maintain servo loops for each of the 471 domains supported, at least in software. Boundary clocks MUST NOT 472 combine timing information from different domains. 474 12. Management and Signaling Messages 476 PTP Management messages MAY be used. Any PTP management message 477 which is sent with the targetPortIdentity.clockIdentity set to all 478 1s (all clocks) MUST be sent as a multicast message. Management 479 messages with any other value of for the Clock Identity is 480 intended for a specific clock and MUST be sent as a unicast 481 message. Similarly, if any signaling messages are used they 482 MUST also be sent as unicast messages whenever the message is 483 intended for a specific clock. 485 13. Forbidden PTP Options 487 Clocks operating in the Enterprise Profile SHALL NOT use peer to 488 peer timing for delay measurement. Clocks operating in the 489 Enterprise Profile SHALL NOT use Unicast Message Negotiation to 490 determine message rates. Slave clocks operating in the Enterprise 491 Profile SHALL NOT use Unicast Discovery to establish connection to 492 Master clocks. Grandmaster Clusters are NOT ALLOWED. The Alternate 493 Master option is also forbidden. Clocks operating in the Enterprise 494 Profile SHALL NOT use Alternate Timescales. 496 14. Interoperation with Other PTP Profiles 498 Clocks operating in the Enterprise Profile will not interoperate 499 with clocks operating in the Power Profile [C37.238], because the 500 Enterprise Profile requires the End to End Delay Measurement 501 Mechanism and the Power Profile requires the Peer to Peer Delay 502 Measurement Mechanism. 504 Clocks operating in the Enterprise Profile will not interoperate 505 with clocks operating in the Telecom Profile for Frequency 506 Synchronization[G8265.1], because the Enterprise Profile forbids 507 Unicast Message Negotiation. This feature is part of the default 508 manner of operation for the Telecom Profile for Frequency 509 Synchronization. 511 Clocks operating in the Enterprise Profile will interoperate with 512 clocks operating in the Default Profile described in [IEEE1588] 513 Annex J.3. This variant of the Default Profile uses the End to End 514 Delay Measurement Mechanism. In addition the Default Profile would 515 have to operates over IPv4 or IPv6 networks, and use management 516 messages in unicast when those messages are directed at a specific 517 clock. If either of these requirements are not met than Enterprise 518 Profile clocks will not interoperate with Annex J.3 Default Profile 519 Clocks. The Enterprise Profile Profile will will not interoperate 520 with the Annex J.4 variant of the Default Profile which requires 521 use of the Peer to Peer Delay Measurement Mechanism. 523 Enterprise Profile Clocks will interoperate with clocks operating 524 in other profiles if the clocks in the other profiles obey the 525 rules of the Enterprise Profile. These rules MUST NOT be changed 526 to achieve interoperability with other profiles. 528 15. Security Considerations 530 Protocols used to transfer time, such as PTP and NTP can be 531 important to security mechanisms which use time windows for keys 532 and authorization. Passing time through the networks poses a 533 security risk since time can potentially be manipulated. 534 The use of multiple simultaneous masters, using multiple PTP 535 domains can mitigate problems from rogue masters and 536 man-in-the-middle attacks. See sections 9 and 10. Additional 537 security mechanisms are outside the scope of this document. 539 16. IANA Considerations 541 There are no IANA requirements in this specification. 543 17. References 545 17.1. Normative References 547 [IEEE1588] IEEE std. 1588-2008, "IEEE Standard for a 548 Precision Clock Synchronization for Networked 549 Measurement and Control Systems." July, 2008. 550 [RFC768] Postel, J., "User Datagram Protocol," RFC 768, 551 August, 980. 553 [RFC791] "Internet Protocol DARPA Internet Program Protocol 554 Specification," RFC 791, September, 1981. 556 [RFC2119] Bradner, S., "Key words for use in RFCs to 557 Indicate Requirement Levels", BCP 14, RFC 2119, 558 March 1997. 560 [RFC2460] Deering, S., Hinden, R., "Internet Protocol, 561 Version 6 (IPv6) Specification," RFC 2460, 562 December, 1998. 564 17.2. Informative References 566 [C37.238] IEEE std. C37.238-2011, "IEEE Standard Profile for 567 Use of IEEE 1588 Precision Time Protocol in Power 568 System Applications," July 2011. 570 [G8265.1] ITU-T G.8265.1/Y.1365.1, "Precision time protocol 571 telecom profile for frequency synchronization," 572 October 2011. 574 [G8271] ITU-T G.8271/Y.1366, "Time and Phase 575 Synchronization Aspects of Packet Networks" 576 February, 2012. 578 [NTP] Mills, D., Martin, J., Burbank, J., Kasch, W., 579 "Network Time Protocol Version 4: Protocol and 580 Algorithms Specification," RFC 5905, June 2010. 582 18. Acknowledgments 584 The authors would like to thank members of IETF for reviewing and 585 providing feedback on this draft. 587 This document was initially prepared using 588 2-Word-v2.0.template.dot. 590 19. Authors' Addresses 592 Doug Arnold 593 Meinberg USA 594 228 Windsor River Rd 595 Windsor, CA 95492 596 USA 598 Email: doug.arnold@meinberg-usa.com 600 Heiko Gerstung 601 Meinberg Funkuhren GmbH & Co. KG 602 Lange Wand 9 603 D-31812 Bad Pyrmont 604 Germany 606 Email: Heiko.gerstung@meinberg.de