Figure 1.7-1: Taking an airplane trip: actions
Before attempting to organize our thoughts on Internet architecture,
let's look for a human analogy. Actually, we deal with complex systems
all the time in our every day life. Imagine if someone asked you
to describe, for example, the airline system. How would you find the structure
to describe this complex system that has ticketing agents, baggage checkers,
gate personnel, pilots and airplanes, air traffic control, and a worldwide
system for routing airplanes? One way to describe this system might
be to describe the series of actions you take (or others take for you)
when you fly on an airline. You purchase your ticket, check your
bags, go to the gate and eventually get loaded onto the plane. The
plane takes off and is routed to its destination. After your plane
lands, you de-plane at the gate and claim your bags. If the trip was bad,
you complain about the flight to the ticket agent (getting nothing for
your effort). This scenario is shown in Figure 1.7-1.
Figure 1.7-1: Taking an airplane trip: actions
Already, we can see some analogies here with computer networking: you
are being shipped from source to destination by the airline; a packet is
shipped from source host to destination host in the Internet. But
this is not quite the analogy we are after. We are looking for some
structure
in Figure 1.7-1. Looking at Figure 1.7-1, we note that there is a
ticketing function at each end; there is also a baggage function for already
ticketed passengers, and a gate function for already-ticketed and already-baggage-checked
passengers. For passengers who have made it through the gate (i.e., passengers
who are already ticketed, baggage-checked, and through the gate), there
is a takeoff and landing function, and while in flight, there is an airplane
routing function. This suggests that we can look at the functionality
in Figure 1.7-1 in a horizontal manner, as shown in Figure 1.7-2.
Figure 1.7-2: horizontal "layering" of airline functionality
Figure 1.7-2 has divided the airline functionality into layers, providing a framework in which we can discuss airline travel. Now, when we want to describe a part of airline travel we can talk about a specific, well-defined component of airline travel. For example, when we discuss gate functionality, we know we are discussing functionality that sits "below" baggage handling, and "above" takeoff and landing. We note that each layer, combined with the layers below it, implement some functionality, some service. At the ticketing layer and below, airline-counter-to-airline-counter transfer of a person is accomplished. At the baggage layer and below, baggage-check-to-baggage-claim transfer of a person and their bags in accomplished. Note that the baggage layer provides this service only to an already ticketed person. At the gate layer, departure-gate-to-arrival-gate transfer of a person and their bags is accomplished. At the takeoff/landing layer, runway-to-runway transfer of a person (actually, many people) and their bags, is accomplished. Each layer provides its functionality (service) by (i) performing certain actions within that layer (e.g., at the gate layer, loading and unloading people from an airplane) and by (ii) using the services of the layer directly below it (e.g., in the gate layer, using the runway-to-runway passenger transfer service of the takeoff/landing layer).
As noted above, a layered architecture allows us to discuss a well-defined, specific part of a large and complex system. This itself is of considerable value. When a system has a layered structure it is also much easier to change the implementation of the service provided by the layer. As long as the layer provides the same service to the layer above it, and uses the same services from the layer below it, the remainder of the system remains unchanged when a layer's implementation is changed. (Note that changing the implementation of a service is very different from changing the service itself!) For example, if the gate functions were changed (e.g., to have people board and disembark by height), the remainder of the airline system would remain unchanged since the gate layer still provides the same function (loading and unloading people); it simply implements that function in a different manner after the change. For large and complex systems that are constantly being updated, the ability to change the implementation of a service without affecting other components of the system is another important advantage of layering.
But enough with airlines. Let's now turn our attention to network protocols. To reduce design complexity, network designers organize protocols -- and the network hardware and software that implements the protocols -- in layers. With a layered protocol architecture, each protocol belongs to one of the layers. It's important to realize that a protocol in layer n is distributed among the network entities (including end systems and packet switches) that implement that protocol, just as the functions in our layered airline architecture were distributed between the departing and arriving airports. In other words, there's a "piece" of layer n in each of the network entities. These "pieces" communicate with each other by exchanging layer-n messages. These messages are called layer-n protocol data units, or more commonly n-PDUs. The contents and format of an n-PDU, as well as the manner in which the n-PDUs are exchanged among the network elements, are defined by a layer-n protocol. When taken together, the protocols of the various layers are called the protocol stack.
When layer n of Host A sends an n-PDU to layer n of Host B, layer n of Host A passes the n-PDU to layer n-1 and then lets layer n-1 deliver the n-PDU to layer n of B; thus layer n is said to rely on layer n-1 to deliver its n-PDU to the destination. A key concept is that of the service model of a layer. Layer n-1 is said to offer services to layer n. For example, layer n-1 might guarantee that the n-PDU will arrive without error at layer n in the destination within one second, or it might only guarantee that the n-PDU will eventually arrive at the destination without any assurances about error.
The concept of protocol layering is a fairly abstract and is sometimes difficult to grasp at first. This concept will become clear as we study the Internet layers and their constituent protocols in greater detail. But let use now try to shed some insight on protocol layering and protocol stacks with an example. Consider a network which organizes its communication protocols in four layers. Because there are four layers, there are four types of PDUs: 1-PDUs, 2-PDUs, 3-PDUs and 4-PDUs. As shown in Figure 1.7-3, the application, operating at the highest layer, layer 4, creates a message, M. Any message created at this highest layer is a 4-PDU. The message M itself may consist of many different fields (in much the same way as a structure or record in a programming language may contain different fields); it is up to the application to define and interpret the fields in the message. The fields might contain the name of the sender, a code indicating the type of the message, and some additional data.
Within the source host, the contents of the entire message M is then "passed" down the protocol stack to layer 3. In the example in Figure 1.7-3, layer 3 in the source host divides a 4-PDU, M, into two parts, M1 and M2. The layer 3 in the source host then adds to M1 and M2, so-called headers, to create two layer 3 PDUs. Headers contain the additional information needed by the sending and receiving sides of layer 3 to implement the service that layer 3 provides to layer 4. The procedure continues in the source, adding more header at each layer, until the 1-PDUs are created. The 1-PDUs are sent out of the source host onto a physical link. At the other end, the destination host receives 1-PDUs and directs them up the protocol stack. At each layer, the corresponding header is removed. Finally, M is reassembled from M1 and M2 and then passed on to the application.
Note that in Figure 1.7-3, layer n uses the services of layer n-1. For example, once layer 4 creates the message M, it passes the message down to layer 3 and relies on layer 3 to deliver the message to layer 4 at the destination.
Interesting enough, this notion of relying on lower layer services is prevalent in many other forms of communication. For example, consider ordinary postal mail. When you write a letter, you include envelope information such as the destination address and the return address with the letter. The letter along with the address information can be considered a PDU at the highest layer of the protocol stack. You then drop the PDU in a mailbox. At this point, the letter is out of your hands. The postal service may then add some of its own internal information onto your letter, essentially adding a header to your letter. For example, in the United States a barcode is often printed on your letter.
Once you drop your envelope into a mailbox, you rely on the services of the postal service to deliver the letter to the correct destination in a timely manner. For example, you don't worry about whether a postal truck will break down while carrying the letter. Instead the postal service takes care of this, presumably with well-defined plans to recover from such failures. Furthermore, within the postal service itself there are layers, and the protocols at one layer rely on and use the services of the layer below.
In order for one layer to interoperate with the layer below it, the interfaces between the two layers must be precisely defined. Standards bodies define precisely the interfaces between adjacent layers (e.g., the format of the PDUs passed between the layers) and permit the developers of networking software and hardware to implement the interior of the layers as they please. Therefore, if a new and improved implementation of a layer is released, the new implementation can replace the old implementation and, in theory, the layers will continue to interoperate.
In a computer network, each layer may perform one or more of the following generic set of tasks:
A protocol layer can be implemented in software, in hardware, or using a combination of the two. Application-layer protocols -- such as HTTP and SMTP -- are almost always implemented in software in the end systems; so are transport layer protocols. Because the physical layer and data link layers are responsible for handling communication over a specific link, they are typically implemented in a network interface card (e.g., Ethernet or ATM interface cards) associated with a given link. The network layer is often a mixed implementation of hardware and software.
We now summarize the Internet layers and the services they provide:
The Internet transport layer protocols (TCP and UDP) in a source host
passes a transport layer segment and a destination address to the IP layer,
just as you give the postal service a letter with a destination address.
The IP layer then provides the service of routing the segment to its destination.
When the packet arrives at the destination, IP passes the segment to the
transport layer within the destination.
