Interworking betweeen OpenFlow and legacy IP networks

In this blog post I return to the goal of selling OpenFlow technology. If it is to become accepted, it does need to be sold.

One of the objections raised about OpenFlow is that it doesnt inter-work with "legacy" IP networks.

As with most sales objections, there is often some truth in these objections and also fear, uncertainty and doubt (FUD) spread by competitors that have something to lose.

So what does the word "interworking" actually mean? In order to answer that question, lets return to basics.

The world is full of IP networking equipment.  In fact thee human race has become dependent on the Internet.  It would be impossible to build a parallel OpenFlow network and have a big bang switch over on a particular date and time.  Lets also be realistic -  legacy IP networking does a reasonable job. The business case of ripping it out and replacing it with OpenFlow doesnt make sense if we apply it on a ubiquitous basis.

At least initially, OpenFlow is being deployed in very specific locations to solve particular problems. I am very familiar with mobile network architectures and in the core network (if you are familiar with the terminology, the Gi network) is where OpenFlow will deliver simplicity, elegance and flexibility for mobile operators and remove the mountain of different boxes which are attempting to control user policy whereas in a mobile feeder network, there are little gains to be made - at least today.  (This would be the Iu network before the SGSN if you are familiar with the terminology). So here OpenFlow has a sweet spot. It is likely that OpenFlow adoption will be on the periphery - places where the legacy technology is struggling or where it's a square peg in a round hole - in other words there are lots of boxes to do work-arounds.

Google actively uses OpenFlow in live operations.  If OpenFlow doesn't interwork then surely we wouldn't be able to use Google!

In my experience, there are real challenges getting legacy IP equipment to interwork. I don't mean interworking between different vendors.  I've seen network engineers struggle to get a Cisco box to talk with another Cisco box simply because one had a different software version!   Interworking challenges are simply part of the world of networking.

So let's look a little closer at OpenFlow. There are 2 types of interfaces: data and control.  Whereas on a legacy router, the control is usually embedded in with the data. One of the key differences is that OpenFlow separates out the data plane from the control plane.

So if you have an OpenFlow switch and we look at the data plane interfaces, they will probably be Ethernet. They will support the IP protocol and the box will forward packets from one port to another.  So far no difference to a legacy switch or router so no challenges for interworking here. At least on first sight.

So what is this control I'm referring to?  Control is the decision making how a packet is routed from A to B. In legacy networking there are a few ways to do this.

1. Broadcast or flooding
2. Someone manually configures it
3. It is automatically discovered

Broadcasting or flooding works on very small networks but it doesnt scale. A basic hub does this. A packet arrives and the hub doesnt know what to do with it so sends it everywhere (including back to the originator).

Next someone manually programmes the equipment saying this address or address range can be reached down here.  Humans tend to make mistakes so traffic might be routed down a black-hole. Also the Internet is constantly changing so it's again not a scalable approach.

Finally we have discovery.  Legacy IP equipment uses a variety of protocols to discover and advertise routing information.  Protocols such as ARP, RIP, OSPF, BGP.

These protocols form the control and routers make their own decisions based on this routing information.

OpenFlow however relies on a "central" intelligence to make routing decisions. When a packet arrives at an OpenFlow switch, if it hasnt been programmed, the switch doesnt know what to do with it.  (A legacy router will have the same issue unless it has been configured and gathered routing information.)  The OpenFLow switch therefore sends a message via the control interface to a controller and says "I've got this packet - what do you want me to do with it?".  Controllers are programmable.  It is therefore possible to write a controller that behaves identically to a legacy router.  The only difference is there is either a logical or maybe a physical separation between the control and the data plane compared to a legacy router.

So if we can develop an OpenFlow switch controller combination that is conceptually identical to a legacy switch, interworking issues are clearly being overstated!

However it doesnt make sense to go to all the trouble of creating OpenFlow to only do what a legacy router does - it wouldnt create the shift away from a box driven networking industry!

Todays legacy IP networks are in-fact islands.  There are lots of fancy terms like routing domains and "autonomous systems" for these islands. The internet is not a single thing - it is a collection of networks where each network has it's own controls.

This is an important concept and it is one that will continue.  To achieve interworking between legacy networks and OpenFlow networks we need islands.  It is the joining point between islands where the challenges and complexities lie.  So at the demarcation point between a legacy network, the gateway router may be talking to the OpenFlow switch using OSPF, where it is advertising what networks it can reach. The OpenFlow switch at the border needs to participate in this discussion.

If look at the last sentence, it isn't 100% true.  The OpenFlow switch can in fact be pretty dumb. When an OSPF packet arrives from the legacy router, it can adopt the approach of forwarding it to the controller and asking what to do with it. It is the controller, using software, that can decide how to interact with the legacy router by programming the OpenFlow switch. 

So interworking with legacy networks is not an insoluble problem. It does require some thought, planning and intelligence but these are skills that you need in legacy networks anyway!

Don't buy this USB to Ethernet dongle!

In one of my first posts on how to build an OpenFlow switch using a  Raspberry Pi, I suggested buying some USB to Ethernet adaptors to overcome the limitation that it only has one Ethernet port and you need more than 1x Ethernet to do any switching!

The USB dongle I pointed to, is however rubbish. Do no buy this. The reason not to buy it, is that the company making these in China populates it with the same MAC address! How stupid is that.

[UPDATE. I guess I'll eat my words. You may as well buy this dongle. I bought a more expensive dongle to see if it was better.  This time it was a white box with a USB fly lead.  Looks totally different on the outside but it is identical on the insider to the much cheaper blue one. Same chipset and MAC address.....So I've done another search to explore yet more alternatives. So I paid £3 for the blue ones,  £6 for the white one and the next clearly different alternative dongle is £20.  I can't see the point in spending £20 for one of these more expensive ones when these £3's work or rather can be made to work. See below for work-around]

It took me a while to figure out why my OpenFlow switch wasn't working how I wanted it.  First rule: Never make assumptions.  I assumed MAC addresses would be different. Wrong.

eth1      Link encap:Ethernet  HWaddr 00:e0:4c:53:44:58 
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

eth2      Link encap:Ethernet  HWaddr 00:e0:4c:53:44:58          <=== SAME!!! Ughhh
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

Here's a dump from ifconfig.  Note the MAC address is the same at 00:e0:4c:53:44:58

Several other people on the Internet have made the same discovery!

If you have bought one of these, the good news it is possible to "fix" the problem. On the Raspberry Pi type:

pi@raspberrypi ~/LINC-Switch $ sudo ifconfig eth2 down
pi@raspberrypi ~/LINC-Switch $ sudo ifconfig eth2 hw ether 00:e0:4c:53:44:59   <-Different MAC
pi@raspberrypi ~/LINC-Switch $ sudo ifconfig eth2 up

Also don't buy the  WiFi dongle I recommended based on the RTL8188CUS chipset.  The reason is although this dongle works, it is a pain to get it supporting AP mode on the Raspberry Pi. I wasted 1 hr and then switched to an RT5370 based one which I got working in AP mode in under 5 mins and they are cheaper too (approx £4).

