About this interactive
The OSI model is the spine of the Protocols and Standards module, and the module is explicit that it is a reference framework rather than a rigid specification — a way of organizing what protocols do so that different suites can be compared, and so that one layer can be replaced without disturbing the rest. This activity tests the one thing the framework is useless without: the order. A student who can recite all seven names in the wrong sequence has learned a word list, not a model. The cards deliberately do not carry layer numbers. If they did, the exercise would collapse into sorting integers, and the student would never have to touch the knowledge the objectives actually name. Each card gives the layer's function instead, which forces the ordering to be reasoned from what the layer does — exactly the reasoning the lessons build. The chain runs like this, and it is worth stating as a chain rather than as seven separate facts. The physical layer can move a signal but has no idea who it is for; it defines the cabling, the connectors, and the electrical or optical encoding of one bit, and it is the layer whose Ethernet preamble never appears in a Wireshark capture because the network card discards it before frame processing begins. The data link layer adds the ability to say who: it frames those bits and delivers them to the next device on this link by MAC address, using Ethernet in the common case and PPP or HDLC on other link technologies. Its reach stops at the link, which is why a router strips this header off at every hop and writes a new one for whatever the next link speaks. The network layer solves that limit with an address that survives the whole journey — IP — and with routing that carries a packet across interconnected networks toward its destination. It reaches the far host but not the right program on it, and the transport layer answers that with port numbers, along with the segmentation and sequencing that let a large transmission be sent in pieces and reassembled, and, where TCP is chosen, the three-way handshake, retransmission of lost segments and flow control. The top three layers are the ones students find hardest, because the module's own lessons spend less time there and because the TCP/IP model collapses all three into a single Application layer. The honest framing is that the collapse is evidence, not a contradiction: modern protocols like HTTP genuinely do not separate session and presentation handling, which is why a four-layer model describes real traffic more comfortably. Within OSI, though, the three remain distinct jobs. The session layer manages the dialogue — opening it, maintaining it, closing it, and keeping track of which exchange a transmission belongs to. The presentation layer makes what arrives interpretable, handling character encoding, format translation, compression and encryption; TLS is the case worth naming, since it genuinely spans this layer and the session layer beneath it and is placed at Presentation by CompTIA convention rather than by clean architecture. The application layer is where the user's software speaks, and where a browser's HTTP GET to a web server originates. The encapsulation story is the reason this ordering is worth internalizing rather than memorizing, and it is carried in the instructions rather than on the cards so that it stays an aid and not an answer key. Data moves down the stack on the sending side with a header added at each step, travels the network, and is unpacked layer by layer on the receiving side. The protocol data unit is renamed as it goes: bits at the physical layer, frames at the data link layer, packets at the network layer, segments at the transport layer, and plain application data above that. That renaming is the clearest single cue for the bottom four layers, and it is deliberately not a cue for the top three — session, presentation and application all carry the same data, so those three have to be ordered from function alone. Two cautions belong here. First, the module is direct that the model does not fit everything: Ethernet does not map cleanly to a single OSI boundary, spanning the physical and data link layers, and ARP sits awkwardly on the layer 2 and 3 line. Treat the model as a guide, and treat the edge cases as evidence that it is a guide. Second, ordering by intuition about which layer sounds more advanced is the habit that produces wrong stacks; the reliable question is what each layer can do that the one beneath it cannot. All seven cards are presented every run rather than a sample, and the reason is that the domain is exactly seven — a stack sampled to a subset is not the OSI model, it is a fragment of one, and the objective being assessed is the complete ordering. This activity is also the inverse of the module's existing Protocol to Layer Sorter, which hands the student a protocol and asks for its layer; this one hands the layers and asks for the stack. The pair works best interleaved with other module content rather than run back to back, since placing them adjacently lets the second one be answered from the first one's screen rather than from memory.