Hacker News new | past | comments | ask | show | jobs | submit login
An OSI model for the 21st century (2014) (davidad.github.io)
90 points by eaguyhn on Aug 20, 2017 | hide | past | favorite | 27 comments



I have read the various comments against the OSI model and the one interesting observation is that none of you seem to have ever worked with a compliant implementation of the OSI model. Honeywell had a commercial product called DSA (Distributed Systems Architecture). We did write distributed applications that used the OSI protocol stack communications and it worked well. Within the applications, we didn't have to worry much about what was happening at the lower levels as those levels simply provided specific services we used. It was used for many years with very good results.

One of the features of the software at the time was that you get two dumb terminals to communicate with each other across the network by simply using the relevant connection protocols. This allowed simple communication streams to occur without having any applications involved, it was handled by the protocols themselves. It also meant that it was very easy to replace those dub terminals with an application without having to change any of the configurations in the network.

TCP/IP rose to the fore due to various reasons that were not related to their technological superiority. To see this you have to look more closely to the history of those times.


For my job I had the opportunity to work with quite some OSI standards on top of TCP/IP (X.216, X.227 and X.500, X.400 as application layers). My experience is quite in line with the common critique: most of these standards add more overhead than they're worth. It was also quite hard to bend these protocols into our use case (when bandwidth comes at a premium, it doesn't take long before the customer starts complaining).

I don't really see how a "dumb terminal" is a noteworthy feature of OSI? That's essentially what telnet does, and it too can just piggyback on top of TCP (probably the only protocol that makes use of all TCP flags available).


What commercial software were you using? TCP/IP was not part of the protocol stack we were using. The dumb terminal was sitting at the top of the protocol stack and wasn't using an application like telnet to access remote devices or applications. The point of my example was simply that a dumb terminal or any device or an application were treated the same in relation to the protocol stack. It did not matter.

The top speed of our links was the enormous 64 kb/s and we often had to use far slower services. We found that the overheads of the communication protocols was very small compared to the application processing overheads. It was a different time, I suppose and I find that I have to wait longer these days even when using ADSL than I did in those days.


AFAIK, the general perception is that http is a transport & upper protocol. Not an application layer protocol.

Anyway, OSI model is mostly a mental picture that bear little practical relevance.

If someone want to follow OSI model and devise a new model, then itself is a wrong approach. TCP/IP was invented out of solving real internetworking problems, without regarding much to the OSI model or any pre-defined model per-se.

As always, David Clark's "e2e principle" (https://en.wikipedia.org/wiki/End-to-end_principle) probably is the only guiding principle (or a after-fact summary) that is worth following.


The end to end principle pretty much made the flow control and re-transmission functions of the LLC sublayer of the data link layer obsolete. So now we pay a 6 to 8 byte penalty (8 bytes if the MAC can tell us the packet length) on every frame transmitted. Wired/optical Ethernet does not normally use LPD (LLC Protocol Discrimination, i.e. 802.2 LLC/SNAP) but unfortunately WiFi does.

So in 2014 while the author is advocating for the data link layer to ensure packets are received by other devices on the channel like the current OSI model does, the IEEE is encouraging new standards to use EPD (Ethernet Protocol Discrimination) instead of LPD. The IEEE just wants the LLC sublayer to only do multiplexing of protocols now.

The author completely missed how the upper layer protocols, i.e. TCP/IP, has made some parts of the lower layer protocols unnecessary. Having a basic model is good thing for classifying different parts of the network and makes discussions clearer. But in the real world things rarely fall into categories that neatly.


Well, there are themes that are evolving that are worth cataloging in a new logical model that can help guide further innovation. I agree though, the model itself isn't the root.


[flagged]


When I used to deal with people straight out of school they would always talk about the OSI model and it would drive me crazy. Everything we did would have to be categorized. What layer is this in, what layer is that in. I just want you to plug that Ethernet cable into that switch port and configure the static IP address in the software so we can get the hell out of here and have a beer.

No amount of explaining that stuff in the real world doesn't neatly fit into those categories would get them to shut up about it. One guy nearly had a mental breakdown when he first came across a tunnel. "How can you have two network layers?!?"

One day I was installing something in a computer lab at a college and on the wall was a giant poster of the OSI model with all the protocols imaginable listed on it. I had to fight the urge to set it on fire...

Yes, models are great for teaching and for certain types of discussions (L2 vs L3 switches) but the real world is always more complicated and the lines in the model tend to blur. Take the basic computer model taught to new students with the CPU, memory, input, output, storage, networking all neatly connected in that familiar diagram. A real computer is never connected that way. Memory is all over the place, storage can be directly on the CPU or hundreds of feet away in another box, etc.

