In my blog on Friday of last week, I talked about the pitfalls of not examining the details of current network services when considering how SDN or NFV might be used to implement or replace them. Some of you have noticed that the blog opens a door to considering network services of all sorts as a kind of hybrid involving two hot topics—NaaS and “microservices”. I want to use a discussion of those to start a deeper dive into a service model for SDN and NFV that will carry through both today’s blog and the one tomorrow.
Let’s imagine an access connection, something like Carrier Ethernet or a consumer broadband connection. It’s just been installed and it doesn’t do anything yet. Pump in a typical packet and it goes into the bit bucket. But let’s also suppose that this connection has one special IP address, like 10.0.0.1. If you go to Port 80 (html) of that address, you would see a portal, and through that portal you could now set up a service. Maybe it’s consumer Internet, or maybe a VLAN, or even perhaps both. Click and you have forwarding as requested, and the ability to receive packets from specified places. You could also say that you wanted firewall, DNS, DHCP, VPN client, special gaming or business collaboration. Whatever you pick is strung out on your access line and now accessible to you.
This sort of thing is where I think that NaaS, SDN, and NFV could get us, with a healthy dose of “microservices” that would be a lot like VNFs but also a lot more.
All technology innovations aside, it’s time we started thinking about access connections as assets that we, and operators, can leverage freely. They should not be dedicated to a specific service, but to an elastic set of service relationships that might be delivered using any convenient protocol. A blank slate. This model would suggest that our access portal could deliver to us a set of network-as-a-service capabilities, but if you look deeper each of these would consist of a connection model and a microservice set.
The connection model is simply a description of the forwarding behavior and site community associated with a NaaS. This is what would define the addressing mechanism used and how traffic emitted at a given site would be handled (line, LAN, tree, are the classics). The microservice set would provide higher-layer features, and could be extended to offer even more—which I’ll get to below.
What this would create would be something like an on-ramp to an expressway that’s lined with useful little shops. You could access only the shops, you could access only the expressway (picking your route) and you could do a bit of both. I’m not saying this is the only to do it, but this would create the architectural model of an “enhanced” service.
Management of this could be done through the portal, meaning that we could set this up to deliver web-based management. We could also deliver SNMP management by simply opening an SNMP microservice, and we could deliver an arbitrary management API as a microservice too, something like TMF MTOSI.
The microservices in this model could be hosted in the cloud, of course, and they could either be deployed per-tenant on demand or be multi-tenant services. In addition, they could be deployed on the customer premises, either in a private cloud or in CPE that provides service termination. The model doesn’t care what a microservice is or does, so it blends cloud applications and NFV features and makes it clear that what’s needed for either is increasingly needed for both.
There are obviously a lot of ways of looking at this besides the one I’m proposing, but I hope my comments make my central point. We need to examine the end-game of SDN, NFV, and the cloud. We need a picture of what networks and services and applications will look like at that point, because without it we’re going to have real trouble in the evolution to SDN and NFV.
Remember my comments on how all this arguably started was an operator vision of transformation? Well, you can’t get much traction without having some sense of what you’re transforming to. Part of that is simple merchandizing. Advocates for SDN and NFV can talk about “starting small” or “early applications” or “basic services”, but transformation isn’t about limited change, it’s about massive change. To what?
Not to mention the specific benefits. If NFV or SDN improves capex or opex or agility, they’d have to spread widely enough for the improvements they offered within their scope to be significant at the business level. Nobody will bet their job on a migration to something that saves one percent.
Where I think the big problem with limited-scope thinking comes in is in hiding the need for and even value of systemic strategies. I talked last week about the protocol issues of current services and their impact on SDN and NFV. The model of NaaS and microservices that I described here could address those issues. But how about the problems of SDN and NFV?
Let’s look at SDN as an example. We have three possible modes of SDN operations. One is where connectivity doesn’t exist and forwarding tables don’t exist, and the introduction of packets stimulates devices to ask the controller what to do with them, thus building up the routes. Clearly this would never work on the Internet with some gigantic central server; it would likely take weeks to converge on full connectivity. Another mode is where the central controller preconfigures routes. This is fine for “interior” routing, but users appear and disappear at the edge and it’s getting to their addresses that forwarding is all about. The final mode is adaptive, which gets us to building something we say is SDN but is actually just doing legacy routing/switching a little differently.
I think that future services will be NaaS-like, meaning pure forwarding with no inherent control/management behavior. I think that control-plane activity will be supported then through microservices, and that microservices will also offer management connections. I’d guess that many agree with these points, but I’d be happy if someone presented an alternative model. Happy because it would get us to the discussion of what the ultimate SDN/NFV/cloud network would look and work like, and how we’d use our revolutionary technologies to get to that state. We need that.