Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Inventor of OpenFlow SDN Admits Most SDN Today Is Hype

Unknown Lamer posted about a year and a half ago | from the cloud-soft-net-2.5-synergy dept.

Networking 62

darthcamaro writes "Every networking vendor today is talking about Software Defined Networking (SDN). The basic idea is that the control of the underlying networking hardware is abstracted by software. Martin Casado helped to come up with the whole topic with his 2005 Stanford thesis (PDF). Eight years later after selling his startup Nicira to VMware for $1.2 Billion, Casado sees the term SDN meaning everything and nothing to all people. From the article: '"I actually don't know what SDN means anymore, to be honest," Casado said. Casado noted that the term SDN was coined in 2009 and at the time it did mean something fairly specific. "Now it is just being used as a general term for networking, like all networking is SDN," Casado said. "SDN is now just an umbrella term for, cool stuff in networking."'"

cancel ×

62 comments

Sorry! There are no comments related to the filter you selected.

"The Cloud" (0)

Anonymous Coward | about a year and a half ago | (#43586513)

The amount of terminology is increasing along with the technological advancement, I prefer the latter.

Re:"The Cloud" (2)

davester666 (731373) | about a year and a half ago | (#43587551)

Yes, SDN hardware will definitely help with your cloud problem. It works with all cloud software stacks and is the final piece of the puzzle to make it all work together.

We can start shipping hardware to your data center and all your offices today, just sign here. And yes, we will have engineers at all your sites to properly install and configure the hardware and train your IT personnel. They will stay on-site until all issues are resolved.

Innovation, SDN, Cloud, etc... (0)

Anonymous Coward | about a year and a half ago | (#43586533)

Innovation - another word killed by marketing

Marketing doesn't kill innovation (2)

Taco Cowboy (5327) | about a year and a half ago | (#43587315)

Marketing does not kill innovation

What really kills innovation is the management's blind push to squeeze the last penny out of existing products

Instead of making improvement, instead of thinking out of the box, instead of innovating --- the bottom-line minded management prefer to "squeez another drop of blood out of what we are producing" instead of pumping money into more R & D, or give the "crazy ideas" a try

Re:Marketing doesn't kill innovation (1)

_Shad0w_ (127912) | about a year and a half ago | (#43587421)

Actually my experience is of them trying to cram more and more features in to existing software, rather than improving and fixing the bugs in the ones that are already there.

Re:Marketing doesn't kill innovation (1)

Austerity Empowers (669817) | about a year and a half ago | (#43587727)

My experience is that corporations are top to bottom insanity. Progress happens only because one or two dedicated people care enough to create something on their own time, at their own risk and deliver it.

If you're expecting marketing, management or quorum, you're lost.

Re:Marketing doesn't kill innovation (2)

tibit (1762298) | about a year and a half ago | (#43588011)

I disagree. I think that squeezing "yet another drop out of what we are producing" is simply leveraging what you have. Suppose you have a piece of hardware that was specified some time ago, but you have a new functionality requirement for the firmware that wasn't in the original spec. You can either throw new hardware at the problem, with a more capable CPU, or you can use what you have. In the latter case, supposedly it's a piece of hardware that has large deployments, has been field tested, and is something you can depend on. Given that you have to implement new features in the firmware anyway, keeping the old hardware and implementing it there may well save you quite a bit of effort. Instead of going on two fronts, with new hardware and firmware, you deal with firmware only. Yes, it may require a bit more finesse to squeeze the new functionality into the less capable hardware platform. My experience is that it's not that big of a deal. Yes, you may have to deal with limitations of the platform, but those often turn out to take a small fraction of the work spent. Most of the time is spent on new features and would be the same time spent whether you reuse the old platform or do it on something brand new.

Re:Marketing doesn't kill innovation (2)

datavirtue (1104259) | about a year and a half ago | (#43592353)

Maybe it is not management's inability to think outside the box, but instead the IT department's lack of business focus and the ability to communicate WHY changing or upgrading will help the business be more profitable. I'm really disappointed at the narrow mindset of the average IT person. No business training, no accounting, no business sense. I'm tired of being associated with the IT department and being lumped in with these technology monkeys.

Riding the hype train (3, Informative)

GeneralTurgidson (2464452) | about a year and a half ago | (#43586553)

I need to build a business around some new buzzword and sell it to VMware. Cloud and everything related to it has really stagnated development of other areas of IT in my opinion. Companies try and figure out WTF SDN is or how to integrate their networking stack with AWS instead of focusing on what's really happening in the IT world.

Re:Riding the hype train (0)

Anonymous Coward | about a year and a half ago | (#43586707)

It's either SDN or more smartphones.

Re:Riding the hype train (0)

Anonymous Coward | about a year and a half ago | (#43589523)

You need to invent and popularize a new buzzword, that's where the money is. "Cloud" is starting to get saturated.

Re:Riding the hype train (1)

aix tom (902140) | about a year and a half ago | (#43592807)

I think I will register "Smog" as the next IT buzzword.

It's the next big thing, so believably cool that not even I know what it is. But whenever something goes wrong, from now on I will always advise that we can correct the problem by transferring the process into the Smog.

"Software defined computing" (4, Funny)

Anonymous Coward | about a year and a half ago | (#43586555)

It's the way of the future.

So we aren't going to be able to replace... (4, Funny)

John Hasler (414242) | about a year and a half ago | (#43586559)

...all the fiber optic cables with software? We aren't going to move everything to the cloud, including the cloud?

Re:So we aren't going to be able to replace... (2, Funny)

Anonymous Coward | about a year and a half ago | (#43586641)

...all the fiber optic cables with software? We aren't going to move everything to the cloud, including the cloud?

Better be careful. God's gonna disappear in a puff of logic if you're not.

Re:So we aren't going to be able to replace... (-1)

Anonymous Coward | about a year and a half ago | (#43586943)

Wow. A slashfag goes totally off topic to bash religion.
 
News at 11.

Re:So we aren't going to be able to replace... (4, Interesting)

fuzzyfuzzyfungus (1223518) | about a year and a half ago | (#43586667)

Certainly not all of them; but I'm pretty sure that the box they are all plugged in to is, pretty much, using a software layer to abstract the ugly details of dumping traffic between them over a really, really, fat internal bus of some flavor.

And, in many cases, a single fiber is(thanks to software) being sliced up into a bunch of little VLANs to create a logical topology that (while it is ultimately constrained by the physical one) is substantially different than the physical topology, especially once you count aggregated port groups, redundant links, and so on.

'SDN' doesn't mean jack in part because everything except your 20 year old 10Mb hub is already doing some amount of software trickery(even dumb switches keep track of which MAC(s) are on which port, and anything with 'managed' in the title can do quite a bit more), with varying levels of ASIC vs. general-purpose-CPU and varying levels of correlation between the logical topology and the physical topology.

There just isn't a nice bright line(at least in terms of real-world use cases, obviously a VM chattering to itself over a loopback interface is 'software' and a passive ethernet tap is 'hardware') between what is 'software defined' and what isn't. They all obviously depend on hardware to execute the software; but the amount of additional logical complexity slopes up surprisingly smoothly.

Re:So we aren't going to be able to replace... (1)

swalve (1980968) | about a year and a half ago | (#43587325)

I'm guessing the goal is to use more or less comoddity hardware. Why build an ASIC when you can solder some broadcom chips to a backplane and do all the fancy shit in software?

Re:So we aren't going to be able to replace... (1)

Austerity Empowers (669817) | about a year and a half ago | (#43587735)

latency, throughput

Re:So we aren't going to be able to replace... (4, Informative)

Lennie (16154) | about a year and a half ago | (#43588987)

SDN in practise just means, networking things (private networks, VPNs, loadbalancers, etc.) have an API so they can be automated.

So when you need to scale out, because your website has more visitors during the day then you don't just get new VMs but those VMs also get connected to the right networks or extra load balancers gets added as well.

The software in software defined networking, is the application specific software. That application can be that website as mentioned above or something completely different.

For example Google uses their self-developed software to reserve bandwidth for their different applications and data-replication jobs and handle link failover on the WAN-links between their datacenters.

Because they used OpenFlow their were able to save money on their WAN-links because they get better utilization than traditional methods. They have normal Google servers that 'directly' configure the forwarding tables.

Re:So we aren't going to be able to replace... (1)

Shatrat (855151) | about a year and a half ago | (#43589689)

Thanks for actually posting an intelligent comment. Everytime there's a story that involves technology I work with I realize how ignorant most of Slashdot really is.
The API I think is the key observation. Forget websites though, that's chump change.
SDN is actually really interesting for my industry, long haul fiber networks. Today we have multiple layers of equipment, the physical fiber plant, the DWDM layer, the OTN layer, the Sonet or Packet transport layer, the IP/MPLS layer. Today those layers don't talk to each other so all the configurations are manual and static. The hope is that SDN succeeds where GMPLS has sort of stalled. GMPLS is really only used in some proprietary network implementations, and not as an interface between different vendor equipment as it was envisioned.

Re:So we aren't going to be able to replace... (1)

Lennie (16154) | about a year and a half ago | (#43599135)

Websites was a an example of 'cloud computing', I wouldn't call Amazon AWS and the others chump change.

Re:So we aren't going to be able to replace... (0)

Anonymous Coward | about a year and a half ago | (#43592721)

Actually Google's OpenFlow based back-end backbone has been an endless source of problems and Urs lied during his presentation when he said that was the only back-end backbone Google was using as there were plenty of off-the-shelf routers still active. So it's not a very good example.

--

Brandon Downey, security expert.

Re:So we aren't going to be able to replace... (1)

Lennie (16154) | about a year and a half ago | (#43599175)

I think the Google backbone example isn't a good example because very little people have the luxury problem Google has: lots of links which are not a 100% utilized and enough developertime to spend to fix.

Re:So we aren't going to be able to replace... (4, Funny)

istartedi (132515) | about a year and a half ago | (#43587579)

We aren't going to move everything to the cloud, including the cloud?

Sure we can. It's all based on something I call the "metacircular evaluator". My consultancy and I can install MEs in all your software systems so that you can move the software into the software, and define your business in terms of your business. "My god!" the tech business reporter exclaimed, "this is the most revolutionary thing I've ever heard, tell me more about how these MEs work".

Well, you just have to re-write everything in Lis--. And then, before I could even finish, the room was empty.

Re:So we aren't going to be able to replace... (1)

gandhi_2 (1108023) | about a year and a half ago | (#43587827)

There's a yo dawg / turtles all the way down in here somewhere....

Thesis link (0)

Anonymous Coward | about a year and a half ago | (#43586579)

points to a paper... but still good to get the main idea.

Now that he's cashed in... (2)

gatkinso (15975) | about a year and a half ago | (#43586625)

...no reason not to be honest.

Re:Now that he's cashed in... (3, Insightful)

girlinatrainingbra (2738457) | about a year and a half ago | (#43586839)

SDN is the hot new buzzword, just like "cloud" computing has been for the last few years. Buzzwords fly by. I agree with you that he can afford to be honest, but he's not just being honest, he's pointing out the "fuzziness" of what the term "SDN" is being applied to.
.
I believe he had a fixed and set definition which he must have specified with some detail in his thesis (isn't that what you're supposed to do in a thesis? be specific?), but nowadays everyone and anyone is calling any configurability of the top or higher levels of networking as "Software defined networking".

Re:Now that he's cashed in... (1)

Lennie (16154) | about a year and a half ago | (#43589001)

Software defined in my mind just means, it has an API so that application specific software can control it.

Re:Now that he's cashed in... (1)

girlinatrainingbra (2738457) | about a year and a half ago | (#43589357)

re: it has an API so that application specific software can control it.

That is pretty much what I meant by "configurable"! You just expressed it more clearly and specifically, as one ought to in a thesis or in a thesis statement! I strongly agree with you.

Re:Now that he's cashed in... (2)

AK Marc (707885) | about a year and a half ago | (#43587019)

He was never dishonest. The problem was that people not wanting to sound dumb, don't question buzzwords. I've shut up every SDN proponent I've run across by asking "what does this do that couldn't be previously done with an ACL?" Nobody could give me an answer. I'd be interested if anyone here can tell me one thing SDN does that a layer-7 ACL couldn't do (assume the functionality of an ACL, but with DPI for the trigger case).

The closest I've come is having a switch sniff for SIP traffic and setting up every call in a unique VLAN, from source to destination, or something like that. No idea why one would want to do that, or what you could do with it after that, or how you'd make it work if you had non-SDN nodes in the middle, but hey, it's at least something it "could" do. I've spent millions proving "dynamic" is bad. "dynamic dedicated bandwidth" is something the company I work for now is selling. The customer can bump up and down their bandwidth. It's expensive, as you have to dedicate the maximum possible to them so that they could use it if they tried, but it gives the impression of cool features, so people pay more for it.

All it was initially was a way of emulating a switch/router in software to use within VMs to handle communications within the box. Then someone said "can't we use that as a router for non-VM?" It was then something someone didn't understand, and you can sell something that's not understood better than something well understood.

Re:Now that he's cashed in... (1)

Anonymous Coward | about a year and a half ago | (#43588171)

If the CAM (Content Addressable Memory) is wide enough to also match on application data in the packets, you can use switches to deliver network packets to the correct server without using the normal network addresses:
- for example a load balancing switch (low latency and cut-through (up to the end of the matched data of course)).
- A network middle ware for pub-sub architecture which can handle a higher number of data-channels.
    * instead of using the multicast addresses one could use partial matches on the channel name (the channel name could be a wild-card searchable dictionary of keywords/attributes).
    * You could broadcast all the channels to all the switches, but let the subscribers select very specific channel on the output of the switch. This can be done on a single multicast address, which is important because network cards can only subscribe to a limited number of multicast addresses before it switches to promiscuous mode.
    * Network card themselves could contain SDN to deliver the channels in the correct place in memory, maybe overwriting the older data so the channel memory buffer always contains the latest broadcasted state. The software on the computer no longer has to parse network packets, or even using the read system call, just a (interrupt based) notification mechanism and then simply use the latest state as it was written to memory by the network card.

I could go on, there is a lot of things SDN could do. Sadly the companies making SDN equipment have no fantasy.

Not Thesis (1)

Anonymous Coward | about a year and a half ago | (#43586675)

I hope that link isn't to the actual thesis paper, because it's only a few pages and describes the most obvious thing in the universe, and more importantly nothing that hadn't been written like a 1000 times before. I hope that his little toy network VM described in that article isn't the genesis of "SDN", because that would either make "SDN" complete bull* from day 1, or make him and everyone else look completely idiotic.

Re:Not Thesis (1)

tibit (1762298) | about a year and a half ago | (#43588057)

It's not bullshit, it's just packaging of existing technologies, for a particular purpose. An SDN client-server connection, apart from housekeeping, is just TCP/IP encapsulated ethernet traffic. Pretty much like remote TUN/TAP. It was designed to solve a particular problem: that of letting students operate on live internet traffic from their own development environment, without having to muck with low-level platform details of how you get the ethernet packets in and out. Turns out it was useful for a few more things than just teaching networking.

dunno (2, Interesting)

Anonymous Coward | about a year and a half ago | (#43586685)

So the only benefit to "SDN" whatever it is that I can tell is that it will could possibly allow source routing. The existing protocols basically will route your packet the shortest hop way or another under guidance of some other metric, unless you set up the router to do some hacks (I hear). The setting up part is done by a human, a network engineer, and the SDN folks think that it shouldn't be done by a network engineer, it should be done by end point software because the network engineer is a human so he is slow and therefore a lesser being than the software engineer, who thinks he knows better. The other reason is that the router vendors are slow in making features available (who needs testing) or fixing bugs in the routers, so the SDN guys think they can write software that does the same thing better and faster.

One application of being able to source route is to trunk over multiple slow links, which normally won't happen with typical routing protocols which will give you one of the routes, usually the lowest-latency link though that is purely up to configuration. Trunking would give you the whole net's bisection bandwidth. Until someone else wants to do the same thing at the same time. "What, there's other software engineers who have machines connected to the Internet?"

Another is on-demand QoS. The killer app is probably to build a DDoS infrastructure foothold into nation states' critical systems. Imagine having wire-rate SDN routers being able to reflect and replicate from within the network.

Re:dunno (3, Funny)

postbigbang (761081) | about a year and a half ago | (#43586941)

You mean "infecting" servers with router VM appliances that smoke government blocks by creating backdoor VPNs, proxies, shadow VLANs and stuff?

Never happens.

Re:dunno (1)

Zero__Kelvin (151819) | about a year and a half ago | (#43591937)

I'm not worried about that. I'll just back hack their IP and decrypt their SDN API !

Re:dunno (3, Informative)

ppanon (16583) | about a year and a half ago | (#43587627)

From what I read of SDN, the idea is to have centralized routing (presumably for use within a data centre, telco, or high-performance campus network) instead of decentralized routing. Instead of having each individual node recalculate routes using tree-based routing algorithms like OSPF, a central node with a holistic view of the network recalculates and redistributes routes using algorithms that allow more fine grained slicing of packet flows for closer to optimal load balancing and congestion management.Unless you're a telco, a co-lo, or have a datacentre with >5 racks steadily generating >50Gb/s of network I/O per rack and needing high availability, it's doubtful that you need to pay the premium for it.

pffffFFF FPGA HA HA HA! (3, Informative)

VortexCortex (1117377) | about a year and a half ago | (#43586719)

I'm glad he's laughing all the way to the bank. Gives me room for my new buzz-word compliant technology: Hardware Optimized for Software Systems (HOSS)

Shhhh, it's just ASIC in sheep's clothing.

Synergy Man! (1)

Dareth (47614) | about a year and a half ago | (#43590529)

Hey we need to get some Synergy going between your HOSS and my Packet In My Packet (PIMP) protocol. I can totally pimp your hoss you know what I mean!

Re:Synergy Man! (1)

Zero__Kelvin (151819) | about a year and a half ago | (#43591979)

Your Packet in My Packet protocol violates my Packet in My Pocket patent.

Words (2)

BradleyUffner (103496) | about a year and a half ago | (#43586777)

If you wanted your new buzzword to have a real meaning perhaps you should have named it something that actually means something. The words Software Defined Network have a generic, non-specific meaning, that's why they are being applied to everything that even remotely fits their definitions. Whatever happened to real names with specifics, like "Carrier sense multiple access with collision detection"

Sofware Defined Networking is hype (0)

Anonymous Coward | about a year and a half ago | (#43586857)

People have figured that out.

What I'm working on is Semantic Networking, a composite framework leveraging domain-specific advances in AI (in software) and nanotech switching devices (in hardware). This will be THE game changer.

Re:Sofware Defined Networking is hype (0)

Anonymous Coward | about a year and a half ago | (#43587367)

Great, I can finally hook my Concept Addressable Store up to a network!

Software Defined Networking (2, Interesting)

hackus (159037) | about a year and a half ago | (#43586903)

From what I can tell it is the idea of having all of the routing centralized at one location with nodes which just accept the commands to route certain src and dst streams. It is different because the software defines the routing on a server in a logical representation for centralized management while the nodes are just really hardware appliances.

It is a nice idea to reduce cost, but in my opinion this is where you would never want to do something like this because it allows way too much power in a central authority.

It would be a Chinese government dream network though and the NSA/CIA would piss themselves that ever happened.
(i.e. In such a system the distributed BGP internet would just go away.)

I am totally against it, and I think everyone will be after they see what the real intent is: To bring network layer control through software to a central authority, which isn't possible right now, and once done, shut it down whoever isn't in the 1%.

-Hack

Re:Software Defined Networking (2, Informative)

Anonymous Coward | about a year and a half ago | (#43587007)

You have zero idea what you are talking about. OpenFlow is a wipe of 25 years of networking crap. It does not hand over control to the government anymore then running BGP on your network does. The idea is that within your network, lets say you are a datacenter operator, you can impose policy over a group of switches and routers. They become a dumb packet forwarding engine. Why would you want to do this? Lets say you are an operator selling VMs. You offer an up-sell option of providing a FW or SLB to the customer. Now lets look at this from the point of view of the network. Server - ToR - Core - Services (FW/SLB) - Router. All networks are a variation on that design for the most part. Notice how the FW and SLB are in the path - even if you do not want them to be? With an OpenFlow network you could move those services to the side, in a rack of their own. The controller could then be told that packets from VM X must go thru the FW 1st before going out. Switch sees a flow, ask the controller, hey what should I do? Controller installs a flow_mod, go to firewall - the packet SA/DA is the router but who cares? Shows up at the firewall, stuff happens then gets sent to the router. Someone buys the FW option - order page tells the controller and it just happens. 4096 VLANs limit? Whats that? Build a full L2 10/8 network. You can enforce the rules that host 1 at 10.0.0.20 and host 2 at 10.0.0.21 cannot talk at the controller level. No ACLs. Broadcast packets? What are those? You send an ARP for something and the controller answers, no need to flood.

Check out www.bigswitch.com.

Re:Software Defined Networking (2, Informative)

Anonymous Coward | about a year and a half ago | (#43587203)

congratulations. you've just substantially raised the complexity of the installation and gained absolutely nothing
in terms of performance, or policy expression, or security.

have fun masturbating

Re:Software Defined Networking (2, Informative)

Anonymous Coward | about a year and a half ago | (#43587213)

oh yes, and drastically reduced the fault tolerance

Re:Software Defined Networking (0)

Anonymous Coward | about a year and a half ago | (#43587305)

I agree with both of these comments. It seems that the slashdot hivemind knows nothing or next to it about networking, protocols, or how real implementations work.

It is just a huge group of programmers thinking they are god and spouting off.

Re:Software Defined Networking (2)

_Shad0w_ (127912) | about a year and a half ago | (#43587443)

I seriously doubt that many of us are programmers any more.

Re:Software Defined Networking (3, Interesting)

ppanon (16583) | about a year and a half ago | (#43587685)

In theory, the centralized routing agent, by having a global view of the network, can both optimize load across links and adjust to congestion patterns better than a distributed network infrastructure can. So for telcos and other colos, that can mean better uptime and more efficient use of expensive high-end infrastructure. Just as a centralized traffic light control system for a city can identify congestion hot spots and adjust light timing to reduce congestion better than isolated traffic lights can.

For instance, if nets A, B, and C are linked in a loop for redundancy, spikes of traffic between A and C could be load balanced by shifting certain source-destination pairs over the link to B to avoid congestion, even though it would normally be faster to go over the A-C link and that's what an OSPF router would do. Alternatively, in the longer term, a telco could make more effective use of fibre if it could temporarily re-allocate fiber currently not used for voice to deal with a spike in data traffic.

Re:Software Defined Networking (0)

Anonymous Coward | about a year and a half ago | (#43587343)

Nice explanation. Thank you.

Re:Software Defined Networking (1)

silas_moeckel (234313) | about a year and a half ago | (#43587423)

The funny thing is that sort of stuff has been done for years in VM hosting without all the virtual network bits. Early last decade hosting providers were using routing protocols to shift inbound traffic about and rewrite tricks for the outbound to make sure bits got to the right physical went though the right firewall or load ballancer or what have you. Well before this kid wrote his thesis.

As to bigswitch there best hardware I could find was a handful of 40ge ports and a few 100ge on a "core" switch that can handle 128k routes. That's something you use to agg the TOR switches and connected up to the core with a default gw.

Phn mm nh ngha mng (-1)

Anonymous Coward | about a year and a half ago | (#43587255)

[url=http://aoqua.sextgem.com/Anh-sex-han-quoc-2] Anh sex han quoc[/url]

Virtual circuit network (5, Informative)

Animats (122034) | about a year and a half ago | (#43587351)

OpenFlow is basically a way to turn a packet network into a rather dumb virtual circuit network. It works something like Tymnet, circa 1971. In Tymnet, all the virtual circuits were set up by a "supervisor" computer, which told each node where each flow was supposed to be forwarded. The supervisor also handled authentication, but data packets didn't have to pass through the supervisor once the connection was set up. That's what OpenFlow does, mostly. The first packet of each new "flow" (IP/port/IP/port set, usually) is sent to Master Control, which decides whether that flow will be allowed. Master Control can also choose to monitor the flow. The implications are obvious.

DOCSIS 3, the cable modem traffic control architecture, can potentially do most of the same things, and offers better control over bandwidth. DOCSIS 3 tends to be run more to control users than to maximize throughput, but that's a marketing issue. (If your cable connection is throttling something, the commands to do it were probably sent to a DOCSIS node.) There's good QoS and fair queuing stuff in DOCSIS 3, but it's not always used intelligently. DOCSIS is less intrusive than OpenFlow; the nodes are sent rules to enforce, but there's no need to get permission of Master Control for every new flow.

The rest of "software defined networking" seems to involve adding another layer of indirection to Ethernet addresses so they can be moved around within the data center. ("There is no problem in computer science that cannot be solved by adding another layer of indirection.") That's a reasonable network management tool, but it's not exactly a profound concept.

Re:Virtual circuit network (2)

Lennie (16154) | about a year and a half ago | (#43589029)

With OpenFlow you can preconfigure most of the forwarding entries (not just routing) as well.

Re:Virtual circuit network (0)

Anonymous Coward | about a year and a half ago | (#43589437)

you seem to be implying a 1:1 correspondence between tcp
connections and flows, and i don't think this is the case. from
my reading of the standard, there can be fewer flows than ports.

Software Defined Networking is what small ISPs do. (2)

citizenr (871508) | about a year and a half ago | (#43587573)

It is used (without knowing they are using it) by people that avoided legacy one router/cable per task Cisco mentality.
Remember Cisco 1700/2600/3600 and how doing ANYTHING on them cost you ass load of money? It was never a question of what should we do, it was always a question what thingamajiggy we should buy to do this one specific thing we want.
Never generation stopped to give a shit about Cisco/Agere/Lucent/Juniper and started deploying all manner of embedded Linux/BSD with software routing. Sure it is slower than dedicated silicon, but it is also much cheaper and more flexible.

Re:Software Defined Networking is what small ISPs (1)

Lennie (16154) | about a year and a half ago | (#43589045)

SDN isn't about commodity hardware per se, it is more about having an API to configure/control and especially automate the network.

SDN is so last year. Those in the know are getting (0)

Anonymous Coward | about a year and a half ago | (#43589423)

Performance
Oriented
Realtime
Networks

Seriously folks, watch this space.

Is SDN what iptables does? (0)

Anonymous Coward | about a year and a half ago | (#43589459)

I've been doing "software defined networking" since the 90s using iptables (and its predecessors ipchains, fwadm, etc). I've gotten to where I can't tell what's a real network connection and what's an iptables tunnel sometimes. What makes this new and special? Wait, you BUY HARDWARE to do SOFTWARE DEFINED networking? Say what? Why not just use the same Linux box that's sitting there idle 90% of the time?

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?