Hcfyk

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

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.)

Data isn't stored in a network, it is transported.

User data is transported as payload by the application-layer protocol (L7) - HTTP, FTP, SMTP, ...

For instance, if you write some text and send that per email it can be encapsulated in an RFC2822 structure (L6), transmitted per SMTP (L7), encapsulated in TCP (L4), in IPv4 (L3), Ethernet frame (L2), Ethernet PHY (L1). Each protocol layer requires the next one underneath, there's no shortcutting.

The network layering takes care of enabling the communication on the the very same host, over a direct cable link, a switch in between, a single router, or many routers across the world.

You need at least one router when the end nodes don't share a common L2 network (across a switch). Note that the full stack is used within the hosts in any case. With a link across a simple switch (common L2 network) there is just no need for a L3 device (router) in between.

In no case does the application-layer protocol decide that it interfaces directly with L2 because it wouldn't need anything else. Application-layer protocols that sit right on top of L2 do exist but they're designed that way.

The differences in the various scenarios are how the data entity is actually transported.

• same host: Encapsulation ends at L3, L4 or even higher. The host stack passes the application-layer flows between the applications and that's it.


• direct cable link: Encapsulation is done L7 -> L4 -> L3 -> L2 -> L1, the line-coded data is transmitted and the destination host reverses the process L1 -> L2 -> L3 -> L4 -> L7.


• same switch/common L2 network: as before but the line-coded data is transmitted to the switch where L1 is removed, the destination MAC is extracted from the L2 frame, the according port looked up in the switch's MAC database, and the frame sent out that port, newly L1 encoded. En/decapsulation is L7 -> L4 -> L3 -> L2 -> L1 (to switch) -> L2 -> L1 (to host) -> L2 -> L3 -> L4 -> L7.


• with a router in between and a switch between each host and the router, the router removes the L2 frame from the L3 packet, decides where to forward (based on its routing table), again encapsulates in an L2 frame, and so on. The en/decapsulation would look like L7 -> L4 -> L3 -> L2 -> L1 (to switch) -> L2 -> L1 (to router) -> L2 -> L3 -> L2 -> L1 (to other switch) -> L2 -> L1 (to host) -> L2 -> L3 -> L4 -> L7.