All clocks in IEEE 1588 systems are organized into a master-slave hierarchy. In operation, the first task of the PTP protocol is to logically configure network communications used by IEEE 1588 into a tree structure supporting this hierarchy

At the root of this hierarchy is a clock that the standard terms the "grandmaster clock". The time scale of the entire IEEE 1588-enabled system will be traceable to the time scale of the grandmaster clock. PTP thus produces a common sense of time throughout the system. If the time scale of the grandmaster clock is UTC, then the entire system will have a UTC time scale. Otherwise, the time scale is relative to the epoch established by the grandmaster.

Figure 3.2. General network topology

Each boundary clock creates a branch point in the hierarchy tree, while the leaves of the tree are formed by ordinary clocks. Network devices that are not boundary clocks do not establish branch points in the hierarchy, and except for performance degradation, are invisible to the protocol. Figure 3.2 above illustrates several topological possibilities.

The PTP master-slave hierarchy is established on top of whatever underlying communication topology is present. Thus, in Figure 3.2, if the network connections represented by the lettered lines are all present, then PTP will seek to logically partition the PTP message traffic in such a way as to produce a tree structure supporting the master-slave hierarchy.

Many underlying communication systems run a minimum spanning tree or similar protocol, and will present a tree-structured communication topology to the PTP algorithms. The spanning tree algorithm used in Ethernet systems is defined in IEEE 802.1D. A very complete discussion of spanning tree algorithms can be found in Interconnection: Bridges and Routers by Radia Perlman 

An example of such a spanning tree structure is illustrated in Figure 3.2, if the segmented lines G, H, and J are removed. However, the PTP protocol assumes that in general the underlying communication is not tree-structured, and will present multiple paths between PTP nodes. Network devices such as an ordinary Ethernet switch not implementing IEEE 1588, but multicasting packets to all ports are invisible to the protocol. Thus, the network of Figure 3.2 would actually appear to PTP as illustrated in Figure 3.3 below.

Figure 3.3. Topology of Figure 3.2 as it appears to PTP

The link G of Figure 3.2 would not be visible to PTP, except possibly by observing fluctuations in latency due to the selection of the path between nodes, for example, between nodes 6 and 1. PTP functionality in nodes 6 and 3 would see nodes 1, 2, 11, and 12 as though they were on a multi-drop link, or connected via a repeater rather than a switch.