B4: Experience with a Globally-Deployed Software Defined WAN

Google solutions: building a WAN connecting multiple data centers and face with these following overheads:
- WAN links are very expensive and WAN routers consist of high-end, specialized equipments that place much value on high availability.
- WAN treat all bits the same => all applications are equally treated regardless whether or not they deserve.

Why uses SDN and OpenFlow for B4 to provide connectivity among datacenter?

• Unique characteristics of data center WAN
• Centralized control to application, servers and LANs
• Elastic bandwidth demand by applications
• Moderate number of data centers (large forwarding tables are not required)
• 30-40% utilization of WAN link entails unsustainable cost
• Could not achieve the level of scale, fault tolerance, cost efficiency and control required for their network using traditional WAN architectures
• Desire to simpler deploy novel routing, scheduling, monitoring and management functionality and protocols
• Others (out of scope): rapid iteration on novel protocols, simplified testing environments, improved capacity planning available from a deterministic central TE server rather than capturing the synchronous routing behavior of distributed protocols, simplified management through a fabric-centric rather than router-centric WAN view

B4 Architecture

Composes of 3 layers: 

• Global layer: logically centralized applications, enable the central control of the entire network
• Site controller: network control applications (NCA) and Openflow controllers (maintain network state based on NCA directives and switch events)
• Switch hardware: B4 switches peer with traditional BGP routers => SDN-based B4 had to support interoperability with non-SDN WAN implementation.
• Deploy routing protocols and traffic engineering as independent services

How to integrate existing routing protocols running on separate control servers with OpenFlow-enabled hardware switches?

Switch Design

Properties:

• Be able to adjust transmission rates to avoid the need for deep buffers while avoiding expensive packet drops
• Don't need large forwarding tables because used by a relatively small set of data centers
• Switch failures usually caused by software rather than hardware issues => move software functionality off the switch hardware, we can manage software fault tolerance

Develop an OpenFlow Agent:

• Running as a user-level process on switch hardware
• Connect to OpenFlow controller hosted by NCS

Network Control Functionality

Routing

To integrate existing routing protocols with Openflow-based switch, they implemented a Routing Application Proxy (RAP) to provide connectivity between Quagga and OF Switch:

• BGP/ISIS route updates
• routing-protocol packet flowing between OF switches and Quagga
• interface update from switches to Quagga

Quagga acts as control plane, perform BGP/ISIS on NCS (only control plane, there's no data plane)

RAP bridges Quagga and OF switch. RAP caches Quagga RIB and translates into NIB entries for use by Onix (platform for OF Switch?)

Traffic Engineering

Centralized TE architecture is composed of:

• Network topology representing sites as vertices and site to site connectivity as edges.
• Flow Group is defined as (source site, des site, QoS) tuple
• Tunnel represents a site-level path, implemented as IP encapsulation
• Tunnel Group maps FGs to a set of tunnels and weights

Bandwidth functions, TE Optimization Algorithm
Specifying the bandwidth allocation to an application given the flow's relative priority or an arbitrary, dimensionless scale, called fair share

TE Protocol and OpenFlow

3 roles for a switch and each of which is involved to a corresponding OF message.

• an encapsulating switch initiates tunnels and splits tra›c between them
•  a transit switch forwards packets based on the outer header
• a decapsulating switch terminates tunnels and then forwards packets using regular routes

Short papers

Towards SmartFlow: Case Studies on Enhanced Programmable Forwarding in OpenFlow Switches

Problems
The limited capabilities of the switches renders the implementation of unorthodox routing and forwarding mechanisms as a hard task in OpenFlow => the goal is to inspect the possibilities of slightly smartening up the OpenFlow switches.

Case studies
Add new features (matching mechanism, extra action) to flow tables

• Using Bloom filter for stateless multicast 
• Greedy routing => performed at switch rather than at controller
• Network coding

An Openflow-Based Engergy-Efficient Data Center Approach

Problem
IaaS providers suffer from the inherent heterogeneity of systems and applications from different customers => different load + traffic patterns has to be handled

Solutions

1. Overprovision to sustain a constant service quality => only applied with huge budget and a lot of resources
2. Smart resource management => ECDC = machine information + network devices + environment data

Plug-n-Serve: Load-Balancing Web Traffic using OpenFlow

Problems

In data center or a dedicated web-hosting service, the HTTP servers are connected by a regular, over-provisioned network; the load-balancer usually does not consider the network state when load-balancing across servers => this way is not true for unstructured network (enterprise, campus) => traffic affects to performance of load-balancing and increase the response time of HTTP request

Solutions - Plug-n-Serve
Load-balances over arbitrary unstructured networks and minimize the average response time by considering the congestion of network and the load on the network + server.

• It determines the current state of the network and the servers, including the network topology, network congestion, and load on the servers.
• It choose the appropriate server to direct requests to, and controls the path taken by packets in the network, so as to minimize the response time

OpenFlow-Based Server Load Balancing Gone Wild

Problem

The switch in SDN network is used for load balancing and overloaded by a huge number of forwarding rules if each rule is installed for each connection.

Plug-n-Serve approach intercepts first packet of each connection and use network topology + load to determine the target replica before forwarding the traffic => many rules (as said above), delay (since involving the controller for each connection). This approach is called "reactive"

Solutions

Use wildcard rule to direct requests for larger groups of clients instead of each client/connection.

• Based on the share of requests among replicas (called weight), the author  proposed an partition algorithm to divide client traffic efficiently.
• Building a IP-prefix tree with the height is log of sum of replica weight
• Assign leaf nodes to replicas based on the proportion of its weight.
• Reduce the number of rules by using a wildcard form (for example: we can use 01* instead of two leaf nodes 010* and 011* to create a corresponding rule for a replica)
• How to handle when we need to move a traffic from a replica to another => note: exisitng connection should complete at original replica => two ways:
• Controller inspects the incoming packet, if it is a non-SYN packet, then it will keep being sent to old replica. If not, the controller will install a rule to forward the packet (and the ones belong to same connection) to new replica
• Controller installs high-priority rules to switch to forward traffic to old replica, and low-priority ones to forward to new replica. After soft deadline with no any traffic, that high-priority rule at switch is deleted.

The author also consider the non-uniform traffic as well as the case in which network is composed of multiple switches rather than two (one for gateway receiving client traffic and the other for load balancing)

SDN-based Application-Aware Networking on the Example of YouTube Video
Streaming

Problem
Northbound API enables the application information exchange between applications and network plan => determine how different kinds of information (such as per-flow parameter, app's signature, app quality parameter) can support a more effective network management in an SDN-enabled network

Solution
Conduct 6 experiments: pure, with interfering traffic, round-robin path selection (controller has no external, information, just automatically change switch ports sequentially for incoming packets), DPI experiments (network information) and Application-aware path selection (application state).