A layer is simply a program or set of programs that provides services to the next higher layer and uses services of the next lower layer. A program that resides at the highest layer will typically provide many sophisticated services to the user, but most of these services are actually implemented, directly and indirectly, by the lower layers.

Because a program provides services only to the layer above it and uses services only of the layer below it, a change to any given layer will affect only the layers it interfaces with. Layering breaks a single monolithic program into parts that are isolated from one another, making the program easier to write and to change. Layering may, however, extract a performance penalty. There is some overhead associated with moving data through multiple layers, but the trade-offs are more than worth the small performance hit.

Protocol Layers

Layering applies to protocols as well as to processes. In systems with layered architectures, a process in one node communicates with its peer process in another node, such as TCP-to-TCP. Peers communicate by means of a common protocol, appropriate to the services they provide. Therefore, layers of processes have corresponding layers of protocols.

This concept gives rise in its most basic form to two layers of services and protocols. The basic service/protocol model is shown on the Layers and Services Diagram. The "service," shown between layers, represents the service interface, or where the services of the lower layer are accessible to the upper layer. This can be a function call interface or a messaging interface.

Although the basic service/protocol model has only two layers, the ideas it illustrates can be extended to an arbitrary number of layers. In fact, data communications systems typically involve from three to seven layers of services and protocols. Higher layers, nearest the user or application, depend on the services of the lower layers to get specific work done, such as transporting the data across a network.

Layering and Routing

One reason that protocols vary from layer to layer is because the services offered by each layer move from simple bit-oriented services to more complex services for application data and user interaction. However, protocols differ for another important reason: the lower layers communicate directly, across a single link, while the upper layers typically communicate with peers indirectly, that is, through intermediate links.

The protocol at the lowest layer supports simple streams of bits flowing between two points. Because the only language understood at this layer is "0" and "1," the protocol only works between peers directly connected by the physical media on which the bits flow. That is the limitation, or scope, of the lowest layer.

If communications between peers at all layers were bound by this restriction, then communication possibilities would be limited. But a program at a higher layer can indirectly request services from more than one process at the lower layers, and thus from more than one physical link

Because higher layers can pass more complex messages, they can include network addressing information, enabling users to reach nodes on other networks, and making large networks possible. Therefore, an important service provided by lower layer protocols, in any of the networking systems we will study (which are all layered), is to handle the routing of messages between computers that are not directly connected by a physical link.

What are the advantages of arranging services and protocols in distinct layers?

Protocol Stacks

Layers of protocols are often called protocol stacks or less commonly, protocol suites. As with services, the lowest layer protocol deals with bits; the highest layer protocol deals with complete data structures and units of information that are ready to be used by an application program or displayed to a user.

Encapsulation and Decapsulation

Programs and processes communicate with their peers with the information contained in protocol headers. For example, suppose a program divides a long message into shorter segments. It must somehow tell the receiving program multiple segments are being sent, and in what order they should be reassembled. One possible alternative is to modify the message, but that would require that the sender provide some portion of the message for the use of lower layers. That would make even the highest layers sensitive to the operation of the lower layers--not a good solution.

Virtually all modern communications systems solve the problem this way: the intermediate layers simply add prefixes, called headers, and in certain instances, will add a trailer to the message. This is called encapsulation, as illustrated on the Encapsulation Diagram.

The header normally contains a field specifying the length of the encapsulated message together with at least one field providing information about the message. If, for example, the message is a segment of a larger message, the header might specify the relative position of the segment in the complete message and perhaps the total number of segments.

The receiving peer program effectively removes the added information (decapsulation) after processing the message, but before passing the message on to the higher layers. We say, "effectively removes," because information from the header must be maintained as in the case of a browser sending a request to a Web server. If the header were truly removed, the IP address of the sender would be deleted, and the Web server software would not know where to send the response. In decapsulation, the original message is not disturbed, and the higher layers do not "see" the encapsulating information. This concept is illustrated on to the Decapsulation Diagram.

[ Previous Section ] [ Unit Contents ] [ Next Lesson ]