Asynchronous Transfer Mode (ATM) is a wide area networking standard set by the telecommunications industry. Although it flirted as competition to Ethernet as a LAN in the 1990s, ATM has since retreated to its WAN stronghold.
The telecommunications standard has scalable bandwidth built in. It starts at 155 Mbits/sec and scales by factors of 4 to 620 Mbits/sec, 2480 Mbits/sec, and so on. Since it is a WAN, ATM’s medium is fiber, both single mode and multimode.
Although it is a switched medium, unlike the other examples it relies on virtual connections for communication. ATM uses virtual channels for routing to multi-plex different connections on a single network segment, thereby avoiding the inefficiencies of conventional connection-based networking. The WAN focus also led to store-and-forward switching. Unlike the other protocols, Figure F.30 shows ATM has a small, fixed-sized packet with 48 bytes of payload. It uses a credit-based flow control scheme as opposed to IP routers that do not implement flow control.
The reason for virtual connections and small packets is quality of service.
Since the telecommunications industry is concerned about voice traffic, predict-ability matters as well as bandwidth. Establishing a virtual connection has less variability than connectionless networking, and it simplifies store-and-forward switching. The small, fixed packet also makes it simpler to have fast routers and switches. Toward that goal, ATM even offers its own protocol stack to compete with TCP/IP. Surprisingly, even though the switches are simple, the ATM suite of protocols is large and complex. The dream was a seamless infrastructure from LAN to WAN, avoiding the hodgepodge of routers common today. That dream has faded from inspiration to nostalgia.
Undoubtedly one of the most important innovations in the communications community has been internetworking. It allows computers on independent and incompatible networks to communicate reliably and efficiently. Figure F.34
F.9 Internetworking
illustrates the need to traverse between networks. It shows the networks and machines involved in transferring a file from Stanford University to the Univer-sity of California at Berkeley, a distance of about 75 km.
The low cost of internetworking is remarkable. For example, it is vastly less expensive to send electronic mail than to make a coast-to-coast telephone call and leave a message on an answering machine. This dramatic cost improvement is achieved using the same long-haul communication lines as the telephone call, which makes the improvement even more impressive.
The enabling technologies for internetworking are software standards that allow reliable communication without demanding reliable networks. The under-lying principle of these successful standards is that they were composed as a hier-archy of layers, each layer taking responsibility for a portion of the overall communication task. Each computer, network, and switch implements its layer of Figure F.34 The connection established between mojave.stanford.edu and mammoth.berkeley.edu (1995).
FDDI is a 100 Mbit/sec LAN, while a T1 line is a 1.5 Mbit/sec telecommunications line and a T3 is a 45 Mbit/sec tele-communications line. BARRNet stands for Bay Area Research Network. Note that inr-111-cs2.Berkeley.edu is a router with two Internet addresses, one for each port.
UCB1.
BARRNet.net 192.31.161.4
mojave.
Stanford.edu 36.22.0.120 CIS-Gateway.
Stanford.edu 36.1.0.22 SU-CM.
BARRNet.net 131.119.5.3
Ethernet FDDI
T1 line T3 line
inr-108-eecs.
Berkeley.edu
128.32.120.108 128.32.120.111 inr-111-cs2.
Berkeley.edu 128.32.149.13
mammoth.
Berkeley.edu 128.32.149.78
FDDI FDDI
Ethernet Ethernet
Internet
fd-0.enss128.t3.
ans.net 192.31.48.244 Stanford,
California
Berkeley, California
the standards, relying on the other components to faithfully fulfill their responsi-bilities. These layered software standards are called protocol families or protocol suites. They enable applications to work with any interconnection without extra work by the application programmer. Figure F.35 suggests the hierarchical model of communication.
The most popular internetworking standard is TCP/IP (Transmission Control Protocol/Internet Protocol). This protocol family is the basis of the humbly named Internet, which connects hundreds of millions of computers around the world. This popularity means TCP/IP is used even when communicating locally across compatible networks; for example, the network file system (NFS) uses IP even though it is very likely to be communicating across a homogenous LAN such as Ethernet. We use TCP/IP as our protocol family example; other protocol families follow similar lines. Section F.13 gives the history of TCP/IP.
The goal of a family of protocols is to simplify the standard by dividing responsibilities hierarchically among layers, with each layer offering services needed by the layer above. The application program is at the top, and at the bot-tom is the physical communication medium, which sends the bits. Just as abstract data types simplify the programmer’s task by shielding the programmer from details of the implementation of the data type, this layered strategy makes the standard easier to understand.
There were many efforts at network protocols, which led to confusion in terms. Hence, Open Systems Interconnect (OSI) developed a model that popular-ized describing networks as a series of layers. Figure F.36 shows the model.
Although all protocols do not exactly follow this layering, the nomenclature for the different layers is widely used. Thus, you can hear discussions about a simple layer 3 switch versus a layer 7 smart switch.
The key to protocol families is that communication occurs logically at the same level of the protocol in both sender and receiver, but services of the lower level implement it. This style of communication is called peer-to-peer. As an analogy, imagine that General A needs to send a message to General B on the
Figure F.35 The role of internetworking. The width indicates the relative number of items at each level.
Applications
Networks
Internetworking
battlefield. General A writes the message, puts it in an envelope addressed to General B, and gives it to a colonel with orders to deliver it. This colonel puts it in an envelope, and writes the name of the corresponding colonel who reports to General B, and gives it to a major with instructions for delivery. The major does the same thing and gives it to a captain, who gives it to a lieutenant, who gives it to a sergeant. The sergeant takes the envelope from the lieutenant, puts it into an envelope with the name of a sergeant who is in General B’s division, and finds a private with orders to take the large envelope. The private borrows a motorcycle and delivers the envelope to the other sergeant. Once it arrives, it is passed up the chain of command, with each person removing an outer envelope with his name on it and passing on the inner envelope to his superior. As far as General B can tell, the note is from another general. Neither general knows who was involved in transmitting the envelope, nor how it was transported from one division to the other.
Protocol families follow this analogy more closely than you might think, as Figure F.37 shows. The original message includes a header and possibly a trailer sent by the lower-level protocol. The next-lower protocol in turn adds its own header to the message, possibly breaking it up into smaller messages if it is too large for this layer. Reusing our analogy, a long message from the general is divided and placed in several envelopes if it could not fit in one. This division of the message and appending of headers and trailers continues until the message descends to the physical transmission medium. The message is then sent to the destination. Each level of the protocol family on the receiving end will check the message at its level and peel off its headers and trailers, passing it on to the next higher level and putting the pieces back together. This nesting of protocol layers Layer number Layer name Main function
Example
protocol Network component 7 Application Used for applications specifically
written to run over the network
FTP, DNS, NFS, http
Gateway, smart switch 6 Presentation Translates from application to network
format, and vice versa
Gateway 5 Session Establishes, maintains, and ends
sessions across the network
Named pipes, RPC
Gateway 4 Transport Additional connection below the session
layer
TCP Gateway
3 Network Translates logical network address and names to their physical address (e.g., computer name to MAC address)
IP Router, ATM switch
2 Data Link Turns packets into raw bits and at the receiving end turns bits into packets
Ethernet Bridge, network interface card 1 Physical Transmits raw bit stream over physical
cable
IEEE 802 Hub
Figure F.36 The OSI model layers. Based on www.geocities.com/SiliconValley/Monitor/3131/ne/osimodel.html.
for a specific message is called a protocol stack, reflecting the last in, first out nature of the addition and removal of headers and trailers.
As in our analogy, the danger in this layered approach is the considerable latency added to message delivery. Clearly, one way to reduce latency is to reduce the number of layers, but keep in mind that protocol families define a standard but do not force how to implement the standard. Just as there are many ways to implement an instruction set architecture, there are many ways to imple-ment a protocol family.
Our protocol stack example is TCP/IP. Let’s assume that the bottom protocol layer is Ethernet. The next level up is the Internet Protocol or IP layer; the official term for an IP packet is a datagram. The IP layer routes the datagram to the desti-nation machine, which may involve many intermediate machines or switches. IP makes a best effort to deliver the packets but does not guarantee delivery, content, or order of datagrams. The TCP layer above IP makes the guarantee of reliable, in-order delivery and prevents corruption of datagrams.
Following the example in Figure F.37, assume an application program wants to send a message to a machine via an Ethernet. It starts with TCP. The largest number of bytes that can be sent at once is 64 KB. Since the data may be much larger than 64 KB, TCP must divide them into smaller segments and reassemble them in proper order upon arrival. TCP adds a 20-byte header (Figure F.38) to every datagram and passes them down to IP. The IP layer above the physical layer adds a 20-byte header, also shown in Figure F.38. The data sent down from the IP level to the Ethernet are sent in packets with the format shown in Figure F.30.
Note that the TCP packet appears inside the data portion of the IP datagram, just as Figure F.37 suggests.
Figure F.37 A generic protocol stack with two layers. Note that communication is peer-to-peer, with headers and trailers for the peer added at each sending layer and removed by each receiving layer. Each layer offers services to the one above to shield it from unnecessary details.
T
Message
H T
H
H T T H H T T HH T T HH T T HH T T
T
H T H T
Message
H T H T H T
Actual Actual
Actual
Actual Logical Logical
Actual
Figure F.38 The headers for IP and TCP. This drawing is 32 bits wide. The standard headers for both are 20 bytes, but both allow the headers to optionally lengthen for rarely transmitted information. Both headers have a length of header field (L) to accommodate the optional fields, as well as source and destination fields. The length field of the whole data-gram is in a separate length field in IP, while TCP combines the length of the datadata-gram with the sequence number of the datagram by giving the sequence number in bytes. TCP uses the checksum field to be sure that the datagram is not cor-rupted, and the sequence number field to be sure the datagrams are assembled into the proper order when they arrive.
IP provides checksum error detection only for the header, since TCP has protected the rest of the packet. One optimiza-tion is that TCP can send a sequence of datagrams before waiting for permission to send more. The number of data-grams that can be sent without waiting for approval is called the window, and the window field tells how many bytes may be sent beyond the byte being acknowledged by this datagram. TCP will adjust the size of the window depending on the success of the IP layer in sending datagrams; the more reliable and faster it is, the larger TCP makes the window.
Since the window slides forward as the data arrive and are acknowledged, this technique is called a sliding window pro-tocol. The piggyback acknowledgment field of TCP is another optimization. Since some applications send data back and forth over the same connection, it seems wasteful to send a datagram containing only an acknowledgment. This piggyback field allows a datagram carrying data to also carry the acknowledgment for a previous transmission, “piggy-backing” on top of a data transmission. The urgent pointer field of TCP gives the address within the datagram of an important byte, such as a break character. This pointer allows the application software to skip over data so that the user doesn’t have to wait for all prior data to be processed before seeing a character that tells the software to stop. The iden-tifier field and fragment field of IP allow intermediary machines to break the original datagram into many smaller data-grams. A unique identifier is associated with the original datagram and placed in every fragment, with the fragment field saying which piece is which. The time-to-live field allows a datagram to be killed off after going through a maxi-mum number of intermediate switches no matter where it is in the network. Knowing the maximaxi-mum number of hops that it will take for a datagram to arrive—if it ever arrives—simplifies the protocol software. The protocol field identifies which possible upper layer protocol sent the IP datagram; in our case, it is TCP. The V (for version) and type fields allow different versions of the IP protocol software for the network. Explicit version numbering is included so that software can be upgraded gracefully machine by machine, without shutting down the entire network. Nowadays, version six of the Internet protocol (IPv6) was widely used.
IP header
IP data
TCP data
Identifier Fragment
Header checksum Source
Source
Sequence number (length) Destination
Destination Length Type
Time Protocol
V L
TCP header
Urgent pointer Window
TCP data
32 bits Piggyback acknowledgment
Flags Checksum L
(0–65,516 bytes)
This section describes five topics discussed in other chapters that are fundamen-tally impacted by interconnection networks, and vice versa.