OpenFlow Introduction and Status

(1)

OpenFlow Introduction and Status

(2)

Revision 1.0

What we will cover today

• The OpenFlow Architecture

– Why it took the networking world by storm

• OpenFlow 1.3

– The Value of Multiple Flow Tables

– Additional Enhancements

• The Unforeseen Challenges

– Introducing Table Type Patterns

• The Future of OpenFlow

(3)

(4)

Revision 1.0

• Network devices process traffic

• But control should be decoupled

– Through the use of Open Standards – In this case, the protocol is OpenFlow

• And 3

rd

_{party apps should be possible}

– Again, making use of open interfaces

– APIs often called “northbound interfaces”

(5)

• The OF1.0 architecture is based

on a simple functional element:

– The Match-Action Table

• This “MAT” primitive has key

advantages:

– It is flexible and powerful

– Maps directly to common real

world devices

– Lends itself to robust analysis

(6)

Revision 1.0

The Winning OpenFlow Approach

6

• Openness and low level (unambiguous) functionality

• And more than that!

– Balance between abstract and useful – Balance between simplicity and power

– Balance between fixed-function devices (e.g. ASICs) and flexible devices (NPUs) • While also advocating more flexibility

• OpenFlow 1.0 exemplified the balance, and quickly became popular

(7)

But OpenFlow 1.0 has some limitations…

• The Match – Action Table is gloriously simple yet powerful

– Ability to richly combine match fields as well as action fields – Many compelling use cases can be easily supported

• But some interesting use cases are hard to support using OF1.0

– E.g. multipathing and multicasting

• Also, we often want networking devices to do more than one thing

– If all functions are based on the same match, just add more actions to the entry – But if the matches differ, we need a LOT more flow entries (and messages)

(8)

Revision 1.0

Cases where a single flow table isn’t enough

8

• With a single flow table, a variety of simple use cases can be supported at scale – But only one at a time! For example:

• L2 learning or L2 forwarding

– But not L2 learning (Source MAC) PLUS L2 forwarding (Dest MAC) • IPv4 multicast

– But not IPv4 multicast with Reverse Path Forwarding Checks – Sometimes a single table can combine functions

• But it means combining matches, which multiplies the # of entries

• E.g. combine 1000 Dest MAC entries with 1000 Source MAC entries… – And you get 1M Dest-Source combo entries!

• The cost: huge tables and lots of messaging overhead

(9)

OpenFlow 1.3: Enhanced Architecture

(10)

Revision 1.0

Architectural enhancement: New Tables

OpenFlow 1.1 (Feb 2011) expanded the table architecture in two key ways - Up to 255 Flow Tables (with “Goto Table N”) enabled independent functions - Group Table simplified multicasting, multipathing and more

Always start at Table 0

When a match occurs, the actions are applied. New action: “Go to Table N”

(11)

Adding flow tables simplifies many use cases

• Multiple Flow Tables allows for supporting many functions (can be more than 2)

– Separating tables by function avoids the “explosion” of flow entries

• Many real world network architectures need multiple independent functions

– MAC (source) learning plus MAC (dest) forwarding

– Port-based VLAN tagging, plus MAC switching, plus IP routing – Statistics gathering plus MPLS tag switching

(12)

Revision 1.0

Other features were added along the way…

12

• OF1.1 also added a group table

– The group entries make multicast and multipathing much easier

• OF1.2 added some new match and action fields

(13)

Enhancements that came in OpenFlow 1.3

• OF1.3 also adds these enhancements over OF1.1 and 1.2

– Better support for redundant controllers

– A Meter Table for rich support for flow metering – New match and action capabilities

• The combination of enhancements prompted the ONF to select OpenFlow 1.3 as a

“stable version” that hardware equipment vendors can target for support.

– See: https://www.opennetworking.org/images/stories/downloads/working-groups/charter-extensibility.pdf

(14)

Revision 1.0

The Unforeseen Challenges

Introducing Table Type Patterns

(15)

The (largely) Unforeseen Challenges

• OF1.3 grew in several dimensions

– Tables, matches, actions, etc

– That is: flexibility, applicability

• Conformance testing got hard

– Support for multiple tables widely

variable, non-interoperable

– Require optional functions or not?

• The OpenFlow balance tilted toward

(less deployed) flexible devices

Many new match / action fields available, and many are optional in the spec More

flow

Other stuff too: groups and meters

(16)

Revision 1.0

New points of tension

16

• Flexibility and Interoperability appear to conflict

– But we need both

• Innovators want flexibility and programmability

• Operators want determinism in production networks

– Determinism means constraints (rules)

• Buyers want both:

– Interoperability to guarantee choice

– “Reconfigurability” to avoid obsolescence

• We needed a way to offer both Flexibility and Interoperability

– And we found one

(17)

OpenFlow Rebalanced

• After OF1.1, some ONF members* foresaw challenges

– They chartered the Forwarding Abstractions WG (FAWG)

• I have the honor of serving as FAWG chair

• FAWG chose Table Type Patterns (TTPs) as the (optional)

framework enhancement to address the challenges.

– The ONF published the TTP spec in June 2014.

• TTPs list only the OpenFlow features planned for a use case

– TTPs are flexible enough to address any specific use case

(18)

Revision 1.0

TTP Practicality  Adoptable

• These colored structures symbolize TTPs ability to spell out specific

needed features as needed for different use cases.

(19)

More about Table Type Patterns (TTPs)

• TTPs are an optional OpenFlow enhancement

• TTPs constrain the flexibility of OpenFlow on case-by-case basis

– The OpenFlow language is still flexible

– But device behavior can now be pinned down using a TTP

• Easier for device to support pre-described behavior

• Interoperability is very attainable with pre-described behavior

• Useful for SDN coders to see what devices are supporting

• TTPs helpful for conformance: good for buyers (and vendors)

(20)

Revision 1.0

The New Balance is Endorsed

20

• Broadcom is first vendor publicly investing in a TTP for their

OpenFlow Data Plane Abstraction

– https://github.com/Broadcom-Switch/of-dpa/blob/master/doc/OFDPA_OASS-ETP101-R.PDF

• Within the ONF, the Test and Interoperability Working

Group, (TIWG) and the Chipmakers’ Advisory Board see

TTPs as useful for representing conformance test levels

• OpenDaylight (ODL), an open source SDN controller, can

now dynamically import and check TTP files, and offer APIs

– Using ODL’s model-driven “Services Abstraction Layer”

(21)

The Future of OpenFlow

(22)

Revision 1.0

The Nearer Future of OpenFlow

22

• Convergence in the OpenFlow/SDN controller space simplifies SDN app development

• ONF-led efforts toward sharing dozens of OpenFlow Solutions is highlighting the

growing maturity of OpenFlow and the larger SDN ecosystem

• New consensus among several ONF groups will help OF1.3 conformance tests

• The advent of TTPs enables the definition of common device behaviors, which:

– Provides a foundation for SDN coding

(23)

The Farther Future of OpenFlow

The ONF has also started investigating ways to create an even richer SDN framework that will fully leverage the power of “next gen” flexible forwarding devices

• Building on ideas from the TTP Framework, the ONF has identified “Protocol

Independent Forwarding” as a compelling approach

– See https://www.opennetworking.org/protocol-independent-forwarding

• The concept is too fluid to begin specification efforts. The ONF is working on a plan to

engage the community of researchers and coders to contribute and mature the ideas – To participate, contact ONF at [email protected]

(24)

Questions and Answers

(25)