OSI Layer – Where User-Generated Data Resides

osi

I am getting a bit confused about which OSI layer is being used to store user-generated data.

As far as I understand the process of encapsulation, the higher layers (starting with layer 7 – application layer) are interacting with their neighbor layers one step below when passing down the data that a user/program intends to send.

So, at which of those OSI layers will the data settle down?

TCP has header and data structure, IP has header and data structure, Ethernet has header and data structure, so I'm not sure in which OSI layer the user generated data is stored during data transmission on IP networks.


One of the reasons why I ask, is uncertainty regarding a hypothetical situation – suppose we have two hosts A and B (both of them on the same vlan 10) separated by two L2 switches:

A——–SW1——-SW2——–B

In this topology, since both hosts are in VLAN 10, we don't need an L3 device in order to allow communication between the hosts. But is there any practical use of L2-only communication? Will I be able to setup the host A as a web server so that the host B could access the web communicating only using MAC addresses? Will the user data be passed down from the application layer straight to the Ethernet frame, bypassing TCP and IP layers?

Thank you

Best Answer

The OSI seven layer model is an abstraction whose purpose is to clarify concepts and make it easier to compare different networking approaches: such as the differences between internet protocol and X.25. It is not a standard that is used in actually implementing networking.

If you're studying the internet protocol, it is much easier to understand it if you approach it in its own terms.

Your example is very common: exactly how a desktop computers most usually communicate with printers, which are usually on the same LAN as their client computers. Assuming a TCP connection, the desktop opens a TCP connection, often to port 9100 on the printer, and starts sending PostScript or other printer-specific data. Other very common printer protocols used UDP over IP over ethernet. The exact same mechanism is used for HTTP to a web server on the LAN, or SSH to a local server.

  • The TCP connection consists of segments, just as always
  • The segments are sent in IP packets, just as always
  • The IP packets are sent as ethernet frames, just as always

It is in fact one of the central, brilliant, ideas of the internet protocol: we're going to use the same higher-level (HTTP/IP) protocols over our local ethernet just the same as if we're crossing an ocean. Previously, computers would very frequently use a LAN-based protocol across the ethernet and something else modem-based for long-haul. In that period, if you wanted your program to communicate with a faraway host, you had to rewrite it. In the internet way, the communicating processes don't know or care if the other end is on the same computer, same room, or same planet.

To directly answer the question: yes, we use all the layers even when communicating locally. (The single exception: if we're communicating within a single host, IP packets are transported across the operating system without ever meeting layer 2: the memory containing the IP packet from the sending process is mapped or copied to the memory of the receiving process.)

Would it be possible to put, say, HTTP directly inside ethernet frames? Certainly, and you could easily write a server and client to do this. But it's a terrible idea. It would only work across a LAN. And you'd have to solve problems like: a) what do you do if a frame is corrupted? b) how do you maximise bandwidth and use full duplex communication? c) How do you use it at new site with Token Ring not ethernet? d) how do you use it from the ethernet site to the Token Ring site? Excellent solutions to these problems are already available: a) TCP ack mechanism, b) TCP sliding windows, c) IP packetising, d) IP forwarding.

(For simplicity of explanation I've omitted the non-ethernet cases, security blocking, permissions, tunnelling and other real-world complexities.)