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.