Thursday 6 June 2013

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.

2 comments:

  1. Open Flow permits direct access to and manipulation of the forwarding plane of network devices like switches and routers, each physical and virtual . it's the absence of AN open interface to the forwarding plane that has junction rectifier to the characterization of today’s networking devices as monolithic, closed, and mainframe-like.

    Thanks
    Silvester Norman

    Change Mac Address

    ReplyDelete
  2. This comment has been removed by the author.

    ReplyDelete