Jason Edelman's Blog
  • Home
  • About
  • Contact

CAPWAP and OpenFlow – thinking outside the box

11/30/2011

5 Comments

 
After reading Ivan Pepelnjak’s (ipspace) and Martin Casado’s (networkheresy) blogs recently, I noticed they were making general comparisons on network tunneling protocols.  These protocols are nothing new, for example using UDP, GRE, EoMPLS, VPLS, and a new one being mentioned over the past several months, VXLAN.  However, what caught my attention was CAPWAP was also a protocol each of them used to compare to GRE, UDP, and VXLAN.  As you’ll recall in my recent OpenFlow post, I spent quite a bit of time comparing OpenFlow to CAPWAP in the sense OpenFlow is being used to separate the control and data planes on switches and CAPWAP is being used to separate the control and data planes on Access Points.

I figured, why not, let’s google CAPWAP and OpenFlow together and see what comes up.  No surprise, you see the post from Matt Davy at IU who was drawing a similar comparison to OF/SDN to CAPWAP/WLAN, my recent blog, Ivan’s blog, Martin’s blog, and then finally the reason why I’m writing this – I saw a link to openvswitch.org that talked about building support for CAPWAP into the open vswitch.  Interesting, right?  Well, to me it is!  So after digging further, it looks like Jesse Gross (from Nicira, the company who does much of the development work on open vswitch) had some comments in the commit log for this feature. 
Here is the link and exact write up by Jesse:
 
“datapath: Add support for CAPWAP UDP transport.

Add support for the transport portion of the CAPWAP protocol as an alternative to GRE for L2 over L3 tunneling.  This is not full support for the CAPWAP protocol.  CAPWAP covers management of wireless access points and describes a control protocol for setting those devices up.  It also describes a data plane protocol that allows packets to be tunneled to a controller for inspection. This data plane protocol is the only component covered by this commit.
Signed-off-by: Jesse Gross”  Btw, this was dated a while back, August 2010. 

Another interesting point here is that Nicira has only implemented the data plane protocol piece of CAPWAP to meet the requirements of tunneling between vswitches.  Why hasn't anyone else done this in broader sense of supporting it general L2/L3 devices?

 This got me thinking, and the more I thought, the more questions I was asking myself, which is normally the case anyway.  So here they are:

  1. Is there any other device in the industry that supports CAPWAP (full blown or data plane protocol) besides access points, WLAN controllers, and open vswitch?
  2. What drove Nicira to implement CAPWAP on openvswitch?  I actually quite like it – it’s definitely thinking outside of the box because it is known as a protocol used in WLAN environments, although as we/I see now, it is just yet another tunneling protocol.
  3. Wireless APs have the ability to speak CAPWAP to a first hop controller and then based on WLAN/SSID, the first hop controller can build another tunnel (EoIP) to what is the "guest" anchor/controller that is commonly deployed in the DMZ to implement path isolation and security for guests.  Wouldn't it be great if the guest anchor could be a L2/L3 device...maybe even a OVS?
  4. What does OpenFlow use to tunnel packets from an edge device back to a controller in the event there isn’t an entry already in the FIB table…or is an L2 adjacency required between a controller and OF-device?
  5. While only the data plane portion of CAPWAP has been integrated into openvswitch, has Nicira also built support for full CAPWAP into their controller in order to support wireless access points?
  6. Could OpenFlow be used as the control protocol and CAPWAP as the data plane protocol for access point support on OF-controllers?  Not sure this would make sense, but figured I’d get all the st*p!d questions out of the way!


These are really open ended questions on my part, but for any of you folks out there that have coded these protocols or is extremely intimate with the protocol specifications, I’d love to get your take.

Thanks,
Jason 
@jedelman8
5 Comments
Ivan Pepelnjak link
12/10/2011 07:05:27 am

Answers:

#2 - speculating: frag/defrag is part of CAPWAP protocol.

#3 - hard; OVS doesn't support the control-plane part of CAPWAP, just the data-plane encapsulation.

#4 - TCP session using OpenFlow protocol. You need IP connectivity between OF switch and OF controller.

#6 - this might make sense assuming AP has CAPWAP-capable HW. If AP does everything in SW, the encapsulation method doesn't matter (unless someone wants to load OF functionality on top of existing AP forwarding plane).

Just my random speculations ;)
Ivan

Reply
Jason Edelman link
12/11/2011 03:44:12 am

Ivan,

Thanks for the speculations :)

#3 - I'm going to dig deeper into this b/c I'm referring to the tunnel between two controllers. Need to see how this differs to the CAPWAP tunnel between an AP and the first hop controller.

#6 - most enterprise APs are supporting CAPWAP in hardware AFAIK so this shouldn't be a problem. Just trying to see how possible a single unified control/mgmt plane would be for a Enterprise.

Reply
James Cabe
12/19/2012 08:39:25 am

I have a question on #6, why would you encapsulate further? I understand that plenty of people expect the tunneling back to the controller, but this has proven fairly inflexible and doesn't seem to be the way the market is moving (cloud controllers that control "fat" APs, preferably in a mesh). I would suppose that you could choose a local "gateway" if doing mesh and wanting it to stay CAPWAP on the user plane. This just seems a bit convoluted and would require heavier hardware. You could definitely make the argument that tunneling the data still makes sense in the interest of traffic protection and route persistence, but I wonder if you could handle this in other, (maybe) more elegant ways?

Thanks for the article, it is definitely one I will repost.

Reply
Jason Edelman link
12/21/2012 08:34:12 am

James,

I do agree with tunneling data back to controllers for WLAN environments. This is going to be changing soon. I'd expect to see different controller architectures within the next 12 months because as we see with emerging standards such as 802.11ac, it'll just be too much to tunnel back - agreed on your point. With all that said, my initial question on #6 is irrelevant now because of how wireless is evolving.


-Jason

Reply
Amelia link
2/5/2014 09:37:05 pm

It is really a great and useful piece of information. I am glad that you shared this helpful info with us. Please keep us up to date like this. Thank you for sharing.

Reply



Leave a Reply.

    Author

    Jason Edelman, Founder & CTO of Network to Code. 


    Enter your email address:

    Delivered by FeedBurner


    RSS Feed


    Categories

    All
    1cloudroad
    2011
    2960
    40gbe
    7000
    Arista
    Aruba
    Big Switch
    Brocade
    Capwap
    Christmas
    Cisco
    Controller
    Data Center
    Dell Force10
    Embrane
    Extreme
    Fex
    Hadoop
    Hp
    Ibm
    Isr G2
    Juniper
    Limited Lifetime Warranty
    Meraki
    Multicast
    N7k
    Nexus
    Nicira
    Ons
    Opendaylight
    Openflow
    Openstack
    Presidio
    Qsfp
    Quick Facts
    Routeflow
    Sdn
    Sdn Ecosystem
    Security
    Ucs


    Archives

    May 2015
    April 2015
    February 2015
    January 2015
    December 2014
    November 2014
    October 2014
    September 2014
    August 2014
    June 2014
    May 2014
    March 2014
    February 2014
    January 2014
    December 2013
    November 2013
    October 2013
    September 2013
    August 2013
    July 2013
    June 2013
    May 2013
    April 2013
    March 2013
    February 2013
    January 2013
    December 2012
    November 2012
    October 2012
    June 2012
    May 2012
    April 2012
    March 2012
    February 2012
    January 2012
    December 2011
    November 2011


    View my profile on LinkedIn
Photo used under Creative Commons from NASA Goddard Photo and Video