This article will focus on the importance of network timing in the wide area network (WAN). It actually started out as an e-mail response to someone who downloaded one of our tools and I thought it was an important issue that needed further detail.
The concepts are fairly simple, but there just aren't that many places that give a synopsis of network timing (at least that I've found).
General Importance of Timing
Clocking (or timing) is essential because digital signals are evaluated or read by the voltage on the line.
Each piece of equipment needs to know exactly when to read the voltage. Figure 1 depicts an ideal digital signal. (The 0 reading equates to binary 0, while a V value equates to binary one.) If your clock told you to read the signal when the signal was at time t1, you would record that signal as a 0. While reading the signal at time t2 means you record the signal as a 1. If all devices are synchronized, they will transmit and receive the signal correctly. If two clocks are out of synchronization, you can end up with one person reading the signal at what it thinks is the correct time (t1), but is actually time t2, giving an incorrect value.
You would like every device in your network timed by the same clock source. Either timed directly or timing derived from the same device that provides clocking for the entire network. Since you derive timing from a "Master" clock, all the devices in the network will be synchronized.
Traditionally the wide area carrier provides a Stratum 1 clock source.
Individual Node Clock Slips
All devices get receive clocking from the receive signal (the 'other' end of the WAN link). For the return signal (the transmit clock from your station) they can either use an internal oscillator or they can use a clock frequency derived from the receive signal (see Figure 3).
If you use a clock source derived from the receive signal, the clock transitions, which indicate when to "read" a one or a zero, are synchronized with the other end of the WAN link. If you use an internal clock source, it will not necessarily be at the same frequency as the other end of the link. Even if it is at the same frequency, it probably won't be in phase. In either case, the clocking transitions for the return signal probably won't match up. There is an allowable tolerance for the send and receive clocks not syncing, but eventually the two clocks (your end and the distant end) drift beyond the tolerance. The tolerances in Figure 2 and Figure3 are 193 bits too fast or too slow. When you exceed 193 bits, you have a clock slip. The number of clock slips you can expect depends on the Stratum level of your clock.
Network Clock Slips
You want everyone tied to the same master clock source or otherwise you get the same clock slip issues, but this time they can affect the entire network, not just a single end node. Even if the master clock is wrong, everyone uses it as a reference, so they all use the same "wrong" clock source. For example, let's say I'm teaching this week. My watch is about 5 minutes faster than everyone else's watch. Mine may be wrong (or everyone else may be wrong), but if I just tell everyone that I am using my watch as the "master time source," then everyone will adjust to the "correct" time for the class.
Timing Loops
Be cautious to ensure you don't get device A deriving timing from device B, who is actually deriving timing from device A (see Figure 4).
This is a timing loop which is not good. Think about it. The local factory calls the radio station every day at 4:50 pm and asks the time. Eventually the radio station asks why they want the time. The factory says "we want to be sure we blow the whistle at the correct time every day." At which point the radio station says they set their clock to the 5:00 factory whistle every day. So in this case you really don't have a good clock signal.
Application/General Design
Let's discuss deriving timing signals from the same source for a second (or 125 microseconds). If Source A is Stratum 1 (e.g. Cesium clock, GPS clock) and device B derives clock from A, then A and B have happy clock signals (see Figure 5). Now let's say that device C derives timing
from device B. To do that, B is taking in A's signal and redistributing it to it's connected devices, which includes device C. C is now deriving timing from a source tied to the Master clock A. The clocks are synchronized and everyone is still happy. The distinction is that the clock source that device C sees is no longer considered Stratum 1. The rule, to which there are exceptions, is that you lose a Stratum layer of accuracy for every device that redistributes the signal. Therefore, device C has a Stratum 2 clock source, derived (or "tied") to the same Master clock that everyone else uses.
For network design purposes you want to have a network timing diagram that shows who derives clock from whom. There shouldn't be a loop in the picture (kind of like a bridging loop/spanning tree situation). Every device should be able to trace its timing to the root of the timing tree (the Master clock). Frequently, you have a backup Master clock source, in case the real Master clock dies, to take over timing for the network (see Figure 6). The backup source ideally has an
entirely separate physical timing tree so that loss of a single node (which might be part of two timing trees) , won't cause loss of network timing. Be aware that there is a chance you will have clock slips when going from the primary to the backup Master clocks, but after everyone syncs up with the new Master clock, there shouldn't be any clock slips beyond those expected by the Stratum level. In summary, ensure you pay attention to proper network timing. For further reading, surf to www.laruscorp.com/larus.htm.