The seven layers of the Open Systems Interconnection (OSI) reference model:
|Network applications such as terminal emulation and file transfer
HTTP, FTP, DNS, SMTP, POP3, IMAP
|Formatting of data and encryption, compression
ASCII, HTML, JPEG, TIFF
|Establishment and maintenance of sessions
TLS, SSH, X.225, RPC, NetBIOS, ASP, Winsock, BSD
|Provision of reliable and unreliable end-to-end delivery. Host to host, Segments.
SSL, TCP, UDP, SPX,
|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
|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
|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
TCP Windowing issues
|Network||IP addressing problems
Duplicate IP addresses
ICMP errors or ICMP filtering
|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”)
Try to think of products to address these problems:
Network connectivity tools
Network connectivity tools