Live from the home of tack – i.e. Vegas, the Blackpool of the desert but without the classiness…or piers – is the latest bombardment of SDN, er, ness, care of Interop 2012.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
Starting with a direct follow-up to my last blog entry – HPs take on SDN, AKA VAN (ok – enough TLAs…) or Virtual Application Networks, the big question was, who was going to drive the VAN since HP doesn’t have the whole solution to deliver it? The answer is F5 Networks. So, the idea is to being to deliver a completely optimised, end to end solution on a per user/per application basis by using templates to define every aspect of performance etc. Makes total sense, sounds too good to be true. So, what’s the answer – test it of course; watch this space on that one.
Meantime, I’ll be reporting in daily from the show – seeing lots of new (to me) vendors who, one way or t’other, are all ticking the SDN/Big Data/Cloud boxes.
It seems to me that we need to get back to basics with SDN so that people actually understand what it is. For example, there’s a definite belief among some that it does away with hardware… Nice idea – so we have software that exists in a vacuum that somehow delivers traffic? There also seems to be confusion between different vendors SDN solutions and OpenFlow. For those wot don’t know, here’s what OpenFlow is – in a classical router or switch, the fast packet forwarding (data path) and the high level routing decisions (control path) occur on the same device.
An OpenFlow Switch separates these two functions. The data path portion still resides on the switch, while high-level routing decisions are moved to a separate controller, typically a standard server. The OpenFlow Switch and Controller communicate via the OpenFlow protocol, which defines messages, such as packet-received, send-packet-out, modify-forwarding-table, and get-stats.
The data path of an OpenFlow Switch presents a clean flow table abstraction; each flow table entry contains a set of packet fields to match, and an action (such as send-out-port, modify-field, or drop). When an OpenFlow Switch receives a packet it has never seen before, for which it has no matching flow entries, it sends this packet to the controller. The controller then makes a decision on how to handle this packet. It can drop the packet, or it can add a flow entry directing the switch on how to forward similar packets in the future.
In other words it provides one, open-standard methodology of optimising traffic, end-to-end, but it is not a solution in its own right, just a potential part of the action.
Whatever – the interesting theme here is that no one talks about MPLS any longer (well maybe apart from Cisco and Juniper that is) despite it still being THE methodology used to move all our data around the ‘net and beyond. There are factions that stand for the WAN optimisation kills MPLS idea. And for good reason – but there’s no overnight change here, given the gazillions invested in MPLS networks. It’ll be interesting to see what the vendors here make of the situation, at least from a timeline perspective…
Meantime it’s showtime, meaning a walk past a beach, complete with wave machine and hundreds of Americans trying to get skin cancer, in order to get to the exhibition halls – this is Vegas, after all.