Recently we've heard a lot about the notion of a "third" network, service or management, but this "third-ism" might be selling the concept of virtualization short and getting in the way of what is really needed to move to The New IP.
When a BT spokesperson talked about a "third way" of management, and the head of the MEF talked about a "third service," the comments were directed at the need to think beyond current models in both networking and IT, services beyond Ethernet and IP, and management beyond traditional OSS/BSS/NMS and IT management. It seems very logical, but the question is whether we might be better served not by a new model, but by a new notion of modeling.
If there is a technological thread common to all of our current revolutions, it's virtualization. If you adopt a strategy that lets you model functional and structural relationships and through processing, these models can commit suitable resources. You can build anything that resources can accommodate.
Software-defined networking (SDN), network functions virtualization (NFV) and the cloud are applications of virtualization. Virtualization is the combination of abstraction of functionality and software-driven instantiation of the abstraction on a pool of resources.
Rather than coming up with a new "third" model, the industry should instead focus on answering the questions: What is the successor service model in a future where virtualization principles can map any set of features to resources? Why does there have to be a single model at all? Abstraction and instantiation, the functional core of virtualization, start with the abstraction, which is a model or model set, so why not let virtualization run free, free to define whatever network models and network services we like?
The heart of SDN
Users consume network services through network service access points (NSAPs). These points are defined by two sets of protocols: the end-to-end protocols that the service transports on behalf of users, and local/control protocols that are ways of accessing or mediating services the network itself can offer.
If you had two NSAPs that could offer identical support for these two things, you'd have identical services from the user perspective. This notion is the heart of SDN -- it doesn't matter how you do the switching/routing control, only that the service looks the way users expect.
There's a corollary to this, though. You could build services that looked like IP or Ethernet but that had features or capabilities that these familiar protocols didn't have. Those features could be inserted transparently to the user, or through an added end-to-end or local/control protocol.
One approach -- a transparent approach -- would be to build a branch office address space from only the applications each user was allowed to access. Another approach -- the added-protocol mechanism -- would be to add logical address (URL) translation to pure Ethernet with a DNS-like extension.
The point is, in a virtual world we can build services ad hoc. We should exploit every bit of that capability to drive both SDN and NFV forward.
On the management side, it's just as interesting. A branch access device has a management information base (MIB) and an API that allows access to its state and control variables. In the real world, that MIB is created by the box that provides the branch access features.
If you translate that box via NFV to a collection of virtual functions, we have to construct the MIB to mimic what the user would expect. But we also have to be able to drill down from that MIB to the constituent functions, at least at the network operations center, to find and fix problems. So we have to construct other MIBs.
MIBs are management services, and if we translate network services to virtual form we have to translate management services in parallel. If we virtualize management services by allowing for MIBs to be constructed as needed, then we've solved what many think is the biggest challenge for SDN and NFV -- evolving operations practices.
Today, OSS/BSS/NMS systems all consume APIs, which are MIBs. If virtual operations practices can create any convenient API/MIB then we can make a virtual network look at the management level like what the OSS/BSS/NMS expects to see. We don't force changes in operations practices at all, we just make it possible for current management tools to work with virtual services and resource pools assigned dynamically.
In addition, we can use virtual-service concepts to create Ethernet and IP, and also to create services that build on either of these base services, or even define totally new models. We can do that without the inertia of building a whole new network based on new boxes -- virtual networks are malleable in a sense we've never experienced in our industry. We can use virtual-service concepts to create old management APIs/MIBs, and also to create any new set of MIBs that might help us operationalize our services more effectively.
What we can't do is to shoehorn infinitely agile technologies into virtual boxes and say that we're transforming to The New IP. We'd just be creating the old IP a different way. The term "think outside the box" is particularly relevant to networking. Boxes have limited us in the past, and virtualization in the form of SDN or NFV lets us break free of those limits. Let's do that, and take full advantage of our "revolutions" so that they are as revolutionary as they can be.
— Tom Nolle, President/Founder/Principal Analyst, CIMI Corp.