Today’s networks have diverse user groups with individual requirements. Think about a service provider network, campus or research network – the interest groups using them are all over the map, literally and figuratively.
A service provider, for instance, has various service segments with different requirements. Video streaming requires larger downstream bandwidth and multicast with fast join. At the same time, growing IoT access networks require security and support for low power operational modes. And larger corporate customers require substantial private networks. How do you meet the needs of these diverse groups?
The traditional approach takes two forms. Put everyone on the best-effort internet, and hope that works out. Or, create a complex structure of virtual network and QoS configurations to implement security, reachability and differentiated service characteristics in a single managed network, and everyone comes to a central support group to manage the network and resolve troubles.
There is a better way. It’s called SDN hardware virtualization.
Using Virtual Forwarding Contexts (VFCs) optimized for packet processing and forwarding, a network operator can partition their physical network problem into simpler, more manageable virtual networks that look and feel just like any other network. SDN hardware virtualization allows a network operator to hand over control and responsibility for meeting disparate requirements to the appropriate groups. All of this is possible without duplicating the physical infrastructure.
How SDN hardware virtualization benefits you
The ability to create separate overlay networks for user communities with special requirements and let those communities manage their own network, as they see fit, is a tremendous benefit. But let’s drill down into some of the finer points of SDN hardware virtualization and how it benefits network operators.
- Service Commissioning without Rewiring
Using SDN hardware virtualization in a network enables on-demand network service spin-up by the network administrator while offering direct control of the VFCs to customers via a self-serve portal. From the customer’s point of view, they have access to the virtual switch which performs like it is a dedicated piece of hardware. If the customer moves, changes, wants more, it’s just a call to the REST API and the change is made. There is no need to go to the physical hardware to rewire.
- Traffic Isolation into Zones
For performance or security reasons a network operator can create different network zones, for instance external customer, developer or secure zones, running on the same hardware infrastructure. This allows specially designed zones to exist in a parallel with a standard production network. These zones can be designed to support traffic management, delay control, added security, or other unique characteristics.
- Simple, Modular SDN Controllers
Independent SDN control of VFCs enables each virtual network operator to choose their own control software. Furthermore, hiding the details of underlay tunnel technologies behind uniform logical ports simplifies the virtual network view. This encourages development of simpler control systems for specific use cases, not “god-like” controllers. This in turn simplifies controller development and testing and leads to more robust solutions.
- Separate Overlay and Underlay
While VFC control can be handed over to a customer or separate operations group, the physical hardware and underlay tunnels are under the control of the network owner (e.g., an infrastructure operations group). This provides both stability and flexibility for supporting overlay networks. From an operator’s standpoint, one can dynamically and quickly create any number of virtual network slices for customers or to even offer up on-demand virtual service creation as something customers can do themselves.
- Protocol Agnostic Virtual Instances
Network forwarding behavior generally falls into the category of Layer 2 or Layer 3 forwarding. The flexibility and programmability provided at the underlay and the overlay VFCs significantly removes the protocol silos, and dev-ops barriers, that conventional networking equipment bring with them. Multiplying this flexibility by supporting multiple virtual instances further removes constraints on multi-tenant forwarding by allowing each tenant group to define its own unique combination of L2/L3 behaviors and forwarding policies, with their own unique control plane implementation.
- Efficient Use of Hardware Resources
With the ability to logically attach any part of a physical port to any virtual switching or routing instance, physical speeds and feeds can be filled with any variety of traffic. For instance, a virtual switch can have many logical ports and each of these ports can be defined to have a different L2 service (as opposed to routers where all logical ports on a virtual service instance must use the same underlay technology). This enables service and network technology interworking and migration without changing out the hardware platform.
- Improved Customer Experience
The network owner can manage and maintain the physical infrastructure and underlay network connectivity, offering a simpler network view to each operations group or customer supported by the virtualized hardware. Customers control only what they need to control and are not bothered with details of the underlay implementation. And the network owner can be more responsive to customer demands for capacity increases or decreases by simply adjusting resource allocations to the VFCs.
- Improved Bandwidth Management
VFCs would not truly represent virtualized switching or routing functions without the same QoS management capabilities as a stand-alone physical box. For each tenant – within each VFC –traffic can be measured and dynamically controlled to maintain service level agreements. This involves right-sizing the VFC as well as managing data throughput. Traffic metering and shaping in the virtual overlay and shaping at the VFC’s egress ports (in the underlay) are supported to enable the operator to optimize bandwidth management both in the overlay and underlay contexts.
What service operations group wouldn’t want the ability to provide individual, best-in-class services – ISP, L2VPN, L3VPN, Content Delivery, IoT, etc. – at any point in their network, at any scale, and via instant, programmatic control? And then be able to adjust resource allocation as needed?
To find out more about SDN hardware virtualization, download Corsa’s white paper.