reference models


This post is a draft. What is a draft?

We have insofar referred to idealized, generic versions of layers, services, and protocols. But how are they, really?

You have learned in other courses that we can conceptualize communication within and between networks of systems via a model, the most famous of which is the OSI model, with its 7 layers.

The seven layers were created by following the principles of identified needed abstraction that functionalities must be unique to each layer, and that there should be a large enough number of layers so that functionalities are not thrown together in a same layer out of laziness (like the inevitable Misc categories that your note taking and knowledge management apps likely have). As with sometimes happens in academia, the model was a bit…bloated and it is not implemented today. Sort of. Models of stacks in use today are heavily based on the OSI model. They tend to be simpler.

This is not a course on networks, and you have likely already seen the ISO OSI model in another course. We will instead cover a model that is simpler than the OSI model, as we concentrate on the Internet and the WWW. Oh, also one that is actually in use, even if only partially: The Internet Protocol Suite, or TCP/IP Reference Model.

The Internet Protocol Suite

The Internet Protocol Suite, also known as TCP/IP Reference model, was designed for the predecessor or Internet, ARPANET, and is still in use today. The TCP/IP Reference Model was designed by the US Department of Defense (DoD) to connect military networks to university research networks (and later extended to other networks) allowing communication to flow through various paths in case an attacker would destroy pieces of a network.

The model features 4 layers, which correspond to layers of the OSI model, and allows some overlap happen in the uppermost and lowermost layers to cover some otherwise missing functionalities.

At the lowest part of the stack, the link layer corresponds to the OSI data link layer and provides some functionality that is described in the OSI physical layer. The US Department of Defense requirements led to the choice of a packet-switching network based on a connectionless layer running across different networks. The link layer describes what links (such as Ethernet) must do to meet the needs of this connectionless layer across different networks. The link layer is mostly an interface between hosts and transmission links.

The internet layer

The internet layer corresponds to the OSI network layer. The layer is responsible to allow hosts to insert packets into networks of any type, and to have them travel independently to the destination through different networks, if required. Order of packets is not ensured, and it is the job of higher layers to deal with this issue, if there even is the issue in the first place.

The layer defines its official packet format, which is called Internet Protocol, shortened as IP, with which you are surely familiar. The layer also defines a protocol named Internet Control Message Protocol, shortened as ICMP, which implements some of its functions. The job of the internet layer is to deliver IP packets where they are supposed to go.

Some people believe that the transport layer is always required to deliver information. This is not true: the internet layer, with IP and ICMP, is capable of transmitting data. It is just not good and useful in doing so. Need an example? Open your terminal and type:

$ ping -c 1
    PING ( 56 data bytes
    64 bytes from icmp_seq=0 ttl=56 time=18.761 ms
    -- ping statistics ---
    1 packets transmitted, 1 packets received, 0.0% packet loss
    round-trip min/avg/max/stddev = 18.761/18.761/18.761/0.000 ms

You have just transmitted information through the internet layer only, using the ICMP protocol and the IP format. The ping command sends echo request packets to a target host (, an IP that belongs to the Uni Stuttgart website) and waits for an ICMP echo reply. We sent a packet with size 64 bytes (54 bytes of data, plus 8 bytes of header) to the Uni Stuttgart Web server and received back a 64 bytes packet with a round-trip (back-and-forth) time of 18.761 ms.
Alright, the internet layer transmits, but only in an unreliable way and on a best-effort delivery. No guarantees at all. Higher levels, such as the next one, have the duty of providing reliability of service.

The transport layer

The transport layer is designed to allow peers at the source and destination hosts to allow for an end-to-end communication. Two main protocols live in the transport layer, namely TCP - Transmission Control Protocol **and **UDP - User Datagram Protocol.

TCP is a reliable, connection-oriented protocol. TCP allows a byte stream to be delivered error-free from one host to another over an internet. At the sending host, the byte stream is segmented into distinct messages (hence, packets are called segments), all of which are passed on to the internet layer (which, in turn, is unreliable and on a best-effort basis). At the destination host, the operating system process responsible for TCP reassembles all received messages into the output stream, as intended when delivered. TCP also handles flow control, to try to slow down a fast sender when messages are too many than possibly can be handled. What enables reliability with TCP is a sequencing of data. Bytes are numbered with a TCP connection, with numbers starting with a random sequence number.

UDP is an unreliable, connectionless protocol. UDP does not provide sequencing or flow control, delegating the task to the application using it (if wished). A checksum field is present in UDP, for calculating data integrity, but its use is not mandatory. These characteristics make UDP a very lightweight protocol, often used in client-server request-reply models where a quick delivery is more important than an accurate delivery.


We have seen before that IP is capable of sending packets, so why do we have UDP when IP looks very similar? One good reason is multiplexing, or, the use of ports. We wish to host more than one service at an IP address, and we do. Services on the same host, at the same address, listen to different ports, which are virtual endpoint that help the receiving end in identifying what to do with the particular packet it receives. Ports are introduced at the transport layer. Both TCP and UDP make use of ports. The application layer will very likely use this precious data, for example when deciding that your transmitted data is for transferring files (port 21) or connecting to a website unencrypted (port 80) or encrypted (port 443).

The application layer

The application layer handles “all the rest” in the stack, including session handling or presentation, which are not officially present in the Internet Protocol Suite model.

The application layer contains all the higher-level protocols that you use daily. These include, but are not limited to, file transfer protocol to send files (FTP on port 21), sending e-mails (SMTP on port 25) and receiving e-mails (POP3 on port 110), and browsing the Web (HTTP on port 80) or all their encrypted counterparts SFTP/FTPS, SMTP/TLS, POP3/TLS, and HTTPS.

An overview of data in the layers

We will see all the four Internet Protocol Suite layers in more detail, but first, a high-level overview of how data is handled in this model.

At the highest layer, the application level, data is what your application does. It might be HTTP traffic, it might be SMTP traffic, it might be something else. This is in green in the picture.

One level below, in the transport layer, data from the application layer is called TCP (or UDP) data and the transport layer is responsible to break it down and append its header to it. The TCP header related data is blue, and overall, it contains parts of application data, too.

One level below, in the internet layer, data from the transport layer is called IP data. The internet layer will add its overhead, the IP header. This is in salmon color.

At the lowest layer, the data becomes a frame and part of the link layer. The link layer is the only one that both prepends and appends its data to the existing one, frame header and frame footer. Data is ready to go over a transmission medium.

I do not use a commenting system anymore, but I would be glad to read your feedback. Feel free to contact me.