Previous Table of Contents Next


In order to route data from the source to the proper destination, whether the network is switched or not, the PDU contains the address of the sender and the address of the receiver of the data. Regardless of the network topology—token ring, Ethernet, or some other topology —including the address of both the sender and intended receiver in the PDU provides some measure of confidence that the data will reach its correct destination. And the correct destination will recognize who sent the data.

The use of sender and receiver addresses in the PDU gives a network the freedom to route PDUs through the network in the most efficient manner possible, allowing the network to maximize bandwidth usage. The result is one PDU may follow a specific path through the network while the next PDU may follow a different path. Also, PDUs may be buffered, or held temporarily, by network elements due to the network link status (busy), the intended receiver not ready to receive, or supercession by higher priority traffic. Yes, Uncle Sam can preempt your Internet session and so can companies that have paid telecommunications companies for a higher class of service. The result? Not all PDUs arrive at the destination in order of transmission, and the delay between each PDUs arrival at the destination can vary significantly. Such routing of the data is anathema to audio- and video-based applications.

To determine if the PDU is corrupted when received, the PDU contains an eight-bit byte (octet) that represents a magical number called a CRC (cyclic redundancy check). The CRC is calculated by the sender using a polynomial and the number of ones (or zeroes) bits stuffed into the PDU. Upon receipt, the receiver calculates the CRC based upon the number of ones (or zeroes) bits received and compares the number calculated to the CRC received. If the two numbers are equal, the receiver can assume, with a high degree of accuracy (better than 1 in 10^12), that the data received was actually the data sent.

However, if the CRC calculation by the receiver does not match the number transmitted, the receiver can perform some sleight of hand and may be able to reconstruct the correct data, using the transmitted CRC. But sometimes the tricks do not work and the receiver must ask the sender to retransmit the corrupted PDU. Such retransmission of the data is anathema to audio- and video-based applications.

So, we are shipping PDUs all around the countryside and we do not have good control over when they reach their destination and in what order. This situation is okay for data communications applications that do not have an intimate relationship with time. But if the data is time sensitive, such as video and multimedia, then data processing issues such as time lapses and delays result in unacceptable system performance.

To provide the throughput necessary to support process-sensitive communication applications a better method is needed. Fortunately, just when we were beginning to need it most, ATM was discovered! Actually the real story is our transmission systems (SONET) have become sufficiently reliable that we can now do away with much of the header overhead, giving us a slim, trim, speedy PDU.

Frame Structures

To really appreciate the benefits of ATM, and to understand why ATM is much faster than legacy systems, a look at the framing used by some legacy systems is worthwhile. When one understands where one has been, then it is much clearer to see where one is going.

Header Type FiEld Size
802.3 destination address 6 bytes
802.3 source address 6 bytes
802.3 length 2 bytes
802.2 destination SAP 1 byte
802.2 source SAP 1 byte
802.2 control data 1 byte

Table 4-1. IEEE 802.3 framing with 802.2 headers

Table 4-1 shows the framing organization for Ethernet IEEE 802.3 with IEEE 802.2 headers. Novell Netware networks use this type of framing by default. It is the framing type automatically selected when the network software for a Novell Netware adapter driver is installed. Novell sets the Service Advertising Protocol (SAP) field to 0xe0, specifying that the upper layer protocol is IPX.

Header Type Field Size
802.3 destination address 6 bytes
802.3 source address 6 bytes
802.3 length 2 bytes
802.3 0xffff 2 bytes
data x

Table 4-2. IEEE 802.3 framing

IEEE 802.3 framing is used most often in Novell networks that use Netware 2.x/3.x servers. Since Novell developed this framing while IEEE 802.3 was still being developed, it is not 100 percent IEEE 802.3 compliant. The data size is unlimited as indicated by the “x”.

Header Type Field Size
Ethernet II destination address 6 bytes
Ethernet II source address 6 bytes
Ethernet II type 2 bytes
data x

Table 4-3. Ethernet II framing


Previous Table of Contents Next