Students quickly figure out that the computer model is just a teaching tool. Just holding a motherboard quickly makes them see that. But for networking they seem to hang on to the OSI model like if it were a piece of flotsam after a shipwreck.


Then you end up with people like I clean up after, who don't know the difference between layers 2 and 3 and can't understand out why putting 1200 clients (spread across a few dozen sites, linked by microwave connections) on the same layer 2 segment causes problems.


"Two network layers?!?"

Hah, yes and in the real world we do far weirder things than that. VXLANs running over [whatever], OpenVPN inside IPSEC and then ssh or RDP inside that. Obviously you don't do all of that routinely but I've seen some crazy shit to work around something or link up odd setups. I have seen a triple nested VPN: IPSEC within IPSEC and OpenVPN inside. I'm sure many here will have seen similar or worse.


[flagged]


A Layer 2 switch is something that works on the data link layer. A normal Ethernet switch falls into this category and the switching is done by MAC address.

A layer 3 switch is something that works on the network layer. It switches using the IP address.

A layer 3 switch is not a router. It does not switch based on the subnet/network mask. It just remembers which IP is on which port just like an Ethernet switch remembers which MAC address is on which port.


Switching = forwarding by looking at l2 headers

Routing = forwarding by looking at l3 headers

It does not matter one bit if above is done in software or an ASIC/FPGA/NPU, what the device looks at to perform it's forwarding decision is what matters, so one device may not just fit neatly into one OSI layer.

Layer 3 switch is mainly a marketing term, it's nonsense really. The devices that fits into that category are what would classically be switches (many ethernet ports, small buffers, cheap) but with full routing capabilities. Routers can be either software or hardware based. Software routers mainly make up the low-end offers from vendors, rich in features and cheap. Hardware routers that use ASIC/NPU's make up low-ish end to the very high end. Any router that ISP's use in their backbone will be the very high end and do all forwarding in hardware, have all QoS features in hardware, etc.


Layer 3 switches have routing / forwarding tables... They qualify as routers.


Which proves my point. Real world stuff rarely fits neatly into theoretical models/categories.

Real world Layer 3 Switches are a hybrid between a router and a pure layer 3 switch. In fact they're just a really fast router.

A normal edge router switches based on IP and a bunch of extra rules. These extra rules range from firewall stuff to QoS. These extra rules need software to process.

A core router is what is now called a Layer 3 Switch. It just cares about the IP address and because of that can be done in hardware making it really fast. It's still a router because as you said it still has routing tables based on networks and subnets.

I don't think anyone makes a true (non-router) layer 3 switch. The only use case I can think of would be a campus wide WiFi network.


"switching" is a layer 2 term. At layer 2, frames are switched. At layer 3, packets are routed. An edge router routes, based upon the destination IP adress (unless you have policies that cause a packet to be sent elsewhere).

Layer 3 implies routing, by the way. A "pure layer 3 switch" is called a router.


Again, theory and reality rarely line up neatly.

A switch moves packets between devices inside a network and a router moves packets between networks. Calling one a frame and one a packet is splitting hairs and irrelevant to whether something is a router or a switch.

Using a *BSD/Linux box I can make a L2 router. I can also make an real (non routing) L3 switch. And since "pure layer 3 switch" is my made up term I think I get to define what it means, thank you very much. It's something that doesn't route, or in other words, you can have the same network (i.e. subnet) on multiple ports.

Then we get into the definition of a network. Is it a building, a department, or how about multiple buildings all over the world? Or how about the network of a backbone provider? Their core "routers" are really switches as they pass packets to other devices inside their network.

And the network gear manufacturers are muddying things even more. Their definition of routing or switching is whether it's done in software or hardware. That's why they're calling some of their equipment a Layer 3 Switch. As I said, that really is just a fast router based on the above definition.

The easiest way to distinguish switching vs routing is whether the packets move to the same or different subnet. It's a good rule of thumb but there are always exceptions.

You can take an L2 switch and replace it with an L3 switch on your network and everything IP based will work as if nothing had happened. You'd just get less broadcast traffic.


> The data link layer is concerned with local delivery of frames ... [0]

> The network layer is responsible for packet forwarding including routing ... [1]

IP operates at layer 3. Layer 3, by definition, implies routing.

> Their definition of routing or switching is whether it's done in software or hardware.

No. No, it's not.

I think that, in general, you kinda sorta know what you're talking about (although you've got a few things incorrect) but the way you keep screwing up basic terminology really makes me wonder.

