SDN OpenFlow Policy Abstractions : Frenetic Netcore Procera
SDN OpenFlow Policy Abstractions : Abstraction layers are a fundamental principle in computer science. It is a core pillar in creating efficiencies through layered, modular scale. Proper abstraction layers are also where the networking train came off the tracks. Network operators program network devices using proprietary APIs one device at a time. In today’s networks, when we push policy to network elements, the control loop is anything but tight. Basic worthwhile operational tools never made it to market, in large part due to a lack of layered abstractions.
Networking is made up of vertically integrated components today that resemble the monolithic mainframes of the 80’s. As we continue the debate around SDN solutions and agnostic forwarding abstractions such as OpenFlow, are merely building blocks that are not magic bullets. What OpenFlow does offer, is a low level network instruction set agnostic to the vendor and likely flexible enough to serve as a base abstraction as it evolves. With a consistent set of primitives we can write controllers and applications that can control forwarding and/or extract valuable information about the state of your network. Operators nailing up static flows for traffic forwarding would be as unmanageable as throwing out your IGPs and hand crafting not just L3 forwarding but L1-L4 forwarding. State distribution will stay decentralized depending on scale, just likely not fully distributed because it just doesn’t make much sense any longer inside an administrative domain, we made it through the cold war.
SDN is More Then Just Pushing Flows, That Needs Abstraction
When looking to stitch a flow across your network, it would be quite cumbersome to handcraft the OpenFlow policy across each element in the network when you can abstract the flow implementation policy with another layer. Frenetic, Netcore and Procera are all SDN OpenFow policy abstractions that uses abstraction layers to hide the details that are unimportant and only present relevant information to upper layers. If you need a forwarding path from A->Z, rather than stitching by hand flows A->B->C->D->E…->Z, you should be able to push a policy A->Z and have the details of everything in between implemented without dealing with the irrelevant semantics of accomplishing that policy. It’s pretty comp sci 101 but we had unique challenges in the past that warranted this architecture and extreme levels of control distribution. As more business logic is expected out of the network, some levels of control will divorce the physical. If we don’t the complexity and feature ransom would lead to even more complexity in an already borderline unmanageable network of today. Everything will route and overlays (either HW or SW) will rule the day. The value and at the same time problem of OpenFlow is its low level abstraction. The policy abstractions in this post are aimed at abstracting much of those complexities.
Openflow is the current popular method of instantiating forwarding rules into network forwarding objects over TCP rather then a vendors proprietary protocol. Programming static flows by hand, is even less scalable than operators using static routes in their networks, rather than using IGPs to dynamically exchange a RIB state. Statically programming flows by hand in anything other than a lab would be unmanageable. Routing is based on Layer 3 prefixes, flow based forwarding is based on a wide variety of L2-L4 headers. The added variables exponentially increases the amount of combinations in a networking devices Flow tables available in hardware TCAM or a vSwitch (Ex. Open vSwitch) software flow table today.
In order to move forward in leveraging the benefits of proactive (pre-populating flow tables) there needs to be expressive languages and compilers to ingest high level networking policy and grind that into large number of flows required to execute the policy.
Examples of Objects Requesting Programmatic Policy Sources:
- User Interface (UI)
- Analytics Platforms
- Instrumentation Software
- Resource Orchestration
- Anything else that can make API calls.
Frenetic: Transform Policy to OpenFlow Flows
Frenetic: A Language for High-Level Reactive Network Control
Frenetic Slidedeck: Frenetic: A Programming Language for OpenFlow Networks
Frenetic Whitepaper: Languages for Software-Defined Networks
Procera: Reactive Policy Layer
Procera: A Language for High-Level Reactive Network Control
Procera Slidedeck: Procera:A Language for High-Level Reactive Network Control
Procera Whitepaper: Procera: A Language for High-Level Reactive Network Control
NetCore: High Level Forwarding Policy Abstraction
It is worth noting E. Crabbe of Google references Netcore in most of his presentations regarding SDN at the IETF.
NetCore: A Language for High-Level Reactive Network Control
NetCore Whitepaper: A Compiler and Run-time System for Network Programming Languages
Video: Frenetic: A Programming Language for OpenFlow Networks
Jen Rexford of Princeton giving a wonderful presentation on Frenetic. Her thought leadership is phenomenal to say the least.
Additional Resources from Brilliant Leaders and Effective Researchers
- PQ Show 20 – Open Network Foundation – FAWG Update –Packet Pushers Podcast
- Jen Rexford Publications -Princeton
- Martin Casado Publications -Vmware/Stanford/Nacira Co-founder
- Nate Foster Publications -Cornell
- Scott Shenker Publications -UC Berkeley/Nacira Co-founder
- Nick McKeown Publications -Stanford/Nacira Co-founder
Thanks for stopping by!
This is very funny because just a couple of days ago I was relating flows to machine code and operating systems to controllers and applications. (Flows are like machine code in the sense that they are just instructions meant to do some higher job) I don’t think any separate frameworks/languages will be necessary however. SDN applications are already creating steps to build these important abstractions. One very good example is implementing a network wide firewall rule in Floodlight, which any ridiculous number of flows can be dynamically generated according to one rule. This is just the groundwork since it’s so early and I think these abstractions will continue and soon we will easily implemented policies.
Hi Jason, Thanks for the comments appreciate it. I like the reference to FloodLight. I think early on applications will come in the form of modules within a controller just like you mentioned.
Looking ahead I tend to predict based on the x86 evolution built on modularity and layering. OpenFlow or any other forwarding primitive has a lot of nuances that would get pretty inefficient dealing with imo. One could probably argue that the Quantum API is a fairly expressive, modular abstraction.
Very thoughtful comments,
Respect,
-Brent
Great stuff! These abstractions are what we need to make SDN more useful in production. I think it would be awesome if we get to the point where we can take abstracted modules, then compose them to build the custom network platform you need.
BTW, I think you put the title for Procera in the box for Netcore.
Thanks Fred!!
Very good summary of what really SDN is. I’m in a particular project to rise further level of networks and looking for a language that supports it. The Frenetic and Procera seem to be the most promising to me, although I still have not done any work with them.
Thanks for share.
I realize this was a year old post, but how usable are these frameworks with cloud stacks? Or are there any updates to these frameworks ? Frenetic/pyretic are layered on top of nox/pox. But I’m not aware of any neutron plugins (as of OpenStack Havana) for nox/pox. Procera doesn’t seem to be publicly released.
Given that SDN’s primary opportunity is seen in data centers, interoperability with cloud frameworks is a must. At this time, I am struggling with floodlight / ryu with OpenStack (as neutron plugins for them are available) and would kill for such an abstraction framework. I think this could get fairly complex when openstack starts to apply its own intelligence to add/delete flows for the virtual tenant networks and if these abstraction frameworks don’t agree with those modifications.