Question 5 of 5: Layered Architecture — the OSI Seven-Layer Model

Question 5: Layered Architecture — the OSI Seven-Layer Model (25 marks)

Question text not reproduced: the examination questions are © Engineers and Geoscientists BC. Open the official past paper (linked at the top of this page) to read the question, then follow the worked solution below.

Part (a) — the seven layers, one sentence each. The question explicitly penalises verbosity, so each layer gets exactly what it is asked for: a name and a sentence.

1. Physical. Transmits raw bits over the medium by defining the signalling, timing, connectors and mechanical interface — voltages, light pulses or radio symbols and the bit rate at which they are sent.
2. Data link. Groups bits into frames and delivers them reliably across one link, providing framing, physical (MAC) addressing, error detection and control of access to a shared medium.
3. Network. Delivers packets between hosts on different networks using logical addresses, choosing a route hop by hop and fragmenting where link sizes differ.
4. Transport. Provides end-to-end delivery between processes, adding segmentation and reassembly, port-level addressing and — when the service requires it — reliability, ordering and flow control.
5. Session. Establishes, manages and terminates dialogues between applications, including dialogue direction control, synchronisation points and recovery of an interrupted exchange.
6. Presentation. Makes the data intelligible to the peer by handling syntax and representation — character encoding, data-structure marshalling, compression and encryption.
7. Application. Provides the network services the user's software invokes directly, such as file transfer, electronic mail, name resolution and the web.

Part (b) — where each item lives.

A useful cross-check on the whole list: exactly one item lands in each of layers 1, 3 and 5–7 or spans a pair, and no item lands in layer 5. That is expected — the session layer has no distinct counterpart in the TCP/IP protocol suite, its functions having been absorbed into application protocols, which is one of the standard criticisms of the OSI model as a description of the real internet.

Part (c) — why layer at all. Layering is how a system too large for any one design team, standards body or vendor to specify is decomposed into pieces that can be specified, built and replaced independently. Each layer offers a service to the layer above through a defined interface and hides how that service is achieved; a layer may therefore be re-implemented freely provided the interface is honoured.

Five consequences make this decisive for a network the size of the internet. Modularity and independent evolution: IP runs unchanged over Ethernet, Wi-Fi, fibre and satellite, and HTTP runs unchanged over TCP or QUIC, because neither knows anything of the other's internals — the layers below and above IP were each replaced wholesale over the internet's lifetime without the other being rewritten. Interoperability through standards: equipment from independent manufacturers interworks if each conforms to the interface, which is what allows a competitive multi-vendor market rather than a single vendor's closed system. Tractable design and reasoning: a designer solves reliable delivery once, at the transport layer, rather than re-solving it in every application, and a protocol can be specified and verified against its neighbours alone. Reuse: one transport implementation in the operating system serves every application above it. Diagnosis and teaching: faults localise to a layer — no link light is layer 1, no route is layer 3, a refused port is layer 4 — which is the structure every troubleshooting procedure follows.

The cost is worth stating, because it is what keeps the layer count small: each boundary adds a header, a copy and some loss of information (a transport layer that cannot see why a packet was lost is exactly the limitation of Question 3(d)), and cross-layer optimisation is often forbidden by the very abstraction that makes the system buildable. The engineering judgement is that the modularity is worth the overhead — a judgement the internet's forty-year evolution has repeatedly confirmed.

Final results.