UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

A fast introduction to SDN from Stanford Professor Nick McKeown

by Xilinx Employee ‎02-25-2014 03:04 PM - edited ‎02-26-2014 12:36 PM (28,343 Views)

Professor Nick McKeown is the Kleiner Perkins, Mayfield, Sequoia Professor of Computer Science and Electrical Engineering at Stanford University and Faculty Director of Stanford’s Open Networking Research Center, where SDN and OpenFlow were developed and where the motto is “Software Defined Networking is the future. We are inventing it.” From 1986-1989, Dr. McKeown worked for Hewlett-Packard Labs in Bristol, England. In 1995, he helped architect Cisco's GSR 12000 router. In 1997 he co-founded Abrizio Inc. (later acquired by PMC-Sierra), where he was CTO. He was co-founder and CEO of Nemo (“Network Memory”), which is now part of Cisco. In 2007 he co-founded Nicira (acquired by VMware) with Martin Casado and Scott Shenker. In 2011, he co-founded the Open Networking Foundation (ONF) with Scott Shenker.

 

To say that Professor McKeown has been working in networking for a while is a gross understatement.

 

Emerging Technology Symposium.jpgEarlier this month, Professor McKeown gave a presentation on SDN (Software Defined Networking) at the 2-day Xilinx Emerging Technology Symposium held in the Fairmont Hotel in downtown San Jose. Here are my notes from his SDN presentation.

 

 

SDN and Streamlining the Plumbing

Professor Nick McKeown, Stanford

 

What is SDN?

 

SDN is a network in which the control plane is separate from the forwarding plane and a single control plane controls several forwarding devices.

 

 

Why is this a big deal?

 

Telcos have used a similar sort of architecture for many generations. However, it’s a big change to the networking industry’s current business model.

 

You need an abstract forwarding model like OpenFlow to make SDN work. The control plane builds a map of the network. The network programmer builds a control program on top of the network map to control the network’s state.

 

 

Why now?

 

The planets are aligning:

 

  • Availability of good merchant switch chips (Broadcom, Marvell, Intel). No need for ASIC teams
  • Big data centers create a greenfield environment for SDN along with teams of knowledgeable network programmers
  • There’s frustration with the stranglehold of larger network equipment vendors—no more status quo

 

 

Why does the industry care?

 

  1. Lower cost/simpler switches. Software can be limited to what’s needed. Users (network and data-center operators, network programmers) need and want this.
  2. Lower maintenance costs. Users don’t want to pay to support complexity they don’t use.
  3. More control. Puts network operators in control of their own networks.

 

A well-defined control abstraction

 

SDN control programs can run on modern servers. Network programmers can use software engineering practices to build better network-control and -management software. It’s easier to add new control programs. It’s possible to solve problems just once no matter the underlying hardware.

 

 

A well-defined forwarding abstraction

 

What do you want the hardware to do? SDN provides vendor-agnostic control of the forwarding plane. Match + action forwarding abstraction. Typically multiple match stages—can be pipelined (except for stateful devices)

 

The programmer wants to decide how packets will be processed. Which headers to modify. Which to recognize/add/remove. What the action sequence should be and what should be the dependencies. Build actions from primitives.

 

Today’s fixed-function switches are at odds with this desired model.

 

Current switch chips also limit you. For example, they have a fixed memory size so you can’t add new tables or types of tables, header fields, actions, etc.

 

This situation forces you to build networking systems in strange ways. You look at the switch chip’s API and you try to build a desired action sequence that fits into the existing API. You’d rather design such a system starting with your requirements, not the APIs.

 

An FPGA allows you more flexibility. You can program the hardware to do what you want to do. This permits top-down design. You can start with what you want, then design, compile, and configure.

 

 

What will SDN chips look like?

 

They will look like FPGAs or something you can build from FPGAs. Network processing is embarrassingly parallel, so you can exploit VLIW-like actions.

 

The SDN compiler will convert target-independent specifications into target-dependent configurations.

 

 

The SDN train is leaving the station

 

What’s wanted is a verifiable forwarding behavior. Networks will get more reliable when configuration becomes more automated—when there are automated tools to create configurations from specs (think EDA).

 

  • Forwarding tables will capture the entire forwarding behavior
  • The control plane will write the forwarding rules
  • Therefore, networking behavior is verifiable (formal verification + static checks)

 

The networking industry currently has no tool automation. Currently, “Masters of Complexity” keep the network running. There are a handful of books on writing networking programs and no classes. Even simple questions are hard to answer.

 

 

Conclusions

 

  • There will be answers in an SDN world.
  • SDN is a business consequence of today’s networking industry.
  • Network intelligence will have to move into software.
  • The hardware will be commoditized and needs to be field-reconfigurable.
  • SDN Networks will be verifiable.

Labels
About the Author
  • Be sure to join the Xilinx LinkedIn group to get an update for every new Xcell Daily post! ******************** Steve Leibson is the Director of Strategic Marketing and Business Planning at Xilinx. He started as a system design engineer at HP in the early days of desktop computing, then switched to EDA at Cadnetix, and subsequently became a technical editor for EDN Magazine. He's served as Editor in Chief of EDN Magazine, Embedded Developers Journal, and Microprocessor Report. He has extensive experience in computing, microprocessors, microcontrollers, embedded systems design, design IP, EDA, and programmable logic.