The Packet University

The Open Systems Interconnect, or OSI model, is a seven layer model used to properly orient applications and technologies in a way that allows them to communicate with one another.  A joint effort between the ITU-T and ISO organizations, this model is meant to categorize technical functionality into areas that are either closer to the application and users or closer to the wire.  I do not believe that it is imperative that we place every application, function or process into a strict layer of the OSI model.  I do believe that understanding this model is very important for troubleshooting, implementation and engineering of solutions.

Generally, training materials and books carve out the seven categories into strict definitions and give a couple of examples of each.  Additionally, there are specific terms given to chunks of data at each of the seven layers.  I believe that what must be understood of the model is different than what is generally taught.  Those who have studied the textbook use of the OSI model know that there are different terms used for data as it is viewed at each layer.  These terms include frame, datagram, segment and the like.  In this discussion I am using the ubiquitous term “Packet’ to describe a chunk of data at any level.  Therefore please keep in mind that I am basing this discussion on functional perspective of the model and how I use it on a day to day basis.  If passing a test is the goal, I suggest following up with the many good sites that explain relationships between each layer, the protocols and the terminology describing information viewed at that layer.

At the core of the OSI model is the concept of encapsulation and decapsulation.   Basically, information or data enters into the top of the stack and is standardized as it flows down the model.  Additionally, metadata or header information is added as it is passed down to the physical layer of the model.  The physical layer or layer on is actually the wire.  When the destination system receives this information, the reverse of this process is performed.  As the information is received and pushed back up the stack on the receiving system, ultimately the information is in a format that can be interpreted by an application or possibly a user. 

This abstraction allows application developers the freedom to develop applications for multiple lower layer protocols without actually understanding the packet generation process.  Imagine where technology would be if these developers had to fully understand this process and build packets to the wire.  A simple IP address change, or even a NIC card replacement (MAC Address Change), may require an application modification.  The OSI model allows some level of abstraction between these different responsibilities.  It also allows for more consistent behavior and provides a roadmap for troubleshooting.

I used to think that this should be an easy concept to illustrate.  By using our postal system I thought one could demonstrate the encapsulation and decapsulation process.  This can closely map to the OSI, but there are some differences.

This example oversimplifies the OSI model.  For example, this does not include a post office that may sit between the two destinations.  It also does not include a depiction of multiple towns, or an apartment complex with a single location of many drop boxes.  Let’s first think through these examples and see how they relate to message delivery in a network.

I am not that familiar with the processes of the postal system.  However, it seems logical to me that in its infancy there were likely cases of direct delivery.  For example, someone on Elm Tree drive sends a message to someone on 2^nd Street.  To lighten the load in the mailbag, the delivery person might not take the message to the post office, but simply drop it in the recipients drop box with the rest of his or her mail upon arrival to that drop box. 

This may not be proper protocol for the post office and it does not scale very well due to the lack of structure and infrastructure.  This is similar to packet delivery at layer one.  A packet is broadcast out and is not required to go through a switch.  There is one main difference with this, and that is the postal service employee decided where the message should be delivered.  When comparing this to CSMA/CD broadcast Ethernet, the packet is broadcast to all points and the proper endpoint makes use of the message.  In other words, address verification becomes the responsibility of the recipient, whereas with my postal service example, the carrier still performed the address verification.

Maybe as the Postal System matured, it was decided to incorporate some standards and policies.  One of these policies may be that there should be no direct delivery and all deliveries must pass through the post office.  One driving factor may have been so postage could be audited and canceled with a postmark.  Previously, the delivery person may have known where John Smith lived.  Since there may be many John Smiths within the service are for the post office, a street address is now required and will be inspected by the post office for routing to the correct delivery person.  This is similar to how switched Ethernet works.  All packets go to a switch so they can be routed to a port that serves the destination MAC address.  There is no reason for every machine on the network to see the packet and it would be inefficient and insecure to broadcast it out in that manner.

A parallel can also be drawn between a routed packet and a message that goes outside of the service area for the local post office.  The local post office will likely examine the envelope and notice that the zip code is not one that they server.  They may route it to another local post office or send it to a regional distribution center.  This could potentially happen more than once, but should provide the most efficient path to the recipient from the perspective of the Postal Service.  In a routed network, a packet that is destined outside the local LAN or VLAN will pass through one or more routers.  Each host or router along the way may have a specific next hop defined or they may route to a default gateway.  In each case the intermediary hops will de-encapsulate the packets to the point necessary for routing. 

