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