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 →

  1. Simhon DoctoriSimhon Doctori02-21-2013

    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?


    • Brent SalisburyBrent Salisbury02-25-2013

      Hi Simhon, thanks for the comments. The race conditions could be a problem. OFP_Barrier is one function that will verify some sanity when it comes to dependencies. Priorities become very different from v1.0 going to v1.3 with multiple tables. Each table can match as it goes through the pipeline instead of some of the problems of v1.0 priorities, and it gives more flexibility to the hardware vendors.

      Barrier might be what you are thinking of, pasted some from the v1.3 spec below. Take care.

      Barrier: Barrier request/reply messages are used by the controller to ensure message dependencies have been met or to receive notifications for completed operations.

      Message Ordering: Ordering can be ensured through the use of barrier messages. In the absence of barrier messages, switches may arbitrarily reorder messages to maximize performance; hence, controllers should not depend on a specific processing order. In particular, flow entries may be inserted in tables in an order different than that of flow mod messages received by the switch. Messages must not be reordered across a barrier message and the barrier message must be processed only when all prior messages have been processed. More precisely:
      1. messages before a barrier must be fully processed before the barrier, including sending any resulting replies or errors
      2. the barrier must then be processed and a barrier reply sent
      3. messages after the barrier may then begin processing
      If two messages from the controller depend on each other (e.g. a flow mod add with a following packet-out
      to OFPP_TABLE), they should be separated by a barrier message.

  2. Marten TerpstraMarten Terpstra02-21-2013


    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.

  3. Brent SalisburyBrent Salisbury02-25-2013

    Hi Marten, thanks for the comments, very thoughtful. Imo, the days of running a fully distributed network within a single administrative domain are coming to an end in my opinion. We can scale modularly and tie things together up the stack. Inter-domain is a much trickier problem that we are starting to see some early federation models getting proofed but I think it needs better and higher level packaging than is currently being entertained.

    The edge of the network needs to incorporate L4 to pickup beginnings of application awareness. Flow based forwarding seems to me easier than trying to bend legacy protocols, but either way, management should obfuscate some of that.

    I havent had a chance to listen to your podcast with Greg and Ethan yet, so let me get a chance to get into that so I understand your definition of (full) orchestration. Not sure if we are talking networking in general or DC resource consumption etc.

    In case anyone else missed Marten’s podcast:

    Thanks for the thoughts!

  4. Brad HedlundBrad Hedlund02-28-2013

    Excellent post. I learned something. Thank you!

  5. Brent SalisburyBrent Salisbury03-04-2013

    Thanks Brad! For anyone reading this comment leave my site immediately and go read Brad’s fantastic post: http://bradhedlund.com/2013/01/28/network-virtualization-a-next-generation-modular-platform-for-the-virtual-network/ Phenomenal post as usual!


  6. AdrieneAdriene05-09-2013

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