2 The TCP/IP Model and the Protocol Suit

Prof. Bhushan Trivedi

Introduction

In this module, we will look at the TCP/IP model in little more detail. We will look at protocols run at each of the layers and how actual communication process takes place between communicating computers.

The TCP/IP Protocol Stack

The TCP/IP protocols suite includes many protocols at the application layer (SMTP or Simple Mail Transfer Protocol for emailing, HTTP or HyperText Transfer Protocol for browsing the internet, FTP or File Transfer Protocol for downloading and uploading files, Telnet for remote login etc.), three protocols at transport layer (TCP, UDP (User Datagram Protocol and SCTP or Stream Control Transport Protocol), and one protocols at network layer (IP). The TCP/IP model does not define any protocol below IP. However, IP cannot work without having support from beneath and in a way assume that there is some interface that helps IP to communicate with the host (hosting device, i.e. mobile phone or laptop or desktop). The host usually has a network card installed on it, which works as both, the data link and the physical layer. For example, the Ethernet card that we use is capable of constructing frames called Ethernet frames which are a job of a data link layer while the mobile phones usually have Wi‐Fi adapter as part of it which can construct Wi‐Fi Frames (which are very different than the Ethernet frames) and send them as well as receive frames from other senders. Laptops usually have both Ethernet adapter as well as Wi‐Fi adapter. In fact, when the TCP/IP protocol stack indicates that the IP is the final protocol in the stack, it is assumed that it can and should work with any protocol below. Thus both mobile phones, as well as desktops, use different interfaces to run the same set of TCP/IP protocols above them.

Closely observe the figure 2.1. it describes the TCP/IP model as well as a protocol stack. The stack describes the protocols runs at various layers starting from application to the network. The word –Any‐ indicates that the TCP/IP standard does not have any specific protocols for those layers and any protocol can work there. In the real world many protocols like Ethernet for wired communication, 802.11 (Wi‐Fi), 802.16 (Wi‐Max), LTE (4G) etc. for wireless are possible to be used at those two layers.

Though we have introduced the TCP/IP model and in a way, the protocol stack, we will elaborate more about both of them in this module. We will start with the notion of connection. Let me remind you that the TCP/IP communication is based on connection‐ oriented or connectionless service over connectionless delivery mechanism. For that, let us understand the notion of physical and logical connection.

The physical and the logical connection

The physical connection is what we are used to. We connect Ethernet cable to our computer or laptop to connect to the network. We call that physical connection. Similarly, we may connect to a Wi‐Fi network by turning on a specific adapter. Even in that case, the connection, in networking parlance, called physical connection. When we discuss connection in TCP/IP parlance, we do not mean physical connection, we mean logical connection. Let us now understand what do we mean by a logical connection.

Logical connection

When a sender wants to communicate with the receiver, he sends a request. The receiver, if willing, responds back positively. When this happens, a logical connection is said to be established. When this does not happen, the logical connection is not established. When a communication process happens after establishing a logical connection, it is said to be connection‐oriented while otherwise is called connectionless.

In the case of a telephone connection, when the caller dials a number, the process initiates a request which is sent to the other end. When the receiver receives a ring, it is said to receive the request. The receiver may decide to pick up the phone or disconnect it depending on his choice. When the receiver picks the phone up, the positive response to the connection request is said to reach the caller. Both of them now can communicate. The connection‐oriented connection is established exactly in that fashion. The sender sends a connection request which the receiver may respond back positively or otherwise. If the receiver accepts that request, the connection is established and communication (bi‐ directional) can proceed further. Any one of the communicating parties can initiate closure of the connection which the other party honors and the connections gets closed.

Connectionless connection phrase seems ironic but it means the connection where the process of establishing logical connection does not take place. In this case, the physical connection exists and used for sending and receiving data but there is no connection establishment or release.

Pros and cons of connection‐oriented connection

When we have a liberty of establishing connection beforehand, there are a few advantages.

They are in order.

1. When a connection is established, an additional query can be fired to the recipient and intermediaries about their capability to handle the quality communication. For example, you can ask if all of them can sustain 1.5Mb data flow or can guarantee only 1 out of 100 frames lost or frames cannot be delayed beyond a point and so on. Thus QOS (quality of service) can be guaranteed. In case the router cannot provide a typical guarantee, the sender may decide to choose another router which can.

2. The connection provides consistent service throughout. As all routers are informed and they have promised, it is possible to predict the load and provide communication service consistently throughout the connection. On the contrary, in connectionless connection, one cannot predict the load and consistency is impossible to provide.

3.When a router is over‐occupied, it is likely to drop packets. Over‐occupancy, because of pre‐booking, is reduced and thus the communication is more reliable in case of connection‐oriented connection.

The biggest problem of connection‐oriented connection is that it is not possible to change the route in the middle of the connection. If a router or a line goes down, the connection is just aborted. We have seen in the previous module that connectionless connection provides autonomy of routers and thus preferred.

However, a smart move by the TCP/IP protocol designers is to provide Connection oriented service over connectionless delivery mechanism which we looked at in the previous module. The TCP and SCTP protocols, running at the transport layer, provide connection‐oriented service to the applications running on top of them. TCP, in turn, take services of IP, which works at the network layer. IP is connectionless and thus provide autonomy to routers.

Virtual circuit

The sender and receiver may be connected in few different ways. In landline telephone lines, they are connected by a dedicated line, which remains unutilized when the callers pause or do not talk. In the case of SMS, the line is only utilized when it is being sent. The first case is known as circuit switching where the complete circuit is occupied beforehand. The SMS like communication is normally known as packet switching as it just sends packets over the line. Only the portion of the line where the packet is being transmitted is occupied and the rest is not used. The Internet, here also, provides a best‐of‐the‐breed kind of a solution. For delivery, IP is connectionless so does not occupy the complete communication line beforehand and thus saves on bandwidth and cost. (that is why VOIP calls are cheaper).

The TC P provides a circuit‐lik e connection to the ap plications. For example, a brows er sends URLs a nd receives web pages, FTP clien ts uploads, and down load files, telnet clien t sends commands and re ceives responses as if connected to the serv er by a direct connection. This feel is a chieved by TCP. That is why it is said to provide a virtu al circuit. T he circuit is virtual as it is not actual ly existing but the ap plications a re given th at type of service. Th ere are many r outers in be tween but TCP hides that information to th e applications on either side.

The IP neither provides a circ uit switchi ng nor a vir tual circuit switching. It follows a packet switchi ng approach. In this ap proach, th e IP sends a nd processes packets without th e notion of the path. Each packet ca n take an altogether different path than its predec essor or successor.

Layers and services

The layers of TCP/IP stack ca n also be looked from the point o f view of t he service provider and us er. The arch itecture is designed i n such a wa y that eac h layer prov ides service to the layer a bove and take service f rom the la yer below.

Figure 2.2 indicat es the idea . The IP r unning at the network layer, for example, provide service to protocol running at the transport layer, TCP, UDP or SCTP.

Let us try to see h ow TCP/IP s tack is designed on this basis. Anything runn ing on the last two layers provides t wo services to the TC P/IP protocol stack, framing (d ata link lay er) and sending the bits a cross (physical). The IP decides t he next nei ghbor and uses this se rvice to send p ackets to n ext immedi ate neighb or. IP can c hoose betw een multiple neighbo rs based on its routing table informati on. IP is also capable of generating routing table infor mation. For tha t, IP deplo ys some protocols lik e Distance Vector or Link State which we do not discuss right now.

TCP ta kes these s ervices fro m IP to p rovide con nection‐ori ented, relia ble service  to the application. If the application does not demand such services, they may prefer to use UDP which in turn take the same services from IP. Applications, like SMTP (for mailing) or FTP (for file transfer), take reliable service from TCP, while some other applications like DNS (Domain Name Service) use UDP.

Interconnecting networks

The idea behind designing TCP/IP was to provide interconnection between networks. When the networks who are using TCP/IP are connected to each other, one would like to ask, at which layer are they connected? A rough architecture of the Internet can be drawn as figure 2.3. Each user feels that the network is connected to the Internet which is a cloud‐like system. Every other network is also connected with it and so it is possible to communicate. This is an abstraction to the actual architecture depicted in figure 2.4. where each network is connected to other networks by a chain of interconnected routers which provide communication paths between networks. The packets sent from the network sender belongs to, is reached to the network receiver belongs to by intermediary routers. The packets are relayed by routers to other routers along the path based on a decision made by network layer of those routers.

In other words, sender’s network and the first router along the path (usually the router from the ISP), is connected by their respective network layers and same is the case with all other routers along the path.

How the routers relay the traffic in the TCP/IP model? How the layers’ function in the process of delivery of packets? Let us try to understand. Observe the figure 2.5. We take a case where there is a sender as well as a receiver who are connected with two intermediary routers. The sender’s application layer generates some traffic based on some application and that traffic needs to be sent to the receiver via these two routers.

The application generates some data and informs the transport layer TCP that it wants to connect to the receiver. Application layer encapsulates the application layer data in some form (a URL or Uniform Resource Locator in case of HTTP, a command in case of telnet, a chunk of a file in case of FTP etc.), and pass it on to TCP. TCP encapsulates that data in its own form and adds its own headers, including many things but most notably, indicate the application which generated the data and thus application which should receive data at the other end1.

When that data is sent from TCP to IP, IP looks at the final destination value in the packet itself and decides which is the nearest next router along the best path. It finds the router based on its routing table value. The data link layer constructs the frame with the sender as sending machine and receiver as the first router. The data link layer passes the frame to physical layer then. The physical layer transmits that frame to first router. The physical layer of first router, upon receipt, passes it up to its data link layer. When it reaches to the

1 How the transport layer decides the size of the segment? Usually it forgoes the layer independence in this case, learn from the physical layer what is the size it can carry, for example, Ethernet can carry 1500 bytes, and decide its own size based on it. For example, for Ethernet it decides it to be 1460 bytes so when TCP header of 20 bytes and IP header of 20 bytes are added to that, it fits exactly in the Ethernet frame.

network layer (of the first ro uter), it fin ds the final destinatio n is not itself, and thu s look in the routing table. Its routing table indica tes that it should pas s it on to th e second router to send it to the receiver.

So it does by constructing t he frame accordingly and passing it to its physical la yer. The physical layer of first router then transmits it to physical layer of se cond router. Same process happens at the seco nd router and the pa cket eventually reach es to the network layer of second router. The second ro uter’s net work layer decides t hat the rec eiver is directly connected and so instructs the data link layer to co nstruct the frame accordingly with sender being the secon d router and receiver being the final router. Once that is done, the phy sical layer of the seco nd router sends it to the physic al layer of t he receiver. When the receiver’s network layer receives the packet, it looks at the destin ation address and unlike the first and the second router, it understa nds that t he packet is destined for this machine only. The IP opens t he IP packet, extracts the TCP seg ment sent by the sen der pass it up t he TCP running on the receiver. TCP verifi es that segment first to be without any errors. It also loo ks at the important information about th e application for which it is destined (or even UDP, whatever the c ase may be). The TC P of the receiver then passes received data to t he respective application. The d esigners have purpos efully named data units at different layers differ ently. The application data, once transport layer’s headers are added at the transport layer, becomes a segment . The segment, when reach the network layer a nd augmented with n etwork lay er headers, it becomes a packet. The packet, when encaps ulated in da ta link layer header as well as th e trailer, it is known as a frame.

We can see the critical role o f IP to interconnect networks and TCP to help transmit the data irrespe ctive of th e type of network (t he network under consideration may be wired or wireless and follo w different protocols), irrespectiv e of the dat a link and physical layers (one may use fast Ethe rnet which provides 100 Mb, an other may provide 10G Etherne t which provides 10 Gigabits per second, and so on), irrespective of the way physical layer converts bits into signals and vice versa, irrespective of the way data link layer frames the data and so on. Let us reiterate what we claimed in module 1. The TCP/IP protocol is designed in a way that it does not assume anything about the data link or physical layer and thus any network beneath does not make any different to their functioning.

Interaction between peers

Another important aspect of the TCP/IP model is that the peers need to communicate to each other. The same layers of sender and receiver are called peers. For example, physical layers of both communicating parties are peers, TCP of both parties are peers and so on. We have already discussed how the TCP/IP model provides an abstraction that applications on either side assumed talking to each other directly. Rather, this is the feature for all layers. Each layer of the sender communicates with the respective layer of the recipient. For example, take the case depicted in figure 2.5. The physical layer of the sender and the first router must communicate with each other to decide which types of signals are sent, when the communication (the frame) begins and when ends, etc. The data link layer of the first router should be able to read the frame constructed by data link layer of the sender and carried by the physical layer, find if there is any error, must check for any instruction by the other end data link layer and take appropriate action if need be. For example, in Wi‐Fi networks (technically 802.11) the sender might say that there is a request to transmit which the current data link layer must provide with a positive or a negative response. We have already seen how sender’s network layer uses the routing table. How is this routing table generated? The network layers of neighbors communicate with each other in one way or other depending on the routing protocols used. They send routing updates which the other end must respond with. Based on responses from the peers, the routers construct this routing table. Similarly, transport layer entities communicate with each other. The difference is, the sender’s and receiver’s transport layer communicates with each other, intermediaries transport layers do not come into the picture. Application layer entities also communicate in the similar fashion. Sender’s client communicates with the receiver’s server and no other application layer of intermediaries take part in the process. That is why transport and application layers are called end‐to‐end and the protocols that they deploy are also known as end‐to‐end protocols. Other layers communicate to next immediate intermediary and thus they are called hop‐by‐hop communicating layers and their protocols are also called so. The transport layer entities must communicate each other for all end‐to‐ end requirements like flow control between a faster sender and slow receiver, maintain quality and security of communication between applications, provide sequence and order to data being communicated etc. The CO over CL service TCP provides is an example of such a service. For providing such services, both sending and receiving transport layer entities must communicate with each other. For example, when the receiver TCP responds back with acknowledgement of the data, the sender TCP layer can send the next bunch of data. When the receiver TCP layer says it cannot accept any more segments for the time being, the sending TCP layer should stop sending for a while.

An application layer communication between peers may clarify above point. An FTP client sends a few commands (as user types them) to server for example, get <a file name> or put <a file name> and server responds back as per the command. Similarly, an SMTP client sends information related to mail and the server responds back. A web client (browser) sends a URL and the web server sends the page back. This application layer processing is more obvious as it happens under our (the user’s) instruction.

Please note that such communication, in much more unreadable form, happens between all peers. When peers communicate with each other, it is generally known as a protocol. Some authors also call the communication, between layers above or below, a protocol while some other authors call them interface. However, we will call communication between peers as protocol. Thus TCP protocol is about communicating between two TCP peers. An Ethernet protocol is about communication between two Ethernet cards and so on.

Please also take a note of a difference between a process and a protocol. A TCP process is an OS process executing in the memory of the computer while a TCP protocol is a method of communication between two TCP processes.

Protocol

A protocol is how peers communicate in an unambiguous way. When I ask a question, my student may raise his hand if he knows the answer. When I select him, he may respond. When you meet your friend in the morning, you say “Hi Buddy” or “Good Morning” and he responds back accordingly. When we go to a movie theater, we render money and get tickets, show them to the doorkeeper to have an entry and so on. These are protocols or the rules that govern our behavior in a typical situation. The whole networking environment is governed by such protocols. Here are basic features of a protocol.

1. There are multiple parties involved, usually two, we call the imitator of the communication as sender and respondent as the receiver but once the introduction gets over, either of the parties can send and receive.

2. The sender knows what to send and in which sequence. The receiver also expects the message to come in a typical sequence. This synchronization is very crucial. When the sender is sending a packet size for example, and the receiver understands it to be the size of the image that follows, a chaotic situation arises. Both of the communicating parties must have an unambiguous way of knowing what is being sent and received.

Let us walk through an example of SMTP to understand the concept better. The SMTP (Simple Mail Transfer Protocol) is used to send and receive emails.

The following snippet shows a communication between an SMTP client (denoted as C) and a server (denoted as S). The comments written inside the braces are not a part of the communication. They are inserted to help the reader know what is actually happening.

S:220 GLSICT.ORG ready (Server, i.e., GLSICT.ORG says, I am ready to accept emails.)

C:  HELO GLSlCA.org (The client replies I am GLSICA.org and would like to send/ receive mail from/to you, i.e., GLSICT.ORG)

S:250 OK (No objections. You can send/receive emails.) C:MAIL FROM: [e-mail]

S:250 OK (Fine! This sender is not blacklisted! I can accept mails from him!) C: MAIL TO: [e-mail]

S:250 OK (Fine! This user exists at this server! And can accept mails on his behalf!) C:MAIL TO: [e-mail]

S:550 No such user (I do not know this user, as there is no such mailbox.)

The SMTP uses some specific commands such as HELO, MAIL FROM, MAIL TO, etc. which are known to both the client and the server. The sequence is also important. Only when the client says MAIL TO, the server responds with either OK or NO SUCH USER.

Standardization bodies

It is important to have the protocols standardized by authorized governing bodies. The Internet community has clear‐cut mechanisms to standardize protocols. The Internet protocols are described by so‐called RFCs (Recommendation for Comments). The SMTP example we have seen above is described according to RFC. IETF (Internet Engineering Task Force) and IAB (Internet Advisory Board) are the two governing bodies which control Internet standards.

The ISO or International Standards Organization is the main body for international standardization. It includes ANSI (American National Standards Institute) which is a member of ISO. All national standardization bodies come under the control of ISO. The OSI standard was from ISO.

The ITU‐T (International Telecommunication Union’s standardization sector) is into standardizing telecommunication standards. The 56‐bit modem was standardized by ITU‐T.

The IEEE (Institute of Electricals and Electronics Engineers) society is another organization having its own standards which are widely recognized. It is the largest professional organization of its kind. The 802 standards developed by IEEE define the protocols used in different kinds of LANs including the Ethernet and 802.11 (Wi‐Fi). Apart from these, there are other standardization bodies like Wi‐Fi and Wi‐Max for device manufacturers for wireless networks and W3C or World Wide Web Consortium for WWW standards.

Summary

This module introduced the TCP/IP protocol suit, the protocols running at different layers of this protocol suite and the need for each layer. The interaction between peers and how protocols especially SMTP at application layer works is explained.

References

1. Computer Networks by Bhushan Trivedi, Oxford University Press
2. Data Communication and Networking, Bhushan Trivedi, Oxford University Press