Publications

WhiteVisor: Support of White-Box Switch in SDN-Based Network Hypervisor

2019 International Conference on Information Networking (ICOIN), Kuala Lumpur, Malaysia, 2019, pp. 242-247, doi: 10.1109/ICOIN.2019.8718167.

Bong-yeol Yu, Gyeongsik Yang, Heesang Jin, Chuck Yoo

Download PDF

Abstract

Network virtualization is a fundamental technology for datacenters and upcoming wireless communications (e.g., 5G). It takes advantage of software-defined networking (SDN) that provides efficient network management by converting networking fabrics into SDN-capable devices. Moreover, white-box switches, which provide flexible and fast packet processing, are broadly deployed in commercial datacenters. A white-box switch requires a specific and restricted packet processing pipeline; however, to date, there has been no SDN-based network hypervisor that can support the pipeline of white-box switches. Therefore, in this paper, we propose WhiteVisor: a network hypervisor which can support the physical network composed of white-box switches. WhiteVisor converts a flow rule from the virtual network into a packet processing pipeline compatible with the white-box switch. We implement the prototype herein and show its feasibility and effectiveness with pipeline conversion and overhead.

Paper summary

Translate virtual rules into a white-box pipeline

A tenant’s simple forwarding rule can require several hardware-specific tables underneath.

White-box switches expose restricted forwarding pipelines. WhiteVisor lets a virtual-network controller use its virtual pipeline while translating that pipeline into rules supported by the physical switch.

Convert virtual rules into the supported table sequence

A pipeline handler translates the virtual forwarding request into the physical switch’s required flow and group tables. A per-tenant rule store keeps the relationship between the original and generated rules for later operations. The prototype targets OF-DPA 3.0.5 and supports L3 and VLAN routing from a single-table virtual pipeline. For L3 traffic, header matching, rewriting and output are distributed across the physical tables to match the hardware pipeline.

Pipeline installation delay for the two supported routing schemes.
RoutingOF-DPAOVS
L34.69 ms0.28 ms
VLAN1.58 ms0.25 ms

Separate pipeline setup cost from packet forwarding

Tests on three white-box switches confirm that the generated L3 and VLAN pipelines deliver traffic between VMs. The measured pipeline-processing delay is 4.69 ms for L3 routing and 1.58 ms for VLAN routing, compared with 0.28 and 0.25 ms for OVS. The delay is incurred when the pipeline is installed. The implementation demonstrates these two OF-DPA schemes; support for other physical pipelines and multi-table virtual switches is left for later work.

Pipeline processing delay for OVS and OF-DPA, for L3 and VLAN routing.View full-size figure
Pipeline installation delay for L3 and VLAN routing. OF-DPA takes longer than OVS in both cases.

Key takeaways

  1. Virtual programmability must fit a concrete hardware pipeline. WhiteVisor bridges the tenant’s rule abstraction and OF-DPA’s required table sequence.
  2. Translation carries a setup cost. The measured installation delay explains part of that abstraction’s cost without implying an extra delay on every forwarded packet.