Autotraversal

Autotraversal is the ability of the protocol analyzer to automatically manage the transition from one protocol layer to another. It depends on a number of factors including predefined stacks and elements in decoders that identify which protocol comes next as the sequence of layers is decoded.

We have said a great deal about layers because it is important to gain a perspective on how the protocol analyzer operates. In practice though, when writing a decoder you are working within the realm of a single protocol and only need to be concerned about other layers in a couple of small and well defined contexts.

How data is divided up into frames depends on the type of communication source involved. With Ethernet, the job is done by the hardware; the Ethernet adapter sends the data to the protocol analyzer a whole frame at a time. (That, by the way, explains why every byte in an Ethernet frame ends up with the same timestamp). With bit-synchronous protocols like HDLC, the hardware also does the work, but in a different way: The receiving hardware passes data to the protocol analyzer a byte at a time with other signals interspersed to denote where frames begin and end. (In some cases, both with Ethernet and bit-synchronous links, the hardware also verifies the CRC on the frame). Finally, there are cases where the hardware is oblivious to framing and the job must be done by software. Examples are byte-synchronous protocols such as Bisync and asynchronous protocols such as PPP and SLIP.

If this business of splitting captured data into frames remains unclear to you, then picture the data bytes as shipping containers. Then, in place of frames, think of shipments ‐ a shipment is a batch of containers that are associated in some way and sent together. Just as with data, containers can be shipped in a variety of ways: by ship, truck/lorry, and railway at least. Then the Ethernet case is similar to containers being sent by rail. From an external viewpoint at least, each frame is like a train. It is very clear where one train ends and the next begins ‐ even if trains run together, you have a locomotive on the front and a caboose/guard's van on the end of each. The other cases are analogous to containers being shipped by road ‐ let us make it a one-lane road because the bytes/containers must arrive in the same order that they were sent in. Then how do we tell where one shipment ends and another starts? In the bit-synchronous case, we insert some special containers between shipments to serve as markers, or flags. These could literally have flags attached to them or they could be painted a unique color. In any case the shipper will have no trouble sorting out the shipments. In the asynchronous case, there are no external clues ‐ one has to look inside the containers to divide up the shipments. Therefore, the job typically falls to the customer (the software) rather than to the shipper (the hardware).

There are many reasons why this is far from a perfect analogy. We just hope it will help you comprehend different aspects of protocol decoding. In some cases, special software usually protocol-specific software, is required to take care of what we call "frame recognition". When the task of frame recognition falls to software, we call that software a Frame Recognizer.