Protocol Layers

Now let us look at what lies within a frame.

Generally, network communication is performed using protocol stacks. The most popular stack is the IP or Internet stack. Others include the Netware Stack and IBM's SNA. When data is transmitted, it is passed down through a stack of agents. Each agent is responsible for managing certain communication functions such as making sure the data is sent to the right place, ensuring it arrives intact, ensuring that shipments are delivered in the right order, and so on. In order to accomplish its designated tasks, each agent prepends its own protocol header to the data and then passes it down to the agent at the next layer. Some agents add a trailer as well, typically to hold a CRC or other frame check. Generally, the higher-layer agents are implemented in software and the lower-layer ones in hardware. On receipt, the opposite happens: each layer's agent strips off its own protocol header (and trailer if there is one) and then passes what remains to the appropriate agent at the next layer up.

So what we find inside a frame is a sequence of protocol layers. We have a very specific use for the term "layer": it refers to such a protocol layer within a frame. From this point on in this manual we will use "layer" strictly and solely in this sense. Or, if we do use it in another sense, then we will make that very clear in the context.

If you are familiar with the term layer as used in the ISO seven-layer model then we must emphasize that our meaning, while certainly related, is significantly different. Most important is that we use the word without any implication as to functionality. We do not assume, for example, that if the first layer is a data-link layer then the second layer must be a network layer. If people want to use a data-link protocol on top of a presentation-level protocol, or a zeeblonking protocol over a freezewhacking one, it is all the same. In other words, the protocol analyzer does not care what your protocols do or how they are arranged ‐ it just decodes them. Indeed, thanks to practices like encapsulation and tunneling, it is quite legitimate to see a frame that contains protocols layered like the one on "Protocol Layer Diagram".

How protocols are layered is not important to the protocol analyzer. The analyzer needs to know the beginning and ending of each layer and the protocol used at each layer. Knowing where each layer begins and ends is easy because, in most cases, one layer begins immediately after the header of the previous layer and continues to the end of the frame. We have ways of handling exceptions such as when there is padding in front of a layer.

Determining the protocol used at each layer is generally easy as well. For a start, the first layer is usually fixed. As for the rest, in some cases there is a fixed sequence. In most other cases the header of one layer includes information that identifies the protocol at the next layer.

The "Protocol Layer Diagram" also serves to illustrate what we mean by "layer", "header" and "payload". A protocol header contains control information and is what the decoder for the protocol primarily decodes. The data carried by the protocol is called its payload. Generally, the payload of one layer comprises the next layer. Matters get a little more complicated when trailers are involved; then the payload of a protocol starts after the header and continues only up to the trailer, not to the end of frame.

There are communication links on which only one protocol is used. This would be the case when a protocol such as ZMODEM or Kermit is used in isolation. Then, we would say, the stack is one-layer deep and that a frame and a layer are essentially the same (unless there happens to be padding at the end of the frame).