In the future, Internet Service Providers (ISP) may offer on-demand, flexible virtual networks connecting different locations and heterogeneous cloud resources with Quality of Service (QoS) connectivity guarantees (such as maximal latency or minimal bandwidth).
The virtualization paradigm is arguably the main motor for networking innovation in the future. Virtualization decouples services from the underlying infrastructure and allows for resource sharing while ensuring performance guarantees. Server virtualization (also known as node virtualization) has already been a huge success and is widely used, for example, in the clouds.
However, cloud virtualization alone is often meaningless without taking into account the network needed to access the cloud resources and data. Thus, to provide deterministic performance guarantees, cloud virtualization needs to be extended to the access and communication network.
"CloudNets" take the virtualization paradigm one step further and offer such a unified approach. A CloudNet describes a virtual network topology where the virtual nodes represent cloud resources (eg storage or computation) which are connected by virtual links.
Figure 1: CloudNet infrasctrucure and embedding
We envision that in the near future, flexibly specified CloudNets (eg used for multi-media conferencing, gaming, social networking, or bulk data transfer) can be requested and realized at short notice and for a desired period of time. For example, a CloudNet may specify geographical constraints (eg realization only in clouds at distance less than 100m), topological constraints (eg some virtual links are half-duplex, full-duplex or even describe a shared medium), capacity constraints (eg minimal reserved storage or bandwidth), performance constraints (eg all users in Germany can access an application with a maxumum delay of 50ms), compatibility constraints (eg some nodes must be binary compatible), or constraints on how the resources required by the virtual node may be split among multiple physical nodes (eg to aggregate resources or ensure redundancy).
There are many applications for CloudNets. In a multi-tenant production data centre or cloud context, the isolation and QoS networking properties of CloudNets are attractive to ensure that jobs do not miss hard deadlines due to unpredictable changes in the load; this guarantees application performance and avoids resource inefficiencies that eventually lead to provider revenue losses.
CloudNets can also be used to seamlessly connect geographically separated clouds or nano data centres, aggregating a huge amount of resources. Another interesting use case is flexible out-sourcing or cloud bursting: a corporate infrastructure or an in-house data centre is connected to public clouds, and at times of high demand, certain applications are migrated to the cloud.
In many of these scenarios, it is unlikely that a CloudNet request specifies every detail: for instance, in our out-sourcing scenario, no specific cloud provider may be named explicitly, and a computational CloudNet request or a CloudNet for delay-tolerant bulk data transfers may specify a flexible time window for the realization. This flexibility in the specification can be exploited for optimizations, for instance to choose the cheapest cloud provider, or to choose the realization period where the load on the infrastructure is low or where electricity is cheap.
Within the limitations of the specification, a CloudNet can also be migrated. A CloudNet provider can use migration to co-locate CloudNets in times of low demand, eg to save energy if the remaining network components can be switched off, or to perform maintenance work. Migration can also be used to improve the Quality-of-Experience: for instance, an SAP server, a gaming server or even (parts of) a CDN server can adaptively migrate closer to the location of the users which reduces the latency. In a global application, the CloudNet servers will cycle around the earth, whereas in a more local application, the servers will follow the commuters downtown in the morning and back to the suburbs in the evening; at night, the virtual servers may switch to a different technology or even be shut down completely.
The concept of CloudNets is particularly interesting for ISPs. The possibility to offer new innovative services may increase revenues, and the more efficient usage of the given resources and the simplified network management can reduce the investment costs for new technology and decrease operational costs. Moreover, ISPs have the competitive advantage of knowing not only the network infrastructure in detail but also the current demand. This allows for various optimizations that could not be performed to a comparable extent by CDN providers for example. The explicit knowledge of the customers’ desired specifications (inferrable from the CloudNet requests) can also simplify the network provisioning and allow the ISP to assess the cost and impact of reconfigurations.
At the same time, note that CloudNets may have a large geographic footprint and cannot be instantiated unilaterally by a single ISP, but require cooperation. This can lead to new business roles. For instance, virtual network providers may emerge which interact with several infrastructure providers as resource brokers or resellers. Such a virtual network provider is not necessarily an independent entity, but may just as well constitute a new subunit inside an existing ISP.
Although many algorithmic and economic implications are not yet well-understood, we believe that the virtualization technology (eg VMWare for server virtualization, or VLANs and OpenFlow for link virtualization) is ripe to realize the vision of CloudNets.
Link: http://www.inet.tu-berlin.de/
Please contact:
Anja Feldmann, Gregor Schaffrath, Stefan Schmid
TU Berlin & Telekom Innovation Laboratories (T-Labs), Berlin
E-mail: {anja,grsch,stefan}@net.t-labs.tu-berlin.de
