Today in OpenStack, if you’re thinking about networking, you’re almost certainly thinking about Neutron. Neutron provides you with networks to attach your VMs to, and you can attach one virtual machine to many networks via individual ports – letting you isolate your internal application traffic from the world. You can use many IP addresses in your application even when the cloud only has a limited number of IP addresses in our IPv4-starved world. What’s wrong with that?
Well, if you’re a normal cloud application designer, that works very well. If, however, you’re working in the world of NFV, it’s rather limiting.
Look at your home network. In your home, all your devices talk to each other over a network – or, if you’re really adventurous, two or three networks – using IP. That works fine – for your house. However, internet service providers and telcos frequently want to do much more than this.
One example is MPLS. In the world of service providers, you sometimes want to make a kind of circuit from one place in the network to another one. You might do it so that you can reserve bandwidth between the two points for a specific purpose, for instance. MPLS can let you do this. But MPLS is not an IP based protocol. It works differently and has different properties.
NFV designers would like access to tools like MPLS to make their network applications work better. And this matters a lot – in the world of high performance virtual networking functions, or VNFs, it’s possible to run VMs so that they completely fill a 10G interface, a pipe ten or more times bigger than the ones you’re likely to have in your home. Unlike the applications you’ll usually find in a public or enterprise cloud, they do a little bit of work to every single packet that passes through them, and the application as a whole – a collection of lots of VMs – can even be processing all the internet traffic of a country-wide mobile phone network. They want to be able to use the right tool for the job.
To date, we’ve added a few of these functions – like MPLS networking – to Neutron. But the problem is they don’t fit there very well – we can make them work, but because we’re still talking in terms of Neutron’s networks and subnets – as if the network is one big flat network like you find at home – the model in the API doesn’t really fit the model of the underlying network, and there are some things you can’t easily describe. Additionally, 90% of OpenStack clouds don’t get any benefit from these new APIs, so we have to find a very careful way to add them. We have to keep backward compatibility, so the APIs that already exist have to work in just the same way. We add these features as extensions, but we still sometimes need to change core networking code, so we have to be very careful not to introduce bugs.
What if we could make a completely new API, completely specific to these special networking tasks, without touching Neutron at all? That’s something I’ve been working on in conjunction with friends from other companies like AT&T, Ericsson, Nokia, Juniper and Huawei.
In the physical world, gluons hold particles together. In an OpenStack cloud, Gluon lives between Nova and the cloud’s networking services and holds them together. Nova can talk to Neutron in just the same way it does today – but it can also talk to other sorts of network provider, ones that are specialised to other tasks. Networking APIs provide ports, and Nova attaches to any of those ports just as it does to Neutron ports today. It doesn’t care where they came from, and Gluon helps to hide all that away. I still get all the things I like from Neutron – but I can add different – and completely independent – networking types to my cloud as I need them. And – equally importantly – if I don’t need them, I can leave them out, and there’s not an ounce of code on my system that’s affected.
We’re trying to go further still. If we want to invent one new API, how many more might we want? How do we experiment? So we’re trying to make it possible for someone to quickly write a model file describing an API for a new networking type – we call these new APIs protons – and rapidly turn that into a reality, using something we call a particle generator. (We might have taken the analogy a little too far, sorry…)
What if I want to use lots of different networking types?
Today, if I want to use different networking concepts using Neutron extensions, I have to find myself a Neutron plugin that does all of the things that I might want to do. That’s not so easy – there’s a basic implementation for some of these APIs in OVS, but if I want lots of these APIs (and, of course, really fast networking), I might be limited to just one commercial network controller from one vendor, or even find there’s nothing out there that does it all.
With Gluon, I can use my many APIs, and, because the APIs are completely independent, each of those APIs can be backed up by a different SDN controller. I can use Neutron with a plugin I like for my normal networking; I can find a controller that does MPLS; I can add a third one for service chaining – and I can use one VM connected to all of these different types of networks, so I get my customer traffic in over MPLS, run it through a service chain, and administer and control my VM using conventional Neutron networks.
And, conversely, if it satisfies all my needs, I can run Neutron by itself just the same way I do today – I don’t have to worry about any of the other services at all, and no matter what new developments come along none of the code I deploy needs to change.
We’re trying to expand the world of cloud networking. We hope you’ll join us on the journey. And we’re trying to make sure we don’t drag you along for the ride.
For more information about Cisco at OpenStack Summit, visit cisco.com/go/openstacksummit. If you are at the event, come by the Cisco Booth C11 to talk to the NFV team.
The open source Project Contiv compliments application intent to enable operational intent to specify infrastructure and policies for network, storage and compute.
