Friday, January 25, 2013

Thimble - Secure, high-speed connectivity with OpenFlow & Science DMZ

I've been busy

Last week I had the pleasure of spending a week in Honolulu at TIP2013, going to workshops, watching presentations, and socialising with some of the most talented network engineers in the world, and I felt incredibly fortunate to do so. I also had the opportunity to present some of my OpenFlow work with them, and was amazed at the feedback that I got from everybody. The recording of my presentation is now available online. I gave the same presentation this week at NZNOG, and I'll link to that when the on-demand video is available.

Thimble

For scientists to move big data in reasonable time frames, they need to have data transfer nodes outside of their campus firewalls, inside a Science DMZ. This is a proven way to optimise file transfers, but exposes your file transfer nodes to the whole internet. Thimble is a way of using OpenFlow to easily program ACLs into your edge switch, and I've covered it briefly here and here. The variation that I presented at TIP2013 and NZNOG positions the Science DMZ between an edge router and campus firewall, allowing a subset of routes to be sent to the OpenFlow switch. This means we only need to send experimental traffic to the Thimble, allowing implementers to test this without risking production traffic.

Clever stuff

You can federate a few Thimbles with a single controller, allowing a file transfer logged on the web application to trigger multiple switches around the world to be reconfigured. We're not just tied to a web interface either - there's nothing to stop us implementing uPnP at the edge and letting file transfer programs communicate with the network to arrange ACLs. The end goal is to take existing concepts and apply modern software design principles, allowing us to do things easily that used to be out of the question - network doesn't need to be this hard.

If you're interested in building a Thimble, I'd love to hear from you - leave a comment or email me and I'll be more than happy to hear your stories and help wherever I can.

RouteFlow in New Zealand

We've had some cool demos up and running this week - a distributed router was deployed at WIX and another data centre here in Wellington, and a RouteFlow deployment powered one of the internet feeds for the NZNOG conference this week. We had a screen up showing the flows present in the switch as people joined and left the wifi, and counters for data plane and control plane traffic. It was a nice visual demo - we could connect a cell phone, show the MAC and IP addresses in the new flow, and start a download to show the data plane traffic going up without changing the control plane traffic - just to prove that we don't need to send every packet via the controller!

What's coming in 2013

We're off to a really good start with OpenFlow this year, and I reckon the killer app is a year or two off at tops. Here's what I want to see happen:
  • Distributed routers - a mesh of 5-10, all controlled centrally
  • MPLS!!! OpenVSwitch now does OpenFlow1.2, and the Pica8 switches have implemented this, so there's no excuse for us not having an OpenFlow replacement for LDP/RSVP
  • Breaking OSI. Flows can match on any combination of ethernet, IP, and TCP/UDP, so I want to see more clever stuff happening with that. OpenFlow will let you do longest-prefix-matching on MAC addresses if you want, or route based on TCP/UDP ports, or some other weird combination. You'd want to find a way to do this that would be valuable, but people just need to jump in and see what new ideas they can come up with.
  • ???? - you tell me what you'd like to see in OpenFlow this year.

2 comments:

  1. Enjoyed the posts Sam. Looking forward to tracking your endeavors.

    ReplyDelete
  2. Thanks for sharing this post it is great i like it very much.
    Thimble

    ReplyDelete