Protocol Stacks Communication Protocols

Chapter 13 Internetworking Interprocess communication within the confines of a single machine is handled by that machine’s local operating system; for example, a Unix system can support two processes that communicate using a pipe. But when processes on different machines need to communicate, communication networks are needed. This chapter describes the protocols used to establish communications and pass data between remote sys- tems.

13.1 Communication Protocols

In order to communicate, computers need to speak a common language. Protocols provide this common language. They specify precisely what can be said, and under what circumstances.

13.1.1 Protocol Stacks

How is communication from one machine to another supported? Let’s look at a specific example, and follow it from the top down. Our example will be sending an email message. Sending email is like copying a file At the top level, sending an email message is just copying a file from the sender to the receiver’s incoming mail directory. This is conceptually very simple. The message text begins with a line saying “ To: yossi ”, so the receiving email program knows to whom the message is addressed. 213 mail mail message It is desirable to coordinate representations of text However, it may happen that the two correspondents are using different types of computers, that represent text characters in different ways. If we don’t take care, our carefully composed text might end up as gibberish. As handling representations is a useful service, we will make it a separate applica- tion, rather than bundling it into the email program. Thus the email program passes the message to the representation program, rather than sending it directly to the other email program. The representation program adds a small header that specifies what representation is being used, and sends the original message plus the header to the representation program on the other computer. The representation program on the other computer checks whether the representation is the same, and if not, per- forms a translation to the local representation. It then passes the message which is now guaranteed to be in the correct local representation up to the email application, which copies it to the correct user’s directory. mail encode encode mail message rep Long messages may need to be broken up into shorter ones Because of limited buffer capacity in the communication hardware and other reasons, it is impossible to send arbitrarily long messages. But users don’t know this, and may want to send a whole book in a single message. Therefore the email handling program may need to break up a long message into short packets on the sending side, and re-assemble them into a single long message at the receiving side. As packetization is again a useful service, we’ll write a separate program to han- dle it. Thus the representation program will not send the message directly to its counterpart on the other computer; instead, it will forward the message to its local packetization program. The packetization program will break the message up into packets, add a header with the packet number to each one, and send them to the packetization program on the other computer. There they will be reassembled and passed up to the representation program, etc. 214 encode packets packets encode mail pkt mess age rep pkt mail Two things are noteworthy. First, the packetization regards the data it receives as a single entity that has to be packetized; it does not interpret it, and does not care if it is actually composed of some higher-level headers attached to the “real” data. In our case, the original message and the representation header are taken as a unit, and divided into two packets. Second, the resulting packets need not be the same size: there is a maximal packet size, but if the remaining data is less that this, a smaller packet can be sent. Routing is needed if there is no direct link But what if there is not direct link between the two computers? The message that is, all its packets must then be routed through one or more intermediate computers. Again, routing is useful, so it will be handled separately. The packetizer then forwards the packets to the router, who adds an address or routing header, and de- termines where to send them. The router on the receiving node checks the address, and forwards the packets as appropriate. At the end the packets arrive at the des- ignated destination computer. The router on that machine recognizes that it is the destination, and passes the arriving packets to the local packetizer for processing. mail encode packets route route packets encode mail route message rep pkt addr Error correction can be applied to each transmission The above scenario is optimistic in the sense that it assumes that data arrives intact. In fact, data is sometimes corrupted during transmission due to noise on the commu- nication lines. Luckily it is possible to devise means to recognize such situations. For example, we can calculate the parity of each packet and its headers, and add a parity bit at the end. If the parity does not match at the receiving side, en error is flagged and the sender is asked to re-send the packet. Otherwise, an acknowledgment is sent back to the sender to notify it that the data was received correctly. 215 Parity is a simple but primitive form of catching errors, and has limited recogni- tion. Therefore real systems use more sophisticated schemes such as CRC. However, the principle is the same. And naturally, we want a separate program to handle the calculation of the error-correcting code ECC and the necessary re-sends. mail encode packets route route packets encode mail route error error error ECC message rep pkt addr All this results in the creation of complex protocol stacks As we saw, it is convenient to divide the work of performing communication into mul- tiple layers. Each layer builds upon the layers below it to provide an additional service to the layers above it, and ultimately to the users. The data that is transmitted goes down through the layers, acquiring additional headers on the way, on the sending side. Then it is transmitted across the network. Finally it goes back up again on the receiving side, and the headers are peeled off. The set of programs that the message goes through is called a protocol stack. Log- ically, each layer talks directly with its counterpart on the other machine, using some particular protocol. Each protocol specifies the format and meaning of the messages that can be passed. Usually this is a protocol-specific header and then a data field, that is not interpreted. For example, the packetization layer adds a header that con- tains the packet number in the sequence. Exercise 162 What is the protocol of the email application? look at your email and make an educated guess. The protocol also makes assumptions about the properties of the communication subsystem that it uses. For example, the email application assumes that the whole message is transferred with no errors, and is in the local representation. In reality, this abstraction of the communication subsystem is created by lower layers in the stack.

13.1.2 The ISO-OSI Layered Model