I've just ordered a different type of USB to Ethernet adaptor to see whether this has the same problem! [UPDATE: Which it did.....]

OpenFlow Switch on Raspberry Pi Part 5: First simple experiment

This is part 5 in the series of building an OpenFlow switch on the Raspberry Pi.

On in part 4 we set-up Ryu to be an L2 switch and it applied flow rules to the LINC switch. The traffic source which triggered the rules was port eth0 which effectively is the control port since this connects the Raspberry Pi to my network and ultimately to the Ryu controller. The flows were therefore applied as a result of noise and chatter on the local LAN.

For our first very simple experiment we need to have a more controlled environment so let's modify the LINC config so that eth0 is solely to connect the switch to the controller.

To shutdown LINC

(linc@raspberrypi)2> init:stop().

Let's edit the LINC config file

sudo vi /home/pi/LINC-Switch/rel/linc/releases/1.0/sys.config

       {ports,
        [
         %% - regular hardware interface
         {port, 1, [{interface, "eth1"}]},
         {port, 2, [{interface, "eth2"}]},
         %% {port, 4, [{interface, "eth0"}]}
         {port, 3, [{interface, "wlan0"}]}
         %% - hardware interface with explicit type

Comment out port 4 (I moved it as the comma on the last entry for port 3 causes the config file to fail).

Restart the switch

pi@raspberrypi ~/LINC-Switch $ sudo rel/linc/bin/linc console

So I now have 3 ports for traffic on the Pi.  I need a traffic source so I connected a laptop via a cable to eth1. There is no DHCP so no IP addresses on the laptop will need be assigned so you will need to change the IP address on the laptop to be a static IP address. I set mine to 192.168.1.130/24 with a default gateway of 192.168.1.1.

So the controller spots the laptop

>  installing new source mac received from port 1

If we now look at the flow tables on the switch we can see what's happening in more detail and understand.

Let's view LINCs flow table:

(linc@raspberrypi)1> ets:tab2list(linc:lookup(0, flow_table_0)).
[{flow_entry,{0,#Ref<0.0.0.374>},
             0,
             {ofp_match,[]},
             <<0,0,0,0,0,0,0,0>>,
             [],
             {1370,616692,527826},
             {infinity,0,0},
             {infinity,0,0},
             [{ofp_instruction_write_actions,4,
                                             [{ofp_action_output,16,controller,65535}]}]},
 {flow_entry,{123,#Ref<0.0.0.381>},
             123,
             {ofp_match,[{ofp_field,openflow_basic,in_port,false,
                                    <<0,0,0,1>>,
                                    undefined},
                         {ofp_field,openflow_basic,eth_src,false,
                                    <<32,207,48,0,192,96>>,
                                    undefined}]},
             <<0,0,0,0,0,0,0,0>>,
             [],
             {1370,616842,124920},
             {infinity,0,0},
             {infinity,0,0},
             [{ofp_instruction_goto_table,6,1}]}]

The line with

{ofp_field,openflow_basic,eth_src,false,
                                    <<32,207,48,0,192,96>>,
                                    undefined}]},

This is the laptop's MAC address in decimal notation 20:CF:30:00:C0:60

(linc@raspberrypi)1> ets:tab2list(linc:lookup(0, linc_ports)).
[{linc_port,1,<0.164.0>},
 {linc_port,2,<0.161.0>},
 {linc_port,3,<0.157.0>}]

OK. LINC isn't the most user friendly if you are a network engineer.  There are plans to improve this and adopt a more familiar user interface like Cisco IOS.

 Right. Let's stop ryu and install a really simple controller configuration to show how things work.

ryu is written in python.  I have to admit that it's taking me a while to get used to python syntax having used c, php and other languages that use {} structures for function declarations.  Python uses just space or tabs to identify what's a function ! Seems crazy to me but that's how it's done.

## Simple ryu layer 2 hub 
## All packets arriving at the OpenFlow switch are passed to the controller
## The controller simply floods all incoming messages out of all ports on the switch
## You would never do this in reality!
## No flows are installed on the switch to remember how to handle packets

from ryu.base import app_manager
from ryu.controller import ofp_event
from ryu.controller.handler import MAIN_DISPATCHER
from ryu.controller.handler import set_ev_cls

class L2Switch(app_manager.RyuApp):
    def __init__(self, *args, **kwargs):
        super(L2Switch, self).__init__(*args, **kwargs)


## set_ev_cls decorator does all the  work. Incoming packets referred to EventOFPPacketIn

    @set_ev_cls(ofp_event.EventOFPPacketIn, MAIN_DISPATCHER)

## packet_in_handler defines rules which are processed when a packet arrives

    def packet_in_handler(self, ev):## All below is part of the packet_in_handler function 
## These are datastructures for the incoming message
## ev.msg represents a packet_in 
        msg = ev.msg
## msg.dp reepresents the datapath for the switch
        dp = msg.datapath
## dp.ofproto represents the protocol to the switch which was negotiated
        ofp = dp.ofproto
        ofp_parser = dp.ofproto_parser
## OFPActionOutput(arg) is which port the message should be sent out of
## OFPP_FLOOD refers to all ports or a flood

        actions = [ofp_parser.OFPActionOutput(ofp.OFPP_FLOOD)]
## Build the packet to send using OFPPacketOut
        out = ofp_parser.OFPPacketOut(
            datapath=dp, buffer_id=msg.buffer_id, in_port=msg.in_port,
            actions=actions)
## Send the built packet
        dp.send_msg(out)

You would never actually use OpenFlow like this. Here's what it does.

A packet arrives at the switch.  The switch checks what rules (flows) have been defined for the arriving packet. The controller hasnt actually installed any so it then refers the packet to the ryu controller.

ryu now dissects the packet passed over the OpenFlow protocol and the above programme tells ryu how to process packets.

The function packet_in_handler is called.

The key line here is

actions = [ofp_parser.OFPActionOutput(ofp.OFPP_FLOOD)]

What this is actually saying is to send the arriving packet to all interfaces.  We are building a hub which is exactly what it does - it floods arriving packets to all ports. The final line commits this.

Now we would never do this in reality since it is a massive overhead. The switch will copy every single packet to the controller asking what to do with it.  The switch never learns anything!

Now given in a real network the controller may be remote from the switch, you can see this would introduce massive latency and massive traffic duplication !

The point of this is really to show the logic of how OpenFlow works.

We can run ryu with more verbose logging to see more about what it is doing

ryu-manager --verbose l2hub.py 

Here's what it comes back with:

loading app l2hub.py
loading app ryu.controller.ofp_handler
instantiating app l2hub.py
instantiating app ryu.controller.ofp_handler
BRICK ofp_event
  PROVIDES EventOFPPacketIn TO {'L2Switch': ['main']}
  CONSUMES EventOFPEchoRequest
  CONSUMES EventOFPErrorMsg
  CONSUMES EventOFPHello
  CONSUMES EventOFPSwitchFeatures
BRICK L2Switch
  CONSUMES EventOFPPacketIn
connected socket:<socket fileno=4 sock=192.168.1.4:6633 peer=192.168.1.15:45743> address:('192.168.1.15', 45743)
hello ev <ryu.controller.ofp_event.EventOFPHello object at 0xf7e510>
move onto config mode
switch features ev version: 0x4 msg_type 0x6 xid 0x70f534ec
move onto main mode
EVENT ofp_event->L2Switch EventOFPPacketIn

Ignore the reference to L2Switch - this is a hub. L2Switch is from the class declaration at the beginning - I copied this example.

You can see ryu is initialising, then it connects to the Raspberry Pi OpenFlow switch running at 192.168.15
It negotiates to use the OF1.3 protocol (0x04)

The Raspberry Pi will report it has also connected to the controller.

16:07:49.296 [info] Connected to controller 192.168.1.4:6633/0 using OFP v4

Now on the laptop connected to the Raspberry Pi, if I set ping running to ping some address, this will be forwarded to the controller. In the controller window you'll see each ping packet event showing in the verbose log

EVENT ofp_event->L2Switch EventOFPPacketIn

In the next post I'll  evolve our simple hub to at least not broadcast out of every port.

OpenFlow security - new exploits?

The past few weeks has seen several high profile DNS exploits.  Hackers have altered the DNS entries to route traffic elsewhere to either an unrelated  site or a fake site.  Typically the way companies discover  this is, is  that the traffic to their website has  disappeared and their web servers are sitting there idle.

More sophisticated exploits would be to leak some of the traffic to an alternative site so it is less likely to be detected through traffic anomolies.

So what has this got to do with OpenFlow?  Well OpenFlow has the potential to abstract routing so that IP addresses are mobile and traffic can be routed programmatically. This is not a million miles from the DNS hack - it would be possible to move traffic routed to a particular valid IP address to another location, in other words it's possible for the network to be the man in the middle and move traffic to another server.

Although this idea isn't new, the same can happen with today's IP networks through route injection, the OpenFlow concepts make this is simpler task.

So how do we prevent this? OpenFlow has put some basic functionality in place to prevent some of this such as secure connections between the controller and the switch,  however the logic on how a network behaves is set at the application level on the controller. The challenge, as OpenFlow networks become more prolific, is to ensure that applications sitting on the controller can be trusted and are doing what we expect.  Imagine a world where the applications installed on the controller have a virus or are simply malicious  and are taking rogue actions. How can we detect this? How can we prevent this?

With the controller exposing north bound interfaces elsewhere, the need for trust from "controllers of controllers" needs to be established.

These are not real risks today since it is likely that any OpenFlow network will be closed, secure and tightly controller by the network administrators but it is definitely something which could emerge as a real threat within the next 5 years.

OpenFlow in the Optical Domain

There's a lot of noise about using OpenFlow in the optical domain. For example Carrier SDN – The ONF’s View.

I'm not 100% convinced about the merits of OpenFlow in the optical space.

Here's a video where Sten Nordell, Transmode's CTO, is talking about SDN in the optical space.

I think he does a reasonable job of weighing up the options and getting back to basics.

I guess the reason I am at least posing the question why OpenFlow might not work in the optical space is:

1/ There are already intelligent networking protocols for optical networks eg G.ASON. I worked for Sycamore that pioneered this and standardised it yet few optical networking companies embraced it for "optical dial-tone".  If historically optical companies didn't embrace it, what is different this time round?

2/ Optical pipes are pipes. There is not an in-band signalling channel anyway and it doesnt naturally lend it self to "MAC inspection".

I'm open to a debate on this at least on the transport side. For the optical switching layer, particularly within data centres, I can see how OpenFlow & SDN concepts can work.

Internet exchange using OpenFlow

I came across this post where they are using OpenFlow for Internet Peering Exchange.

Building a better internet exchange with OpenFlow 

I've not really had much involvement with peering so I don't know the operational issues which relate to peering however the aspect of controlling ARP responses and checking them using OpenFlow pretty straightforward.

I'll add this to my list to examine in more detail to understand the real-world aspects of managing peering.

OpenFlow based WiFi authentication - how else could you do it?

With OpenFlow, it is very straightforward to do user authentication and sign-on in a WiFi network using MAC authentication.

In an OpenFlow network when a user attaches to the WiFi network, the switch passes the new/unknwon user's packet to the controller for authentication. The controller can then check the user's MAC address against a database to see if it is known and then the user can be either routed to a public network or redirected to an authentication page. Once the user has authenticated, the authentication process can inform the controller and the controller can push a new rule for that MAC address.

So how could this functionality be achieved in another way without using OpenFlow?

In order to use the MAC address we need to operate at Layer 2.  We can't use the IP address unless we introduce another stage to obtain the MAC address from the assigned IP address.

So let's walk through how we might be able to do this using existing networking technology.

So a user attaches to a WiFi HotSpot. The WiFi Access Point can then assign an IP address using DHCP. We could have a custom DHCP server that allows us to query the database to verify MAC addresses. The DHCP server can then assign an IP address.

OK we have now authenticated a user but not solved the problem of routing to either a landing page or allowing the user to connect to the internet.  How could we solve this?  Well we could assign a different IP address subnet based on whether the user is known or unknown or maybe use different VLANs depending on whether the user is known or unknown.

So once the user has visited the landing page and authenticated they should now be allowed to have unhindered access to the internet. The problem is the routing policy is based on the users IP address.  We now either need to expire the users IP address and repeat the DHCP process or introduce more controls into the routing domain. Probably the easiest to do is to issue short lease DHCP addresses.

If we let the IP address continue we need more sophisticated controls in the routing layer. One way to achieve this would be to use a Deep Packet Inspection (DPI) box to apply these routing policies. DPI is actually overkill since we don't need to look deep into the packet. We actually only need the IP or MAC address. Using APIs off the DPI box we can control how the user's traffic is routed.  OK maybe a load balanced is a better option.  We can use the API on the load balancer to route traffic that way. It will need to look up the IP address to find out whether it is authentication. We still need to use the DHCP and load balancer as the solution. The DPI or loadbalancer will need to cache the authentication state to avoid repetitive look-ups.

OK let's ignore the DHCP option.  Let's use just a load balancer. We assign the user an IP address and the traffic arrives at the load balancer. The load balancer now looks up the IP address to find the MAC address and whether it is authenticated or unauthenticated. We can then route the traffic. The load balancer will need to store the authentication state locally to determine the routing policy and avoid looking every packet up and creating database load.

OK it is possible to implement comparable functionality to OpenFlow for WiFi MAC authentication using existing technology.  What this thought experiment has shown that it ends up being more complex and a rather bespoke design.  If I decided to change the requirements it is possible I may need to restart the design from scratch or add more complexity.  In OpenFlow I suspect the additional requirements can achieved pro grammatically by the controller

LINC learning Switch post

I found this great blog post on LINC.  

The post provides a good overview of the chained forwarding table options possible with the LINC OpenFlow switch.

OpenFlow Switch on Raspberry Pi Part 4: Ryu config to make LINC a L2 switch

This is part 4 in the series of building an OpenFlow switch on the Raspberry Pi.  In  part 3 of this OpenFlow series we had built our switch, installed the Ryu controller and got the switch to connect to the controller.

Before carry on it's worth expanding a bit more on the Ryu controller. It's an OpenSource controller developed by NTT in Japan and released under the commercially friendly Apache2 licence.

When we started the controller in the last post it was in fact useless. The controller is a little unusual since it is in-fact a framework for control. It effectively allows you to build network APIs (Application Programmer Interfaces). You need to write your own business logic to define what you want the network to do. This business logic is defined in fairly short python programmes.  I'm not a python programmer and have never learnt - I will have to get my 15 year old son to teach me how to programme in python!

You can think of these python scripts as apps - potentially there could be an app store for the network equivalent to iTunes.

Fortunately we have some ready made python scripts available which we can use with ryu and at least do some useful things.

Before we shutdown ryu and get it to use one of these scripts let's see what state LINC is in to confirm that the ryu controller has in-fact done nothing!

The LINC switch uses Erlang syntax so the commands may seem complex and unfamiliar.

 The command to view the forwarding table on LINC is:

(linc@raspberrypi)1> ets:tab2list(linc:lookup(0, flow_table_0)).

The response is:
[]

An empty table. The switch doesn't know what to do with any packets that arrive since the forwarding table is empty.

OK lets shutdown ryu by doing CTRL-C.

We now need to use one of the python scripts which came with LINC. There are also scripts which came with ryu but they don't all work with LINC.

You can either use the script at:

https://github.com/FlowForwarding/LINC-Switch/blob/master/scripts/ryu/l2_switch_v1_3.py

Copy and paste this into a file called l2_switch_v1_3.py on the computer where your controller is running or copy the script in the LINC installation directory.  This python switch allows LINC to function as a layer 2 switch.  It could alternatively be an app to turn it into a firewall or whatever network device you dream up!

LINC-Switch/scripts/ryu/l2_switch_v13.py 

We now need to restart ryu with the python script

$  LINC-Switch/scripts/ryu/l2_switch_v13.py

In my case ryu now reports:

installing new source mac received from port 4
installing new source mac received from port 4
installing new source mac received from port 4

Let's now look at LINC. In the console we have

10:08:40.542 [info] Created port: {port,4,[{queues_status,disabled},{queues,[]},{config,{port_configuration,undefined,up,false,false,false}},{features,{features,undefined,'100Mb-FD',true,copper,unsupported}},{queues,[]},{interface,"eth0"}]}
10:08:40.780 [info] Created port: {port,3,[{queues_status,disabled},{queues,[]},{config,{port_configuration,undefined,up,false,false,false}},{features,{features,undefined,'100Mb-FD',true,copper,unsupported}},{queues,[]},{interface,"wlan0"}]}
10:08:41.020 [info] Created port: {port,2,[{queues_status,disabled},{queues,[]},{config,{port_configuration,undefined,up,false,false,false}},{features,{features,undefined,'100Mb-FD',true,copper,unsupported}},{queues,[]},{interface,"eth2"}]}
10:08:41.289 [info] Created port: {port,1,[{queues_status,disabled},{queues,[]},{config,{port_configuration,undefined,up,false,false,false}},{features,{features,undefined,'100Mb-FD',true,copper,unsupported}},{queues,[]},{interface,"eth1"}]}
10:08:41.307 [info] Connected to controller 192.168.1.4:6633/0 using OFP v4

[{flow_entry,{0,#Ref<0.0.0.897>},
             0,
             {ofp_match,[]},
             <<0,0,0,0,0,0,0,0>>,
             [],
             {1370,599721,348915},
             {infinity,0,0},
             {infinity,0,0},
             [{ofp_instruction_write_actions,4,
                                             [{ofp_action_output,16,controller,65535}]}]}]

(linc@raspberrypi)5> ets:tab2list(linc:lookup(0, flow_table_0)).

We now have something in the flow table

[{flow_entry,{0,#Ref<0.0.0.1215>},
             0,
             {ofp_match,[]},
             <<0,0,0,0,0,0,0,0>>,
             [],
             {1370,600106,318986},
             {infinity,0,0},
             {infinity,0,0},
             [{ofp_instruction_write_actions,4,
                                             [{ofp_action_output,16,controller,65535}]}]},
 {flow_entry,{123,#Ref<0.0.0.1219>},
             123,
             {ofp_match,[{ofp_field,openflow_basic,in_port,false,
                                    <<0,0,0,4>>,
                                    undefined},
                         {ofp_field,openflow_basic,eth_src,false,
                                    <<192,63,14,164,241,229>>,
                                    undefined}]},
             <<0,0,0,0,0,0,0,0>>,
             [],
             {1370,600110,573684},
             {infinity,0,0},
             {infinity,0,0},
             [{ofp_instruction_goto_table,6,1}]},
 {flow_entry,{123,#Ref<0.0.0.1223>},
             123,
             {ofp_match,[{ofp_field,openflow_basic,in_port,false,
                                    <<0,0,0,4>>,
                                    undefined},
                         {ofp_field,openflow_basic,eth_src,false,
                                    <<0,31,208,172,255,21>>,
                                    undefined}]},
             <<0,0,0,0,0,0,0,0>>,
             [],
             {1370,600110,817008},
             {infinity,0,0},
             {infinity,0,0},
             [{ofp_instruction_goto_table,6,1}]},
 {flow_entry,{123,#Ref<0.0.0.1254>},
             123,
             {ofp_match,[{ofp_field,openflow_basic,in_port,false,
                                    <<0,0,0,4>>,
                                    undefined},
                         {ofp_field,openflow_basic,eth_src,false,
                                    <<116,240,109,81,22,170>>,
                                    undefined}]},
             <<0,0,0,0,0,0,0,0>>,
             [],
             {1370,600112,591632},
             {infinity,0,0},
             {infinity,0,0},
             [{ofp_instruction_goto_table,6,1}]}]

Yours will probably look different. In the next post we'll do a little test scenario and controlled traffic.

OpenFlow Switch on Raspberry Pi Part 3: Ryu OpenFlow controller connected to LINC switch

Back to the cheapest OpenFlow switch in the world based on the Raspberry Pi.

So far we've built our OpenFlow switch, installed Erlang and installed the LINC OpenFlow switch.

The switch isn't much use without a controller.  There are a number of OpenFlow switches out there. Beacon, Flashlight, Ryu and more.

Beacon is rather old so doesn't work with LINC which supports the latest protocols. For my OpenFlow lab I'm going to use the NTT ryu controller.

Ryu is written in python so should work on your platform. It's even possible to run it on the Raspberry Pi but for now I'm running it on an OpenSuse machine.

The Ryu webpage is  http://osrg.github.io/ryu/  and the download page takes you to Ryu's github page at https://github.com/osrg/ryu

If you have an up-to-date python installation you may be able to install Ryu with the simple command

pip install ryu

If you're like me you're installation will need some work to make it install!

I didn't have pip (the python package installer) so I had to install "distribute" first

$ wget http://python-distribute.org/distribute_setup.py
$ python distribute_setup.py

Then I had to install pip

$ wget http://pypi.python.org/packages/source/p/pip/pip-0.7.2.tar.gz
$ tar xzf pip-0.7.2.tar.gz
$ cd pip-0.7.2
$  python setup.py install

Then I installed ryu

$ pip install ryu

You may be lucky and it runs.
$ pip install ryu

I was not so lucky.  I was missing the gevent python library

$  pip install gevent

However it wouldn't install so I had to install the python-devel RPM next
I then installed a bunch of missing python libraries

$ pip install gevent
$ pip install webob
$ pip install routes

Finally gevent worked !
$ pip install gevent
$ ryu-manager
loading app ryu.controller.ofp_handler
instantiating app ryu.controller.ofp_handler

Yes a running OpenFlow controller !!
Although LINC supports auto controller configuration using OF Config, we'll set it up manually.

Now we have a running controller on a machine, we need to find the IP address of the machine. On Linux
the command is /sbin/ifconfig -a

My address is 192.168.1.4

On windows machines you need a cmd prompt and type ipconfig /all to find the IP address

We now need to edit the LINC config file to point it at the controller.
To edit the file on the Pi

pi@raspberrypi ~/LINC-Switch $ sudo vi rel/linc/releases/1.0/sys.config

      %% Configuration of the controllers switch will connect to. Ideally
       %% this list should be empty and assignement should be handled by an
       %% OF-Config client.
       %% Default OFP controller port is 6633.
       {controllers,
        [
         {"Switch0-DefaultController", "192.168.1.4", 6633, tcp}
        ]},

       %% Configure ports available to the switch when using the
       %% userspace backend according to your system setup.
       %% * Under Linux all TAP interfaces must be set up beforehand
       %%   as persistent.
       %% * Under MacOSX TAP interfaces are created during node
       %%   startup (which requires setting an ip parameter).

 This line is commented out with a %% by default so the %% needs to be removed and the correct IP address inserted.

OK time to let the switch connect to the controller!

pi@raspberrypi ~/LINC-Switch $ sudo rel/linc/bin/linc console
Exec: /home/pi/LINC-Switch/rel/linc/erts-5.9.3.1/bin/erlexec -boot /home/pi/LINC-Switch/rel/linc/releases/1.0/linc -mode embedded -config /home/pi/LINC-Switch/rel/linc/releases/1.0/sys.config -args_file /home/pi/LINC-Switch/rel/linc/releases/1.0/vm.args -- console
Root: /home/pi/LINC-Switch/rel/linc

Erlang R15B03 (erts-5.9.3.1) [source] [async-threads:0] [kernel-poll:false]

20:52:02.873 [info] Application lager started on node linc@raspberrypi
20:52:02.883 [info] Application ssh started on node linc@raspberrypi
20:52:02.912 [info] Application enetconf started on node linc@raspberrypi
20:52:02.927 [info] Application linc started on node linc@raspberrypi
Eshell V5.9.3.1  (abort with ^G)
(linc@raspberrypi)1>
(linc@raspberrypi)1> 20:52:03.230 [info] Created port: {port,4,[{queues_status,disabled},{queues,[]},{config,{port_configuration,undefined,up,false,false,false}},{features,{features,undefined,'100Mb-FD',true,copper,unsupported}},{queues,[]},{interface,"eth0"}]}
20:52:03.481 [info] Created port: {port,3,[{queues_status,disabled},{queues,[]},{config,{port_configuration,undefined,up,false,false,false}},{features,{features,undefined,'100Mb-FD',true,copper,unsupported}},{queues,[]},{interface,"wlan0"}]}
20:52:03.736 [info] Created port: {port,2,[{queues_status,disabled},{queues,[]},{config,{port_configuration,undefined,up,false,false,false}},{features,{features,undefined,'100Mb-FD',true,copper,unsupported}},{queues,[]},{interface,"eth2"}]}
20:52:03.974 [info] Created port: {port,1,[{queues_status,disabled},{queues,[]},{config,{port_configuration,undefined,up,false,false,false}},{features,{features,undefined,'100Mb-FD',true,copper,unsupported}},{queues,[]},{interface,"eth1"}]}
20:52:04.020 [info] Connected to controller 192.168.1.4:6633/0 using OFP v4

(linc@raspberrypi)1>

Success!

In my next post in this series we'll start doing some useful experiments.

OpenFlow and WiFi

My last post answered a question that came up about the latency between an OpenFlow switch and the OpenFlow Controller. I've also been asked about OpenFlow and the relevance for WiFi.

OpenFlow often talks about ethernet packets so the question was "Can we extend this idea to WLAN systems such as wifi?"

Of course!

WiFi is of course ethernet based.  It's basically just a different layer 1 technology (physical interface) compared to the physical interface of wired cable. Supporting OpenFlow for WiFi is simple - at least conceptually.

Before delving into WiFi I though it would be interesting to look at the wider OpenFlow landscape beyond ethernet.  OpenFlow is attracting a lot of interest in traditional telecom area of optical networking where there is no Ethernet at all. It is viewed as a possible mechanism to dynamically provision optical pipes on the fly. There is a technology already defined in the optical networking space for pipe provisioning - G.ASON (automatically switched optical network). It has has some traction but is not universally adopted therefore many vendors are looking at OpenFlow as possible next generation mechanism for optical provisioning.

So back to WiFi. Because WiFi is ethernet packet based, OpenFlow can be used today but why would you want to use OpenFlow in a WiFi environment?

If you are building a public WiFi HotSpot today, you'll need some registration service. Often people have a landing page where they can register to gain access. Usually what happens is the person connecting to the HotSpot opens a browser and starts to connect to say Google. The person is not authenticated so there needs to be a box to intercept the connection to Google and redirect them to the landing page instead.  Many corporate users may have their internal proxy set and the box doing the intercept may fail to redirect these users to the landing page.  If the draconian security department at the corporate hasn’t given the user permission to change the web site proxy address then they are stuck!

An OpenFlow enabled WiFi Access Point would however  not require the additional complexity of box to intercept the connections - it can do it itself.

The customer's device sends some packets and the OpenFlow device can look to see if this person is authenticated and simply forward the packets to a specific address if they are not.  The OpenFlow architecture would do this by default. The packet would arrive at the OpenFlow switch and let's say it's been configured to use the MAC address lookup. If the MAC address is unknown to the switch, the packet would be referred to the controller.  The controller can then do a MAC look-up to see if this user is already a subscriber - this could easily be done via LDAP for example. If the customer was unknown they could be redirected to a registration or landing page and if they were a subscriber they would simply be connected to the Internet service without any effort on their part.

In fact it would be possible to provide a seamless service for customers. A vastly better experience for WiFi than is currently in place.

So if the customer's MAC address is already known then the OpenFlow WiFi access device could even authenticate the user solely on MAC address and direct them to their service without all the hassle of signing in.

OpenFlow and latency

One of the questions that came up about OpenFlow last week was about latency.  It was a good question and exposes the lack of clarity about the role between the switch and the controller.

The switch is the data plane. It's role is to move data packets from A to B
The controller makes decisions for the switch whether to move specific packets from A to B or whether they should go from A to C or even block them.

In order for the controller to make this decision, the switch consults with the controller when a new packet arrives. Now this is where the confusion arose. The switch only refers the first packet it doesn't know how to handle. The controller then communicates a rule and the switch continues to use that rule until either it expires or is told to use a new rule. Subsequent packets in the flow do not need the controller to be involved. The switch does the work.

If the switch referred every packet to the controller then:

1. The bandwidth pipe to the controller would need to be huge since all the traffic would be copied to the controller
2. The latency would increase by at least the round trip time to the controller
3. The controller would need higher availability,  scale massively and have more real-time performance than the switch

 The first packet referred to the controller does indeed increase the latency by at least the round trip to the controller but subsequent packets do not. Once the switch knows how to handle subsequent packets the controller does not need to be involved.

The end result is the pipes to the controller do not need to be big.  It needs to be big enough to handle the packets for how many new flows per second there are x the span of control of the controller. If you have an environment where there are lots of long duration flows (eg video serving) there will be les work for the controller to do compared to say web surfing which tends to be lots of short duration packet exchanges.

There is little information to help network planners dimension the link to the controller so this is one area where there is an opportunity for academics to do research and potentially for tools to be developed.  It is likely that the tools would be closed loop taking the traffic profiles and extrapolating for dimensioning.

OpenFlow webinar

Last night I did a webinar on OpenFlow with Stu Bailey - CTO of InfoBlox

It was my first webinar - it's an odd experience and actually far more nerve racking than standing in front of an audience because there is absolutely no audieence feedback.

The webinar was recorded so if you would like to watch it (it's about 50 mins long), it will be shortly available on the Erlang Solutions website. Watch the OpenFlow webinar.

OpenFlow Switch on Raspberry Pi Part 3: Configuration and getting it running

In part 1 I showed what hardware you need to turn your Raspberry Pi into an OpenFlow switch by  adding USB to Ethernet adaptors.

In part 2 I showed how to install Erlang and install the LINC OpenFlow switch

In this part we start with configuring the switch.

The first thing we need to do is identify what networking ports we have on our Pi.

We use the command ifconfig -a to find out what Ethernet ports we have

pi@raspberrypi ~ $ ifconfig -a

eth0      Link encap:Ethernet  HWaddr b8:27:eb:21:08:6a
          inet addr:192.168.1.19  Bcast:192.168.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:121 errors:0 dropped:0 overruns:0 frame:0
          TX packets:83 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:11559 (11.2 KiB)  TX bytes:11040 (10.7 KiB)

eth1      Link encap:Ethernet  HWaddr 00:e0:4c:53:44:58
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0  carrier:0  
          collisions:0  txqueuelen:1000                                                                               
           RX bytes:0 (0.0 B)  TX bytes:0 (0.0B)   

eth2      Link encap:Ethernet  HWaddr 00:e0:4c:53:44:58
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

wlan0     Link encap:Ethernet  HWaddr 00:0b:81:89:5e:bf
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)


Port eth0 is the native Ethernet port on the Pi and the USB based Ethernet ports are showing up as eth1, eth2 and wlan0.  If you've added more or different ports for your hardware, your port numbers will differ.

We now need to edit the LINC config file so that it knows what ports it has access to.
If the version you have downloaded is higher than 1.0 you'll need to change the line below

pi@raspberrypi ~/LINC-Switch $ sudo vi rel/linc/releases/1.0/sys.config

We now need to edit the section of the file to declare the ports which form part of the switch

       {ports,
        [
         %% - regular hardware interface
         {port, 1, [{interface, "eth1"}]},
         {port, 2, [{interface, "eth2"}]},
         {port, 3, [{interface, "wlan0"}]},
         {port, 4, [{interface, "eth0"}]}
         %% - hardware interface with explicit type
         %% {port, 1, [{interface, "net0"}, {type, eth}]},
         %% - regular tap interface
         %% {port, 2, [{interface, "tap0"}]},
         %% - tap interface under MacOSX with dynamically assigned IP
         %% {port, 3, [{interface, "tap1"}, {ip, "10.0.0.1"}]},
         %% - tap interface with explicit type
         %% {port, 4, [{interface, "net1"}, {type, tap}]}
        ]},

Note that the last active port shouldn't have a comma after it

We can now start the OpenFlow switch for the first time

pi@raspberrypi ~/LINC-Switch $ sudo rel/linc/bin/linc console

Exec: /home/pi/LINC-Switch/rel/linc/erts-5.9.3.1/bin/erlexec -boot /home/pi/LINC-Switch/rel/linc/releases/1.0/linc -mode embedded -config /home/pi/LINC-Switch/rel/linc/releases/1.0/sys.config -args_file /home/pi/LINC-Switch/rel/linc/releases/1.0/vm.args -- console
Root: /home/pi/LINC-Switch/rel/linc
Erlang R15B03 (erts-5.9.3.1) [source] [async-threads:0] [kernel-poll:false]

21:18:47.473 [info] Application lager started on node linc@raspberrypi
21:18:47.483 [info] Application ssh started on node linc@raspberrypi
21:18:47.542 [info] Application enetconf started on node linc@raspberrypi
21:18:47.557 [info] Application linc started on node linc@raspberrypi
Eshell V5.9.3.1  (abort with ^G)
(linc@raspberrypi)1> 21:18:47.957 [info] Created port: {port,4,[{queues_status,disabled},{queues,[]},{config,{port_configuration,undefined,up,false,false,false}},{features,{features,undefined,'100Mb-FD',true,copper,unsupported}},{interface,"eth0"}]}
21:18:48.197 [info] Created port: {port,3,[{queues_status,disabled},{queues,[]},{config,{port_configuration,undefined,up,false,false,false}},{features,{features,undefined,'100Mb-FD',true,copper,unsupported}},{queues,[]},{interface,"wlan0"}]}
21:18:48.435 [info] Created port: {port,2,[{queues_status,disabled},{queues,[]},{config,{port_configuration,undefined,up,false,false,false}},{features,{features,undefined,'100Mb-FD',true,copper,unsupported}},{queues,[]},{interface,"eth2"}]}
21:18:48.704 [info] Created port: {port,1,[{queues_status,disabled},{queues,[]},{config,{port_configuration,undefined,up,false,false,false}},{features,{features,undefined,'100Mb-FD',true,copper,unsupported}},{queues,[]},{interface,"eth1"}]}

(linc@raspberrypi)1>
You can see LINC has created the ports defined in the config file and ended with the Erlang prompt.

OK. Let's shutdown the switch. We use the Erlang command  init:stop().

(linc@raspberrypi)1> init:stop().
ok

In the next post we'll get an OpenFlow controller running and start talking to the switch.

OpenFlow Switch on Raspberry Pi Part 2: Installing the OpenFlow switch on the hardware

In the first article I introduced the concept of building the worlds cheapest OpenFlow switch based on the Raspberry Pi. A 4 port switch was constructed from about £50 worth of hardware.

We are now going to install the open source software on the Pi to get ourselves a functioning switch.

The software we are going to use is one which I've been involved with for about 18 months which is the LINC OpenFlow switch.  This switch is written in Erlang and can be downloaded for free from flowforwarding.org

First we need to install Erlang on our Raspberry Pi.  I have assumed your Pi is running Raspbian - if not you'll need to download the image onto a new SD card.

First you need a command prompt on your Pi as we need to edit some files

pi@raspberrypi ~ $ sudo vi /etc/apt/sources.list

Insert into this file:

deb http://binaries.erlang-solutions.com/debian wheezy contrib

Then at the command prompt type

pi@raspberrypi ~ $ wget -O - http://binaries.erlang-solutions.com/debian/erlang_solutions.asc |sudo apt-key add -
pi@raspberrypi ~ $ sudo apt-get update
pi@raspberrypi ~ $ sudo apt-get install esl-erlang

Assuming there were no problems, you should now have Erlang installed on your Pi.

We now need to install LINC.

First we need to install a few more libraries

pi@raspberrypi ~ $ sudo apt-get install git-core bridge-utils libpcap0.8 libpcap-dev libcap2-bin uml-utilities

Now we need to clone the LINC switch

pi@raspberrypi ~ $ sudo git clone https://github.com/FlowForwarding/LINC-Switch/
pi@raspberrypi ~ $ cd LINC_Switch

Now we need to compile the switch software

pi@raspberrypi ~ $ sudo make

 We now have a LINC OpenFlow switch installed on our Raspberry Pi hardware.

In the next blog I will cover how to configure it and start it up

Cheapest OpenFlow switch in the world. Using the Raspberry Pi as an OpenFlow switch.

If you want to learn about OpenFlow, there is no better way than to experiment.

So how do you experiment when this stuff is new?

Simple. Copy Google and build your own network!

I am currently building my own OpenFlow switch so I can build my an OpenFlow lab and start experimenting. The goals for my DIY switch are that it has to be cheap, easy to build and useful.

Thankfully lots of other amazing people have done all the hard work for me.  You'll be able to build your own OpenFlow switch for about £50.

I'm using the Raspberry Pi which you can buy for around £30. The Raspberry Pi is a small ARM based computer running Linux. It has an HDMI port, composite video, Ethernet port and 2xUSB ports.

OK you might be thinking this isn't going to make much of a router when it only has 1x Ethernet port!

To solve that problem I'm using a USB hub and have bought some USB to Ethernet adapters for about £3 each and a WiFi dongle based on the RTL8188CUS chipset for about £8.

Assuming you have a USB mouse, USB keyboard, a monitor or TV with a HDMI port + HDMI cable and a USB hub then the cost for 3xEthernet + 1xWiFi switch/router will be £44.

Here's mine:

The Raspberry Pi recognised the USB to Ethernet adaptors and dongle straight-off so no messing around with drivers.

This isn't going to be fastest router/switch on the planet. Firstly running Ethernet over USB is slow anyway and these adaptors are USB 1.1 (what do you expect for £3) so they will max out at about 6Mbit/s anyway.
The Raspberry Pi is hardly a high spec computer either and in addition we will be running the switch software in user space.

[Post blog note.  These USB to Ethernet adaptors are pretty crap. The Chinese manufacturer has programmed them all with the same MAC address....It's not the end of the world - you can over-ride it with ifconfig but still bloody annoying. AlsoI'd recommend the RT5370 WiFi dongles over the RTL8188CUS - I had problems getting the RTL to work in Access Point mode.  See this blog post for more details on both of these points.]

The purpose of this switch is not speed. It's to learn.

In future articles I will explain how to  install the software on your Raspberry Pi, get your controller and start experimenting.

I'm also experimenting with the slightly more expensive RouterBoard 450GL. This is custom built low-end 5 port router for about £80.  This is a little more involved to hack and will be covered in later articles.

Selling OpenFlow technology

This post was first published on my sales blog "Selling High Tech" on the 19th April 2013.

Software Defined Network (SDN) and OpenFlow are the latest networking hot buzzwords in the word of high tech. I've just spent the last 2 days at the pinnacle of SDN by attending the ONF summit which has been an interesting experience. I've been on the bleeding edge of SDN as I've been involved in its development for the last 18 months and it is getting to the point where the hype is turning into reality and that means this new hot tech has to be sold.


Before I delve into the challenges of selling SDN I thought it would be interested to explain what it is, why everyone is getting excited and my personal perspective since in reality SDN is an old idea in the telecom world but very new in the networking world.

At the heart of OpenFlow is the idea to separate out control from data. In data networking, that means messages to control set-up, build routing tables etc are all carried in the same channel as the data for example these control messages are carried alongside the web page you're downloading.

Routers and networking switches have in-built intelligence and when configured correctly will make decisions about how your data gets from A to B.

Separating control from data happened in the telecom world around 40 years ago so the concept is far from new. In fact it happened several times in telecom. The very old systems used tones carried in the speech path for signalling purposes. The problem with this is that users could “hack” the telecom network to trigger the controls. This problem still exists to some extent and is called freaking. DTMF is a signalling (control) mechanism to signal to the network on your fixed line phone what number you want to dial – this control info is carried in the data (speech plane). Hackers manipulate PABX, voice-mail and other systems which use DTMF for control. Hacking the core telecom network in this way is not possible anymore. Mobile phones send call set-up signalling information separately from the voice since they use more up-to-date technology.

The other change in the telecom network which happened 30-40 years ago was in the core and was more fundamental and had a profound impact. Telecom circuit have a separate channel in which signalling information is carried. The fundamental change was not the physical separation of the signalling from the data which was already present but the centralisation of signalling. Digital telecom networks relied on the dialled digits to signal to the next switch how to route the call. The numbering plan was cleverly designed so the dialled digits described how to get the call from A to B. You can kind of think of it as source routed packets. However the problem was all this signalling channels were difficult to maintain (read labour intensive) since each switch needed to have part of the information about how to get from A to B. The transition to centralised signalling or STPs (Signal Transfer Points) was a fundamental change – it meant each switch simply needed enough signalling information to know how to handle queries and the STPs handle the details of the call set-up. It is this change which has a close parallel to what is happening in networking with SDN.

So why was the change to centralised signalling in telecom such a fundamental change? Up until that point, dialled digits were geographical – the call was set-up hop-by-hop, with each switch holding lots of configuration data. It meant things like freephone numbers were difficult if not impossible to establish. In the old model each node would need to know how to route free-phone numbers. With the centralised model it was possible to add new functionality (Service Creation Points) which sat above the STPs allowing number abstraction – suddenly numbers were not tied to geographical locations. This meant someone dialling an 800 number could be routed to a physical phone based on their originating location or based on the state of the destination eg busy. Because signalling was centralised, operator based controls became possible for example call blocking. These were not services for users – these were services to protect the network. If a telephone number was in high demand for example ticket booking or voting, call volumes could be throttled to stop excessive network load.

So let's jump forward to SDN. Separation of the control and data planes is actually giving routing information to a controller which is analogous to the STP. Controllers will be connected via northbound interfaces to systems allowing applications to control the network (analogous to SCPs) . The service abstraction was labelled under Intelligent Networking.

So one of the key problems with selling SDN is actually “what problem does it solve”. The messages for the past 2 days at the ONF conference have been about

• Lower costs
• Flexibility
• Responsiveness

We may think of IP routing as being fresh and modern but the reality is it has progressed very little in the last 20 years. There have been lots of bolt on protocols attempting to overcome shortcomings. SDN concepts have been born out of frustration. Cloud services and virtualisation in the server space have enabled the time to create a new server to be reduced from days to minutes. Creating a new server is a low cost, almost labour free activity and yet the bottle neck is now the networking. The moment networking changes are needed there is no automation, it takes days to implementation the manual changes and because humans are involved, they are error prone. Companies like Google have therefore resorted to writing their own SDN since they want networking to be exactly like the server space. This covers the points of flexibility and responsiveness.

The other area which has been covered over the last couple of days is lower costs. The same networking vendors that have progressed things little in the last 20 years have kept prices high. There is nothing fundamental in SDN to make things cheaper – at least from a capital cost perspective. What is really happening is SDN is a disruption change allowing new players to emerge and it is shifting value from boxes to the higher layers. Networking boxes therefore become more commodity. It is this area where I have been involved for the last 18 months with the LINC OpenFlow switch which enables new low cost vendors to enter the networking space.

Returning to our telecom parallel, it is the STP (OpenFlow controllers) and SCP (OpenFlow applications) where new opportunities and players are emerging. The volume is in the switch/router layer whilst the value and therefore profit will be with the higher layers. Switches will be commodity with little opportunity to differentiate.

The fundamental change in telecom was not the cost element since in reality this was extra boxes to buy so actually higher cost. Operators moved to a centralised control model since costs were reduced from a support perspective. It was far easier to maintain since routing could be changed dynamically (least cost routing) and adds and changes made in a simple manner from a central location.

Throttling before, was complex configuration activity and therefore prone to human error but with a centralised control function it became possible to automate the activity.

Number translation and number abstraction was also a powerful and fundamental change. It meant numbers were no longer tied to a location. Call control became more flexible allowing dynamically change to call routing and call manipulation. This lead to virtualised PABX type service like Centrex. The operators had a powerful new tool to create new services in a simple way. For example private dial/numbering plans.

So fast forward to today. The sales messages for SDN and OpenFlow are about lower cost and flexibility (easier support and faster provision). The reality is OpenFlow will probably not lead to lower capital costs – at least not initially. If you already have a router network and it works then you won't save money by replacing it with OpenFlow since you will have new investment costs and scrappage costs for your existing network. Depending on how much service and network provisioning change is taking place in your network you may have reduced support and administration costs resulting from OpenFlow's flexibility – this becomes a simple business case. Are my support cost reduction gains worth the capital investment?

Contrasting with telecoms is useful. Load control and throttling is comparable to today's denial of service threats. Today if we have an attack, it can be quite a manual task to apply blocking rules across a large distributed network. Ironically building resilient fault tolerant networks actually creates more problems compared to a simple linear service chain. More meshing means more options for threats and attacks to find alternative routes.

OpenFlow's centralisation enables similar functionality to telecom's traffic management. Centralised blocking control means that policies such as block all traffic from this IP address or all traffic to this IP address can be simply created and applied on a network-wide basis. If you are in the firewall business you better watch out. OpenFlow is going to impact your business.

For example it now be possible to block queries to particular DNS lookups. Schools may restrict access to facebook.com during specific hours so that the lookup simply fails!

It's worth briefly considering IP v4's addressing. In reality it is hierarchical with the numbering having a geographical binding. This sub-net relates to a country and sub-net location. It is not so different from old world telecoms yet we like to fool ourselves that IP is a fresh new idea!

The decoupling of the control of the data forwarding plane in telecom allowed address abstraction – the numbers pretty much became irrelevant. We still needed “unique” numbers but they were no longer cast in-stone.

It is this decoupling in telecoms that spawned service innovation and flexibility. I believe that exactly the same will happen in IP and OpenFlow enables this control abstraction.

So let's look at telecom services and see what insights we can gain for the future of SDN. Firstly numbering abstraction. We probably won't have freephone equivalents since IP bearer costs are not exposed to the end user (yet) however being able to route traffic to an address (telephone number) and route traffic optimally is an interesting and potentially powerful feature. Consider Google. Currently there is coarse granularity traffic routing eg google.com, google.co.uk etc and there are data centre load balancing similar to ACD functionality in the telecom world. We now have IP addresses which the control plane can decide to route in different ways to today. We could for instance allow the network to handle routing to the nearest Google data centre without lots of special hacks such as DNS, or special routes to do the data centre assignment.

Virtual, overlapping or private address spaces suddenly are possible. The traffic can be routed based on the originator. The actual address becomes in many respects irrelevant.

OpenFlow is currently based around applying routes for persistent flows yet this doesn't have to be that way. Telecoms services allowed calls (flows) to change their route based on conditions (end-point was busy so forward to voice-mail) or actions such as “I'll forward your call onto xyz as they can help you”. Doing the same in the IP has some challenges since TCP assumes that endpoints remain constant and have state information but there's nothing stopping this model for UDP traffic sources or future protocols. It's probably easier to adopt redirection approaches for TCP.

It is not clear what SDN based applications and services will emerge yet it is clear that this base functionality will simplify the creation of innovative new services.

Telecom may seem old world but it has continued to move forward, particularly in the mobile space. Today's mobile networks are IP based with specialist boxes to overcome the limitations of IP eg GSNs for mobility functions. The latest generation is adopting a key element called a PCRF (Policy Control Function) which manages the service level and privileges at a user level. These parallel worlds can learn from each other!

So back to selling SDN. Today the message is one of flexibility and cost. It's hard to sell these application layer services when we don't yet know what they will be or the value they deliver. If the customer values on the fly network provisioning and dimensioning then there is real value which can be sold. It's feasible to randomly wire an OpenFlow network and it will sort it out. Today's legacy IP networks struggle. The types of customers that would value this dynamic network provisioning are cloud providers or companies with large constantly changing data centres.

Customers that place a high value on service availability and up-time would also value OpenFlow. Many IP boxes have found their way into the traffic path creating long serial service chains. When there are lots of boxes in a chain there is more chance of a service outage if one fails and more chance for unexpected interactions between boxes. Examples of these boxes are firewalls, load balancers, deep packet inspection. Generally these boxes are control functions.

It is rare that these types of boxes modify content in the payload. Usually they make a decision do I allows this or where should I send this. These are control functions. Occasionally there are boxes that modify payload for example content caches, content adaptation and maybe deliberate injection of jitter on VoIP calls! For the most part they are control functions so they can be moved into the control plane by OpenFlow. The end result is the data path becomes much shorter with fewer boxes which means higher reliability.

Today building fault tolerant IP networks is a challenge. Adding protection, redundancy and fail-over creates complexity. Complexity often leads to reduced availability so ironically the additional equipment built to provide resilience and higher availability can lead to reduced availability!

As the saying goes “every change has a consequence”. The consequence of simplifying the data path is the control layer potentially becomes more complex. The network has the potential for the network to become more fluid and dynamic. Particular services such as Video traffic, might request routing for low latency and therefore have a very different traffic path to web browsing. Sure the services get the best available performance for their needs but it creates a new problem for the operations staff when they want to trouble shoot an issue. Where was the traffic?

OpenFlow does allow traffic forwarding so the job of monitoring and troubleshooting can be assisted. Just like firewall vendors, if you're a probe vendors then watch out. OpenFlow is set to change your business!