BACKGROUND IMAGE: iSTOCK/GETTY IMAGES
The cloud has created two missions for the network in terms of bringing about the convergence of IT resources. Mission one is to connect the application, storage and compute elements that make up the resource pool that we call "the cloud" with stable cost and performance across large geographies. Mission two is to support application needs for connectivity, both internally among the components of applications and externally for application users. Together, the combination of these two network missions creates the foundation of the notion of network-as-a-service or NaaS.
IP and Ethernet networks are connection networks, in that they provide uniform connectivity to the entire community of endpoints. That kind of open networking isn't suitable for many enterprise applications, which is why we have virtual private networks today. The problem is that VPNs are almost always site networks -- static communities of specific business sites. Network as a Service is an evolution of the basic notion of using VPNs to create virtual application networks. The NaaS technology that is the best known today is software-defined networking, or SDN.
To "software-define" a network, the key requirement is to use a set of application program interfaces (APIs) to build virtual networks with specific properties that match the needs of applications. These needs can be external, such as the need for Quality of Experience in user connections, or internal, such as the need for consistent connectivity inside the virtual resource pool of the cloud itself . Network as a Service, in SDN terms, represents the set of services that applications and software can use.
Three main approaches to creating virtual networks, including overlays and SDNs
We use so many different network services that, in many ways, it's not surprising that multiple approaches to SDN have emerged as different vendors and users attempt to address Network as a Service needs that have the highest priority to them.
- The virtual overlay network, pioneered by Nicira and later acquired by VMware, is an SDN model with wide appeal. SDN overlay networks -- also called virtual overlay networks -- use tunnels to create a virtual network on top of traditional IP or Ethernet. Because these virtual overlay networks ride existing networks like ordinary traffic, they can be used with any existing network equipment. They don't inherit the technical restrictions on the number of virtual networks a protocol like IP or Ethernet can support, so you can have tens of thousands of virtual overlay networks in a cloud -- enough to give every application its own. This ensures that applications sharing a pool of resources don't interfere with each other or create security problems. This kind of application is often called multi-tenant because it creates a network whose services are partitioned for all of its users/applications, which are the tenants. With this first SDN model, Network as a Service takes the place of a traditional virtual private network.
- The centrally controlled software-defined network, defined by the Open Networking Foundation using the OpenFlow protocol, was the second SDN model to emerge. OpenFlow enables a software controller to manage network traffic by creating forwarding-table rules in every device. By making all packet forwarding a function of a central controller, every aspect of traffic management and connectivity can be software directed. OpenFlow is supported by all the major network vendors, and OpenFlow controllers are available from the Open Daylight project, Big Switch, Juniper, Alcatel-Lucent and other vendors.
OpenFlow networks can support any number of virtual private networks, and manage traffic for optimum performance, optimum utilization of network trunks and optimum operations costs. In theory, virtually any network router or switch can be made OpenFlow compatible, and software switches and routers (virtual switches like Open vSwitch) can be controlled as well as hardware devices. The combination of software controllers and open virtual switching lets both network operators and enterprises build networks without any traditional network hardware at all, if desired. Therefore OpenFlow can create virtually any NaaS service model, but it requires considerable software to centralize network addressing, topology discovery and traffic management
- The non-centrally-controlled software-defined networking model looks to achieve the benefits of OpenFlow SDN without the need for a massive central control function to direct all connections and traffic. The Internet Engineering Task Force (IETF) is considering a number of changes to existing protocols like Border Gateway Protocol (BGP) and new standards like Infrastructure-to-Application Information Exposure (i2aex) for central management of network data that would allow current IP networks to offer SDN-compatible features without relying on controlling individual forwarding tables in every switch. Cisco has been a strong advocate of this approach, which emphasizes the APIs used for software control rather than changes in network technology. Because the third SDN model builds on current network protocols and practices, its appeal is that it can converge current network devices into future SDN networks.
Virtual convergence benefits from all software-defined network models
The fact that there are three distinct SDN models shouldn't discourage advocates of virtualization-based convergence. All three models offer improved Network as a Service capabilities, even though they differ in whether they focus on segmenting connectivity for the isolation of tenants and applications, or managing network traffic. Best of all, there appears to be a movement in the market to create a unified SDN model that includes all three.
If the cloud, with its dynamic applications and dynamic converged resources, is above Network as a Service, and physical network equipment, with its long useful life, is at the bottom, it's easy to imagine that building highly flexible, software-based virtual network overlays on top of a traffic-focused infrastructure SDN would be a good approach. Network vendors including Alcatel-Lucent, Brocade, Cisco and Juniper all offer a form of this, and even independent software networking vendors like Netsocket have announced software-overlay technology that can be used to control a lower layer of traffic-based SDN services.
Two layers of software-defined networking -- meaning a separation between an "upper" virtual software overlay and a lower-level "infrastructure" SDN that is bound to network hardware -- may be the perfect path to convergence and the cloud. An agile centralized SDN layer can quickly adapt to services and applications above, and the transport services of the lower SDN layer will likely be bound to the infrastructure and more distributed in order to connect resources, connect users and optimize utilization and operations. By virtualizing everything through flexible connectivity in a proven layered model, virtual convergence is created in the best possible way.