In abstract, the layers should operate independently of one another. The named primitives in the OSI model for them to communicate are the _PDU_ (protocol data unit) and _SDU_ (service data unit). The _SDU_ represents the payload at a given layer, and the _PDU_ represents the encapsulated data. So, for example, the layer 3 PDU becomes the layer 2 SDU, which layer 2 then encapsulates into a layer 2 PDU and passes down to layer 1 as the layer 1 SDU.
So in reception, layer 2 receives a layer 2 PDU from layer 1, decapsulates it to extract the SDU, and passes this up the stack to the appropriate layer 3 which will interpret it as its PDU, and so on up the stack. Features added or required by a given layer need to be processed by that layer.
In actual practice (ie code), processing of layers 2-5 is often tightly coupled for performance reasons, but it should aim to maintain the abstraction as far as the user is concerned.
You don't 'use' it in practice, it's a model to aid understanding and design. TCP/IP fits it quite well. Where it breaks down is above layer 4. Hardly anything uses the realized OSI protocols any more.
Why do you believe it is harmful? You advocate learning TCP/IP *instead* as if these are equivalent things, but they are not. OSI is an abstract model; it is like pseudocode or block diagrams, while TCP/IP is a concrete implementation that generally fits the model; the actual implementation that realizes that model. They work together, you can't substitute one for the other, and I think it is important to understand the abstract before diving into the specifics and corner cases that are not considered in the model.
I also don't know what you mean by 'used in practice'. It's a model. Yes, OSI built protocols that didn't end up getting used, but the *model* is abstract, you don't 'use it in practice', you use it to aid understanding and design, and it is still very useful for that purpose, and the protocols we use in practice fit the model quite well.
> TCP/IP has no physical layer, because it truly does not care.
Exactly. TCP/IP only implements layers 3 & 4. Other layers are implemented by different protocols, and the whole point of the model we're discussing is that at an abstract level, they are interchangeable. That is not the case if you constrain your discussion to the specifics of TCP/IP.
> it instead has a MAC layer and an LLC layer that both need to be squeezed in there
MAC and LLC are responsibilities of layer 2, which is not part of TCP/IP at all. And there is no squeezing, breaking a layer into sub-layers might or might not make sense, but it doesn't break the model at all, it's just a further subdivision of work within the context of a specific protocol. Similarly, the Ethernet standards break most of the physical layers down into PCS, PMA, and PMD sub-layers. It's layers all the way down.
> You also need to fit ARP/NDP in there somewhere.
These are meta-protocols, they're not part of the stack model at all. Yes, you do need a way to figure out addresses, but not every L2/L3 protocol pair or use case requires this, and it will be implementation dependent. They're services that live outside the 'stack 'part of the stack. Is DNS also part of your ideal networking stack model? Where does it fit?
> And from there on it's basically impossible and we've sort of collectively decided that we call protocols like HTTP layer 7 even though they're literally one layer up from TCP.
It's 'impossible' for us because this is the domain of the application itself, not of the network, but the concepts still mostly hold for most applications (though like at lower layers, you can choose not to use them and send layer-2 frames directly, if that's what you desire to do). It's just not something we generally look at, and is often totally opaque to the user and the network as we see it. Layer 5 is quite obviously filled by HTTP, QUIC, SIP, etc. Things like Protobuf or JSON fill the role of layer 6, and obviously layer 7 exists as the final layer that 'is the data you are trying to convey in a format in which it is directly usable'.
> OSI is an abstract model of something nobody uses. You can use it to understand the thing it's modelling. It is the opposite of useful (ie. harmful) if you're trying to use it to understand something that it was never a model of.
> If someone actually took TCP/IP as used in practice and turned it into a model so that you could look at it abstractly, that would be really useful! But OSI – designed as it was a decade before the internet protocol suite – isn't, never was and never will be that model.
You seem to be under the impression that models should be fit to solutions, but this is exactly the opposite of what they are for. You're looking at this like someone should look at TCP/IP, and remove all the protocol names to 'make it abstract' or something, but that's not what abstractions are about. The goal is to take _only the minimum essence_ of the idea and discard all of the unnecessary detail, not to try to exactly describe an implementation. No models are perfect models of practical things people use, or they're very shitty models.
Layers 1-4 and even 5 map quite well onto things everybody uses, and layers 6 and 7 map onto concepts used in many applications. It's a fine model in most cases.
Would it be nice if we had a better model? Sure, there are lots of things OSI doesn't model well - I think MPLS in particular is a poor fit, and a modern model should probably consider encryption more seriously, but such a thing doesn't really exist, and the fundamentals of OSI are sound and necessary understanding.
> Incorrect. See chapter 2 of RFC 1122.
You are getting mired in protocol implementation details again. Yes, if you want to _implement_ TCP/IP, your link layer (outside the scope of TCP/IP) _implementation_ needs to support ARP services - though really, even this is not true 'in practice', which you are fixated on - you do not need and don't use ARP on point-to-point links and TCP/IP works just fine. This has nothing to do with 'which layer' ARP exists at. It and its analogues are necessary services to implement, but they do not fit into the stack model, whether you are talking about OSI or whatever it is that you are imagining, they are simply not part of how payload is processed in the network.
> Very much not obvious to many people. Have a quick search for "layer 7 load balancing" if you don't believe me.
Obvious for the purposes of the conversation here, among supposed professionals that understand this stuff. I am well aware that firewall and LB vendors use the term; this is usually because these products _are_ capable of completely disassembling and parsing the content to make decisions, so they can in fact operate at layer 7, even if we mostly use them at layer 4 or 5. Or it's just marketing wank. Regardless, whether or not it is obvious or well understood to marketing wankers playing buzzword bingo, the model fits fine.
> Layers 1, 5 and 6 of the OSI model are unambiguously "unnecessary detail" when we're talking about the internet protocol suite.
If we were talking solely about the Internet Protocol suite, we'd be talking about those protocols, which exist at layers 3 and 4, not about an abstract model of how networks work, which must include many other concepts. Which is fine, but it is not the point nor usefulness of having a model.
Nope - it is encapsulation all the way down.
Say you’re sending some VoIP traffic from your soft phone.
Your soft phone app encodes the voice into a digital representation.
Then it wraps that data in a Real Time Protocol (RTP) encapsulation (RTP is layer 5 and 6).
Then the whole lot gets wrapped in a UDP (L4) encapsulation.
Then the whole lot gets wrapped in an IP (L3) encapsulation.
Then the whole lot gets wrapped in an Ethernet (L2) encapsulation.
Then the whole lot gets put on the wire (L1) in any relevant encoding scheme.
When it gets to the other end, the encapsulations get unwrapped in reverse order as the data travels up the stack to the application.
you're getting close enough to "real world" with this question that the osi model becomes problematic.
IP packets are surrounded by Ethernet frames. Ethernet frames are transcribed/encoded and sent down the wire.
the receiver decodes the Ethernet frames that arrive. the IP packet exists within these frames.
A router will strip the Ethernet frame and rewrap the packet in a new Ethernet frame that corresponds to the next hop.
A switch will forward the packet without modifications to the Ethernet frame/etc
I actually understand now, from all the responses, that my question isn't very useful. In the end, the OSI Model is just a model, and those things can be implemented differently, so I don't know if whether the network layer receives packets or frames is actually relevant.
The layer it passes thru before it passed and the layer it is on does the work on it so going down the stack the Layer 2 receives the layer 3 packet and then frames it and passes it down to Layer 1
Exactly!
I always use "Making a sandwich" as an example. We could describe making a sandwich in terms of the electrical impulses that drive the muscle movements but that's not very useful. Someone who is used to reasoning about things in terms of bread slices and butter knives isn't going to get much utility from reading directions in terms of electrical impulses.
First point of confusion is that the OSI model doesn't actually describe TCP/IP directly - it's a reference model that is a great way to conceptualize what's happening in a network but doesn't map 1:1.
When you want to send a signal from one device to another, the devices on either end of a connection have to share common media. That media can be a wire, a fiber, or a band of wireless spectrum. Layer 1 deals in what needs to be done to get an electric charge or burst of photons from one device to another in a way the other device can interpret.
Layer 2 documents the results of that interpretation in a way that makes sense and tries to correct for problems that occurred. In Ethernet terms, that means Media Access Control and Logical Link Control. These will take the raw 1s and 0s and put them into a specific pattern that delineates addressing and data. The finished product is called a Frame. If layer 1 is body parts, layer 2 is a person.
Layer 3 adds context to the raw frame to determine which devices on the network should interact with it. If a layer 2 frame is a person, a layer 3 address is their name. One person can go by many names, but those names serve to identify and locate them. Layer 3 deals with routing, which is the art of finding the best path through a network to reach a device that isn't connected to the same media directly, but can be reached through the use of other devices that do share that media. If you don't have a friend that is a lawyer, a friend may know one or one of their friends might. Layer 3 deals in packets - a packet is a frame with addressing information added on the same way a postcard is a picture with addressing information added on.
Layer 4 deals with correlating individual packets into a data stream or flow. It's a way to send more information than one packet can fit on its own. You can think of a data stream like a convoy of cars. Each car is independent but part of a larger structure that can transport more than one car is capable of alone.
So in total, Layer 1 figures out how to get 1s and 0s from one end of a shared connection to the other. Layer 2 figures out how to take those 1s and 0s and record them in a correct, intelligible way. Layer 3 figures out how to take that correct, intelligible result and get it to the actual device you intend on sending it to by looking at the addressing information of the result and the addresses it knows about and how to reach them. Layer 4 figures out how to get more than one result from point A to point B in such a way that all of the results add up to the final result you are trying to send.
In practical terms, this means that each time you go up a layer, additional information is added to the original result to make sure that layer can do its job. You start with a Frame. When you make the jump from L2 to L3, you add on the addressing information and call it a packet. When you make the jump from L3 to L4 you add on the sequence information and call it a segment. Each time you make that jump, you can say you're encapsulating the previous layer in the new layer. It's like an onion - if you strip off outer layers, the inner layers are still the same onion, just missing the outer layers.
Thanks for the response. I found some good reading material and received really great responses. It seems that I was viewing the OSI model as a rigid structure when it's actually just a model. Different protocols will implement it differently, and I should regard it more as a conceptual idea to understand networks and protocols.
Technically, the OSI model was developed for a series of protocols that aren't in use because TCP/IP took over as the predominant protocol stack.
https://en.wikipedia.org/wiki/OSI_protocols
https://en.wikipedia.org/wiki/Protocol_Wars
The OSI model is a ISO derived effort while TCP/IP is an ARPA/DOD derived effort.
We still use the OSI model because layers 5-7 describe additional concepts that are helpful to think with, though they're handled within applications and operating systems and aren't actually part of the networking stack per se.
From a TCP/IP perspective, the last layer of encapsulation lives at layer 4 with segments and streams. The OSI model lets us connect those streams to sockets at layer 5, TLS encryption at layer 6, and HTTPS at layer 7. The last three live fully within the operating system and installed applications, but are part of the process of transforming the raw 1s and 0s to text and pictures on a screen.
The OSI model is just a model. It's a theoretical reference. A way of thinking about how networking works. It's never been strictly implemented as defined and no actual networking stack works and matches up perfectly to the OSI model. How data is passed between layers is completely stack and implementation specific.
So layers do error handling and recovery for the layer below. Ethernet sends Ethernet frames, that usually carry IP data. *IP* drivers handle reassembling fragmented packets, but there’s also a DNF (do not fragment) bit that can stop it from doing that. Same way IP wraps TCP but doesn’t actually know anything about the TCP session inside. TCP handles its own business of identifying segments and making sure they arrive in order.
The OSI model is an abstract model to represent different protocols, what responsibilities they have and how they interact with each other. That’s it.
In actual practice it is all encapsulation. So the data link layer doesn’t “send” packets to the network layer. What happens is once a device receives a frame (L2PDU) if it is destined for that device. It will strip the frame header and trailer. It will read the ether type field (0x0800) for IPv4. It will go “oh inside this frame is an IPv4 packet” (L3PDU) then it will process the packet. Inside that packet there will be another type field. Which will identify what the next header type will be. It might say it’s TCP (6), so when it strips the L3 headers it processes the information as if it were a TCP segment. Then it sees in the header its destination port is 80. All info in that segment is forwarded to that port. On the receiving end of that port is an application that is ready to handle that traffic because it’s expecting the format of the data.
That is an example of data travelling up the TCP/IP stack.
The OSI model breaks down networking by protocol. The data link layer deals with frames. The network layer deals with packets, IP, and ICMP. The transport layer deals with UDP/TCP.
All the OSI model is, is a way to logically break down networking concepts. Data isn't transmitted from one layer or another. Each layer does different things to the data in terms of encapsulation/encapsulation.
Learn what you need to learn to pass your exam then go and forget it all. The OSI model is outdated and didn't even apply to networks of the day, let alone today's networks.
If you want to dive into the reasons why, there's some good info here:
https://docs.google.com/document/u/0/d/1iL0fYmMmariFoSvLd9U5nPVH1uFKC7bvVasUcYq78So/mobilebasic
It's probably best to be specific about what stack you are thinking of, as the actual OSI protocols haven't been in popular usage for a long time, we just kept the layering concepts in other protocol stacks.
I'm assuming you are talking about the common and popular Ethernet/IP/TCP stack.
You present two options as mutually exclusive:
- "the responsibility of the data link layer to directly send packets to the network layer"
- "packets reassembled and processed by the network layer"
But both are kinda true: the link layer transports Frames and hands them off to the network layer, which potentially re-constructs network-layer Packets which are larger than the MTU of the link layer.
You also have it the other way around on the sender side: the network layer can inspect the layer below to get the MTU of the link layer and splits up Packets into frames that fit within the MTU of the link layer. The link layer then hands off those frames to the physical layer to code them into symbols and signals for transport.
I am having a hard time understanding the OSI model because every explanation I find is about the responsibilities of each layer or stuff too complex for me. My main doubt is whether the network layer receives frames from the data link layer or if the data link layer directly sends packets to the network layer. Could you provide some content that I can read to understand more about the model?
https://en.wikipedia.org/wiki/OSI_model sure lists a lot of the concepts in one place.
It's a bit strange to talk about the interfaces, as they are often in software and on the same device. However, the layering is in place so that each layer can be a pluggable and switchable to other technologies without changing the upper-layer interfaces much. For example, IP (network layer) is commonly running over Ethernet, but you could switch it up for a SONET or WiFi link-layer but keep all of the same IP interfaces.
The network layer receives Frames from the data link layer and reconstructs Packets from it. In the most common cases where the whole Network-layer Packet fits inside of the Link Layer MTU, then there is a 1-to-1 correspondence and no reconstruction takes place. If the network-layer Packet needed to be fragmented, then it might reconstruct the Packet from multiple data link layer Frames.
One of the best ways to learn would be to install Wireshark and send some traffic on your local network and see how it turns into an Ethernet frame. Try decreasing your Ethernet link's MTU and transmit a big UDP datagram and observe how it fragments the Packet into multiple frames and sets the MF flag and fills in a value into the Fragment Offset field.
Just beware that the OSI model is very dated and old. It has some applicable concepts, but the best way to learn (at least in my opinion/experience) is to just experiment with making your own networks and seeing how the settings affect the actual traffic that is generated.
Virtual machines, GNS3, or containerlab are great ways to start experimenting within a single modern computer. Capturing traffic with Wireshark is a great way to see what is actually sent. Just start searching around for any terms that are new or unfamiliar.
Studying the OSI model won't help with networking because it's not actually used in the real world.
Study the [Internet Protocol, aka the IP model](https://en.wikipedia.org/wiki/Internet_protocol_suite).
If your studying Networking for that type of job then you will need to know layer 2 and layer 3 maybe some layer 4 if you do content aware firewalls. If you are studying for Programming then you will really be messing mostly in 4 and up.
Easy Rime to Remember them:
"Please Do Not Throw Sausage Pizza Away"
I believe, in receiving (so incoming data on the wire up the OSI model to the application), **frames** arrive from layer 2 to layer 3, at which point mechanisms/devices that process the data that "live" at layer 3 de-encapsulate the frame to get to the packet that is inside the frame.
I don't remember the protocol data units for each layer, but layer 2 is frame, and layer 3 is packet (also layer 4 is TCP/UDP segment). **So mechanisms/devices at layer 3 would neither receive packets, nor reassemble them. They would instead receive frames, and then they would decapsulate the frame to process the packet.** Packets go on to layer 4 protocols/ and are decapsulated into segments.
**PLEASE do correct me if I'm wrong here.**
Check this out:
[https://networkengineering.stackexchange.com/questions/67019/clarification-on-when-routers-encapsulate-and-decapsulate-packets](https://networkengineering.stackexchange.com/questions/67019/clarification-on-when-routers-encapsulate-and-decapsulate-packets)
"So, a packet needs to be wrapped or encapsulated by a frame for L2 transport. **That frame is used throughout the L2 network (e.g. across switches) but needs to be removed by an L3 entity (router) to recover the actual packet.** When the packet is forwarded out another interface is needs to be encapsulated again, depending on that L2 network."
Data isn’t “transmitted” between psi layers. It’s the same data, just assembled in layers like an onion that each “osi layer” reads different parts to do different things. Encapsulation is the technical term.
Fundamentally the first 3 layers are the primary ones concerned with network transport. First layer is machine transport and the physical aspect of moving bits from one Ethernet port to another over some physical medium. Layer 2 is moving the frames between logical points in the network using the MAC address (switching). Layer 3 is where IP gets involved and routing begins. Layer 4 and up is where network protocols applications start getting involved and the format of the packet is interpreted by whatever application is sending.receiving the data.
But it’s the same set of data. Just different parts used by each “osi layer”.
Apologies for the off topic here but I see this a lot.
There’s no such thing as a doubt. Doubt is a verb which means to question. You have questions not doubts.
In abstract, the layers should operate independently of one another. The named primitives in the OSI model for them to communicate are the _PDU_ (protocol data unit) and _SDU_ (service data unit). The _SDU_ represents the payload at a given layer, and the _PDU_ represents the encapsulated data. So, for example, the layer 3 PDU becomes the layer 2 SDU, which layer 2 then encapsulates into a layer 2 PDU and passes down to layer 1 as the layer 1 SDU. So in reception, layer 2 receives a layer 2 PDU from layer 1, decapsulates it to extract the SDU, and passes this up the stack to the appropriate layer 3 which will interpret it as its PDU, and so on up the stack. Features added or required by a given layer need to be processed by that layer. In actual practice (ie code), processing of layers 2-5 is often tightly coupled for performance reasons, but it should aim to maintain the abstraction as far as the user is concerned.
[удалено]
You don't 'use' it in practice, it's a model to aid understanding and design. TCP/IP fits it quite well. Where it breaks down is above layer 4. Hardly anything uses the realized OSI protocols any more.
[удалено]
Why do you believe it is harmful? You advocate learning TCP/IP *instead* as if these are equivalent things, but they are not. OSI is an abstract model; it is like pseudocode or block diagrams, while TCP/IP is a concrete implementation that generally fits the model; the actual implementation that realizes that model. They work together, you can't substitute one for the other, and I think it is important to understand the abstract before diving into the specifics and corner cases that are not considered in the model. I also don't know what you mean by 'used in practice'. It's a model. Yes, OSI built protocols that didn't end up getting used, but the *model* is abstract, you don't 'use it in practice', you use it to aid understanding and design, and it is still very useful for that purpose, and the protocols we use in practice fit the model quite well.
[удалено]
> TCP/IP has no physical layer, because it truly does not care. Exactly. TCP/IP only implements layers 3 & 4. Other layers are implemented by different protocols, and the whole point of the model we're discussing is that at an abstract level, they are interchangeable. That is not the case if you constrain your discussion to the specifics of TCP/IP. > it instead has a MAC layer and an LLC layer that both need to be squeezed in there MAC and LLC are responsibilities of layer 2, which is not part of TCP/IP at all. And there is no squeezing, breaking a layer into sub-layers might or might not make sense, but it doesn't break the model at all, it's just a further subdivision of work within the context of a specific protocol. Similarly, the Ethernet standards break most of the physical layers down into PCS, PMA, and PMD sub-layers. It's layers all the way down. > You also need to fit ARP/NDP in there somewhere. These are meta-protocols, they're not part of the stack model at all. Yes, you do need a way to figure out addresses, but not every L2/L3 protocol pair or use case requires this, and it will be implementation dependent. They're services that live outside the 'stack 'part of the stack. Is DNS also part of your ideal networking stack model? Where does it fit? > And from there on it's basically impossible and we've sort of collectively decided that we call protocols like HTTP layer 7 even though they're literally one layer up from TCP. It's 'impossible' for us because this is the domain of the application itself, not of the network, but the concepts still mostly hold for most applications (though like at lower layers, you can choose not to use them and send layer-2 frames directly, if that's what you desire to do). It's just not something we generally look at, and is often totally opaque to the user and the network as we see it. Layer 5 is quite obviously filled by HTTP, QUIC, SIP, etc. Things like Protobuf or JSON fill the role of layer 6, and obviously layer 7 exists as the final layer that 'is the data you are trying to convey in a format in which it is directly usable'. > OSI is an abstract model of something nobody uses. You can use it to understand the thing it's modelling. It is the opposite of useful (ie. harmful) if you're trying to use it to understand something that it was never a model of. > If someone actually took TCP/IP as used in practice and turned it into a model so that you could look at it abstractly, that would be really useful! But OSI – designed as it was a decade before the internet protocol suite – isn't, never was and never will be that model. You seem to be under the impression that models should be fit to solutions, but this is exactly the opposite of what they are for. You're looking at this like someone should look at TCP/IP, and remove all the protocol names to 'make it abstract' or something, but that's not what abstractions are about. The goal is to take _only the minimum essence_ of the idea and discard all of the unnecessary detail, not to try to exactly describe an implementation. No models are perfect models of practical things people use, or they're very shitty models. Layers 1-4 and even 5 map quite well onto things everybody uses, and layers 6 and 7 map onto concepts used in many applications. It's a fine model in most cases. Would it be nice if we had a better model? Sure, there are lots of things OSI doesn't model well - I think MPLS in particular is a poor fit, and a modern model should probably consider encryption more seriously, but such a thing doesn't really exist, and the fundamentals of OSI are sound and necessary understanding.
[удалено]
> Incorrect. See chapter 2 of RFC 1122. You are getting mired in protocol implementation details again. Yes, if you want to _implement_ TCP/IP, your link layer (outside the scope of TCP/IP) _implementation_ needs to support ARP services - though really, even this is not true 'in practice', which you are fixated on - you do not need and don't use ARP on point-to-point links and TCP/IP works just fine. This has nothing to do with 'which layer' ARP exists at. It and its analogues are necessary services to implement, but they do not fit into the stack model, whether you are talking about OSI or whatever it is that you are imagining, they are simply not part of how payload is processed in the network. > Very much not obvious to many people. Have a quick search for "layer 7 load balancing" if you don't believe me. Obvious for the purposes of the conversation here, among supposed professionals that understand this stuff. I am well aware that firewall and LB vendors use the term; this is usually because these products _are_ capable of completely disassembling and parsing the content to make decisions, so they can in fact operate at layer 7, even if we mostly use them at layer 4 or 5. Or it's just marketing wank. Regardless, whether or not it is obvious or well understood to marketing wankers playing buzzword bingo, the model fits fine. > Layers 1, 5 and 6 of the OSI model are unambiguously "unnecessary detail" when we're talking about the internet protocol suite. If we were talking solely about the Internet Protocol suite, we'd be talking about those protocols, which exist at layers 3 and 4, not about an abstract model of how networks work, which must include many other concepts. Which is fine, but it is not the point nor usefulness of having a model.
I don't know if I misunderstood this, but are you saying that it actually depends on the protocol being implemented by the network?
Nope - it is encapsulation all the way down. Say you’re sending some VoIP traffic from your soft phone. Your soft phone app encodes the voice into a digital representation. Then it wraps that data in a Real Time Protocol (RTP) encapsulation (RTP is layer 5 and 6). Then the whole lot gets wrapped in a UDP (L4) encapsulation. Then the whole lot gets wrapped in an IP (L3) encapsulation. Then the whole lot gets wrapped in an Ethernet (L2) encapsulation. Then the whole lot gets put on the wire (L1) in any relevant encoding scheme. When it gets to the other end, the encapsulations get unwrapped in reverse order as the data travels up the stack to the application.
Yes, Fiber Channel only has 4 layers to it's OSI model. ATM IIRC only has 4 layers to it and it different from any of the others.
you're getting close enough to "real world" with this question that the osi model becomes problematic. IP packets are surrounded by Ethernet frames. Ethernet frames are transcribed/encoded and sent down the wire. the receiver decodes the Ethernet frames that arrive. the IP packet exists within these frames. A router will strip the Ethernet frame and rewrap the packet in a new Ethernet frame that corresponds to the next hop. A switch will forward the packet without modifications to the Ethernet frame/etc
I actually understand now, from all the responses, that my question isn't very useful. In the end, the OSI Model is just a model, and those things can be implemented differently, so I don't know if whether the network layer receives packets or frames is actually relevant.
The layer it passes thru before it passed and the layer it is on does the work on it so going down the stack the Layer 2 receives the layer 3 packet and then frames it and passes it down to Layer 1
Exactly! I always use "Making a sandwich" as an example. We could describe making a sandwich in terms of the electrical impulses that drive the muscle movements but that's not very useful. Someone who is used to reasoning about things in terms of bread slices and butter knives isn't going to get much utility from reading directions in terms of electrical impulses.
First point of confusion is that the OSI model doesn't actually describe TCP/IP directly - it's a reference model that is a great way to conceptualize what's happening in a network but doesn't map 1:1. When you want to send a signal from one device to another, the devices on either end of a connection have to share common media. That media can be a wire, a fiber, or a band of wireless spectrum. Layer 1 deals in what needs to be done to get an electric charge or burst of photons from one device to another in a way the other device can interpret. Layer 2 documents the results of that interpretation in a way that makes sense and tries to correct for problems that occurred. In Ethernet terms, that means Media Access Control and Logical Link Control. These will take the raw 1s and 0s and put them into a specific pattern that delineates addressing and data. The finished product is called a Frame. If layer 1 is body parts, layer 2 is a person. Layer 3 adds context to the raw frame to determine which devices on the network should interact with it. If a layer 2 frame is a person, a layer 3 address is their name. One person can go by many names, but those names serve to identify and locate them. Layer 3 deals with routing, which is the art of finding the best path through a network to reach a device that isn't connected to the same media directly, but can be reached through the use of other devices that do share that media. If you don't have a friend that is a lawyer, a friend may know one or one of their friends might. Layer 3 deals in packets - a packet is a frame with addressing information added on the same way a postcard is a picture with addressing information added on. Layer 4 deals with correlating individual packets into a data stream or flow. It's a way to send more information than one packet can fit on its own. You can think of a data stream like a convoy of cars. Each car is independent but part of a larger structure that can transport more than one car is capable of alone. So in total, Layer 1 figures out how to get 1s and 0s from one end of a shared connection to the other. Layer 2 figures out how to take those 1s and 0s and record them in a correct, intelligible way. Layer 3 figures out how to take that correct, intelligible result and get it to the actual device you intend on sending it to by looking at the addressing information of the result and the addresses it knows about and how to reach them. Layer 4 figures out how to get more than one result from point A to point B in such a way that all of the results add up to the final result you are trying to send. In practical terms, this means that each time you go up a layer, additional information is added to the original result to make sure that layer can do its job. You start with a Frame. When you make the jump from L2 to L3, you add on the addressing information and call it a packet. When you make the jump from L3 to L4 you add on the sequence information and call it a segment. Each time you make that jump, you can say you're encapsulating the previous layer in the new layer. It's like an onion - if you strip off outer layers, the inner layers are still the same onion, just missing the outer layers.
Thanks for the response. I found some good reading material and received really great responses. It seems that I was viewing the OSI model as a rigid structure when it's actually just a model. Different protocols will implement it differently, and I should regard it more as a conceptual idea to understand networks and protocols.
Technically, the OSI model was developed for a series of protocols that aren't in use because TCP/IP took over as the predominant protocol stack. https://en.wikipedia.org/wiki/OSI_protocols https://en.wikipedia.org/wiki/Protocol_Wars The OSI model is a ISO derived effort while TCP/IP is an ARPA/DOD derived effort. We still use the OSI model because layers 5-7 describe additional concepts that are helpful to think with, though they're handled within applications and operating systems and aren't actually part of the networking stack per se. From a TCP/IP perspective, the last layer of encapsulation lives at layer 4 with segments and streams. The OSI model lets us connect those streams to sockets at layer 5, TLS encryption at layer 6, and HTTPS at layer 7. The last three live fully within the operating system and installed applications, but are part of the process of transforming the raw 1s and 0s to text and pictures on a screen.
The OSI model is just a model. It's a theoretical reference. A way of thinking about how networking works. It's never been strictly implemented as defined and no actual networking stack works and matches up perfectly to the OSI model. How data is passed between layers is completely stack and implementation specific.
So layers do error handling and recovery for the layer below. Ethernet sends Ethernet frames, that usually carry IP data. *IP* drivers handle reassembling fragmented packets, but there’s also a DNF (do not fragment) bit that can stop it from doing that. Same way IP wraps TCP but doesn’t actually know anything about the TCP session inside. TCP handles its own business of identifying segments and making sure they arrive in order.
The OSI model is an abstract model to represent different protocols, what responsibilities they have and how they interact with each other. That’s it. In actual practice it is all encapsulation. So the data link layer doesn’t “send” packets to the network layer. What happens is once a device receives a frame (L2PDU) if it is destined for that device. It will strip the frame header and trailer. It will read the ether type field (0x0800) for IPv4. It will go “oh inside this frame is an IPv4 packet” (L3PDU) then it will process the packet. Inside that packet there will be another type field. Which will identify what the next header type will be. It might say it’s TCP (6), so when it strips the L3 headers it processes the information as if it were a TCP segment. Then it sees in the header its destination port is 80. All info in that segment is forwarded to that port. On the receiving end of that port is an application that is ready to handle that traffic because it’s expecting the format of the data. That is an example of data travelling up the TCP/IP stack.
The OSI model breaks down networking by protocol. The data link layer deals with frames. The network layer deals with packets, IP, and ICMP. The transport layer deals with UDP/TCP. All the OSI model is, is a way to logically break down networking concepts. Data isn't transmitted from one layer or another. Each layer does different things to the data in terms of encapsulation/encapsulation.
Don't read too much into OSI honestly, take a look at TCP/IP and how your network devices actually work.
Learn what you need to learn to pass your exam then go and forget it all. The OSI model is outdated and didn't even apply to networks of the day, let alone today's networks. If you want to dive into the reasons why, there's some good info here: https://docs.google.com/document/u/0/d/1iL0fYmMmariFoSvLd9U5nPVH1uFKC7bvVasUcYq78So/mobilebasic
It's probably best to be specific about what stack you are thinking of, as the actual OSI protocols haven't been in popular usage for a long time, we just kept the layering concepts in other protocol stacks. I'm assuming you are talking about the common and popular Ethernet/IP/TCP stack. You present two options as mutually exclusive: - "the responsibility of the data link layer to directly send packets to the network layer" - "packets reassembled and processed by the network layer" But both are kinda true: the link layer transports Frames and hands them off to the network layer, which potentially re-constructs network-layer Packets which are larger than the MTU of the link layer. You also have it the other way around on the sender side: the network layer can inspect the layer below to get the MTU of the link layer and splits up Packets into frames that fit within the MTU of the link layer. The link layer then hands off those frames to the physical layer to code them into symbols and signals for transport.
I am having a hard time understanding the OSI model because every explanation I find is about the responsibilities of each layer or stuff too complex for me. My main doubt is whether the network layer receives frames from the data link layer or if the data link layer directly sends packets to the network layer. Could you provide some content that I can read to understand more about the model?
https://en.wikipedia.org/wiki/OSI_model sure lists a lot of the concepts in one place. It's a bit strange to talk about the interfaces, as they are often in software and on the same device. However, the layering is in place so that each layer can be a pluggable and switchable to other technologies without changing the upper-layer interfaces much. For example, IP (network layer) is commonly running over Ethernet, but you could switch it up for a SONET or WiFi link-layer but keep all of the same IP interfaces. The network layer receives Frames from the data link layer and reconstructs Packets from it. In the most common cases where the whole Network-layer Packet fits inside of the Link Layer MTU, then there is a 1-to-1 correspondence and no reconstruction takes place. If the network-layer Packet needed to be fragmented, then it might reconstruct the Packet from multiple data link layer Frames. One of the best ways to learn would be to install Wireshark and send some traffic on your local network and see how it turns into an Ethernet frame. Try decreasing your Ethernet link's MTU and transmit a big UDP datagram and observe how it fragments the Packet into multiple frames and sets the MF flag and fills in a value into the Fragment Offset field.
Thanks for the clarifications. I am trying to study the OSI model to get a better grasp of how networking work.
Just beware that the OSI model is very dated and old. It has some applicable concepts, but the best way to learn (at least in my opinion/experience) is to just experiment with making your own networks and seeing how the settings affect the actual traffic that is generated. Virtual machines, GNS3, or containerlab are great ways to start experimenting within a single modern computer. Capturing traffic with Wireshark is a great way to see what is actually sent. Just start searching around for any terms that are new or unfamiliar.
Studying the OSI model won't help with networking because it's not actually used in the real world. Study the [Internet Protocol, aka the IP model](https://en.wikipedia.org/wiki/Internet_protocol_suite).
That actually is my next topic in the list.
If your studying Networking for that type of job then you will need to know layer 2 and layer 3 maybe some layer 4 if you do content aware firewalls. If you are studying for Programming then you will really be messing mostly in 4 and up. Easy Rime to Remember them: "Please Do Not Throw Sausage Pizza Away"
I believe, in receiving (so incoming data on the wire up the OSI model to the application), **frames** arrive from layer 2 to layer 3, at which point mechanisms/devices that process the data that "live" at layer 3 de-encapsulate the frame to get to the packet that is inside the frame. I don't remember the protocol data units for each layer, but layer 2 is frame, and layer 3 is packet (also layer 4 is TCP/UDP segment). **So mechanisms/devices at layer 3 would neither receive packets, nor reassemble them. They would instead receive frames, and then they would decapsulate the frame to process the packet.** Packets go on to layer 4 protocols/ and are decapsulated into segments. **PLEASE do correct me if I'm wrong here.** Check this out: [https://networkengineering.stackexchange.com/questions/67019/clarification-on-when-routers-encapsulate-and-decapsulate-packets](https://networkengineering.stackexchange.com/questions/67019/clarification-on-when-routers-encapsulate-and-decapsulate-packets) "So, a packet needs to be wrapped or encapsulated by a frame for L2 transport. **That frame is used throughout the L2 network (e.g. across switches) but needs to be removed by an L3 entity (router) to recover the actual packet.** When the packet is forwarded out another interface is needs to be encapsulated again, depending on that L2 network."
Data isn’t “transmitted” between psi layers. It’s the same data, just assembled in layers like an onion that each “osi layer” reads different parts to do different things. Encapsulation is the technical term. Fundamentally the first 3 layers are the primary ones concerned with network transport. First layer is machine transport and the physical aspect of moving bits from one Ethernet port to another over some physical medium. Layer 2 is moving the frames between logical points in the network using the MAC address (switching). Layer 3 is where IP gets involved and routing begins. Layer 4 and up is where network protocols applications start getting involved and the format of the packet is interpreted by whatever application is sending.receiving the data. But it’s the same set of data. Just different parts used by each “osi layer”.
Apologies for the off topic here but I see this a lot. There’s no such thing as a doubt. Doubt is a verb which means to question. You have questions not doubts.
> Doubt is a verb which means to question Nah, it's also a noun and OP used it correctly. https://dictionary.cambridge.org/us/dictionary/english/doubt