Buyers are already sold on Infrastructure-as-a-Service, Platform-as-a-Service and Software-as-a-Service, but what...
about Network-as-a-Service? Despite the fact that the cloud is created in and connected through the network, we hear little or nothing about a new network paradigm for the cloud. Network-as-a-service is not only real, but it is likely to become universal. However, it may take software-defined networking (SDN) in the form of OpenFlow to make that happen.
Cloud computing deploys a public pool of resources that can be provisioned on demand. They also must provide connections to its users, storage access, inter-process communications, and resource allocation or management.
Typical IP and Ethernet network technologies have shortfalls when it comes to the cloud, due to security, QoS, and operational cost scalability. At the heart of those limitations is the notion of “permissive connectivity.” IP and Ethernet presume that all endpoints can be addressed by others. This presumption of universal connectivity makes it harder to manage security and engineer traffic flows to meet specific application SLAs.
One proposed solution is to centralize a connection policy using SDN. In SDNs, the endpoints have no implicit right to connect, so nothing on the network is connected at first. Instead, a software control function decides what connections to permit, and which route traffic will take for those connections. This bundles connectivity, security and traffic engineering into a single master-control location, where policies dictate how resources are used and who’s allowed to connect with what.
More on cloud networking
Cloud computing networks primer
A networking guide to private cloud orchestration
Private cloud computing over the WAN
This centralized network resource management is virtually identical with the resource management strategy behind IaaS, PaaS, and SaaS cloud services. Therefore, it’s not surprising that SDN-based networking will be the foundation for Network-as-a-Service.
The role of OpenFlow as a SDN architecture
Many major switch/router vendors have expressed support for OpenFlow, an architecture that is an implementation of SDN.
OpenFlow is a combination of a specification and open-source software that runs in a switch or router as part of the central controller. In an OpenFlow network, when a switch or router gets a packet, rather than making the forwarding decision itself, it sends the packet to the controller, which then uses policies to make the decision. Those policies then create a forwarding rule, which the controller passes back to the requesting device.
For Network-as-a-Service, OpenFlow has benefits and challenges
The description alone of how OpenFlow works illustrates both its strengths and limitations. Because OpenFlow connections are explicit, Network-as-a-Service is more secure and potentially has more QoS. This is because policies that set routes for packets can use application and even user priority to determine how traffic is allocated to resources, thus setting performance levels. In theory, an OpenFlow network could be safe from denial of service attacks, and would be more difficult to hack. In addition, they would support video and critical applications better.
The challenge with OpenFlow is scalability. An OpenFlow network could not work if every packet had to be sent to a central controller to be analyzed. To make Network-as-a-Service work, OpenFlow scalability must be improved or its use must be contained within cloud networking. Both options are already being proposed.
OpenFlow will work best where traffic is made up of a modest number of predictable flows. That way, once the switches/routers learn the traffic rules from the controller, little additional interaction with the controller is needed. When used within a data center to control server-to-server or server-to-storage traffic, OpenFlow is a very important contribution. Even within data centers in a distributed cloud (public, private, or hybrid), OpenFlow could be expected to manage traffic within the cloud. The question is whether it can manage traffic between the cloud and cloud users, and if not, how OpenFlow SDNs and Network-as-a-Service will be linked to the users.
Merging OpenFlow with IP networking may be the answer
If a large base of users/workers is visibly beyond the scope of a explicitly-managed connection, what’s needed is a way of somehow merging OpenFlow with traditional IP networking at the edge of the cloud. Luckily, there are proposals already in play to interwork OpenFlow and MPLS to generate a new kind of IP network that offers a combination of open connectivity and policy-managed connectivity.
More on OpenFlow and software-defined networks
Software-defined networking eases cloud management for providers
OpenFlow controllers could change networking forever … or not
OpenFlow specification emerges: Rise of the software-defined network
There are also potential ways of making OpenFlow control more hierarchical and scalable. Also, there are initiatives in cloud computing, where the concept of Network-as-a-Service first arose, to manage how we address cloud applications. These initiatives convert applications into “virtual services” of the cloud. It’s too early to say if these will create a scalable OpenFlow model, but if they do, they’ll advance Network-as-a-Service by improving how cloud resources are accessed. In the future, all of these developments could create a Network-as-a-Service that escapes the boundaries of the cloud, and moves all the way to the network edge.
Yet, within the cloud, there’s no need to wait. OpenFlow Network-as-a-Service would offer enterprises much more control over data center and inter-data center cloud traffic than would be available today with Ethernet or IP. There is tremendous potential for lowering operational costs by eliminating expensive IP and Ethernet discovery and adaptive topology updating. The time of the Network-as-a-Service may not be now for everyone, but all the indications point to the idea that it’s coming to data centers soon.
About the author: Tom Nolle is president of CIMI Corporation, a strategic consulting firm specializing in telecommunications and data communications since 1982. He is a member of the IEEE, ACM, Telemanagement Forum, and the IPsphere Forum, and the publisher of Netwatcher, a journal in advanced telecommunications strategy issues. Tom is actively involved in LAN, MAN and WAN issues for both enterprises and service providers and also provides technical consultation to equipment vendors on standards, markets and emerging technologies. Check out his SearchTelecom networking blog Uncommon Wisdom.