Ethernet | Wireline Networking Technologies and Packetization

Nearly all wireline voice mobility networks in the enterprise start with Ethernet. Ethernet is a family of related networking technologies that establish how two machines that are physically connected can talk to each other. Ethernet was designed to be as simple to deploy as possible, so that it can be set up as an unmanaged network, where physically connecting two endpoints together, somehow, through the network is enough to allow them to find each other and communicate. (Note that this doesn't mean that higher-level protocols will work on this network without effort-just Ethernet itself.)

All of the Ethernet protocols belong to the IEEE 802.3 series and are based on the idea of encoding frames. A frame is a well-defined packet message, with a source, a destination, a length, and a type. The logical format of the Ethernet frame is shown in Table 1.

Table 1: Ethernet Frame Format 

Destination	Source	Ethertype	Frame Body	FCS
6 bytes	6 bytes	2 bytes	n bytes	4 bytes

In Ethernet, links are anonymous. Endpoints, however—the line cards that the Ethernet cables plug into—are given addresses. These addresses are assigned at the time the device is built, and are permanently associated with the device. The Ethernet address is a 48-bit (6-byte) address, as shown in Table 2. The first three bytes, or 24 bits, is called the Organizationally Unique Identifier (OUI). Each manufacturer of Ethernet equipment is assigned one or more of these OUIs by the Institute of Electrical and Electronics Engineers (IEEE) Registration Authority. The manufacturer chooses the second 24 bits from a unique pool, often in order starting from 00:00:01. Together, the scheme guarantees that this address will never be accidentally taken by another device.

Table 2: The Ethernet Address Format

	OUI	Manufacturer-Defined
Bit:	0-23	24-47

	L	G
Bit	6	7

Ethernet also defines two special flags in the address. The L bit specifies a local address, which is dynamic and invented by a device for temporary usage. This has an application in Wi-Fi, but is otherwise not common. The G bit is for group-addressed frames-either broadcast or multicast. A group-addressed frame is meant to go out to multiple devices at once, for all of them to receive. Multicast transmissions use this mechanism. The special group address FF:FF:FF:FF:FF:FF (all 1s) is the broadcast address, and specifically requests to go to every device, whether they are in a multicast group or not.

This is one way by which Ethernet guarantees that it does not require management to add or remove devices from the network. When a device wants to transmit over a wire to another device, it has no way of knowing if that second device is there. Ethernet was intentionally designed to be as simple as possible, so senders have to transmit and hope that the other device is there. When the sender creates a frame, it places the destination Ethernet address first in the frame, followed by its own address. Then comes the type of the frame, used to figure out what network protocol is running on top of Ethernet. An arbitrary frame body follows, subject to size restrictions: the body of the frame cannot be greater than 1500 bytes, usually, and cannot be less than 64 bytes. (Shorter frames must be padded.) Finally, Ethernet provides a way to determine whether noise on the Ethernet line causes any bit errors, by using a. frame check sequence (FCS), a mathematical checksum of the bits in the frame that will generally not match the contents of a frame if there are any errors. Ethernet uses a CRC-32 checksum.

Ethernet itself is a serial protocol, much like serial lines used to connect modems together, but operating with much more sophistication and at a faster rate. Most Ethernet types today fall into two categories: copper and fiber. The commercially available copper Ethernet technologies all use a modified version of a telephone cable, made out of copper wires. Each cable carries eight small, insulated copper wires, twisted into pairs as is done for analog telephone lines. The plastic connectors at each end also look like telephone connectors, but have eight pins, rather than the usual six. These connectors, often referred to as RJ45, a specification in which the connectors figure prominently, snap into thecorresponding sockets on all Ethernet devices. Differing numbers of the pairs within the four-pair cable may be used for different Ethernet technologies.

The first RJ45-based Ethernet is called 10BASE-T, or simply original Ethernet. Devices that support 10BASE-T run at 10Mbps, across just two of the pairs within the cable, one for reception, and one for transmission. (The other pairs are not used for data.) These Ethernet lines run a serial protocol, where the voltage on the line is flipped to signal a one or a zero in the bits used to encode the frame. However, these serial lines do not constantly transmit. Instead, the line is usually idle. But when a device wants to transmit on the line, it simply starts transmitting. The transmission itself is the frame, just described. Before the frame itself is sent, a few bits are prepended to it. These bits, known as thepreamble, are used to alert the device at the other end that the transmission is going to begin. The preamble is a 64-bit sequence of alternating ones and zeros, except for the last two bits, which are both ones. The receiving device detects that a transmission comes in, by looking for the sharp swings in voltage in the line from idle, representing the preamble's bits. By the time the preamble is done, the receiver will have figured out the timing of the bit patterns, in case the receiver's clock is slightly off from the sender's. The full bits of the frame proper come in, including the checksum. At the end of the transmission, the sender and receiver have to wait for a few microseconds, and then the line becomes idle and ready to be transmitted on again.

Given that 10BASE-T is a point-to-point physical system, as there can only be one transmitter on one twisted pair, and the other transmitter on the second, there needed to be some way to interconnect multiple lines and thus multiple devices together. The solution to that is the Ethernet hub. The hub works by connecting the twisted pair that is used by a device to transmit, to every link's twisted pair used to receive. This connection allows the transmission by one device to reach all of the others on the same segment, or other devices attached to the same hub. Hubs are purely electrical, and do not participate in the network itself. When a device transmits on an Ethernet hub, every device on that hub hears the signal. A receiver knows that the frame is for it by looking at the destination Ethernet address. If the address matches, then the frame is kept; otherwise, it is discarded unless the operating system on that device requests to receive all frames on the line. The use of hubs, and the definitions for 10BASE-T, require that the transmissions are all half-duplex, meaning that a reception and transmission cannot occur independently.

Adding multiple devices together on an Ethernet link introduces a problem. Two or more devices are capable of transmitting at the same time. If two devices do transmit at the same time, their signals will mix on the wire, and all of the receivers will receive the garbage created by the interference. Thankfully, there is a solution to avoid this. The overall concept is known by the unwieldy phrase Carrier Sense Multiple Access with Collision Detection (CSMA/CD). Let's break that phrase apart, starting from the end. The collision detection portion of Ethernet works rather simply. When the device starts transmitting, it watches the receive twisted pair for its own transmission to return to it. If it sees a signal that differs from its transmission, more than just by a delay, it knows that another device is also transmitting. To prevent wasting time by having both signals clobber each other, the transmitter stops transmitting the frame and sends out a jamming signal for a short burst to ensure that the line is dead. The senders then retry their frame, up to a certain number of times. If the signal does not get clobbered by the time the frame reaches the end, the sender knows that the frame must have made it down the wire safely. If that were all to it, however, two devices with data to send would never be able to avoid colliding. That is because they would both detect the collision at nearly the same time, stopping their transmissions and waiting the mandatory time for the line to come back to quiet, and then they would transmit their next frames immediately. The segment would be in constant collision. To avoid that, the CSMA portion of Ethernet is used. Carrier sense is the act of detecting that a transmission is already on the line. First, the devices check the receive line, to make sure that a signal is not coming in already, corresponding to a transmission already in progress. If there is a transmission in progress, the transmitter waits until it ends. Then it transmits. If a collision occurs, CSMA uses the notion of a random backoff. Instead of each device transmitting exactly after a fixed time from the previous frame after the collision, each device picks a random integer greater than or equal to zero and less than the maximum backoff for this transmission. They then wait that many of slots, each one measured in microseconds, before transmitting again. This step reduces the probability that the devices will collide a second time. If the collision occurs again, the maximum backoff doubles, starting from the first backoff of two slots. This process stops when the frame is successfully transmitted, or abandoned. The next frame will then go out with no backoff.

The problem with backoffs is that they lead to unstable behavior when the network is loaded. This congestion occurs because of excess collisions, and more and more of the time on the network becomes dedicated to retransmissions and less time to new data. The solution to the problem was with the introduction of the Ethernet switch. The Ethernet switch is similar in concept to the telephone switch. A telephone switch isolates the paths between two connections, allowing two devices to speak at a time as if they were directly connected, independent of the other traffic. An Ethernet switch doesn't directly connect circuits, being packet-based, but it does eliminate one device's dependance on the transmissions of the other devices.

The Ethernet switch works by terminating each Ethernet link. Whereas a hub ties the multiple links together into one interconnected collision domain, the switch acts as a separate receiver for each connected device. Two or more devices can transmit at once, on their individual ports, and the switch will independently receive and gather the frames. The frames are then analyzed, interpreted for their destination addresses, and the frame is then sent out on the link that has that address. Because the switch has to read and understand the Ethernet frames, its job becomes one of a traffic director. The concept of simultaneous reception resolves collisions between two endpoint devices, but the switch goes further, by performing the above-mentioned detection of which device is on each link. This function is a crucial part of bridging traffic, and works by the switch maintaining a learning table, built up dynamically, of the Ethernet addresses that have been seen as sources on each link. This table is essentially soft state, meaning that the entries are not permanently recorded, and are built up or refreshed as needed. The last remaining problem is for when the switch gets a frame whose destination address has not yet been learned. In this case, the switch just forwards the frame on every port on the switch, except for the one the frame came in on.

With a switch, the transmit side of each Ethernet link can become a bottleneck. Multiple frames can come in destined to one link, especially if this link holds a common server of some sort. When this happens, the switch is forced to build a backlog of pending transmissions, known as a queue. This queue is a list of packets, usually ordered first-come, first-serve, or first-in, first-out (FIFO). One of the switch's major benefits is that it has translated the resource contention that occurred with hubs into an orderly, predictable wait for packets to get to a popular resource.

The other benefit of a switch is that the collision concept can now be removed entirely. Because, on a switch, there are only ever two possible transmitters on a link, and because there are separate transmit and receive pairs, there is no reason for the receiver to echo back the transmitter's signal. Instead, each device can operate the transmit and receive lines independently. This is known as full duplex operation.

Full duplex operation was introduced with 100BASE-TX, or Fast Ethernet. Fast Ethernet runs at 100Mbps for each direction, greatly increasing the possible data rate on the line. Fast Ethernet uses the same cables and connectors as the original 10BASE-T Ethernet (though lesser-quality cables of the type cannot be used), and the standard defines Fast Ethernet to be backward-compatible with the original. The mechanics of the Fast Ethernet encoding are more advanced than that of the original Ethernet. I will not concern you with the details here, as Ethernet signals are rarely noisy and insight into the encoding is not necessary. The key is that the frame format remains the same, but the data rate is ten times that of Ethernet. Additionally, because Fast Ethernet can use a switch, the backoff procedure is no longer required when transmitting to a Fast Ethernet peer. However, Ethernet hubs are still allowed. Furthermore, 10BASE-T devices may still be connected to a Fast Ethernet port. To determine whether the device can use the 100BASE-TX standard, a protocol known as autonegotiation occurs. Autonegotiation starts as soon as two ports are plugged together. 100BASE-TX devices send out special signals on the line, establishing that it is using 100BASE-TX and communicating its duplex setting. If the other side is also 100BASE-TX, the link will use Fast Ethernet. On the other hand, if the other device does not respond with the other signal (and instead sends the usual 10BASE-T link detection pulses), the 100BASE-TX device will downgrade until the link is unplugged.

Gigabit Ethernet over copper is specified in the 1000BASE-T standard. Gigabit Ethernet, again, is backward-compatible, and uses similar cables, though with tighter quality requirements than either of the previous standards. One major difference for Gigabit Ethernet is that it uses all four twisted pairs in the cable. Combined with using a more advanced bit coding, this produces the extra speed-100 times faster than the original Ethernet.

HYBRID SWITCHING

Hybrid, as the name implies, is a combination of techniques. Various combinations of hybrid switching have appeared in data communications over the years, but have been relegated for the most part to CPE, outside the classical telephone world. In the broader context, IEEE 802.xx LLC (logical link control) and a combination of higher layer Ethernet packets mapped to Internet packets could be labeled a hybrid. However, continued innovation and development emerging after the 1984 deregulation of the long distance telephone business led to newer approaches to transmission and switching such as SONET/SDH, ATM, and other packet- or cell-based technologies. The impact of the Internet Society, in particular the Internet Engineering Task Force (IETF), on global communications standards has been significant to say the least. An example of the kind of innovation that is likely to survive and grow well in to the future is embodied in a technique called multi-protocol label switching (MPLS) sometimes truncated to simply label switching. MPLS is a combination of techniques derived from IP and ATM switching and protocols.

Other Emerging Switching and Routing Technologies

ASON (Automatic Switched Optical Network), GMPLS (Generalized Multi-Protocol Label Switching), and RPR (Resilient Packet Ring) are in active standards development and various stages of maturity at the time of this writing. A full description of each is far beyond the scope of this book. However, a brief description of each is noteworthy. ASON and GMPLS are often seen as a source of contention and competition between ITU and IETF standards development groups, but this is more an impression gained from reading press reports. ASON is a new architecture that will leverage existing SONET/SDH architecture by adding optical switching and control protocols. The motivation for ITU members and their suppliers lies mainly in reduction of capital investment at the core and operations cost associated with provisioning, while at the same time enabling paying customers to use the network in new and innovative ways. Recognize that this work is heavily biased by ITU due process in which the focus is working from well-defined detail requirements for architecture. The basic approach is to agree on the architecture and then work out a set of underlying control protocols, and don’t forget that the background and experience of the developers is heavily influenced by years of operating TDM networks controlled by CCS7/SS7 and DTMF signaling.

GMPLS is an initiative that grew out of effort directed at extending MPLS traffic-engineering techniques. Recall that MPLS as a concept is something of a hybrid or a combination of circuit and packet switching. Motivation for this work lies in the simple desire to more effectively and efficiently control the transmission or transport facilities—circuits in the network. How to do this? Simply invent a new protocol that tells the network to ‘‘do this’’ or ‘‘do that’’ based on a new bright idea, almost without regard to practical business considerations.

The main interest driving the work of both groups appears to be some form of standardized control of the multiplexing and transmission layers in the network. Significant work remains to be accomplished before stability and maturity, sufficient to entice suppliers to invest in design and development of real products capable of attracting service provider investment is achieved. Overall, the serial cycles of standards stabilization, product design, and, finally, deployment by service providers may take 2, 3, 5, or maybe 7 or 8 years. For now, the most appropriate action for the user community is simply monitoring events as they occur.

RPR (Resilient Packet Ring) is the most mature of the three. This work is currently under the moniker IEEE 802.17. Essentially, this is an extension of BLSR (bi-directional line switched ring) technology whereby TDM/PDH, or the more common TDM/SONET/SDH, is modified to replace TDM with Ethernet, or something akin to Ethernet packets. Such an architecture would permit more efficient use of the bandwidth on a given transmission facility because it would allow multiple classes of service on a single facility. Another way of looking at it is to consider that typical BLSR configuration is such that only half of the facility is carrying live traffic, while the other is idle waiting to pickup the traffic when the load-bearing side fails. If the TDM is replaced with Ethernet or similar packet switching techniques capable of carrying classed traffic and priority based packet switching, both sides of the BLSR become useful. If one side fails, lower priority traffic gets delayed or dropped while higher priority traffic moves.

More information on these emerging standards and technologies is as close as your favorite Internet search engine.

PACKET SWITCHING

One only need examine history over the past couple of hundred years to see that older communications models and methods bear resemblance to some of the current crop of fast growing methods. For example it’s not difficult to see the similarity between smoke signals and telegraph messages. If one takes the smoke signal model and imagines a sender sending a message to a receiver and the receiver repeating the message to another smoke sender and so on, it’s easy to see the resemblance to packet forwarding characteristics of the Internet protocol or email.

If you have any interest at all in the Internet and have done any reading on the subject, you’re aware that it’s based on packet switching. Packet switching depends on some basic functional elements including transmission links, and a switching engine called a router.

There are a lot of similarities between cell-based switching and packet-based switching, and there are some differences. Packet switching is simply making decisions about where to send the packet at hand. Packets are like cells in the sense that they must be opened, intelligence found about where they are headed and where they have been, and then switched and/or routed. The instructions are just inside the packet with a few other tidbits of information.

One of the fundamental differences between packet switching and cell switching is at the heart of most of the ambiguity and hand-wringing that occurs when considering the routing-switching—layer 2-layer 3 solution. It’s really quite simple. Cells, PDH streams, and PPP (HDLC) are layer 2 functions. What separates these techniques from packet techniques is a time base. Packets, at least IP datagrams that make up user datagram protocol and Telecommunications protocol over Internet packets, have no reference or relationship to any clocking, timing, or basic synchronizing intelligence. They are just out there somewhere in the Ether. T1/E1, PPP/HDLC, ATM, and Ethernet all have clocking and synchronizing information embedded in the stream.

Packet switching is nothing more than switching and/or routing at packet borders, or between packets after the details in the packet header have been opened and read. Only after the entity has been opened and read can it be routed or switched to a second port. Many times the mail system is used as a metaphor for packet switching. It’s a pretty good metaphor, but with some subtle differences. First, the packet entity must be opened and read. It does not have an outside and an inside unless the payload has been encrypted, or otherwise sealed and secured in some way. One of the fundamental flaws in the Internet everyone knows about and experiences every day is simple courtesy and security. In addition to the payload and addressing information, there are other significant details inside the packet entity exposed for any and everyone to see and do with as they please. These other details have to do with all kinds of fun things that can muck up the overall machinery such as administrative control of the routing machines.

A view that says the Internet has evolved from prior well-known methods and technology wouldn’t be difficult to contend, but would likely be more difficult to defend. Many modern IP network designers seem blissfully unaware that the Internet is critically dependent on an underlying transmission infrastructure they simply refer to as the network layer. Very few of them have a clue about the importance of network clocking and timing. Many think packet over SONET/SDH isn’t a big deal because it’s done all the time (over PDH), which for the most part goes over SONET/SDH any way. Very few realize that HDLC, or PPP framing, is as rigid and fixed as T1, E1, T3, or E3. A few understand the details of packet-over SONET/SDH. The ones that do understand this fundamental know that Internet architecture includes layer 1 and layer 2 and is not, as the rest of their esteemed colleagues contend, self-healing.

Throw in all the mumbo jumbo about connection-oriented and connectionless protocols and mumble solution in between every fifth use of the word router or whatever else can be thought of, but the basics remain the same. That is, something on the premises, or at the network access point, contains or establishes intelligence that tells the network how to set up a connection between two or more points, and thereby transmit and receive information through the network. Anyone can play around with semantics all day about dumb terminals and smart networks, or at the other extreme, they call intelligent terminals and dumb networks. At the end of the day, what’s important is effective and efficient use of limited resources.

If confusion reigns, stop and ask a couple basic questions: ‘‘Is it circuit, cell, or packet?’’ ‘‘What is being shared?’’ Is it time, bandwidth, or both? What are the interface, bitrate, and active protocols on the facility? What is supposed to be done with it? What did the customer ask for? What is being delivered? Is it broke? With a little patience and perseverance, confusion will soon stop raining, the clouds will pass, and matters will clear up as you climb up or down the stack of bits and bytes.

CLOCKING, TIMING, AND SYNCHRONIZATION | Network Technology

Regardless of the type of transmission media (wire, radio, or fiber), bits are sent and bits are received. Every receive port in the network has to deal with an incoming serial bit stream that includes clocking and payload bits. Clocking and data, also called payload, have their timing and phasing relationships established at the point of creation. Along the way, the serial bit stream may be multiplexed with additional serial bit streams, cross-connected to a different carrier, or switched at the circuit, cell, or packet layer. Yes, this is layer 1 and 2 of the OSI stack. Separating clock information from payload, or mucking around with the time relationship between signal transitions amounts to errors. If, for whatever reason, a network element loses its synchronization reference and wanders outside holding limits, anything and everything using it as a synchronization reference is out of time with the larger network, converting valuable data to invaluable trash.

Clocking and data recovery are a critical function. Considering the clocking concept from the perspective of a receive port on a network element or the receive end of a transmission path gives the ability to look backward toward the source and forward toward other network elements and facilities dependent on the clock for proper operation and delivery of the associated payload.

If there is a single point in the entire end-to-end, top-to-bottom process that is the most critical in moving digitized information through a network, it has to be at each and every receive point in the network. Receiving the bitstream intact and then extracting clocking information must be done before the payload can be extracted. Even if the receiver is clocked externally, clock and data signals in the incoming stream must be separated and defined. Payload framing depends on timing relationships, and guess what, timing depends on clocking. Serial data streams just aren’t real if they don’t have a mechanism delineating framed data and clock signals. Understanding clock and data recovery as a stand-alone function is one of the keys to understanding digital communications networks. Figure 1 is a block diagram of a typical clock and data recovery function found in almost every network element.

Figure 1: Clock and Data Recovery Functional Block Diagram

The functions in Figure 1 include receiving light or radio waves from the media, detecting and converting it to electrical voltage transitions. This requires a lens or optical interface in the case of light waves. The equivalent in radio waves would be an antenna. The purpose of either is to detect and focus the received energy into a signal containing the time variations between and during presence and absence of signal. The signal is then passed to a detector, which converts the signal into a series of transitions representing the serial bitstream originally sent by the transmitter.

The raw bitstream is then fed to a clock extraction circuit and a buffer. The clock is extracted and used for two purposes: one is a clock signal representing the original clock used when the data was created or multiplexed, and the other drives a data recovery circuit. The data recovery circuit extracts and re-clocks the data to restore as precisely as possible the transitions between 1s and 0s making up the data. At this point, the data is simply just that. We don’t know anything about framing or channelization and nothing about protocols, byte size, packing, or error correction. These are all to be determined with additional processing, and take place through the upper layers of the ISO stack.

The clocking signal is representative of the original clock sent by the transmitter. It also has a lot of unknowns, but the important point to recognize is that this signal represents timing from another node or remote site outside the physical boundaries of the receiving equipment site. This signal could be important in the overall scheme of things or it could be irrelevant. For example, it could be used as a timing reference for the entire site. If that were the case, then many other considerations become important. If it is used as a timing reference for the entire site, there is no question that it will continue being proliferated to other sites because it becomes the clock that turns up as the receive clock after clock and data recovery at other sites receive signals from the instant site.

Naturally, this begs a few questions: ‘‘Where did that clocking signal originate?’’ ‘‘What is its level of accuracy?’’ ‘‘Is it a network clock?’’ Clocking in communications networks is as critical and necessary as synchronizing and time code in television audio and video. Timing in communications networks can be as complicated or as simple as timing in digital audio and video systems. Clock accuracy in communications networks is built around a four-level hierarchy with the most accurate clock at the first level and least accurate at the fourth level. Originally developed by Bell Labs for AT&T’s digital network in the 1960s, adopted and standardized by ANSI, ITU, and other standards-making bodies, the system is referred to as stratum 1 through stratum 4. In the beginning, there was only one stratum 1 clock in operation for the entire network at any given time. This clock was distributed to regional switching and operating centers and used to time and synchronize network elements at that level in the hierarchy and so on to local central offices at the bottom of the hierarchy. Each clock level depended on the one above it for synchronization. If it lost the reference signal from above, the local clock was permitted to operate within a range wider than the higher reference until the higher-level reference was once again available.

As you can imagine, there’s not much of a disturbance when the reference clock disappears. But what about when the reference clock returns or if it is intermittent? Dealing with these situations led to the development of a hold-over specification, which basically requires the clock to remain within, or hold its frequency of operation for a given time and, in the interest of overall stability, not switch back to the higher hierarchy reference clock until after some period of stable operation, and if possible, switch gracefully, sometimes called hitless switching.

Primary reference clock (PRC) products compliant with ANSI and ITU standards are available from many sources. These clock sources can run independently, or they can be referenced and locked to other sources traceable to the World Timing Standard for time-of-day, called Coordinated Universal Time (UTC).^[2] UTC is the result of combining TAI (International Atomic Time) and Universal Time 1 (UT1). TAI is a timing reference derived by averaging outputs from the clocks of approximately 100 countries. These clocks keep the timing relationship to each other within 2 to 3 millionths of a second over a year. UT1 provides a correction to compensate for the difference in solar time and TAI caused by slightly elliptical orbit and polar inclination, both of which affect solar time.

Distributing the PRC to all the elements in early digital network infrastructure was expensive, cumbersome, and complex. However, advances in lowering the cost of clock reference products and the availability of the global positioning system (GPS) and Internet-based references running under network time protocol (NTP) have dramatically reduced cost on all fronts and improved reliability and accuracy of the sources and their references.

Why all the fuss and bother? Essentially, signals derived from multiplexing low-speed digital bit streams into higher-order aggregate bit streams, some of which provide private line, and others that provide circuit-, cell-, and packet-switched services must be synchronized and timed exactly the way digital audio and video signals are timed and synchronized, including SMPTE time code, to bit level accuracy within a frame. The only differences are that Telecom digital signals aren’t subject to switching transitions such as a split screen or cross-fade, and telecom and digital program content run on entirely different time bases. One other point is that this timing accuracy has absolutely nothing to do with the transmission media—it makes no difference if the transmission is satellite or terrestrial radio, optical transmission, or baseband electrical signal transport.

One thing to pay attention to in systems where the bit stream is modulated onto a carrier is the capability of a particular modulator to lock the carrier frequency generator to an external source such as the incoming digital signal or PRC. On the receive end, it may be appropriate to lock the local receiver beat frequency oscillator in the receiver to either a PRC or the incoming digital signal clock. Including these capabilities in a piece of equipment is not without cost; however, those that do provide that capability will be capable of better bit error performance across the transmission facility because of the absence of asynchronous cross talk causing clock slips.

Lastly, be careful not to confuse network primary reference clock with program clock reference in Moving Picture Experts Group (MPEG). The two are completely different animals and have nothing to do with each other. When MPEG2 program streams are transported through networks, the PCR is just another set of bits in the payload.