alphaspirit - Fotolia


How to make legacy and emerging network technologies work together

Emerging network technologies like SDN and NFV have to interwork with legacy equipment and be managed as one. Find out what it will take to get there.

Nobody doubts that the network of the future will be different from the network of the present, but it's a given that we only get to the future one step at a time. Even in the most futuristic view, it's hard to imagine that all of the network devices we now use will have disappeared. That means emerging network technologies, including both software-defined networking (SDN) and network functions virtualization (NFV), will not only have to coexist with legacy equipment but be managed together.

This raises the question of how to make legacy and emerging network technologies play well with others. So far, three options offer the best solutions: functional abstraction; interworking network zones; and common management representations. Let's look at some details.

How functional abstraction works

A "functional abstraction" can be descried as a kind of network service black box that turns a network function into an abstraction without committing resources to it. It has visible service properties in that it has inputs and outputs, but it hides the details of its implementation, so there's no looking inside of it to see what's what. In network evolution, functional abstraction lets us group technology options that do the same thing and classify them as equivalent. This facilitates introducing new technology, as well as the coexistence of multiple technologies. SDN and NFV can be introduced into networks with legacy equipment, and with each other, if we can represent the new network elements created by SDN or NFV as virtual forms of existing devices or systems of devices.

An SDN white box switch coupled with an SDN controller that manages packet forwarding to mimic an Ethernet network could be used wherever an Ethernet switch is currently used. For example, it could be the basis for an IP subnet or provide data center switching, even if other real Ethernet switches were in use. All that's required is that the virtual device created by SDN appears as a "real" Ethernet device at its interface points. That means Ethernet itself can be a functional abstraction realized by legacy switches or SDN.

As either their SDN or NFV commitment expands, operators may find that forcing these new virtual black boxes to conform to current device protocols and standards limits their utility.

But as either their SDN or NFV commitment expands, operators may find that forcing these new virtual black boxes to conform to current device protocols and standards limits their utility. One way to address this problem is to expand the creation of an SDN or NFV virtual device to span multiple devices or virtual functions. The black box can contain many elements, but because one of its properties hides its internal structure, it can still be connected like a legacy device and used in conjunction with current technologies.

Where the virtual device looks like a collection of devices -- or a subnet, area or zone -- the focus needs to be on how to replicate the devices with SDN and NFV in the way subareas or zones would be connected in traditional networks. For example, an SDN or NFV implementation of core virtual routing might be made to appear as a Border Gateway Protocol autonomous system, which could actually simplify how the SDN/NFV virtual core integrates with legacy technology. Anything that can meet the boundary interfaces of a network zone can integrate with other elements that conform to those same interfaces.

The trick to interworking legacy, SDN and NFV

Of course management is the most complicated issue with interworking SDN, NFV and legacy elements. The management of a virtual device could be presented to a management layer in the same way as the management of the real device it is based on. But any divergence in the implementation of the device -- hosting functions, white box switching, controllers, internal data paths, etc. -- would have to be visible to network operations personnel on demand to be able to isolate and repair problems. This requires not only a mechanism to dive below the boundary of the black box, it requires a way to find the components inside when they could have been hosted nearly anywhere, and harmonizing their state with the virtual device overall.

Considering network management virtualization

Both SDN and NFV suffer from this management connection challenge. An SDN network is really a set of coordinated forwarding rules that implement a kind of distributed virtual router. As a result, all of the pieces have to work under synchronized control of a central element. This controller makes decisions on forwarding that are invisible to the IP or Ethernet service and implements them through a set of Open Flow commands. In NFV, elements of a service are hosted based on best-fit policies in a distributed farm of resources that could extend all the way to the customer premises. Obviously the deployment of either has to create management connections as it progresses or elements will be lost to management view.

The virtual device model is the approach most vendors and operators are relying on, and in the near term, while deployments of SDN or NFV are small, there's a good chance it will work. But as SDN and NFV expand, virtual devices may simply not be enough if operations cost reduction is a major near-term goal. In that case, virtualizing management itself may be the only solution.

A virtual management mechanism is already implied in cloud standards. The OASIS TOSCA standard for application deployment in the cloud has a parallel definition for management processes and deployment processes. In essence, management virtualization means defining the management of any set of virtual elements through a set of expressions that relate each virtual management variable to one or more of the real variables associated with the resources assigned during deployment. Multiple management views could be defined concurrently to support service provider or customer support and network operations differences.

All of these mechanisms are useful, but they all rely on the assumption that a unified approach to functional abstraction, interworking and management is taken across legacy, SDN and NFV elements. Since standards have not yet provided for this, operators should look to vendors to ensure that they offer some pre-standard mechanism that works, and that this mechanism is harmonized with standards as they evolve.

Waiting for standards is not an option here; the opportunities associated with SDN and NFV are too great, and the consequences of delay too extreme. Most operators believe major changes in service agility, capital equipment and operations efficiency have to be made before 2018. If that's true, it's time to get started.

Next Steps

Review the three models of SDN with Tom Nolle

Understand the most important features and functions for your NFV framework

How to bridge physical and virtual networks

A look at how SDN and NFV work to advance each other's capabilities

This was last published in January 2015

Dig Deeper on Telecommunication networking