overed by one or more of these doc- uments. Several other recommendations might come into the picture if your testing involves time- division multiplexing (TDM) type circuits, but the subset identified in Figure 12-7 should satisfy almost all situations. In the category of end-to-end network limits, a chain of devices under test (DUT) is tested to ascertain what happened to the timing signal after crossing multiple hops in the network. For clock node specifications, the DUT is tested standalone with specialized test equipment. 12.3.1 Overall Approach The first thing to decide before starting the testing is what you need to test given the resources available. That is because there are possibly hundreds of different combinations of tests and scen- arios that could entail being in the test lab for possibly months. Some of the test cases take days to execute (100,000 seconds or longer) and some cases require a settle time of at least 24 hours (or longer) before starting the test (holdover is one example). So, deciding what you want to prove or certify is an important consideration, as well as aligning the test cases with the equipment and time available. The next important point is to realize that testing of network timing and the certification of clock and network performance are largely standardized (by the ITU-T). Yes, you can "roll your own" and test some scenarios that are important to your situation if you feel it is warranted. But remember that when you develop your own test case or method, you cannot claim the equipment is failing be- cause it does not meet some limit in the ITU-T recommendations. A good example of this is testing a T-BC against G.8273.2 noise generation limits-for example, to determine constant time error (cTE), but doing it while introducing impairment on the PTP input messages (such as adding PDV to the PTP messages sent to the DUT). When certifying whether a clock is Class A, B, C, or D, the test method mandates that the output signal of the clock is measured while it receives "ideal inpu