OpenFlow takes networks in a different direction

An easier route

Top three mobile application threats

As network topologies and data access patterns have evolved, load profiles can change so quickly that a completely new approach to networking is required. That approach is OpenFlow.

According to Renato Recio, IBM Fellow and system networking CTO, life before the advent of x86 virtualisation was simple: client computers did most of the heavy lifting.

They crunched the data, dealt with files and mostly moved stuff back to servers as a form of centralised storage. In a campus environment, this north-south data flow could account for up to 95 per cent of the traffic. 

In this scenario, multiple client computers needed to talk to a single, central set of servers. These computers rarely flattened their provided network connections and so you could oversubscribe the connection between their access switch and the next level of switch.

Continue this game until you have a small number of very fat pipes talking to your core switch and your big servers.

Talk show

Eventually, servers started doing most of the work by themselves. The web server talked to the database server, which talked to the object storage head node. The application server is talking to a separate database server and everyone’s talking to the authentication and logging servers.

Recio views it by the numbers. “I think it has always been east to west in data centres,” he says.

“Microsoft published a paper in 2010 that found 75 per cent of traffic in a service provider data centre was east to west, 50 to 60 per cent in an enterprise data centre. Most of this east-to-west traffic takes place within a rack.”

Those oversubscribed links start to look like a bad idea

The traditional tree topology starts to show strain here. Servers tend to be capable of doing a lot more heavy lifting behind a single network link than your average client system ever did.

Those oversubscribed links start to look like a bad idea. With judicious planning, you could keep workloads within a single rack, and non-blocking access switches save the day.

Then along came virtualisation and suddenly we’re back out into the weeds. In a fully virtualised datacenter, any workload can be located on any physical server inside any rack. Not only that, but these workloads move. The tree-topology, oversubscription-based network model has become a weakness.

For truly dynamic data centres to work, static network design ends up having to swing entirely the other way – adding massive amount of additional capacity just in case your highest-load (but completely interdependent) servers end up on opposite ends of the network diagram from each other.

Add in the modern push towards converged networking and the network simply had to evolve.

One solution to this problem is OpenFlow.

“Look at all the hypervisor platforms that are out there,” says Recio. “They all live in layer 2. Overlays are going to change that, but now they all live in layer 2. That means you have to stretch the size of layer 2 so that virtual machines live not just in a rack, but across racks.”

Clear the trees

This takes some doing. “To stretch that data centre across layer 2, you really need multipathing. We have a lot of different ways to do this. There’s Trill, and a lot of people doing proprietary things. OpenFlow is another, open, way,” says Recio.

“You can run algorithms to create multiple paths, including disjoint paths, to create a topology from it. You are not bogged down by spanning the tree.

“One of the values of using OpenFlow is that we've seen with some of our partners that you can get much faster convergence times. [Because the OpenFlow controller has these paths already computed and discovered], it can very quickly choose an alternative path.”

In an OpenFlow environment, switch configuration is managed centrally rather than in a device-centric manner. Network services can be run like apps on top of the network. Instead of having to work with a series of device-specific commands, properties and abilities, OpenFlow takes a fabric-wide, rule-based approach.

An OpenFlow rule starts by matching fields on a frame (switch port, VLAN, MAC source, MAC destination, IP source, IP destination, IP protocol, TCP source port and TCP destination port).

An action is then performed – forward to switch port(s), encapsulate and forward to controller (OpenFlow server), drop, process normally, modify fields. There are also optional vendor-specific field actions possible (say for load-balancing).

OpenFlow devices capture relevant statistics, and all of this can be done today on a single-chip solution capable of processing 1.28Tbps.

OpenFlow aims to solve several problems. “What gives it the ability to control the network much better than you could with just management plane tools is that you're actually programming the dataplane from the controller,” Recio explains

“The controller is running all the pathing algorithms. It is loading this into the switches, the forwarding tables and the rules that you need to implement and forward data along a path.

“The value of the programmability is that on that controller I can run software that can do things, for example a pathing service, a security appliance, a firewall or an intrusion prevention system. I can send stuff to the controller so that it can do intrusion prevention for me.

“That programmability can leverage OpenFlow to program the data plane flows. It's a powerful, disruptive option we did not have in the past. When you see this address, here's the action you're going to take. It changes. That's one example, but there are many others you can think of based on actions you could take.”

Command centre

To see how an OpenFlow switch might work in a real environment, we have to look at how these rules might be applied.

A switch sees a frame from MAC address A destined for MAC address B. The central configuration server is aware of which MAC addresses live on which ports of which switches across the entire fabric. The server is also aware of link states for every connection, as well as throughput statistics per port.

Since the central database is aware of all this, so too are the individual switches. The best route between the source switch and the destination switch is computed and the frame is forwarded.

Should a link anywhere in the switching fabric become saturated or a cable become unplugged, the central database is made aware of it. The information is quickly disseminated throughout the fabric, and new paths for packets can then be computed as required. This provides high availability with fast convergence.

Getting packets from A to B is only the beginning. We can do interesting layer-three stuff with OpenFlow.

Is your http server at IP address A down? Have the switches redirected the traffic to the server at B. Do you detect a frame with unknown characteristics? Forward it to the central configuration server to be characterised and examined.

Layer two, layer three. If you want your switch to do it, ease of configuration at data-centre scale (instead of merely device scale) is OpenFlow's bailiwick.

Truly dynamic programmable networks are here today, and vendors such as IBM are already shipping gear. ®

Combat fraud and increase customer satisfaction

More from The Register

next story
Feast your PUNY eyes on highest resolution phone display EVER
Too much pixel dust for your strained eyeballs to handle
Samsung Galaxy S5 fingerprint scanner hacked in just 4 DAYS
Sammy's newbie cooked slower than iPhone, also costs more to build
Microsoft lobs pre-release Windows Phone 8.1 at devs who dare
App makers can load it before anyone else, but if they do they're stuck with it
Leaked pics show EMBIGGENED iPhone 6 screen
Fat-fingered fanbois rejoice over Chinternet snaps
Report: Apple seeking to raise iPhone 6 price by a HUNDRED BUCKS
'Well, that 5c experiment didn't go so well – let's try the other direction'
US mobile firms cave on kill switch, agree to install anti-theft code
Slow and kludgy rollout will protect corporate profits
Rounded corners? Pah! Amazon's '3D phone has eye-tracking tech'
Now THAT'S what we call a proper new feature
Zucker punched: Google gobbles Facebook-wooed Titan Aerospace
Up, up and away in my beautiful balloon flying broadband-bot
Sony battery recall as VAIO goes out with a bang, not a whimper
The perils of having Panasonic as a partner
NORKS' own smartmobe pegged as Chinese landfill Android
Fake kit in the hermit kingdom? That's just Kim Jong-un-believable!
prev story


Designing a defence for mobile apps
In this whitepaper learn the various considerations for defending mobile applications; from the mobile application architecture itself to the myriad testing technologies needed to properly assess mobile applications risk.
3 Big data security analytics techniques
Applying these Big Data security analytics techniques can help you make your business safer by detecting attacks early, before significant damage is done.
Five 3D headsets to be won!
We were so impressed by the Durovis Dive headset we’ve asked the company to give some away to Reg readers.
The benefits of software based PBX
Why you should break free from your proprietary PBX and how to leverage your existing server hardware.
Securing web applications made simple and scalable
In this whitepaper learn how automated security testing can provide a simple and scalable way to protect your web applications.