I agree with this statement - "Let's make sure we know what we need before we launch a major buildout that will need to be redone many times before it's suitable for the intended purpose", mentioned by JeffL_2; The issue is how do we go about it. So many vendors leap into the market with proprietary technology or methodologies (ala CISCO and EIGRP) and then try to make it the standard, instead of using patience with the standards committees like the IETF and JEDEC and waiting for the markets and the standards to mature. And why do they do this? Security. We all admit we enjoy having jobs. It is trust in ourselves that insures that we eat, but it is trust in others that insures our survival. Also, I believe it's a false assertion to claim we can only endorse either SDN or ASICs implement methodologies -when Reconfigurable Hardware has only just recently emerged. But it may require us to hand over significant authorization power to others -the free market (ie unemployment!). Which brings me back to our circular dilemma which we refuse to face: our fear of job/career security. There is a diamond within reach, but we refuse to let go of the sand.
The problem I see is we're only talking about IoT as a "market" rather than having a more meaningful definition that would shed some light on what our primary concerns ought to be. For example to the extent that it will be used for control instead of just monitoring, security will tend to get a lot more focus, otherwise any "script kiddy" with a Raspberry Pi could bring havoc to the system. Ironically at least on the "big iron" switches it frequently takes something on the order of a DDOS attack to mess things up, if on the other hand you're dealing with a significantly narrower bandwidth it takes a much LESS structured attack to create significant problems! Remember even on the systems we use now the "dumb router" that was necessitated by early IP address limitations became the "firewall" we now rely on to help address our security shortcomings, it would be preferable if we didn't have to suffer through that all over again. If we have to proliferate crypto strategies throughout IoT then the minimum MIPS requirement per node goes up substantially. Let's make sure we know what we need before we launch a major buildout that will need to be redone many times before it's suitable for the intended purpose.
Sorry, but I think this topic of SDNs, much like IoT and "cloud computing," is mostly trade press/marketing buzzword hype. It gets taken way too literally, like something brand new, when in fact it's "more of the same." By which I mean literally MORE, of what we've known for decades.
Routers and layer 3 switches are becially identical devices, as far as their function goes, and as far as how they operate within Internet Protocol routed networks. The difference is only in how they are built. In order to allow faster speeds, what the hype calls "layer 3 switches" do most of their routing functions in hardware.
If you want to adjust the way these devices operate in real time, for instance changing the routing priorities of different queues, then you have to allow for these functions to be done in software. Also if you want to adjust the remote monitoring of minute aspects of each device, that too will drive you to a more software-oriented router. Obviously, the larger a network is, the more you may want to monitor and adjust these devices remotely. Everyone has known this for years and years.
So it becomes a balancing act. To think that Cisco and any other router vendor aren't fully aware of these tradeoffs is naive. And same as always, the device makers will introduce proprietary solutions, in their otherwise commodity products, to solve specific customer requirements in particularly clever ways. While at the same time, also offering the standards-based solutions that the marketing hype encourages the corporate buyers to ask for.
In a few short years from now, we'll look back at today's buzzwords du jour and we'll see that in fact, things progressed along a predictable and continuous line, without any obviously jarring change in direction.
A Book For All Reasons Bernard Cole1 Comment Robert Oshana's recent book "Software Engineering for Embedded Systems (Newnes/Elsevier)," written and edited with Mark Kraeling, is a 'book for all reasons.' At almost 1,200 pages, it ...