re forwar- ded to that component of the timing subsystem dealing with packet processing, and the timestamps are used to calculate the time offset and mean path delay. Outgoing PTP messages are created in the packet processing component of the timing subsystem and then sent for forwarding out the egress interface designated as a PTP master port. As the mes- sages exit the interface, they are timestamped using a reference time signal coming over a hardware path from the timing subsystem. The whole point of a timing-aware clock is that the system is designed to eliminate many of the likely causes of timing error. Using hardware signals for time transport dispenses with many pos- sible problems caused by the normal processing of a packet switch, such as queuing, scheduling, and SO on. This means that the clock will, depending on the quality of the design and the compon- ents, have a readily predictable and reliable performance, which is not impacted by the traffic load. This performance is characterized by numerous metrics in the ITU-T G.8273.2 recommendation where the class of clock operation is specified as Class A, B, C, or D. Engineers are most concerned with the noise generation parameters, which is the amount of timing error (noise) introduced by time passing through the node. The section "Clock Performance", later in this chapter, provides more details on this topic, including noise generation. You should refer to Chapter 5 for details of the metrics themselves. 9.1.1 Assisted Partial Timing Support The advantages of FTS topologies over PTS topologies in combination with PTP-aware nodes are plain to see, SO there is a strong motivation to use that approach. When that approach is not pos- sible, G.8275.2 PTPoIP can be switched through PTP-unaware nodes, with the disadvantage that the performance will be less predictable and be degraded by traffic. Which raises the question, given those constraints, what is the point of this profile? The original use case for G.8275.2 PTPoIP was based on the need of operators (p