Diving into the ISO OSI Network Stack Discussion
-
So as you can see from the example, the MySQL Protocol is the Layer 7 Application protocol, that's the protocol used by the application itself that it puts onto the wire. SQL is a language for querying the database and doesn't get placed onto the wire directly, but might sometimes be part of a payload that is handled by MySQL. But if it is part of a payload, then it is inside of the L7 MySQL protocol.
If SQL was a protocol at layer five, think of the implications. That would mean that the Adobe PDF sitting on your desktop, which is quite clearly an end user file, was actually some kind of "Network traffic in stasis".
-
@scottalanmiller said in FibreChannel Switch Types:
@dafyre said in FibreChannel Switch Types:
So that means you would put things like NFS, and NetBios at the application layer too? (pulling again, from the Cisco page for reference).
Of course, which is where they are accepted by the industry to be and always have been. Remember that Cisco calls when they do Ethernet too, but isn't part of the standard. Cisco and standards are oil and water. That's the last place you should be looking for how networking works, they have their own agenda, they own definitions and their own compatibility.
https://en.wikipedia.org/wiki/Application_layer
iSCSI is layer 7. SQL is not part of the network at all but you can call it L8, the layer directly above the network stack. But if you've ever worked with a database, it is really obvious that SQL is a language that humans work in, so is above the stack. Just like BASH is not part of the network stack. Or PowerShell. Of a text based video games.... those are applications. Applications are above the application layer of the OSI stack, not part of it.
Wikipedia is not a good place to go, lol. I had this open in my browser tab already...
https://en.wikipedia.org/wiki/List_of_network_protocols_(OSI_model)
Which puts iSCSI at Layer 4, and NetBios, NFS and a few others at Layer 5.
My page has been more recently updated. I win.
-
Seriously though. How you would fill out the OSI model?
-
@dafyre said in FibreChannel Switch Types:
@scottalanmiller said in FibreChannel Switch Types:
@dafyre said in FibreChannel Switch Types:
So that means you would put things like NFS, and NetBios at the application layer too? (pulling again, from the Cisco page for reference).
Of course, which is where they are accepted by the industry to be and always have been. Remember that Cisco calls when they do Ethernet too, but isn't part of the standard. Cisco and standards are oil and water. That's the last place you should be looking for how networking works, they have their own agenda, they own definitions and their own compatibility.
https://en.wikipedia.org/wiki/Application_layer
iSCSI is layer 7. SQL is not part of the network at all but you can call it L8, the layer directly above the network stack. But if you've ever worked with a database, it is really obvious that SQL is a language that humans work in, so is above the stack. Just like BASH is not part of the network stack. Or PowerShell. Of a text based video games.... those are applications. Applications are above the application layer of the OSI stack, not part of it.
Wikipedia is not a good place to go, lol. I had this open in my browser tab already...
https://en.wikipedia.org/wiki/List_of_network_protocols_(OSI_model)
Which puts iSCSI at Layer 4, and NetBios, NFS and a few others at Layer 5.
My page has been more recently updated. I win.
SO they are claiming that no socket is used for iSCSI traffic? That it replaced TCP?
-
@dafyre said in FibreChannel Switch Types:
Seriously though. How you would fill out the OSI model?
Excellent question
-
@dafyre said in FibreChannel Switch Types:
Seriously though. How you would fill out the OSI model?
What do you mean?
-
@scottalanmiller said in FibreChannel Switch Types:
@dafyre said in FibreChannel Switch Types:
Seriously though. How you would fill out the OSI model?
What do you mean?
He means that you define things differently than what we understand of the OSI model although that may just be our misunderstanding of it
-
@dafyre said in FibreChannel Switch Types:
@scottalanmiller said in FibreChannel Switch Types:
@dafyre said in FibreChannel Switch Types:
So that means you would put things like NFS, and NetBios at the application layer too? (pulling again, from the Cisco page for reference).
Of course, which is where they are accepted by the industry to be and always have been. Remember that Cisco calls when they do Ethernet too, but isn't part of the standard. Cisco and standards are oil and water. That's the last place you should be looking for how networking works, they have their own agenda, they own definitions and their own compatibility.
https://en.wikipedia.org/wiki/Application_layer
iSCSI is layer 7. SQL is not part of the network at all but you can call it L8, the layer directly above the network stack. But if you've ever worked with a database, it is really obvious that SQL is a language that humans work in, so is above the stack. Just like BASH is not part of the network stack. Or PowerShell. Of a text based video games.... those are applications. Applications are above the application layer of the OSI stack, not part of it.
Wikipedia is not a good place to go, lol. I had this open in my browser tab already...
https://en.wikipedia.org/wiki/List_of_network_protocols_(OSI_model)
Which puts iSCSI at Layer 4, and NetBios, NFS and a few others at Layer 5.
My page has been more recently updated. I win.
https://en.wikipedia.org/wiki/ISCSI
That page shows iSCSI as riding on top of TCP, not replacing it. And it gets port numbers. Only L7 services get port numbers, AFAIK. I don't know of any exception to that.
-
@wirestyle22 said in FibreChannel Switch Types:
@scottalanmiller said in FibreChannel Switch Types:
@dafyre said in FibreChannel Switch Types:
Seriously though. How you would fill out the OSI model?
What do you mean?
He means that you define things differently than what we understand of the OSI model although that may just be our misunderstanding of it
I just gave an example though. It's hard to say why you see it differently as my understanding of the model is my understanding of it Other than things floating between L5 and L6 as a natural consequence of TCP/IP being a four layer model, I don't see these as really convoluted. iSCSI, for example, is the payload of the network stack, so L7 without question. How could it be anything else? SQL Isn't part of that stack, quite obviously. What makes it seem like it is, other than some confused kid at Cisco making a chart - this is Cisco that told a Spicecorps that without 14Tb/s you couldn't watch YouTUbe.
-
So my question then would be, in your view of the OSI model and what iSCSI does, where would you put it in the stack knowing that it is the "final deliverable" of the communications in question and that it will be consumed directly by the final application and that it plays no role in the delivery, it is the thing "to be delivered." Where would you put it knowing what it is?
-
Likewise, where do you picture things like PDF, HTML, Word, SQL and other "file formats" that are not networking components at all but are document formats used internally by humans or applications? Would you put them into the networking stack even though they are file formats? And what role do they play when sitting on disk? Is the disk a "time frozen" snap of the network? If Word is an underpinning network component, what application protocol rides on top of it?
-
This page has FC at Layer 4 too, whoops. I guess the author things that Fibre Channel runs over Ethernet instead of replacing it!
https://en.wikipedia.org/wiki/List_of_network_protocols_(OSI_model)
That page has a disclaimer at the top there there is no citations. There is a reason, it's just bonkers.
-
@scottalanmiller said in FibreChannel Switch Types:
So my question then would be, in your view of the OSI model and what iSCSI does, where would you put it in the stack knowing that it is the "final deliverable" of the communications in question and that it will be consumed directly by the final application and that it plays no role in the delivery, it is the thing "to be delivered." Where would you put it knowing what it is?
I might could go to Presentation layer, but still leaning towards Session.
The Application layer would be the tools you use to configure your OS to interact with the iSCSI device that is "presented" to the OS... ie: iSCSI Initiator on Windows.
The Presentation layer would be where the iSCSI session and it presents a block device to the application layer. I could leave it at Presentation, except for one thing. The presentation layer has to communicate somehow, so down the stack it goes, sending the Destination IP, and Destination port, and payload (actual data to be read / written) down to the session layer.
To actually complete the communication, the session layer passes its data down to the Transport layer, and away we go.
-
@dafyre said in FibreChannel Switch Types:
@scottalanmiller said in FibreChannel Switch Types:
So my question then would be, in your view of the OSI model and what iSCSI does, where would you put it in the stack knowing that it is the "final deliverable" of the communications in question and that it will be consumed directly by the final application and that it plays no role in the delivery, it is the thing "to be delivered." Where would you put it knowing what it is?
I might could go to Presentation layer, but still leaning towards Session.
The Application layer would be the tools you use to configure your OS to interact with the iSCSI device that is "presented" to the OS... ie: iSCSI Initiator on Windows.
You are outside of the network stack completely. In the OSI model, L7 is the Application Layer of the network stack. It is still networking protocols. It can never be something that a user touches. Users touch Applications, applications put the Application Layer communications on the wire, which is then encapsulated by the stack. The network stack does not include things that users ever see like desktops, applications, files, languages and such.
I see why this is getting confused. You are trying to include the entire computer in the network stack, not just the network protocols.
-
@scottalanmiller said in FibreChannel Switch Types:
I see why this is getting confused. You are trying to include the entire computer in the network stack, not just the network protocols.
That's exactly the reason in my case
-
@scottalanmiller said in FibreChannel Switch Types:
@dafyre said in FibreChannel Switch Types:
@scottalanmiller said in FibreChannel Switch Types:
So my question then would be, in your view of the OSI model and what iSCSI does, where would you put it in the stack knowing that it is the "final deliverable" of the communications in question and that it will be consumed directly by the final application and that it plays no role in the delivery, it is the thing "to be delivered." Where would you put it knowing what it is?
I might could go to Presentation layer, but still leaning towards Session.
The Application layer would be the tools you use to configure your OS to interact with the iSCSI device that is "presented" to the OS... ie: iSCSI Initiator on Windows.
You are outside of the network stack completely. In the OSI model, L7 is the Application Layer of the network stack. It is still networking protocols. It can never be something that a user touches. Users touch Applications, applications put the Application Layer communications on the wire, which is then encapsulated by the stack. The network stack does not include things that users ever see like desktops, applications, files, languages and such.
I see why this is getting confused. You are trying to include the entire computer in the network stack, not just the network protocols.
You are probably right. I spend so much time focusing on the "whole computer" aspect of things that I don't get elbow deep in terminology like this enough.
I've slept a few times since I first learned of the OSI model, lol.
-
@dafyre said in FibreChannel Switch Types:
The Presentation layer would be where the iSCSI session and it presents a block device to the application layer. I could leave it at Presentation, except for one thing. The presentation layer has to communicate somehow, so down the stack it goes, sending the Destination IP, and Destination port, and payload (actual data to be read / written) down to the session layer.
To actually complete the communication, the session layer passes its data down to the Transport layer, and away we go.
iSCSI has to talk to the initiator, which is an application. So we know it is L7. That's provable by the fact that an application uses it directly. That much we can prove.
If you want to increase the stack to include applications, like MySQL or a web browser or Apache or Exchange or the iSCSI Initiator, then you would label those as L8 or L9 the application itself. It's weird because those things are not part of the networking, but the things that talk via the networking. Really the payload should be L8.
Another way to think of it, everything in the OSI model is visible in a packet capture plus the final payload which is just carried and not part of the networking itself. And obviously applications are not on the wire, so cannot be packet captured.
-
@dafyre said in FibreChannel Switch Types:
@scottalanmiller said in FibreChannel Switch Types:
@dafyre said in FibreChannel Switch Types:
@scottalanmiller said in FibreChannel Switch Types:
So my question then would be, in your view of the OSI model and what iSCSI does, where would you put it in the stack knowing that it is the "final deliverable" of the communications in question and that it will be consumed directly by the final application and that it plays no role in the delivery, it is the thing "to be delivered." Where would you put it knowing what it is?
I might could go to Presentation layer, but still leaning towards Session.
The Application layer would be the tools you use to configure your OS to interact with the iSCSI device that is "presented" to the OS... ie: iSCSI Initiator on Windows.
You are outside of the network stack completely. In the OSI model, L7 is the Application Layer of the network stack. It is still networking protocols. It can never be something that a user touches. Users touch Applications, applications put the Application Layer communications on the wire, which is then encapsulated by the stack. The network stack does not include things that users ever see like desktops, applications, files, languages and such.
I see why this is getting confused. You are trying to include the entire computer in the network stack, not just the network protocols.
You are probably right. I spend so much time focusing on the "whole computer" aspect of things that I don't get elbow deep in terminology like this enough.
I've slept a few times since I first learned of the OSI model, lol.
Easiest example is HTTP because it is so common, well known and uses encryption commonly whereas many things do not and we have to shoehorn it into an example. HTTP is the most well known example of L7, it's literally every textbook example. With that we can break down the communications to show the OSI layer by layer pretty easily. Of course there is no L6 because TCP/IP doesn't actually use all of the layers and everything between L4 and L7 gets smooshed together or skipped. Remember, you can skip layers basically anywhere and the layer something belongs to is the highest one you can't skip.
Chrome (Application) Apache (Application) | | HTML (Document) HTML (Document) | | L7: HTTP L7: HTTP | | L5/6: SSL L5/6: SSL | | L4: TCP 443 L4: TCP 443 | | L3: IP L3: IP | | L2: Ethernet L2: Ethernet | | L1: Physical Signaling --------------------------------- L1: Physical Signaling
In this nine layer example, I included the application itself, the client and server software. I included beneath that the document format that those applications use to speak to each other. Then that HTML document is wrapped in HTTP to hand to the network stack which can carry HTTP, as it has networking characteristics, down the stack, over to the other stack and back up. HTML is the final payload here, HTTP is its network carrier. You can replace HTTP with FTP, NFS, SMB, AFP and other protocols, of course, demonstrating that they, too, are L7 just like HTTP.
In this example, we end at the logical L1. Beneath that there is no more logic, only the physical wires and cables themselves. But the L1 represents the GigE protocol NOT the wire proper. It's the physical signaling standard, not the physical electrical impulses.
-
@scottalanmiller said in FibreChannel Switch Types:
@dafyre said in FibreChannel Switch Types:
@scottalanmiller said in FibreChannel Switch Types:
@dafyre said in FibreChannel Switch Types:
@scottalanmiller said in FibreChannel Switch Types:
So my question then would be, in your view of the OSI model and what iSCSI does, where would you put it in the stack knowing that it is the "final deliverable" of the communications in question and that it will be consumed directly by the final application and that it plays no role in the delivery, it is the thing "to be delivered." Where would you put it knowing what it is?
I might could go to Presentation layer, but still leaning towards Session.
The Application layer would be the tools you use to configure your OS to interact with the iSCSI device that is "presented" to the OS... ie: iSCSI Initiator on Windows.
You are outside of the network stack completely. In the OSI model, L7 is the Application Layer of the network stack. It is still networking protocols. It can never be something that a user touches. Users touch Applications, applications put the Application Layer communications on the wire, which is then encapsulated by the stack. The network stack does not include things that users ever see like desktops, applications, files, languages and such.
I see why this is getting confused. You are trying to include the entire computer in the network stack, not just the network protocols.
You are probably right. I spend so much time focusing on the "whole computer" aspect of things that I don't get elbow deep in terminology like this enough.
I've slept a few times since I first learned of the OSI model, lol.
Easiest example is HTTP because it is so common, well known and uses encryption commonly whereas many things do not and we have to shoehorn it into an example. HTTP is the most well known example of L7, it's literally every textbook example. With that we can break down the communications to show the OSI layer by layer pretty easily. Of course there is no L6 because TCP/IP doesn't actually use all of the layers and everything between L4 and L7 gets smooshed together or skipped. Remember, you can skip layers basically anywhere and the layer something belongs to is the highest one you can't skip.
Chrome (Application) Apache (Application) | | HTML (Document) HTML (Document) | | L7: HTTP L7: HTTP | | L5/6: SSL L5/6: SSL | | L4: TCP 443 L4: TCP 443 | | L3: IP L3: IP | | L2: Ethernet L2: Ethernet | | L1: Physical Signaling --------------------------------- L1: Physical Signaling
In this nine layer example, I included the application itself, the client and server software. I included beneath that the document format that those applications use to speak to each other. Then that HTML document is wrapped in HTTP to hand to the network stack which can carry HTTP, as it has networking characteristics, down the stack, over to the other stack and back up. HTML is the final payload here, HTTP is its network carrier. You can replace HTTP with FTP, NFS, SMB, AFP and other protocols, of course, demonstrating that they, too, are L7 just like HTTP.
In this example, we end at the logical L1. Beneath that there is no more logic, only the physical wires and cables themselves. But the L1 represents the GigE protocol NOT the wire proper. It's the physical signaling standard, not the physical electrical impulses.
This, I can follow. Now do one for iSCSI, lol.
-
iSCSI Target Driver iSCSI Initiator Driver | | SCSI 3 SCSI 3 | | L7: iSCSI L7: iSCSI | | L4: TCP L4: TCP | | L3: IP L3: IP | | L2: Ethernet L2: Ethernet | | L1: Physical Signaling --------------------------------- L1: Physical Signaling