OpenFlow Introduction and Status Curt Beckmann, EMEA CTO for Brocade / October 8, 2014
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 Near and Far
The OpenFlow Architecture 3
OpenFlow is based on a simple architecture 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 4
The OpenFlow 1.0 Architecture 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 5
The Winning OpenFlow Approach 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 In contrast to earlier efforts that never gained traction 6
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) 7
Cases where a single flow table isn t enough 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 The community recognized the need for enhancement 8
OpenFlow 1.3: Enhanced Architecture And the Value of Multiple Flow Tables 9
Architectural enhancement: New Tables Always start at Table 0 When a match occurs, the actions are applied. New action: Go to Table N 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 10
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 IPv4 Routing plus selective mirroring of traffic for analytics 11
Other features were added along the way 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 But for a variety of reasons, the market did not adopt OF1.1 or OF1.2 12
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 OF1.3.x == STABLE 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 In fact, the ONF paused on OF1.4 to help signal the stability of OF1.3 and to allow time for feedback 13
The Unforeseen Challenges Introducing Table Type Patterns Revision 14 1.0
The (largely) Unforeseen Challenges OF1.3 grew in several dimensions Tables, matches, actions, etc That is: flexibility, applicability Other stuff too: groups and meters 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 It s in the nature of the problem More flow tables Many new match / action fields available, and many are optional in the spec 15
New points of tension 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 16
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. (The ONF s logo for FAWG) TTPs list only the OpenFlow features planned for a use case TTPs are flexible enough to address any specific use case But more practical to implement on common (ASIC) devices *Members from Google, which was actively deploying OpenFlow, were early and vocal 17
TTP Practicality Adoptable These colored structures symbolize TTPs ability to spell out specific needed features as needed for different use cases. 16 Sept 2014 18
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) Any member of the SDN community can make (and share) a TTP 19
The New Balance is Endorsed 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 (The ONF s logo for TIWG) 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 20
The Future of OpenFlow Near and Far Revision 21 1.0
The Nearer Future of OpenFlow 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 Provides a basis for OpenFlow 1.3 Multiple Flow Table Conformance Tests 22
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 pif@opennetworking.org And watch this space for related announcements 23
Questions and Answers 24
THANK YOU 25