One of the more interesting infrastructure themes currently getting attention and investment is Software Defined Networks. The ambition is for there to be a simple network control plane, with clearly defined APIs, enabling changes in network operations depending on the priorities of the applications currently using the network.

The post collects my notes.

Updated 3 May 2012 to add summary from Google keynote at the Open Networking Summit in April.

IBM white paper (May 2011) describes IBM and NEC Openflow demo at Interop 2011.
"The OpenFlow Protocol allows entries in the Flow Table to be defined by a server external to the switch, which creates the potential to unify server and network device management. For example, a flow could be a TCP connection, all the packets from a particular MAC or IP address, or all packets with the same VLAN tag. Each flow table entry has a specific action associated with a particular flow, such as forwarding the flow to a given switch port (at line rate), encapsulating and forwarding the flow to a controller for processing, or dropping a flow’s packets (for example, to help prevent denial of service attacks)."

Nanog 54 - the most interesting panel at San Diego (6 Feb 2012) discussed Openflow, standards work in progress, and one approach to implementing SDN.

Quoting Ed Crabbe (Google) on why Google is interested in SDN - it sees an opportunity to improve cost control for their infrastructure while maintaining performance.

common threads: partition resources and control within network elements

minimize network element local control plane
offline control of forwarding state
offline control of network element resource allocation
minimize complexity of software local to network elements

SDN has been around as a concept for a long time. Ipsilon GSMP, 1996; Cambridge's The Tempest, 1998 and so on down the years. Flowspec in 2008 looks like openflow, too.

IETF PCE, 2004, based on having RSVP-TE deployed, ISIS, etc. From network element software side, it's more complex, but it's deployable today.

But why SDN?
comes down to cost. Most of what we do is cost optimization with bounds for performance

CAPEX:
make efficient use of resources
network element CPU and memories
underlying network capacity
move heaviest workloads off expensive, relatively slow embedded hardware to fast, cheap, commodity hardware

OPEX:
reduce network complexity and thus operational overhead and outage time
simplify policy composition
enforce correctness constraints and invariants
reduce inter-dependencies between routers, between protocols

reduce complexity of distributed control system software on network elements

implement innovative new techniques (Heller's Elastic Trees, etc.)

Innovation velocity - desirable to speed feature implementation and deployment
Do new protocol development fast; right now, takes too long to get new protocols into devices.

IBM distributed virtual switch
IBM announced a distributed virtual switch (5000V) 14 Feb 2012 supporting SPAN, ERSPAN, Ethernet Virtual bridge, load balancing, ACLS, etc, integrated into VMware. Alex Bennet (Battery Ventures) "This is an important development because as the first tier of network switching moves into the server, the virtual switch becomes extremely strategic real-estate and control point for emerging SDN architectures."

Summary and notes from Urs Hoelzle's keynote at ONS, titled 'Openflow @ Google'

"OpenFlow has helped us improve backbone performance and reduce backbone complexity and cost"

For the WAN, aim is to have cost per bit/second go down with scale, as for CPU and storage; without a lot of systems engineering, that's not what actually happens, since network complexity goes up; also, a 100G bps interface costs a lot more than 10 x 10 gbs interfaces, or 100 x 1G bps.

Google are operating the WAN backbone carrying traffic between data centers with centralized traffic engineering.
Multiple switch chassis in each domain, custom hardware running Linux; Quagga BGP stack, ISIS/IBGP for internal connectivity

They have a simulation environment for testing "with the complete system, end to end. Everything is real except the hardware".

Building a software defined WAN results in higher performance, better fault tolerance, and lower costs.
Conclusion : Openflow and SDN are ready for real world use.

References
IBM Openflow white paper http://public.dhe.ibm.com/common/ssi/ecm/en/qcw03010usen/QCW03010USEN.PDF
Brocade presentation on Openflow from Nanog 54 http://www.nanog.org/meetings/nanog54/presentations/Monday/Beckmann.pdf
Matt Petach's notes (source for Ed Crabbe quotation) http://kestrel3.netflight.com/2012.02.06-nanog54-morning-session.txt
Open Networking Foundation https://www.opennetworking.org/
IBM virtual switch announcement http://www-01.ibm.com/common/ssi/cgi-bin/ssialias?infotype=AN&subtype=CA...
Battery Ventures http://thewholestack.com/2012/02/23/forget-startups-ibm-may-take-home-th...
Commentary from Omar Baldinado, now at BigSwitch http://www.bigswitch.com/blognews/openflow-mythbusting-by-google
Summary from Nick Lippis http://lippisreport.com/2012/04/lippis-report-191-what-i-learned-at-the-...

Cunning Systems evaluates product and service ideas in computing and communications. If you would like to discuss an idea, contact us at info@cunningsystems.com