messages supplied by the clock and placed into the DS1 overhead. Line-derived timing A network element can choose (or be configured) to derive its timing from the line-level, by monitoring the S1 sync-status bytes to ensure quality. Holdover As a last resort, in the absence of higher quality timing, a network element can go into a holdover mode until higher-quality external timing becomes available again. In this mode, the network element uses its own timing circuits as a reference. Timing loops A timing loop occurs when network elements in a network are each deriving their timing from other network elements, without any of them being a "master" timing source. This network loop will eventually see its own timing "float away" from any external networks, causing mysterious bit errors—and ultimately, in the worst cases, massive loss of traffic. The source of these kinds of errors can be hard to diagnose. In general, a network that has been properly configured should never find itself in a timing loop, but some classes of silent failures could nevertheless cause this issue. Next-generation SONET/SDH SONET/SDH development was originally driven by the need to transport multiple PDH signals—like DS1, E1, DS3, and E3—along with other groups of multiplexed 64 kbit/s pulse-code modulated voice traffic. The ability to transport ATM traffic was another early application. In order to support large ATM bandwidths, concatenation was developed, whereby smaller multiplexing containers (e.g., STS-1) are inversely multiplexed to build up a larger container (e.g., STS-3c) to support large data-oriented pipes. One problem with traditional concatenation, however, is inflexibility. Depending on the data and voice traffic mix that must be carried, there can be a large amount of unused bandwidth left over, due to the fixed sizes of concatenated containers. For example, fitting a 100 Mbit/s Fast Ethernet connection inside a 155 Mbit/s STS-3c container leads to considerable waste. More important is the need for all intermediate network elements to support newly introduced concatenation sizes. This problem was overcome with the introduction of Virtual Concatenation. Virtual concatenation (VCAT) allows for a more arbitrary assembly of lower-order multiplexing containers, building larger containers of fairly arbitrary size (e.g., 100 Mbit/s) without the need for intermediate network elements to support this particular form of concatenation. Virtual concatenation leverages the X.86 or Generic Framing Procedure (GFP) protocols in order to map payloads of arbitrary bandwidth into the virtually concatenated container. The Link Capacity Adjustment Scheme