This book aims to provide insight into the OpenFlow protocol and it's fundamentals by walking step by step through the technology.

Once OpenFlow is described, I move to consider Software Defined Networking (SDN) in terms of controllers and their applications. As a Network Engineer who configures networks everyday, this is the book that I would want to read so I could learn a bit about how and why OpenFlow/SDN works, and what impact it will have on the marketplace, vendors and the next generation product cycle.

It's early in the technology cycle for OpenFlow/Software Defined Networking and there are few products or even companies that are implementing these technologies. Even so, the impact on the networking market and vendor product has been significant in terms of future products and strategy.

This book looks at the fundamentals of OpenFlow without any particular product or technology approach in mind. This is vendor neutral look at the good and bad of OpenFlow networking. We discuss hardware limitations, the impact of silicon designs and what to consider when evaluating OpenFlow.

This book assumes that you have some level of Network experience and knowledge such as TCP/IP, Ethernet, and broad networking concepts and some familiarity to the day to day operation of networks.

Why OpenFlow is Important - A Brief History

It’s likely that many people have not heard about OpenFlow and Software Defined Networking and that’s not surprising. It seems to have arrived with a bang from nowhere and many people are clamouring with indiscreet enthusiasm for a technology.

Why are we talking about OpenFlow at all ?

The Data Networking industry has been mostly static since the early 2000’s when major technologies like OSPF and BGP in routing, MPLS for tag switching and cross-bar fabrics for Ethernet switches were all in their early stages. The last decade has seen these technologies matures and move to common usage but *not much else*. Performance using 1 Gigabit Ethernet was acceptable but not much consumer demand for 10 Gigabit.

Most people agree that Networking is responding to three infrastructure changes:

1. Server Virtualization
2. Operational Reliability
3. End Point Mobility.
4. Scaling

Server Virtualisation means that a single virtualisation server (such as VMware ESXi) can have many “guest” servers installed. While ten virtual servers per host is typical today, the density is rapidly increasing . This led to two upgraded (not new) requirements: Speed and Reliability. Firstly, ten servers per physical cable required more speed and greater bandwidth (which are not the same) and drove the demand for 10 Gigabit Ethernet.

The second requirement is reliability. Data Centres have relied on Spanning Tree and Routing for path control for Ethernet Frames and IP Packets respectively but their reliability is relatively poor. Spanning Tree can take five to fifteen seconds to converge after a failure. And routing protocols like OSPF can take as little as five seconds up to thirty seconds in traditional installations to converge around a topology change. If a path change for a single server can impact twenty or more guests, the scale of that impact is highly magnified.

Virtualisation allows for End Point mobility. Networking was intended to reasonably static - desktop computers were wired to the wall, servers installed in a fixed locations. Increasingly, end user computing is dynamic - there are more phones / tablets using WiFI and constantly moving around the network. There are more laptops than ever. And even the data centre , home of the “non-movable server”, has now changed since server virtualization arrived. There is lot of demand for change in networking to support mobility and improved reliability.

The final driver is Scalability. In simple terms, there are more computers than ever before. The ‘Cloud’ data centre is enabling enormous increases in server density, Storage is moving to Ethernet and IP networking and Users can easily have three devices such as a tablet, phone and laptop.

Table of Contents (as at 20130818)

• I Part 1 - Introducing OpenFlow & SDN
  • 1 Why OpenFlow Matters in Today’s Networks ?
  • 2 Dedication
  • 3 Technical Reviewers
• II Part 2 - What is OpenFlow ?
  • 4 OpenFlow and Network Devices
  • 5 Some Basics
  • 6 OpenFlow Forwarding
  • 7 Are Routing and Switching protocols good enough ?
  • 8 Management Failures
  • 9 Defining OpenFlow
  • 10 Describing OpenFlow Controllers
  • 11 Understanding Flow Forwarding Instead of Routing or Switching
  • 12 OpenFlow & Software Defined Networking
  • 13 Capital Intensive Hardware Lifecycle
  • 14 APIs: North and Southbound Abstractions
  • 15 Hybrid Mode Networking
  • 16 Overlay Networks with OpenFlow & SDN
  • 17 Standards and Stewardship of OpenFlow Protocols
  • 18 Vendor Support for OpenFlow
• III Part 3 - OpenFlow Technical Details
  • 19 OpenFlow Data Path Identifier (DPID)
  • 20 OpenFlow Packet-In
  • 21 OpenFlow Table-Miss
  • 22 Multiple Controllers
  • 23 OpenFlow Message Handling
  • 24 Pipeline Processing
  • 25 Quality of Service
  • 26 Topology Discovery
  • 27 Spanning Tree and L2 Convergence
  • 28 Configuration and Status Monitoring
  • 29 Comparison to NetFlow
  • 30 OpenFlow Features Negotiation
  • 31 Switch Hardware Design
  • 32 Hardware Limits - Silicon, TCAMs and Software
  • 33 Sample Flow Tables and Use Cases
  • 34 Controller Flow Handling Strategies
  • 35 Forwarding with L3 Proxy
  • 36 Mapping Flow Paths
  • 37 Controller Distribution and Placement
  • 38 The Known Problems of OpenFlow
  • 39 OpenFlow Changes over Time
  • 40 Device Performance for OpenFlow
  • 41 OF Instructions
  • 42 Network Virtualisation
  • 43 Hardware Purchasing Considerations
  • 44 Securing OpenFlow
  • 45 #OpenFlow Message Packet Captures
  • 46 In Closing