y "timing aware" and aids the timing signals at every point of the network between the source of time and the consumption of it-referred to as full timing support (FTS). The alternative is where there might be assistance at some points but not at every point-referred to as partial timing support (PTS). See the Chapter 8 sections on G.8271.1 (FTS) and G.8271.2 (PTS) for information on these two different approaches. The expectation is that the FTS case is implemented using the ITU-T G.8275.1 telecom profile in combination with SyncE to carry frequency, while the PTS case is implemented using the ITU-T G.8275.2 telecom profile with PTP over IP (PTPoIP) and where SyncE for frequency is optional. The clear difference between them comes down to a single critical factor: the FTS case can guaran- tee a level of deterministic performance, whereas the PTS case cannot. Figure 9-11 illustrates the differences between the two options. G.8275.1 + SyncE PRTC / T-GM T-TSC slave clock G.8275.2 + SyncE (optional) PTP-unware PTP-unware PTP-unware network network network PRTC / T-GM T-TSC-P PTP-unaware T-BC-P slave clock network element Figure 9-11 Full Timing Support Versus Partial Timing Support One point that is worth reinforcing very strongly is also repeated quite plainly in some of the ITU-T recommendations, such as G.8271.2: A network that is based on the architecture defined in [ITU-T G.8265], and is designed to meet the network limits for frequency defined in [ITU-T G.8261.1], is not designed for the delivery of accurate time or phase, which requires much lower levels of packet delay vari- ation (PDV) and asymmetry. The network limits specified in this document are for small, well-controlled networks (e.g., in-building or last-mile network segments), which can guar- antee that the stringent PDV and asymmetry network limits are met. This means that if you have a network already (successfully) carrying frequency using G.8265.1, you should not assume that this same network will accurately carry phase/time using G.8275.2. Al- 