In networking, router, switch, frame, and packet are all clearly defined -- as are the various layers and the PDUs involved at each of them -- and mean specific things but you can call 'em whatever you want to, I suppose.

[0]: https://en.wikipedia.org/wiki/Data_link_layer

[1]: https://en.wikipedia.org/wiki/Network_layer


You've completely missed my points and at the same time gave a perfect example of someone who's rigedly trying to follow the OSI model.

> IP operates at layer 3. Layer 3, by definition, implies routing.

Layer 3 does not imply routing! I can shut down my internet link and still use a layer 3 protocol to talk to my file server from my workstation. No routing is happening because the packets are not leaving my network.

> > Their definition of routing or switching is whether it's done in software or hardware.

> No. No, it's not.

I know it's not. That's what the hardware manufactures are saying on their websites. It's stupid but it shows how blurry the line is between switching and routing.

> I think that, in general, you kinda sorta know what you're talking about (although you've got a few things incorrect) but the way you keep screwing up basic terminology really makes me wonder.

I know exactly what I'm talking about and know my terminology. The problem is you're trapped in the OSI model and can't see where things overlap.

> In networking, router, switch, frame, and packet are all clearly defined -- as are the various layers and the PDUs involved at each of them -- and mean specific things but you can call 'em whatever you want to, I suppose.

Routing and switching are not as clearly defined as you think. Just google routing vs switching and you get many variations. Some talk about frames and packets, others about MACs and IPs, but the core principle common to them all is that switching is in network and routing is out of network. A few also mention that routing is a more specific form of switching.

Your issue is you mistakenly belive that routing and switching are each tied to a specific layer in the OSI model. With that belief, yeah, frames are switched and packets are routed. But as I and others here have stated, things in the real world don't always follow the theoretical model.

Take for example the idea seen frequently online of doing away with the ethernet layer and having IP as the frame format. So now in the OSI model what was in layer 3 and 4 now become 2 and 3. Or does some of it drop and some stay in the same spot? It quickly turns into a mess. Mainly because what was supposed to happen in layer 2 (flow control and acknowlegements) is happening in layer 4 (TCP). Mainly because the designers of TCP did not follow the OSI model.

My point is that you can't use what was defined in the OSI model to rigedly define what's happening in real world protocols.

As I said, you can create a switch that operates at layer 3. It would learn what nodes are on each port by watching ARP requests. It would send out ARP replies for nodes on other ports with its own MAC and would also have to forward DHCP requests.

This device would function exactly as a switch. You could have the same subnet on many ports and it would work. You can move a node from one port to another and it would work. A router can't do those things. A router forwards packets based on their destination network.

But if you can't understand that and are stuck in the OSI model, we've esentially taken what was at layer 3 and put it in layer 2. The old layer 2 is just there for comatibility. You could even rip out one of the ethernet links between two of these layer 3 switches and replace it with a serial link that just transmits IP packets and everything would work as normal.


The only reason googling shows so much confusion is most people don't understand the definitions of routing and switching.

"Layer 2" = switching. "Layer 3" = routing. "Layer 3 switch" = a marketing term for an ethernet switch that is also a router, and supports internal routing between VLANs (and related optimizations for this common use case.)

Your "pure layer 3 switch" that only services a single subnet is actually a regular old layer 2 switch. It doesn't need to be aware of "layer 3" at all.


> The only reason googling shows so much confusion is most people don't understand the definitions of routing and switching.

No, it means that people are using a broader definition that is not locked into the OSI model. Both definitions are valid but the OSI one is a subset of the other one. Than means the OSI one can't describe certain network devices that exist in the real world. A layer 3 switch can't exist according to the OSI model. It can in the real world.

Go way back to the parent of this thread. See the sentence "Anyway, OSI model is mostly a mental picture that bear little practical relevance."? Yet you're here arguing we have to use the OSI model's definition of switching and routing.

> "Layer 2" = switching. "Layer 3" = routing.

Only if you think that the OSI model is the be all end all definition of what a network is. It's not. The TCP/IP designers didn't think so either and moved functionality that was traditionally in the lower layers to the upper layers.

> "Layer 3 switch" = a marketing term

Yes, it's been turned into a marketing term. But to understand why it's a marketing term you need to know what a real layer 3 switch is. Then it becomes readily apparent why they really created is a router with a handful of switching features rolled in for speed.

> Your "pure layer 3 switch" that only services a single subnet is actually a regular old layer 2 switch.

