The Internet Research Task Force, sister organization of the Internet Engineering Task Force, officially chartered a Software-Defined Networking Research Group earlier this year. This group is exploring various software-defined networking approaches that can be used in the near-term, as well as working to identify future research challenges. Dave Meyer, co-chair of the group and chief technology officer at Brocade, answers our questions about the SDNRG's goals and invites everyone in the networking community to get involved.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
What are the Internet Research Task Force's (IRTF) goals for the Software-Defined Networking Research Group (SDNRG)?
David Meyer: The SDNRG operates like a research group, with seminar-style meetings. The reason we're doing it this way is to expand not only the understanding of what software-defined networking (SDN) is and where it's going, but also to attract people not necessarily involved with the Internet Engineering Task Force (IETF).
We'd like to use the Internet Research Task Force for the SDNRG and vice versa to help connect a lot of the dots with SDN within our community. Right now, the idea that things are software-defined this or that is kind of amorphous -- everyone has their own idea of what SDN is. We want to be a place where people can come find out what's common or different with various SDN approaches, and also gain an understanding of the research challenges in those areas.
This group is very different than the IETF, because rather than determining the future of SDN, our goal is to explore this space and build a research agenda around it. Key areas of interest for the group include: solution scalability, abstractions, and programming languages and paradigms that are particularly useful within the context of SDN.
How does the SDN Research Group define SDN?
Meyer: Originally, SDN was considered to be OpenFlow and a complete separation of control and data plane, with centralized control and an open interface to the forwarding plane that was flow-based. The switches were dumb, with all the intelligence in the controllers, and the controller provided at least a logically centralized interface to everything.
My own view, which I call the 'SDN continuum,' is that OpenFlow SDN, just to distinguish it, is sort of a point embedded within a larger design space that's highly dimensional. If you look at it as a polar design point -- it's pretty far out there -- you can come back to what we have today and get something you might call control-plane SDN. The idea here is to make the control plane programmable, maybe do some things with the forwarding plane, but leave the existing control plane in place and make it programmable. This is kind of what's going on in the IETF, with examples like I2RS [interface to the routing system], BGP-LS [Border Gateway Protocol-Link State] and ALTO [Application Layer Traffic Optimization] in that category.
But you can go even further out in the other direction and take an agnostic approach to what's in the existing forwarding plane or control plane and overlay a completely new control plane over the top and do interesting things.
In my model, all of these approaches are SDN because they're all about software and network programmability of one kind or another. So I've kind of built this idea that network programmability is a larger thing. It's not exactly popular with everyone, but even network functions virtualization (NFV) fits into the category once you start looking at it that way. These are all software entities, right? That's the key part. For truth in advertising, not everyone agrees with me. A lot of people say SDN is about the separation of control and data planes. That's one thing you can do -- but I don't think it's necessary, or sufficient, for that matter.
Is the SDN Research Group focusing on specific SDN models?
Meyer: A lot of people are sharing their research. At the last meeting, Diego Lopez from Telefonica spoke about NFV, Rob Sherwood talked about the Big Switch view of SDN, which is really the more traditional one I described, and Kireeti Kompella from Juniper Networks shared another approach. Then Tom Nadeau from Juniper Networks described the difficult research problems in the SDN space. And Ed Crabbe from Google talked about Google's view of SDN. Other people were there, too, but this just gives you an idea of how we ran it last time. I have 100 emails from people wanting to talk about things at the next meeting -- it shows how much thought is going into this area.
What big issues does the SDN Research Group think SDN can solve?
Meyer: I'm going to share my view, but there are other views. The real value proposition here is that at the end of the day it's really a business issue, right? The goal of all this activity is to lower total cost of ownership for people who own or are running networks, because if they can't monetize, optimize and do it in an agile way, then what’s the point? That's the Holy Grail of this stuff and everyone -- from infrastructure providers to enterprises to over-the-top providers -- wants the ability to programmatically automate configuration management, monitoring and feedback loops.
We can't scale efficiently and have it be done by humans. We've known that for years, and one of the really good things SDN has brought to the networking community is a totally new, deeper understanding of what programmatic interfaces need to look like. And we know that people want to write Ruby and Python, that kind of stuff. So we've learned from the SDN process, even in the early days, how to think about building network APIs [application programming interfaces] and interfaces that are consumable by the people writing code.
Another key piece is DevOps, which is a huge movement that requires this sort of interface. So again, programmatic automatic configuration management monitoring -- all this stuff is bi-directionally important. We need to be able to get this stuff out of the network and data mine the network. All of these things have come into our consciousness because of SDN.
So the 100,000-mile view of what we're going to get out of SDN: new ways of optimizing and monetizing networks and controlling total cost of ownership; new features, new ways of being agile; new ways of viewing how we actually operate networks. That's what we'll get out of it. But the idea that the distributed control plane infrastructure that's been so successful in the Internet is going to go away isn't realistic, or desirable, for that matter.
What are the SDN Research Group's interests in terms of security with SDN?
Meyer: Three different research groups in different geographies of the planet and in different sectors -- academic, enterprise and service provider -- have come up with security proposals. Everyone is nervous about security, and rightfully so.
Even in the sort of control plane SDN scenarios -- in which you take an existing control plane and make it programmable -- if you use a protocol like I2RS, which is being developed by the IETF right now to allow you to both read and write into what's called the routing information base on the router, it's basically routing state and it's an open loop. You don't know what's on the other side -- it could be a person. Once you have that, it makes the security environment difficult to analyze. That's a huge topic and is one of the main ones we'll focus on.
One of the key things to know about security is that it's inversely related to the complexity of the system -- meaning the enemy of security is complexity, because you can't understand the system if it's too complex. An odd thing still being researched is that some of the SDN scenarios are actually more complex and their security properties will be difficult to analyze or understand. Some are easier, some more difficult. It is and will continue to be a fertile area of research for years.
Is there anything else you'd like everyone to know about the SDN Research Group?
Meyer: Yes -- the group is open to everyone and all ideas are welcome. Engineers are invited to participate on the research side, and if you're a researcher and want to participate on the engineering side, this is a good way to do it and help us cross-pollinate. The operational community is sort of in the middle, and they're also very active. Everybody is welcome and invited to participate.
SDNRG will report its progress though its wiki and presentations at IETF and IRTF meetings.