Hybrid OpenFlow Using The Normal Action

Hybrid OpenFlow Using The Normal Action

Normal OF

Hybrid OpenFlow Using The Normal Action

Hybrid OpenFlow Using The Normal Action: When a new technology is introduced in networking, it is not uncommon for most to transition that new technology into their network for test/dev or production by starting with small chunks at a time. Hybrid OpenFlow deployments will used by many of us as a place to start with SDN with fairly low risk and flxible enough to integrate into existing architectures. Just a minimal edge deployment of OpenFlow provides the flexibility to apply new policy techniques never before possible outside of software switching. If you compare a hybrid OpenFlow edge to the overlay data center architectures, not much is different. Using the OpenFlow Normal action, represents the default route of hybrid flow based forwarding at the edge. The disruption and CapEx is fairly low since the hybrid model is still using traditional networks as you aggregate upstream into the native network. Classify and then forward.

Overlay tunneling in the data center gets the attention because it can solve layer 2 adjacency requirements for live workload migrations (vMotion). Tunneling is where much focus has been, when the true innovation, is the classification at the edge before the flows get stuffed into tubes. There are very few, if any, good reasons to extend layer2 networks in that same manor in enterprise and provider networks, other than more broken L2 applications. That said, take aways the tunnels, s/vSwitch/HW Switch/g and you are left with an SDN edge attached to a native forwarding core. The main difference is, one edge device is virtual in a vSwtich and the other is a physical switch (more on that in a future post). The commonality between virtual and physical is they can both be reduced to a forwarding target with similar primitives between the two for object instantiation. A key method for enabling a seemless transition is the OpenFlow normal forwarding action (OFPP_NORMAL). Proper processing at the edge to push into an LSP or any other data path at aggregation, is interesting in and of itself.

Early OpenFlow is a tool for a handful of applications to exploit. Now that the primitives are exposed, we can start writing code to solve problems, instead of adding a new RFC on the top of the 6,000+ others. While operation orders and any needs for recirculation are fuzzy, OFP normal allows you to peel traffic with essentially an ACL. That redirects traffic toward your early application, whether it is programmatic PBR, duplicating output ports for tapping or just an early test/dev environment. Just as the name implies, the action specified in a proactive flow rule or flowmod, if reacting to a packet in, instructs the packet to be sent to the “normal” forwarding pipeline for forwarding. The normal action is listed in Download OpenFlow v1.3
spec as an optionally supported action. There is a hybrid working group, at least still listed at the ONF that doesn’t appear to have anything coming out of it. Most vendors are supporting the OF Normal action (or a really, really good front patch story), if they don’t support a hybrid path, they would be a tough sell for most of the colleagues I collaborate with.

NORMAL: Represents the traditional non-OpenFlow pipeline of the switch (see 5.1). Can be used only as an output port and processes the packet using the normal pipeline. If the switch cannot forward packets from the OpenFlow pipeline to the normal pipeline, it must indicate that it does not support this action. – OpenFlow v1.3 Spec

OpenFlow Hybrid Pipeline

What the normal action means for early OpenFlow deployments is, an application can push some specific flow rules to peel off traffic for something like a traffic steering or a tapping application to be matched. If that traffic is not matched it would have a rule as a catch all at the end to forward that packet to the normal forwarding pipeline.

OpenFlow Pipeline
OpenFlow Pipeline

Hybrid OpenFlow Pipeline using the Normal Action
Hybrid OpenFlow Pipeline

What the normal action translates to, is the ability to redirect “interesting traffic” that you want to push into an OpenFlow application, if there is not a match by the OpenFlow flow rules, it matches the normal action for typical packet forwarding.

The normal action pushed into an HP 3500yl with all fields wildcarded as a default match at the end of a flow rule set (think ACL), looks like the following. That one flow rules tells the switch to process packets normally. I think it is important that it is understood from an operations perspective. Match whatever you want to match for early applications and let the rest go. Notice that the flow rule is processed in hardware as displayed in the following output:

Hybrid OpenFlow Normal Rule

When you are looking at early SDN and OpenFlow enabled gear, I think it is vital to have features like normal support to be able to adjust architectures as needed. In summary, one flow rule can turn have traffic act as it normally would. On top of that, add your early use cases without the need to reinvent the wheel. In summary, hybrid techniques allow for early explorations of the new found freedoms that open systems present, by cherry picking traffic for particular applications, while still performing traditional functionality in packet forwarding for routine operations.

Next, Adding the Normal Action to Flow Tables

In the next post, we will walk through instantiating that normal flow rule for those new to OpenFlow. To do so we will be using the application Avoir, developed by our friends at Marist University. It is a great OpenFlow GUI that sits atop the FloodLight controller and uses the static flow pusher module for OpenFlow rule instantiation.


Thanks for stopping by!


About the Author

Brent SalisburyBrent has worked in both the Enterprise and vendor sides. In 2014 Brent left RedHat to be a co-founder of Socketplane.io, a startup with a focus on reliable, scalable and performant Docker networking. In 2015, Docker Inc. acquired Socketplane. Now working at Docker, he is part of an engineering team that is building community and working to make sure the users experience of Docker networking is as satisfying as the rest of the amazing project that is fundamentally changing the infrastructure market as fast as anything the industry has experienced since the micro processor.View all posts by Brent Salisbury →

Guest
2 years 18 days ago


It’s pleasant to ultimately get a internet site where the blogger knows what
they may be talking just about.

Guest
2 years 2 months ago


Brent,
Excellent post. I learned something. Thank you!

Guest
2 years 3 months ago


Brent,

if I may add.

The hardest thing in a Hybrid model to understand, implement and manage is who has control and how the two control mechanisms truly orchestrate the combined network. Preventing traffic loops, inconsistent or contradicting actions and what do to in failure situations is hard with a single control plane, let alone multiple. More complex hybrid models (e.g. can OF modify the packet, but legacy does the forwarding) can blur this line even more. And similar to your comparison, I believe vSwitch based tunneling techniques that are not orchestrated with the pNetwork will suffer from similar complexities. Independent layering does not create an orchestrated network.

Some basic level of Hybrid may be a convenient way to get some very basic OF added to a normal network, but possibly with limited capabilities and at the risk of adding complexity, not remove any. Full value of SDN (deliberate use here vs OF) imho requires full orchestration.

Guest
Simhon Doctori
2 years 3 months ago


Hi Brent,

Thanks a lot for your posts, they are very useful for understanding and getting into SDN.

There is one issue, thus, that was yet not discussed on your blog (as far as I could look for …) – the correlation and synch of the flows which are set on a specific OF switch by two or more different applications.

Meaning, which module is responsible, if at all, to make sure that applications A’s rules are set prior to application B’s rules as it should? Although, I believe, it is up to the controller to do the work I could not find any controller capable of doing it.

For instance – let’s say app A is a firewall on L3/2 and app B is a doing a switch function, then app A rules must come on Table N and app B rules must come on table M where N<M, otherwise pkts will be forwarded before applying the security rules. If assuming the application were developed at two different vendors then who takes care of the sync?

It is also required for rules which are set on the same table (on the same OF switch) and needs to be synch in their priorities value.

Have you or others addressed this issue?

Thanks,
Simhon.