The Role Of the OSI Model

The seven layers of the Open Systems Interconnection (OSI) reference model:

7 Application	Network applications such as terminal emulation and file transfer HTTP, FTP, DNS, SMTP, POP3, IMAP
6 Presentation	Formatting of data and encryption, compression ASCII, HTML, JPEG, TIFF
5 Session	Establishment and maintenance of sessions TLS, SSH, X.225, RPC, NetBIOS, ASP, Winsock, BSD
4 Transport	Provision of reliable and unreliable end-to-end delivery. Host to host, Segments. SSL, TCP, UDP, SPX, Gateway, Brouter
3 Network	Packet delivery, including routing. Packets, logical (IP) addressing IPv4, IPv6, ICMP, IGMP, BGP, OSPF, RIP, IGRP, EIGRP, ARP, RARP, X.25, NETBEUI, MPLS, Multicast Brouter, Router, Frame Relay Device, ATM Switch, DDP
2 Data-Link	Framing of units of information and error checking. Physical (MAC, hardware) addressing, checksum IS-IS, ARP, PPP, Bridge, Switch, Ethernet, Wi-Fi, Token-Ring, FDDI, ATM, VLANS, LACP, MLPPP
1 Physical	Transmission of bits on the physical hardware. Frames, electrical signals Ethernet, Wi-Fi, T1/​T3, Optical transports such as DWDM, Repeater, wiring, hub

The OSI model can be used as a checklist. It is a reference model. It is not a design framework. It is not a guide to interconnecting systems, in spite of the Open Systems Interconnection name. The OSI model does not describe products. Step through the OSI model to review if you have attended to major aspects of interconnection.

“Which routing protocols (RIP, EIGRP, OSPF, BGP) work on which OSI layer?” answer from QSolved:

We have a fundamental problem in discovering how shall a protocol be classified into a layer? Very often, it is classified by the services it depends on. Quite logically, they must be provided already by other layers, and within our usual hierarchical models, the services are provided by the lower layers than the layer in which the protocol under dispute is located. That would, for example, place the OSPF (and RIP and EIGRP as well) into the Application Layer. However, a second way to classify a protocol is to classify it by the services it provides itself. Now, the OSPF clearly provides services to Internet layer, but not the usual “transport” service as, say, Ethernet does, but rather it provides control information on how shall the Internet layer operate. This would move the OSPF down to or under the Internet layer, maybe even to the Link layer. Clearly, the OSPF could be encapsulated directly into Link layer frames in a similar fashion to the IS-IS and it would work, so the Internet layer is not really necessary to deliver OSPF packets. Still, the Internet layer provides, for example, the addressing semantics (address formats et al.) used inside the OSPF messages… so even an OSPF placed on the Link layer (that should be agnostic about the Internet layer) needs to be Internet layer specific, at least in the addressing issues. That, in my opinion, moves the OSPF to the Internet layer, not as a user protocol used to transport user data, but rather as a support (or service) protocol used for purposes of the Internet layer itself. And this holds for all routing protocols.

The OSI model is not easily used in reverse. Given a product or technology, where does it fit in the OSI model? Is it data-link? Is it network? Is it data-link and network? Is it Session? No, its probably not Session.

Take, for example, SSL. There are persons who insist it is a Transport layer protocol, while others (scilnet.fortlewis.edu, Optimizing Network Performance with Content Switching: Server, Firewall and Cache Load Balancing) suggest it resides higher in the stack.

Consider Multi-Protocol Label Switching (MPLS). When people refer to it as a “Layer 2.5 protocol,” they indicate that the OSI reference model is of limited use as a taxonomy. MPLS directly maps to an intermediate step between the Data-Link layer and the Network Layer of the IP protocol stack, and these implementations correspond to the layers 2 and 3 of the (protocol agnostic) OSI model.

You do not develop products to map to a layer in the OSI model. For example, OSPF runs directly over IP. You develop products to fill a need, to address a problem, to fit a niche.

Use the OSI model as a checklist. Don’t try to force products into its layers. It is a reference model. Strict conformance to it as a specification should not be expected. Don’t worry about it.

For example, walk through the seven layers of the Open Systems Interconnection (OSI) reference model and try to think of the types of problems which may arise:

Application	Name resolution issues with DNS or NetBIOS names Network application issues System application issues HTTP, FTP, SMTP application issues SMB signing issues Man-in-the-middle attacks
Presentation
Session
Transport	Retransmission problems Packet fragmentation Port issues TCP Windowing issues
Network	IP addressing problems Duplicate IP addresses Routing problems Protocol errors ICMP errors or ICMP filtering External attacks
Data-Link	Improperly configured network addresses ARP table and ARP cache issues Speed / duplex mismatch (e.g., “Auto”? Don’t you require “Full”?) Wireless radio interference Excessive hardware errors (e.g., “chatter”)
Physical	Power issues Hardware failure Connector issues Cabling issues

Try to think of products to address these problems:

Application	Network simulators Traffic generators Protocol analyzers
Presentation
Session
Transport	Network simulators Traffic generators Protocol analyzers Netflow Network probes Traffic analyzers
Network	Netflow Network probes Traffic analyzers
Data-Link	Netflow Network probes Network connectivity tools
Physical	Cable testers Network connectivity tools