Peel the OSI Layer Model Onion
Our last two tutorials have explored the five key areas of network management and some of the classic solutions to these network management challenges.
Many of these standards and methodologies, such as the five functional areas of network management, are very academic in nature. And while they may help you evaluate the capabilities of the enterprise network management system you are considering purchasing (and, of course, make for interesting reading), they may not necessarily help you with day-to-day network management functions, such as troubleshooting an application that is running slow, or a WAN link that is down.
For that aspect, we need a more practical network management approach, which can be found in a brief review of the Open Systems Interconnection (OSI) model, first published in 1994. For us engineering types, this model provides us with a systematic method of breaking down and organizing the many functions that comprise an enterprise network into smaller pieces, which are then easier to handle. Let’s briefly review that model, and look at some example network management issues that can occur at each layer.
Physical Layer: maintains the physical and electrical connection between two endpoints, and may be implemented with twisted pair or fiber optic premises cable, a wireless LAN or cellular WAN link, or a host of other options including microware, infrared and satellite. The unit of information transmitted at the Physical layer is the bit.
Thus, if you have a single workstation with an issue, or a group of stations (such as a branch office) that you cannot reach, then an examination of the physical layer between these two points is a good starting point – the problem may be as simple as a disconnected cable or a loose connector. Physical layer tools, such as cable testers, will likely be the least expensive (and possibly most useful) items in you network management toolbox.
Data Link Layer: deals with the reliable connection and local addressing between adjacent nodes on the network, and is typically implemented on an Ethernet LAN or a T-1 WAN network interface card. This layer puts the bits from the physical layer into a specific order, known as a frame. If noise or some other aberration occurs on the link, an error control mechanism within that data Link layer frame (such as a checksum) may signal the problem.
However, just because an error occurs does not mean that you need to do something about it. For example, most VoIP frames contain 20-40 milliseconds of voice information. If only a few frames get clobbered, the humans may never notice the problem, until it gets more severe. A network monitoring system or protocol analyzer will detect those invalid frames, and give you an early warning of a problem (such as a noisy WAN link) that merits further investigation.
Network Layer: handles the routing and switching between two locations, and is almost invariably implemented using the Internet Protocol. This layer also adds another layer of addressing (the IP address) so that your station can be uniquely identified on the global network. That IP address is contained within the Network layer unit of information, called the packet.
So, if you find that you can’t call a specific region of your network, and the Physical connections have tested OK, then a scrambled address or addressing translation may be the culprit, and a protocol analyzer is going to be required to sort this one out.
Taken together, the physical, data link and network layers are often referred to as the Communications Subnetwork, as this part of the architecture is responsible for the transfer of the voice or data signals from one workstation on the network to another. And since this network may comprise a number of LAN and WAN connections, this delivery process may get quite involved. While it is certainly possible to manage and/or test each of these network elements separately, access to all of the necessary test points could be challenging. As a result, many networks use testing probes, which are deployed at strategic locations, and can report back to a central network management console on the health of that network segment.
Transport Layer: is responsible for the reliability of the end-to-end connection, and is typically implemented with two protocols. The Transmission Control Protocol (TCP) defined in RFC 793 provides the greatest amount of reliability, but at a cost of additional overhead. The User Datagram Protocol (UDP), defined in RFC 768cuts back on the reliability, but then reduces the transmission overhead. The unit of information for TCP is called a stream, while the unit of information for UDP is called a datagram. Many networks, such as those deploying VoIP, may use both TCP (to reliably setup the connection) and UDP (to efficiently transfer the voice samples).
Session Layer: provides for the establishment and termination of the communications sessions, and could be implemented with the Session Initiation Protocol (SIP) for a VoIP LAN, or with Signaling System 7 (SS7), which runs the telephone network’s signaling system for a public WAN. Signaling is a big deal, because if you can’t establish a reliable connection, you can transfer any voice or data information. Note the references above to protocols, and the need to use a protocol analyzer to sort out call establishment or disconnect procedures that do not operate as prescribed.
Presentation Layer: provides a mechanism of translating the sender’s data format into a format that could be understood at the receiver. In conventional networks, data encryption and data compression are good examples of Presentation layer functions. We use many presentation layer functions within an enterprise – in data compression (e.g. disk and tape storage), data encryption (secure transactions) and in the codec (coder/decoder) that makes the analog-to-digital conversion for your VoIP telephone. As before, this is likely to require a protocol analyzer to sort out.
Application Layer: provides functions that support the end user, such as database access, file transfers, web browsing, unified messaging, and a host of other human-oriented functions. Most of the application layer functions are buried deep within other protocols, so a device that has the capabilities for deep packet inspection, such as the more sophisticated Quality of Service (QoS) monitors, or a protocol analyzer, will be required to sort out these issues.
To summarize, the lower three OSI layers are typically implemented in hardware, and are therefore more accessible and straightforward to manage. The upper four layers are very likely implemented in software, and will require more complex tools for diagnosis and management. We’ll look at some of those tools and their functions in our next tutorial.
Copyright Acknowledgement: ©2009 DigiNet Corporation, All Rights Reserved
Mark A. Miller, P.E. is President of DigiNet Corporation, a Denver-based consulting engineering firm. He is the author of many books on networking technologies, including Voice over IP Technologies, and Internet Technologies Handbook, both published by John Wiley & Sons.