Fundamentals (of Linux Networking) - Protocol Layering
(Page 5 of 8 )

So far we’ve discussed the underlying physical hardware of a network, and in the case of an internet, the protocol used to ensure compatibility between different networks. More than one protocol exists, however. For example, take the acronym “TCP/IP.” You already know what “IP” stands for: Internet Protocol. But what about “TCP”? What about other protocols we use on our networks, such as HTTP or FTP? How do these protocols relate to each other if they’re not all the same?

It’s practically impossible to create a single protocol that can handle every issue that might be encountered on a network. Consider security, packet loss, hardware failure, network congestion, and data corruption. These issues and more need to be addressed in any networked system, but it can’t be done with just a single “super” protocol. The solution, then, is to develop a system in which complementary protocols, each handling a specific task, work together in a standardized fashion. This solution is known as protocol layering.

Imagine the different protocols involved in network communications stacked on top of each other in layers. This is also known as a protocol stack or stack. Each layer in a stack takes responsibility for a particular aspect of sending and receiving information on a network, with each layer in the stack working in concert with the other layers (see Figure 1-7).

Figure 1-7.  Protocol layers

As shown in Figure 1-7, sending information to another computer means sending the information “down” through a stack, over the network, and then “up” through the stack on the receiving node. When the receiving node wishes to send a response, the roles are reversed: it becomes a sender and the process is repeated. Each layer on each node is the same. That is, the protocol in layer 3 on the sender is the same protocol in layer 3 on the receiver. Thus, a protocol layer is designed so that layer n at the destination receives essentially the same datagram or packet sent by layer n at the source. We say “essentially” because datagrams have components like time to live fields that will be changed by each node involved in the transfer, even though the core data payload should remain identical from sender to receiver.

Protocol Layer Models

The dominating standard for a protocol layer is from the International Organization for Standardization (ISO) and is known as the Open Systems Interconnection reference model, or simply the OSI model. The OSI model describes seven specific layers: Application, Presentation, Session, Transport, Network, Data Link, and Physical Hardware. A description of each layer is shown in Table 1-5.

Table 1-5. OSI Seven-Layer Reference Model

LAYER	NAME	DESCRIPTION
7	Application	Application programs such as web browsers and
		file transfer programs
6	Presentation	Standard routines such as compression
		functions used by layer 7
5	Session	Establishes transmission control between two
		nodes, regulating which node can transmit and
		how long it can transmit
4	Transport	Provides additional reliability checks to those
		performed by lower layers
3	Network	Defines the basic unit of communication across
		a network, including addressing and routing
2	Data Link	Controls how data is sent between nodes, such
		as defining frames and frame boundaries
1	Physical Hardware	Controls the physical aspects of a network
		connection, such as voltage

Figure 1-8 shows the result of applying the OSI model to our earlier layer diagram.

Figure 1-8.  The OSI model

In practice, though, the typical protocol stack found in most networked environments today is known as a TCP/IP stack and, while perfectly compatible with the OSI model, it is conceptually different. The “TCP” in TCP/IP means Transmission Control Protocol and will be discussed later in this chapter. Just by the name alone, you can see that today’s networks require multiple protocols working together to function.

In a TCP/IP environment, the network transport is relatively simple, while the nodes on the network are relatively complex. TCP/IP requires all hosts to involve themselves in almost every network function, unlike some other networking protocols. TCP/IP hosts are responsible for end-to-end error checking and recovery, and also make routing decisions since they must choose the appropriate gateway when sending packets.

Using our OSI diagram as a basis, a corresponding diagram describing a TCP/IP stack would look like Figure 1-9.

Figure 1-9.  The TCP/IP layer model

This diagram shows a TCP/IP stack as having four layers versus the seven layers in an OSI model. There are fewer layers because the TCP/IP model doesn’t need to describe requirements that are needed by older networking protocols like X.25, such as the Session layer. Looking at our TCP/IP stack, we can see that Ethernet is our Network Interface, IP is our Internet layer, and TCP is our Transport layer. The Application layer, then, consists of the applications that use the network, such as a web browser, file transfer client, or other network-enabled applications.

There are two boundaries in our TCP/IP stack that describe the division of information among the application, the operating system, and the network. These boundaries correspond directly to the addressing schemes already discussed. In the Application layer, the application needs to know nothing other than the IP address (and port) of the receiver. Specifics such as datagram fragmentation, checksum calculations, and delivery verification are handled in the operating system by the Transport and Internet layers. Once the packets move from the Internet layer to the Network layer, only physical addresses are used.

At first it would seem like a lookup must be performed to get the physical address of the receiver when starting communications, but this would be incorrect. Remembering the gateway rule, the only physical address that needs to be known by the sender is the physical address of the destination if the destination is on the same network, or the physical address of the gateway if the destination is on a remote network.

Next: User Datagram Protocol >>
 

More Administration Articles
More By Apress Publishing

Comments On: Fundamentals (of Linux Networking)

· This article is an excerpt from the book "The Definitive Guide to Linux Networking...   >>> Post your comment now!

Buy this book...

This article is excerpted from chapter one of the book The Definitive Guide to Linux Networking Programming, written by Keir Davis et. al. (Apress, 2004; ISBN: 1590593227). Check it out today at your favorite bookstore. Buy this book now.