Communication using TCP/IP

Now, the actual communication takes place as discussed below. We shall assume the network as shown in Fig. 2.14 for this example. We still assume that a user on node A wants to send a message (e.g., an email) to a user on node G. The following steps will be executed to accomplish this task.

1. The application layer running on node A (e.g., an email program) hands over the message to be transmitted to the TCP layer running on node A.

2. The TCP layer breaks the message into smaller segments, and appends the TCP header to each one, as shown in Fig. 3.11. We will talk about this later when we discuss TCP in detail.

Fig. 3.11 TCP layer breaks down the original message into segments

3. The IP layer breaks each segment further into fragments if necessary, and appends the IP header to each one. We will assume for simplicity that the fragmentation is not necessary. At the IP level, the TCP header + datagram is treated together as data. This is the basic process of encapsulation. Thus, in this case, it will just append the IP header to the datagram for IP (i.e., the original datagram plus TCP header). This becomes the datagram for the lower layer (i.e., Ethernet). The datagram now looks as shown in Fig. 3.12.

Fig. 3.12 IP header is added to the TCP segment

The IP header contains the 32 bit source as well as destination addresses corresponding respectively to the source and destination computers.

4. Now, the whole IP datagram shown earlier is treated as data as far as Net-1 (which is an Ethernet) is concerned. The IP software at node A realizes from the network id portion of the destination IP address (contained in IP header) that it is not the same as the network id of the IP address of computer A. Therefore, it realizes that the destination computer is on a different network. Therefore, it simply has to hand the datagram over to router R1. As a general rule, every node has to hand over all datagrams that have a different network id than their own, in the destination address field, to a router, based on the routing algorithm. In this case, based on this algorithm, node A decides that it has to hand over the datagram to R1. Note that both A and R1 are on the same Ethernet network, and Ethernet only understands frames of certain format. Here is where encapsulation comes handy.

58

5. The datagram now reaches the NIC of node A. Here, an Ethernet frame is formed as shown in Fig. 3.13.

The data portion in the frame is the IP header + TCP header + datagram. The Ethernet header contains the 48-bit source and destination addresses. As we know, these are physical addresses given by the manufacturer to the NICs of the source (i.e., node A) and destination (i.e., router R1) computers. The problem is how do we get these physical addresses?

Fig. 3.13 Ethernet frame

6. The NIC at node A has to move 48 bit physical source and destination addresses into the Ethernet frame as well as compute the CRC. The source address is that of NIC of A itself, which the node A knows. The problem is to get the same for the destination, which is the NIC of router R1. To get this, an Address Resolution Protocol (ARP) is used. The Ethernet frame now is ready to be transmitted.

7. Now, the usual CSMA/CD protocol is used. The bus is continuously monitored. When it is idle, the frame is sent. If a collision is encountered, it is resent after a random wait and so on. Finally, the frame is on the bus. While it travels through various nodes, each node’s NIC reads the frame, compares the destination address in the frame header with its own, and if it does not match, discards it.

8. Finally, when it matches with that of the router R1, it is stored in the memory of the router’s NIC. The NIC of the router verifies the CRC and accepts the frame.

9. The NIC of the router removes the Ethernet frame header and obtains back the original IP datagram, as shown in Fig. 3.14, and passes it on to the router.

Fig. 3.14 Original IP datagram

10. Now, the router checks its routing table to learn that if the final destination is G, the next hop for this datagram is router R2. To use the routing table, the destination 32-bit IP address has to be extracted from the IP header, because the routing tables contain the destination IP address and the next hop to reach there. In this case, the next hop is router R2.The router R1 knows that there is a X.25 WAN connecting it and R2. In fact, R1 and R2 both are on this X.25 WAN (though R1 is also on the Ethernet LAN).

11. At this stage, the IP header + TCP header + data, all put together, is treated as data again for X.25, and a header for X.25 is generated and a datagram in the X.25 format is prepared. The datagram header contains the source and destination addresses, which are those of R1 and R2, respectively, as our

59 intention is to transport the datagram from R1 to R2, both on the X.25 network, wherein the datagram also now is in the X.25 format. Router R1 then releases the datagram on to the X.25 network using ARP as before. It looks as shown in Fig. 3.15.

Fig. 3.15 X.25 frame

12. The X.25 network has its own ways of acknowledgement between adjacent nodes within the X.25 network, etc. The datagram travels through various nodes and ultimately reaches the R2 router.

13. R2 strips the X.25 datagram of its header to get the original IP datagram, as shown in Fig. 3.16. R2 now extracts the source and destination 32-bit IP addresses from the IP header.

Fig. 3.16 Original IP datagram

14. R2 is also connected to the Token Ring network. Now, R2 compares the network id portion of the 32-bit destination IP address in the above datagram with its own and realizes that both are the same. As a consequence, it comes to know that computer G is local to it.

15. R2 now constructs a Token Ring frame out of this IP datagram by adding the Token Ring header, as shown in Fig. 3.17. The format shows 48-bit physical source and destination addresses. These are now inserted for those of R2 and G respectively, frame control bits are computed and the Token Ring frame is now ready to go. For this, again ARP is used.

Fig. 3.17 Token Ring frame

60

16. R2 now directly delivers the Token Ring frame to computer G. G discards the Token Ring frame header to get the original IP datagram.

17. In this fashion, all the datagrams sent by computer A would reach computer G. The IP header is now removed (it has already served its purpose of transporting the IP packet). And the datagrams only with TCP header are handed over to the TCP layer at node G. They may reach out of sequence or even erroneously. The TCP software running in computer G is responsible for checking all this, acknowledging the correct receipt, or requesting for re-transmission. The intermediate routers do not check this. They are only responsible for routing. Therefore, we say that IP is connection-less but TCP is connection-oriented.

18. Ultimately, all the datagrams are put in sequence. The original message is, thus, reconstructed.

19. The message is now passed on to the appropriate application program such as email running on computer G. The TCP header contains the fields source and destination socket numbers. These socket numbers correspond to different application programs—many of them are standardized, which means that given a socket number, its corresponding application program is known. These socket numbers are used to deliver the datagrams to the correct application program on computer G. This is important because G could be a multi-programming computer that is currently executing more than one application. So, it is essential that the correct application program receives these datagrams.

20. The program on computer G can process the message, e.g., it can inform the user of that computer that an email message has arrived. Thus, the user on computer G can then read the email message.

We will notice the beauty of TCP/IP. Nowhere are we doing exact frame format or protocol conversion.

TCP/IP works on all the nodes and routers, but Ethernet works as it did before. It carries the frame in its usual fashion and follows the usual CSMA/CD protocol. The same is true about X.25 and Token Ring. The point to note is TCP/IP fools all these networks and still carries a message (email, file, Web page, etc.) from any node to any other node or any other network in the world!

Therein lies the beauty of TCP/IP.

3.6 THE CONCEPT OF IP ADDRESS