In the case of layer three routing, IP for example, these packets move up and down the lower three layers of the OSI model each time they pass through a router.  To be more specific, layers one and two are peeled away to expose the layer three information.  When the packet is routed, those bottom two layers are added back with the pertinent information from the perspective of this router.  In other words the layer two addressing will be different at this point and at layer one, the physical connection may be different as well.

From the above diagram, it is easy to see that it depends on what type of device is handling the packet; there is a different amount of decapsulation and re-encapsulations.  If the packet is passing through a layer two device, or a switch, it is basically peeling off the physical characteristics and examining the data link headers.  This allows the switch to make the decision as to the output port and apply that port’s physical characteristics to the packet.  If a packet passes through a router, the physical and data link attributes are removed and the layer three headers are examined.  This allows the router to make next hop routing decision.  In this case, the next hop information will ultimately include the proper layer two destination information and physical port for egress.  This may be a MAC address and an Ethernet port, or it could be a DLCI number and a serial port using Frame Relay encapsulation. 

I know there are those reading this that would be quick to argue that the next hop is an IP address in today’s IP based networks.  While I agree with the logic, the next hop address is never in the actual packet.  The next hop address is an IP address from the routers perspective.  However, the router only uses this information to determine the egress port and what layer two information to insert into the packet.  This information is added onto to the packet and it is forwarded out the proper interface.

Returning to the discussion of the model, my Postal Service analogy begins to break down at the fourth layer, or the Transport Layer.  This layer has less to do with transporting the information from end to end, but defining rules around the behavior of this information.  For example, a connectionless protocol like UDP will not typically expect anything in return.  An example is an application logging to a syslog server over UDP will simply send out these messages and expect nothing in return.  If the message is dropped for any reason, there will be no way the sender will know about it.  If the application and server used a connection oriented layer four protocol like TCP, there is a defined behavior with acknowledgements.  This would allow the TCP/IP stack of the sending host to detect and resend the message.

The remaining upper three layers have much more to do with compatibility.  To demonstrate these, I would like to use the example of browsing to a web site.  When a user opens a web site with a web browser, this application is formatting it in and presenting it to a user.  This is a function in the application, or seventh layer, of the OSI model.  If the user chooses to view source on the web page, the user will see some information that is more difficult to read than using the main browser application.  This is typically ASCII information presented with HTML markup and would be considered to reside in the presentation or sixth layer of the OSI model.  If it were possible to see how the HTML was requested on a web site, a series of GET requests and responses would be seen.  This is the HTTP protocol and resides at the fifth or session layer of the OSI model. 

The reason that most technicians look at packets is to troubleshoot an issue or to better understand how something works.  Understanding this model helps understand how to interpret packets in a packet sniffer and aids in the troubleshooting process.  Some people may choose to begin troubleshooting at one end or the other of the model.  In any case, it is important to start at some point and understand how information is passed between layers.  When interpreting information in a packet sniffer, it may be only possible to see the layers between the Data Link Layer and the Presentation layer.  It is impossible to see the actual physical layer modulation of bits on the wire without something like an oscilloscope.  Additionally, it is impossible for a packet sniffer to format the information exactly as it will be in an application.

There are those reading this in disappointment because it did not help them memorize how protocols map to corresponding layers.  Additionally this did not help clarify what the correct terminology is for data units at this layer.  However, the intent of this article was to confirm the abstraction of this model and demonstrate the encapsulation and decapsulation of data as it moves between processes and through the network. 

When troubleshooting issues on a network, the concepts introduced by the OSI model will more efficiently direct technicians and engineers to the root cause of the issue.  Additionally, it will lead to greater understanding of the network and systems as each issue is worked through.  From an analytical standpoint it is extremely important that the complex concepts of today’s networks be compartmentalized in order to understand the interprocess communication.  However, we must take care not to over emphasize the need to define a strict layer for each process.  It is entirely possible that a process or protocol could combine the functionality of multiple layers.   In other words, it is important that we understand the purpose and intent of the OSI as a model and not a strict template requiring absolute adherence.

---