Types of Packet-Switching Networks

Types of Packet-Switching Networks

As you've seen, packet-based data transfer is what defines a packet-switching network. But—to confuse the issue a bit—referring to a packet-switching network is a little like referring to tail-wagging canines as dogs. Sure, they're dogs. But any given dog can also be a collie or a German shepherd or a poodle. Similarly, a packet-switching network might be, for example, an X.25 network, a frame relay network, an ATM (Asynchronous Transfer Mode) network, an SMDS (Switched Multimegabit Data Service), and so on.

X.25 packet-switching networks
Originating in the 1970s, X.25 is a connection-oriented, packet-switching protocol, originally based on the use of ordinary analog telephone lines, that has remained a standard in networking for about twenty years. Computers on an X.25 network carry on full-duplex communication, which begins when one computer contacts the other and the called computer responds by accepting the call.
Although X.25 is a packet-switching protocol, its concern is not with the way packets are routed from switch to switch between networks, but with defining the means by which sending and receiving computers (known as DTEs) interface with the communications devices (DCEs) through which the transmissions actually flow. X.25 has no control over the actual path taken by the packets making up any particular transmission, and as a result the packets exchanged between X.25 networks are often shown as entering a cloud at the beginning of the route and exiting the cloud at the end.


A recommendation of the ITU (formerly the CCITT), X.25 relates to the lowest three network layers—physical, data link, and network— in the ISO reference model:

·         At the lowest (physical) layer, X.25 specifies the means—electrical, mechanical, and so on—by which communication takes place over the physical media. At this level, X.25 covers standards such as RS-232, the ITU's V.24 specification for international connections, and the ITU's V.35 recommendation for high-speed modem signaling over multiple telephone circuits.

·         At the next (data link) level, X.25 covers the link access protocol, known as LAPB (Link Access Protocol, Balanced), that defines how packets are framed. The LAPB ensures that two communicating devices can establish an error-free connection.

·         At the highest level (in terms of X.25), the network layer, the X.25 protocol covers packet formats and the routing and multiplexing of transmissions between the communicating devices.

On an X.25 network, transmissions are typically broken into 128-byte packets. They can, however, be as small as 64 bytes or as large as 4096 bytes.

DTEs and DCEs
As already mentioned, the sending and receiving computers on an X.25 network are not known as computers, hosts, gateways, or nodes. They are DTEs. In X.25 parlance, DTEs are devices that pass packets to DCEs, for forwarding through the links that make up a WAN. DTEs thus sit at the two ends of a network connection; in contrast, DCEs sit at the two ends of a communications circuit,

PADs So far so good. But since packets are as important to a packet-switching network as atoms are to matter, what about the devices that create and reassemble the packets themselves? In some cases, such as an X.25 gateway computer (the DTE) that sits between a LAN and the WAN, the gateway takes care of packetizing. In other cases, as with an ordinary PC (another type of DTE), the job is handled by a device known as a packet assembler and disassembler, or PAD. In this case, the PAD sits between the computer and the network, packetizing data before transmission and, when all packets have been received, reconstituting the original message by putting the packets back together in the correct order.
Is this work difficult? Well, to a human it might be, because packets are sent along the best possible route available at the time they are forwarded. Thus, it's quite possible for the packets representing a single message to travel over different links and to arrive at their destination out of order. Considering the amount of traffic flowing over a WAN, and considering the possible number of transmitting and receiving nodes, it would seem that the job of reconstructing any given message represents a Herculean task. Well, to people, it probably does. To a PAD, it does not. Putting Humpty Dumpty back together again is all in a day's work for the PAD. It does such work over and over again.

