idnits 2.17.1 draft-ietf-tictoc-ptp-enterprise-profile-09.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 28 instances of lines with control characters in the document. == There are 1 instance of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 2017) is 2318 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: 2 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Enterprise Profile for PTP December 2017 3 TICTOC Working Group Doug Arnold 4 Internet Draft Meinberg-USA 5 Intended status: Standards Track Heiko Gerstung 6 Meinberg 7 Expires: June 12, 2018 December 12, 2017 9 Enterprise Profile for the Precision Time Protocol 10 With Mixed Multicast and Unicast Messages 12 draft-ietf-tictoc-ptp-enterprise-profile-09.txt 14 Status of this Memo 15 This Internet-Draft is submitted in full conformance with the 16 provisions of BCP 78 and BCP 79. This document may not be 17 modified, and derivative works of it may not be created, except to 18 publish it as an RFC and to translate it into languages other than 19 English. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six 27 months and may be updated, replaced, or obsoleted by other 28 documents at any time. It is inappropriate to use Internet-Drafts 29 as reference material or to cite them other than as "work in 30 progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html 38 This Internet-Draft will expire on June 12, 2018. 40 Copyright Notice 41 Copyright (c) 2017 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with 49 respect to this document. Code Components extracted from this 50 document must include Simplified BSD License text as described in 51 Section 4.e of the Trust Legal Provisions and are provided without 52 warranty as described in the Simplified BSD License. 54 Abstract 56 This document describes a profile for the use of the Precision 57 Time Protocol in an IPV4 or IPv6 Enterprise information system 58 environment. The profile uses the End to End Delay Measurement 59 Mechanism, allows both multicast and unicast Delay Request and Delay 60 Response Messages. 62 Table of Contents 64 1. Introduction 2 65 2. Conventions used in this document 3 66 3. Technical Terms 3 67 4. Problem Statement 5 68 5. Network Technology 6 69 6. Time Transfer and Delay Measurement 7 70 7. Default Message Rates 8 71 8. Requirements for Master Clocks 8 72 9. Requirements for Slave Clocks 8 73 10. Requirements for Transparent Clocks 9 74 11. Requirements for Boundary Clocks 9 75 12. Management and Signaling Messages 9 76 13. Forbidden PTP Options 9 77 14. Interoperation with Other PTP Profiles 10 78 15. Profile Identification 10 79 16. Security Considerations 10 80 17. IANA Considerations 10 81 18. References 11 82 18.1. Normative References 11 83 18.2. Informative References 11 84 19. Acknowledgments 11 85 20. Authors addresses 12 87 1. Introduction 89 The Precision Time Protocol ("PTP"), standardized in IEEE 1588, 90 has been designed in its first version (IEEE 1588-2002) with the 91 goal to minimize configuration on the participating nodes. Network 92 communication was based solely on multicast messages, which unlike 93 NTP did not require that a receiving node ("slave clock") in 94 [IEEE1588] needs to know the identity of the time sources in the 95 network (the Master Clocks). 97 The so-called "Best Master Clock Algorithm" ([IEEE1588] Clause 98 9.3), a mechanism that all participating PTP nodes must follow, 99 set up strict rules for all members of a PTP domain to determine 100 which node shall be the active sending time source (Master Clock). 101 Although the multicast communication model has advantages in 102 smaller networks, it complicated the application of PTP in larger 103 networks, for example in environments like IP based 104 telecommunication networks or financial data centers. It is 105 considered inefficient that, even if the content of a message 106 applies only to one receiver, it is forwarded by the underlying 107 network (IP) to all nodes, requiring them to spend network 108 bandwidth and other resources like CPU cycles to drop the message. 110 The second revision of the standard (IEEE 1588-2008) is the 111 current version (also known as PTPv2) and introduced the 112 possibility to use unicast communication between the PTP nodes in 113 order to overcome the limitation of using multicast messages for 114 the bi-directional information exchange between PTP nodes. The 115 unicast approach avoided that, in PTP domains with a lot of nodes, 116 devices had to throw away more than 99% of the received multicast 117 messages because they carried information for some other node. 118 PTPv2 also introduced so-called "PTP profiles" ([IEEE1588] Clause 119 19.3). This construct allows organizations to specify selections 120 of attribute values and optional features, simplifying the 121 configuration of PTP nodes for a specific application. Instead of 122 having to go through all possible parameters and configuration 123 options and individually set them up, selecting a profile on a PTP 124 node will set all the parameters that are specified in the profile 125 to a defined value. If a PTP profile definition allows multiple 126 values for a parameter, selection of the profile will set the 127 profile-specific default value for this parameter. Parameters not 128 allowing multiple values are set to the value defined in the PTP 129 profile. Many PTP features and functions are optional, and a 130 profile should also define which optional features of PTP are 131 required, permitted, or prohibited. It is possible to extend the 132 PTP standard with a PTP profile by using the TLV mechanism of PTP 133 (see [IEEE1588] Clause 13.4), defining an optional Best Master 134 Clock Algorithm and a few other ways. PTP has its own management 135 protocol (defined in [IEEE1588] Clause 15.2) but allows a PTP 136 profile specify an alternative management mechanism, for example 137 SNMP. 139 2. Conventions used in this document 141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 142 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 143 in this document are to be interpreted as described in RFC-2119 144 [RFC2119]. 146 In this document, these words will appear with that interpretation 147 only when in ALL CAPS. Lower case uses of these words are not to 148 be interpreted as carrying RFC-2119 significance. 150 3. Technical Terms 152 Acceptable Master Table: A PTP Slave Clock may maintain a list of 153 masters which it is willing to synchronize to. 155 Alternate Master: A PTP Master Clock, which is not the Best 156 Master, may act as a master with the Alternate Master flag set on 157 the messages it sends. 159 Announce message: Contains the master clock properties of a Master 160 clock. Used to determine the Best Master. 162 Best Master: A clock with a port in the master state, operating 163 consistently with the Best Master Clock Algorithm. 165 Best Master Clock Algorithm: A method for determining which state 166 a port of a PTP clock should be in. The algorithm works by 167 identifying which of several PTP Master capable clocks is the best 168 master. Clocks have priority to become the acting Grandmaster, 169 based on the properties each Master Clock sends in its Announce 170 Message. 172 Boundary Clock: A device with more than one PTP port. Generally 173 boundary clocks will have one port in slave state to receive 174 timing and then other ports in master state to re-distribute the 175 timing. 177 Clock Identity: In IEEE 1588-2008 this is a 64-bit number 178 assigned to each PTP clock which must be unique. Often the 179 Ethernet MAC address is used since there is already an 180 international infrastructure for assigning unique numbers to each 181 device manufactured. 183 Domain: Every PTP message contains a domain number. Domains are 184 treated as separate PTP systems in the network. Slaves, however, 185 can combine the timing information derived from multiple domains. 187 End to End Delay Measurement Mechanism: A network delay 188 measurement mechanism in PTP facilitated by an exchange of 189 messages between a Master Clock and Slave Clock. 191 Grandmaster: the primary master clock within a domain of a PTP 192 system 194 IEEE 1588: The timing and synchronization standard which defines 195 PTP, and describes the node, system, and communication properties 196 necessary to support PTP. 198 Master clock: a clock with at least one port in the master state. 200 NTP: Network Time Protocol, defined by RFC 5905, see [NTP]. 202 Ordinary Clock: A clock that has a single Precision Time Protocol 203 (PTP) port in a domain and maintains the timescale used in the 204 domain. It may serve as a master clock, or be a slave clock. 206 Peer to Peer Delay Measurement Mechanism: A network delay 207 measurement mechanism in PTP facilitated by an exchange of 208 messages between adjacent devices in a network. 210 Preferred Master: A device intended to act primarily as the 211 Grandmaster of a PTP system, or as a back up to a Grandmaster. 213 PTP: The Precision Time Protocol, the timing and synchronization 214 protocol define by IEEE 1588. 216 PTP port: An interface of a PTP clock with the network. Note that 217 there may be multiple PTP ports running on one physical interface, 218 for example, a unicast slave which talks to several Grandmaster 219 clocks in parallel. 221 PTPv2: Refers specifically to the second version of PTP defined by 222 IEEE 1588-2008. 224 Rogue Master: A clock with a port in the master state, even though 225 it should not be in the master state according to the Best Master 226 Clock Algorithm, and does not set the alternate master flag. 228 Slave clock: a clock with at least one port in the slave state, 229 and no ports in the master state. 231 Slave Only Clock: An Ordinary clock which cannot become a Master 232 clock. 234 TLV: Type Length Value, a mechanism for extending messages in 235 networked communications. 237 Transparent Clock. A device that measures the time taken for a 238 PTP event message to transit the device and then updates the 239 message with a correction for this transit time. 241 Unicast Discovery: A mechanism for PTP slaves to establish a 242 unicast communication with PTP masters using a configures table of 243 master IP addresses and Unicast Message Negotiation. 245 Unicast Negotiation: A mechanism in PTP for Slave Clocks to 246 negotiate unicast Sync, announce and Delay Request Message Rates 247 from a Master Clock. 249 4. Problem Statement 251 This document describes a version of PTP intended to work in large 252 enterprise networks. Such networks are deployed, for example, in 253 financial corporations. It is becoming increasingly common in such 254 networks to perform distributed time tagged measurements, such as 255 one-way packet latencies and cumulative delays on software 256 systems spread across multiple computers. Furthermore, there is 257 often a desire to check the age of information time tagged by a 258 different machine. To perform these measurements, it is necessary 259 to deliver a common precise time to multiple devices on a network. 260 Accuracy currently required in the Financial Industry range from 261 100 microseconds to 500 nanoseconds to the Grandmaster. This 262 profile does not specify timing performance requirements, but such 263 requirements explain why the needs cannot always be met by NTP, as 264 commonly implemented. Such accuracy cannot usually be achieved with 265 a traditional time transfer such as NTP, without adding 266 non-standard customizations such as hardware time stamping, and on 267 path support. These features are currently part of PTP, or are 268 allowed by it. Because PTP has a complex range of features and 269 options it is necessary to create a profile for enterprise 270 networks to achieve interoperability between equipment 271 manufactured by different vendors. 273 Although enterprise networks can be large, it is becoming 274 increasingly common to deploy multicast protocols, even across 275 multiple subnets. For this reason, it is desired to make use of 276 multicast whenever the information going to many destinations is 277 the same. It is also advantageous to send information which is 278 unique to one device as a unicast message. The latter can be 279 essential as the number of PTP slaves becomes hundreds or 280 thousands. 282 PTP devices operating in these networks need to be robust. This 283 includes the ability to ignore PTP messages which can be 284 identified as improper, and to have redundant sources of time. 286 5. Network Technology 288 This PTP profile SHALL operate only in networks characterized by 289 UDP [RFC768] over either IPv4 [RFC791] or IPv6 [RFC2460], as 290 described by Annexes D and E in [IEEE1588] respectively. If a 291 network contains both IPv4 and IPv6, then they SHALL be treated as 292 separate communication paths. Clocks which communicate using IPv4 293 can interact with clocks using IPv6 if there is an intermediary 294 device which simultaneously communicates with both IP versions. A 295 boundary clock might perform this function, for example. A PTP 296 domain SHALL use either IPv4 or IPv6 over a communication path, 297 but not both. The PTP system MAY include switches and routers. 298 These devices MAY be transparent clocks, boundary clocks, or 299 neither, in any combination. PTP Clocks MAY be Preferred Masters, 300 Ordinary Clocks, or Boundary Clocks. The ordinary clocks may be 301 Slave Only Clocks, or be master capable. 303 Note that clocks SHOULD always be identified by their clock ID and 304 not the IP or Layer 2 address. This is important in IPv6 networks 305 since Transparent clocks are required to change the source address 306 of any packet which they alter. In IPv4 networks some clocks 307 might be hidden behind a NAT, which hides their IP addresses from 308 the rest of the network. Note also that the use of NATs may place 309 limitations on the topology of PTP networks, depending on the port 310 forwarding scheme employed. Details of implementing PTP with NATs 311 are out of scope of this document. 313 PTP, like NTP, assumes that the one-way network delay for Sync 314 Messages and Delay Response Messages are the same. When this is 315 not true it can cause errors in the transfer of time from the 316 Master to the Slave. It is up to the system integrator to design 317 the network so that such effects do not prevent the PTP system 318 from meeting the timing requirements. The details of 319 network asymmetry are outside the scope of this document. See for 320 example, [G8271]. 322 6. Time Transfer and Delay Measurement 324 Master clocks, Transparent clocks and Boundary clocks MAY be 325 either one-step clocks or two-step clocks. Slave clocks MUST 326 support both behaviors. The End to End Delay Measurement Method 327 MUST be used. 329 Note that, in IP networks, Sync messages and Delay Request 330 messages exchanged between a master and slave do not necessarily 331 traverse the same physical path. Thus, wherever possible, the 332 network SHOULD be traffic engineered so that the forward and 333 reverse routes traverse the same physical path. Traffic 334 engineering techniques for path consistency are out of scope of 335 this document. 337 Sync messages MUST be sent as PTP event multicast messages (UDP 338 port 319) to the PTP primary IP address. Two step clocks SHALL 339 send Follow-up messages as PTP general messages (UDP port 320). 340 Announce messages MUST be sent as multicast messages (UDP port 320) 341 to the PTP primary address. The PTP primary IP address is 342 224.0.1.129 for IPv4 and FF0X:0:0:0:0:0:0:181 for Ipv6, where X can 343 be a value between 0x0 and 0xF, see [IEEE1588] Annex E, Section 344 E.3. 346 Delay Request Messages MAY be sent as either multicast or unicast 347 PTP event messages. Master clocks SHALL respond to multicast Delay 348 Request messages with multicast Delay Response PTP general 349 messages. Master clocks SHALL respond to unicast Delay Request PTP 350 event messages with unicast Delay Response PTP general messages. 351 This allow for the use of Ordinary clocks which do not support the 352 Enterprise Profile, if they are slave Only Clocks. 354 Clocks SHOULD include support for multiple domains. The purpose is 355 to support multiple simultaneous masters for redundancy. Leaf 356 devices (non-forwarding devices) can use timing information from 357 multiple masters by combining information from multiple 358 instantiations of a PTP stack, each operating in a different 359 domain. Redundant sources of timing can be ensembled, and/or 360 compared to check for faulty master clocks. The use of multiple 361 simultaneous masters will help mitigate faulty masters reporting as 362 healthy, network delay asymmetry, and security problems. Security 363 problems include man-in-the-middle attacks such as delay attacks, 364 packet interception / manipulation attacks. Assuming the path to 365 each master is different, failures malicious or otherwise would 366 have to happen at more than one path simultaneously. Whenever 367 feasible, the underlying network transport technology SHOULD be 368 configured so that timing messages in different domains traverse 369 different network paths. 371 7. Default Message Rates 373 The Sync, Announce and Delay Request default message rates SHALL 374 each be once per second. The Sync and Delay Request message rates 375 MAY be set to other values, but not less than once every 128 376 seconds, and not more than 128 messages per second. The Announce 377 message rate SHALL NOT be changed from the default value. The 378 Announce Receipt Timeout Interval SHALL be three Announce 379 Intervals for Preferred Masters, and four Announce Intervals for 380 all other masters. 382 Unicast Discovery and Unicast Message Negotiation options SHALL NOT 383 be utilized. 385 8. Requirements for Master Clocks 387 Master clocks SHALL obey the standard Best Master Clock Algorithm 388 from [IEEE1588]. PTP systems using this profile MAY support 389 multiple simultaneous Grandmasters if each active Grandmaster is 390 operating in a different PTP domain. 392 A port of a clock SHALL NOT be in the master state unless the 393 clock has a current value for the number of UTC leap 394 seconds. 396 If a unicast negotiation signaling message is received it SHALL 397 be ignored. 399 9. Requirements for Slave Clocks 401 Slave clocks MUST be able to operate properly in a network which 402 contains multiple Masters in multiple domains. Slaves SHOULD make 403 use of information from the all Masters in their clock control 404 subsystems. Slave Clocks MUST be able to operate properly in the 405 presence of a Rogue Master. Slaves SHOULD NOT Synchronize to a 406 Master which is not the Best Master in its domain. Slaves will 407 continue to recognize a Best Master for the duration of the 408 Announce Time Out Interval. Slaves MAY use an Acceptable Master 409 Table. If a Master is not an Acceptable Master, then the Slave 410 MUST NOT synchronize to it. Note that IEEE 1588-2008 requires 411 slave clocks to support both two-step or one-step Master clocks. 412 See [IEEE1588], section 11.2. 414 Since Announce messages are sent as multicast messages slaves can 415 obtain the IP addresses of master from the Announce messages. Note 416 that the IP source addresses of Sync and Follow-up messages may 417 have been replaced by the source addresses of a transparent clock, 418 so, slaves MUST send Delay Request messages to the IP address in 419 the Announce message. Sync and Follow-up messages can be 420 correlated with the Announce message using the clock ID, which is 421 never altered by Transparent clocks in this profile. 423 10. Requirements for Transparent Clocks 425 Transparent clocks SHALL NOT change the transmission mode of an 426 Enterprise Profile PTP message. For example, a Transparent clock 427 SHALL NOT change a unicast message to a multicast message. 428 Transparent Clocks SHOULD support multiple domains. Transparent 429 Clocks which syntonize to the master clock will need to maintain 430 separate clock rate offsets for each of the supported domains. 432 11. Requirements for Boundary Clocks 434 Boundary Clocks SHOULD support multiple simultaneous PTP domains. 435 This will require them to maintain servo loops for each of the 436 domains supported, at least in software. Boundary clocks MUST NOT 437 combine timing information from different domains. 439 12. Management and Signaling Messages 441 PTP Management messages MAY be used. Management 442 messages intended for a specific clock, i.e. the [IEEE1588] defined 443 attribute targetPortIdentity.clockIdentity is not set to All 1's, 444 MUST be sent as a unicast message. Similarly, if any signaling 445 messages are used they MUST also be sent as unicast messages 446 whenever the message is intended for a specific clock. 448 13. Forbidden PTP Options 450 Clocks operating in the Enterprise Profile SHALL NOT use peer to 451 peer timing for delay measurement. Grandmaster Clusters are NOT 452 ALLOWED. The Alternate Master option is also forbidden. Clocks 453 operating in the Enterprise Profile SHALL NOT use Alternate 454 Timescales. 456 14. Interoperation with IEEE 1588 Default Profile 458 Clocks operating in the Enterprise Profile will interoperate with 459 clocks operating in the Default Profile described in [IEEE1588] 460 Annex J.3. This variant of the Default Profile uses the End to End 461 Delay Measurement Mechanism. In addition, the Default Profile 462 would have to operates over IPv4 or IPv6 networks, and use 463 management messages in unicast when those messages are directed at 464 a specific clock. If either of these requirements are not met than 465 Enterprise Profile clocks will not interoperate with Annex J.3 466 Default Profile Clocks. The Enterprise Profile will not 467 interoperate with the Annex J.4 variant of the Default Profile 468 which requires use of the Peer to Peer Delay Measurement Mechanism. 470 Enterprise Profile Clocks will interoperate with clocks operating 471 in other profiles if the clocks in the other profiles obey the 472 rules of the Enterprise Profile. These rules MUST NOT be changed 473 to achieve interoperability with other profiles. 475 15. Profile Identification 477 The IEEE 1588 standard requires that all profiles provide the 478 following identifying information. 480 PTP Profile: 481 Enterprise Profile 482 Version: 1.0 483 Profile identifier: 00-00-5E-00-01-00 485 This profile was specified by the IETF 487 A copy may be obtained at 488 https://datatracker.ietf.org/wg/tictoc/documents 490 16. Security Considerations 492 Protocols used to transfer time, such as PTP and NTP can be 493 important to security mechanisms which use time windows for keys 494 and authorization. Passing time through the networks poses a 495 security risk since time can potentially be manipulated. 496 The use of multiple simultaneous masters, using multiple PTP 497 domains can mitigate problems from rogue masters and 498 man-in-the-middle attacks. See sections 9 and 10. Additional 499 security mechanisms are outside the scope of this document. 501 17. IANA Considerations 503 There are no IANA requirements in this specification. 505 18. References 507 18.1. Normative References 509 [IEEE1588] IEEE std. 1588-2008, "IEEE Standard for a 510 Precision Clock Synchronization for Networked 511 Measurement and Control Systems." July, 2008. 512 [RFC768] Postel, J., "User Datagram Protocol," RFC 768, 513 August, 980. 515 [RFC791] "Internet Protocol DARPA Internet Program Protocol 516 Specification," RFC 791, September, 1981. 518 [RFC2119] Bradner, S., "Key words for use in RFCs to 519 Indicate Requirement Levels", BCP 14, RFC 2119, 520 March 1997. 522 [RFC2460] Deering, S., Hinden, R., "Internet Protocol, 523 Version 6 (IPv6) Specification," RFC 2460, 524 December, 1998. 526 18.2. Informative References 528 [G8271] ITU-T G.8271/Y.1366, "Time and Phase 529 Synchronization Aspects of Packet Networks" 530 February, 2012. 532 [NTP] Mills, D., Martin, J., Burbank, J., Kasch, W., 533 "Network Time Protocol Version 4: Protocol and 534 Algorithms Specification," RFC 5905, June 2010. 536 19. Acknowledgments 538 The authors would like to thank members of IETF for reviewing and 539 providing feedback on this draft. 541 This document was initially prepared using 542 2-Word-v2.0.template.dot. 544 20. Authors' Addresses 546 Doug Arnold 547 Meinberg USA 548 929 Salem End Road 549 Framingham, MA 01702 550 USA 552 Email: doug.arnold@meinberg-usa.com 554 Heiko Gerstung 555 Meinberg Funkuhren GmbH & Co. KG 556 Lange Wand 9 557 D-31812 Bad Pyrmont 558 Germany 560 Email: Heiko.gerstung@meinberg.de