SDN and OpenFlow have had good traction within the datacenter and many of the early investigations and deployments have centered on the datacenter and overlay networks. In the meantime, there’s been a push to find use cases beyond the datacenter, into the service provider networks, for inter-datacenter traffic (similar to Google), as well as for mobile, backhaul and enterprise WAN connectivity. Here at SDNCentral, we wanted to highlight new ideas and use cases beyond just the traditional datacenter and so we reached out to Ping Pan, Architect at Infinera to have him share his ideas around OpenFlow and optical transport networks.
SDNCentral: Thank you for spending time with us today! Does SDN and OpenFlow have a place in transport networks?
Ping: “Absolutely! Transport networks today are islands of equipment that don’t always interoperate well, and tend to be slow and inflexible. I think the SDN frameworks that have started to open up datacenter and campus networks can do a lot of good to transport networks. And this is not just an idea that I and Infinera are pushing, but there’s a group of us from multiple companies, including Adva Optical, Ciena, Juniper, Ericsson and Huawei, that are pushing a proposal around SDN for the transport network to the ONF.”
(Editor’s note: Ping has kindly made his slides available to the SDNCentral community for download–see the form below the interview)
SDNCentral: The SDN community has been well-trained to ask about use-cases right up front, as you may well recall when the OpenFlow hype started being noticeable early this year; so I have to ask, what use cases do you see for SDN in transport networks?
Ping: “There are multiple use cases, but perhaps we can talk about two that I’ve seen come up quite a few times already. One is around virtual overlay networks, which shouldn’t be a surprise since we’re already familiar with the concept of inter-datacenter overlay networks using virtual switches within hypervisors. The other is bandwidth-on-demand, where the carrier can provide immediate provisioning of additional bandwidth between locations, perhaps even with self-service provisioning by end customers to facilitate large data transfers or other immediate bandwidth needs.”
SDNCentral: What other capabilities are possible with SDN in transport networks?
Ping: “You could imagine service providers allowing a flexible fabric-like platform for offering OTT (over-the-top) services, or even providing APIs to end-customers to programmatically command the transport network to do their bidding. Of course, the billing and SLA mechanisms all have to be built out, and the usual OSS/BSS integration has to be done, but I see in the longer term, that the flexibility will benefit business agility and provide additional services that carriers can sell.”
SDNCentral: Let’s take that idea to the extreme. Share with us the vision that you and your counterparts in the transport world are pushing.
Ping: “I think we’re all familiar with the idea of the virtual switch, and the project known as Open vSwitch (OVS). Now, OVS with OpenFlow was innovative in that applications can program the switch forwarding logic via OpenFlow to create paths between virtual end-points. And we see the same with physical switches with OpenFlow support as well. In general, the datacenter is relatively transparent (at least within an enterprise) and the underlying connectivity is usually well known and exposed.
In the transport world, there are many challenges with provisioning and controlling transport networks today. Plus, unlike in the datacenter, carriers tend to be more discreet about the underlying connectivity and topology—both for customer security and for competitive reasons. The big idea that my counterparts and I are pushing is the concept of OTS, or the Open Transport Switch. Like OVS, the OTS is a virtual switch designed to provide programmability to applications or external orchestration platforms, and like OVS, we would like to expose the simple model of virtual ports, or end-points. The OTS is designed to be transport agnostic, or rather, it hides the complexity of the underlying transport and takes care of all the complicated tasks like creating cross-connects and managing wavelengths in optical networks.
If we succeed, then organizations could interact with a collection of OTSes, or a big OTS that provides a simple programmatic API to connect the multiple locations that the organization is at. We could provide a safe abstraction to applications and organizations, with isolation between clients, and keeping the underlying physical network hidden from end customers.”
SDNCentral: Wow, that’s a pretty compelling vision: the transport network as a virtual switch that we can program to do our bidding. I can see us creating dynamic paths between locations, asking for instant bandwidth and provisioning paths with a set of known SLAs. Controllers being agnostic of whether they are talking to vSwitches in hypervisors, physical top-of-rack switches in datacenters, or transport switches in the metro and wide-area networks. That’s pretty cool! So, when can we get our hands on that?
Ping: “Well, it’s going to take some effort and participation from multiple parties. We’re just starting the process and trying to get momentum behind the idea and partners in our mission. We’re working with the ONF to get the process started and anyone interested in participation can contact us. The more resources and people, the faster you can get your hands on it.”
SDNCentral: We hope that you get a great response to your call for assistance and partners and that we see the vision realized sooner than later! Thank you again for your time!