No it's not. If you could modify the end nodes in the network (you can with Linux or the *BSDs) to use the broadcast MAC address for the destination and have them ignore the ethertype field you'd completely bypass Layer 2. The layer 3 switches would still be able to function and switch packets to the proper nodes. A layer 2 switch in this situation would still work but would broadcast all packets to all nodes and thus stop acting as a switch.

> It doesn't need to be aware of "layer 3" at all.

If it's not aware of layer 3 at all then it's not a layer 3 switch.

A layer 3 switch by definition needs to understand layer 3. So if you had one that just switches using IP (v4 and/or v6) it would not be able to switch other protocols like IPX for example. A layer 2 switch would switch anything.


Please point me to a definition of a "real layer 3 switch." I would like to know. I've been working with TCP/IP for almost 25 years.

It sounds like you want to eliminate the broadcast domain... If you want point-to-point ethernet, put your end nodes on a IPv4 /31 (or /30, depending) and be done with it. You will have a "pure layer 3" environment: all traffic will be routed. No end node modifications required.


> Please point me to a definition of a "real layer 3 switch."

All definitions of layer 3 switch I've found were stuff like this: https://en.wikipedia.org/wiki/LAN_switching#Layer_3_switchin...

Those definitions are parroting the manufacturer's definitions. Those devices are routers with ASIC switching using the IP address.

My definition of a real layer 3 switch is this: A device that forwards packets based on the IP address. The decision on which port to forward is based on where an IP was last seen and not on a configured network/netmask value.

Nobody that I know of sells devices like this but you can build one for yourself. The reason I'm going on about a pure layer 3 switch is because it's on one end of the discussion about these hybrid "Layer 3 Switches" that the network manufacturers are selling. It's like trying to talk about what a mule is when you refuse to define what a donkey is.

So we have a pure layer 3 switch on one end and a layer 3 router on the other. The "Layer 3 Switches" that are now being sold are about 95% of the way towards the router side of that line.

> If you want point-to-point ethernet, put your end nodes on a IPv4 /31 (or /30, depending) and be done with it. You will have a "pure layer 3" environment: all traffic will be routed.

But then you're routing and have different subnets everywhere. You won't be able to transparently replace a layer 2 switch with that.

Ethernet framing is redundant. The LLC/SNAP header has already been deprecated by the IEEE so there's 8 bytes saved. The ethertype field is redundant as the first byte of the payload will tell you if it's IP v4 or v6 so there's an extra 2 bytes. The source and dest MAC addresses are redundant as we have source and dest IP addresses so there's a 12 byte savings. The vlan tag would need to stay for now because of IPv4 but we could replace it by repurposing some of the 0 bits in an IPv6 link local address. The preamble, SFD and FCS would stay although the preamble might be able to be shortened as it's minimum length was dictated partly by how many hubs a packet could cross.

So you replace your layer 2 switch with this layer 3 switch. Everything still works with no configuration necessary. As new network cards that can do IP framing come out you configure each port from ethernet framing to IP framing. So now it's a Layer 3 switch on some ports (Ehternet framing) and a Layer 2 switch on others (IP Framing).

Once all ports are switched over the device has now become a Layer 2 IP switch. Now you can see why I don't like the definition of Layer 2 = Switching, Layer 3 = Routing. The device functions as a switch regardless of the framing on each of the ports.

If you use the more general definition of Switching = inside the same network (i.e. subnet) and Routing = between networks then things become more clear.

I know some people on the internet want IP framing to become a thing. Will it? Maybe, maybe not. But by using the more rigid OSI definition of switching and routing it becomes harder to talk about topics like that.

That's why we have TCP/IP now. Because some people were willing to think outside of the OSI box.

> It sounds like you want to eliminate the broadcast domain

It wouldn't eliminate it. The broadcasts would eventually become either IPv4 broadcasts or IPv6 multicasts. It would reduce the sizes of the domains and reduce traffic however.



Please add (2014) to the title.


For sure! MacSec has gained in popularity lately, and a lot of the issues the author raises have been solved by other efforts.


its hiding in the discourse, but I think author would be better off completely abandoning the notion of a canonical stack and provide a categorization of functions - routing, identity, reliability, etc


Well it turns out that security is getting set up in other layers but these are for more specialized applications than general run of the mill internet usage. For example there is encryption available at the physical layer even at very high data rates. Additionally there is MacSec which is a layer 2 technology. It's curious that the author mentions neither.


John Day maintains that OSI was never fully implemented. Cf. "Recursive InterNetwork Architecture" https://en.wikipedia.org/wiki/Recursive_InterNetwork_Archite...




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: