n, such as MiFID-II from the European Union, requiring accurate timestamping of business transactions and traceability of those timestamps (think of high-frequency and low- latency trading) Requirements to measure one-way latency and cumulative delays across multiple computers not only locally but across data centers Increased scale and speed requiring more accurate time-tagged measurements The Enterprise Profile does not detail any specifics on timing performance, but an increasing num- ber of enterprise timing requirements cannot be achieved using more traditional methods such as NTP (see the section "PTP Versus NTP" toward the beginning of the chapter). NTP is normally a software-only solution with limited accuracy and could not improve this performance without adding significant hardware support, support that is already available for PTP. Because IEEE 1588-2008 includes many options, this profile is designed to limit the available choices, values, and parameters to increase interoperability between different implementations. The Enterprise Profile uses PTP transport with UDP over both IPv4 (1588-2008 Annex D) and IPv6 (Annex E) with an E2E delay mechanism. The P2P mechanism is specifically not allowed. The pro- file supports OC, TC, and BC clocks with a mixture of unicast and multicast transmission, as follows: Announce messages are multicast (fixed at 1 per second). Delay_Req can be either unicast or multicast, and the master port must reply with the Delay_Resp carried by the same method as the Delay_Req. Sync messages are multicast. The options defined for the Enterprise Profile allow for interoperability for clocks running the IEEE 1588-2008 E2E default profile (Annex J.3) when transported with PTPoIP. One interesting feature of this profile is that clocks should support different domains. This allows the operator to run multiple, independent, and redundant sources of time within the enterprise net- work. End devices can use timing information from multiple masters by combining information from multiple in