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