 is beating, however, as operation results in the creation of a VC4, which is large enough to discussed in Section 42.3, there is a chance that the SDH network accommodate up to 63 VC12s. Unfortunately, as discussed in Sec- element (e.g. multiplexer) which is performing the stuffing oper- tion 42.3, complications arise in this operation, because the network ation, is not quite synchronous with the rest of the network. In this element that is performing this task, may not itself have created all case C12 which it creates is similarly asynchronous. the VC12s. (See Figure 42.9.) This leads to the possibility that not all the VC12s are completely synchronous with one another or, 42.4.1 Path OverHead information more importantly, with the VC4 into which they are being loaded. The solution to this problem comes in two parts. Firstly, the Having mapped the 2Mbit/s bit stream into the C12, the next internal structure of the VC4 has been purposely designed to allow operation is to generate and attach the Path Overhead byte (POH), each VC12 to run slightly faster, or slower, than the VC4 rate. This which enables this C12 to be identified, monitored for errors and is done by designating certain bytes in the C4 as overflow bytes (one routed through the SDH network. The addition of this POH byte to per VC12) to cope with a VC12 that is running too fast. On the other the C12 creates a Virtual Container 12 (VC12). As mentioned in hand, when a VC12 is running slow, then occasionally, a VC12 byte Section 42.3, the idea is that the POH stays attached to its C12 all can be repeated. Secondly, this (hopefully) infrequent change of the way from the point where it was generated, to the point at which phase of a VC12 relative to its VC4 is recorded by means of a the 2Mbit/s payload exits the SDH network. These two points are pointer. A VC4 maintains one pointer for each of the VC12s within the 'Path Termination' points for this VC12, with the continuous its payload, and each pointer registers the offset in bytes between stream of VCs b