Frame relay
Frame relay is a newer, faster, and less cumbersome form of packet switching than X.25. Often referred to as a fast packet switching technology, frame relay transfers variable-length packets up to 4 KB in size at 56 Kbps or T1 (1.544 or 2 Mbps) speeds over permanent virtual circuits.
Operating only at the data link layer, frame relay outpaces the X.25 protocol by stripping away much of the "accounting" overhead, such as error correction and network flow control, that is needed in an X.25 environment. Why is this? Because frame relay, unlike X.25 with its early reliance on often unreliable telephone connections, was designed to take advantage of newer digital transmission capabilities, such as fiberoptic cable and ISDN. These offer reliability and lowered error rates and thus make the types of checking and monitoring mechanisms in X.25 unnecessary.
For example, frame relay does include a means of detecting corrupted transmissions through a cyclic redundancy check, or CRC, which can detect whether any bits in the transmission have changed between the source and destination. But it does not include any facilities for error correction. Similarly, because it can depend on other, higher-layer protocols to worry about ensuring that the sender does not overwhelm the recipient with too much data too soon, frame relay is content to simply include a means of responding to "too much traffic right now" messages from the network.
In addition, because frame relay operates over permanent virtual circuits (PVCs), transmissions follow a known path and there is no need for the transmitting devices to figure out which route is best to use at a particular time. They don't really have a choice, because the routes used in frame relay are based on PVCs known as Data Link Connection Identifiers, or DLCIs. Although a frame relay network can include a number of DLCIs, each must be associated permanently with a particular route to a particular destination.

Also adding to the speed equation is the fact that the devices on a frame relay network do not have to worry about the possibility of having to repackage and/or reassemble frames as they travel. In essence, frame relay provides end-to-end service over a known—and fast—digital communications route, and it relies heavily on the reliability afforded by the digital technologies on which it depends. Like X.25, however, frame relay is based on the transmission of variable length packets, and it defines the interface between DTEs and DCEs. It is also based on multiplexing a number of (virtual) circuits on a single communications line.
So how, exactly, does frame relay work? Like X.25, frame relay switches rely on addressing information in each frame header to determine where packets are to be sent. The network transfers these packets at a predetermined rate that it assumes allows for free flow of information during normal operations.
Although frame relay networks do not themselves take on the task of controlling the flow of frames through the network, they do rely on special bits in the frame headers that enable them to address congestion. The first response to congestion is to request the sending application to "cool it" a little and slow its transmission speed; the second involves discarding frames flagged as lower-priority deliveries, and thus essentially reducing congestion by throwing away some of the cargo.
Frame relay networks connecting LANs to a WAN rely, of course, on routers and switching equipment capable of providing appropriate frame-relay interfaces.

ATM
You're focused on networks when ATM no longer translates as "Automated Teller Machine" but instead makes you immediately think "Asynchronous Transfer Mode." All right. So what is Asynchronous Transfer Mode, and what is it good for?
To begin with, ATM is a transport method capable of delivering not only data but also voice and video simultaneously, and over the same communications lines. Generally considered the wave of the immediate future in terms of increasing both LAN and WAN capabilities, ATM is a connection-oriented networking technology, closely tied to the ITU's recommendation on broadband ISDN (BISDN) released in 1988.
What ATM is good for is high-speed LAN and WAN networking over a range of media types from the traditional coaxial cable, twisted pair, and fiberoptic to communications services of the future, including Fiber Channel, FDDI, and SONET (described in later sections of this chapter).
Although ATM sounds like a dream, it's not. It's here, at least in large part.
Cell relay ATM, like X.25 and frame relay, is based on packet switching. Unlike both X.25 and frame relay, however, ATM relies on cell relay, a high-speed transmission method based on fixed-size units (tiny ones only 53 bytes long) that are known as cells and that are multiplexed onto the carrier.

Because uniformly sized cells travel faster and can be routed faster than variable-length packets, they are one reason—though certainly not the only one—that ATM is so fast. Transmission speeds are commonly 56 Kbps to 1.544 Mbps, but the ITU has also defined ATM speeds as high as 622 Mbps (over fiberoptic cable).

How it works
Imagine a "universal" machine—one that can take in any materials, whether they are delivered sporadically or in a constant stream, and turn those materials into lookalike packages. That's basically how ATM works at the intake end. It takes in streams of data, voice, video…whatever…and packages the contents in uniform 53-byte cells. At the output end, ATM sends its cells out onto a WAN in a steady stream for delivery, as shown in Figure 8-1.
That all seems simple enough, but now take a look at the "magic" of ATM in a little more technical detail.
To begin with, remember that ATM is designed to satisfy the need to deliver multimedia. Well, multimedia covers a number of different types of information that have different characteristics and are handled differently, both by the devices that work with them and by higher-level networking protocols. Yet, in order to make use of ATM, something must interface with the different devices and must package their different types of data in