In my last post I summarized the DVR solution and tried to explain the motivation for yet another L3 implementation in Neutron that I am going to present in the coming posts.
This 2-post series is intended to cover basic SDN and OpenFlow mechanisms that we used in the L3 controller:
The NORMAL action comes to the rescue and lets us offload legacy non-OpenFlow pipeline (like MAC learning mechanism, VLAN, ACL, QoS and other base features) to the forwarding element kernel module, which is optimized to handle such operations in near-line-rate.
But what happens when the NORMAL action is used in an OpenFlow flow?
Basically, what happens is that the traffic is redirected to a completely separated processing pipeline. This is illustrated in the diagram below.
This 2-post series is intended to cover basic SDN and OpenFlow mechanisms that we used in the L3 controller:
- Hybrid OpenFlow Switch
- SDN models for managing the forwarding elements (switches)
Hybrid OpenFlow Switch
Hybrid OpenFlow switch was introduced in OpenFlow/1.1. Hybrid switches support both OpenFlow operation pipeline and normal (legacy) Ethernet switching functionality.
The hybrid switch allows forwarding of packets from the OpenFlow
pipeline to the normal pipeline through the NORMAL and FLOOD reserved ports.
The main reason for introducing the hybrid switch was to optimize the handling of operations like MAC learning, where a reactive approach was just not efficient - Doing MAC learning in the OpenFlow controller poses a significant cost in terms of network bandwidth and latency and does not scale for large networks.
The NORMAL action comes to the rescue and lets us offload legacy non-OpenFlow pipeline (like MAC learning mechanism, VLAN, ACL, QoS and other base features) to the forwarding element kernel module, which is optimized to handle such operations in near-line-rate.
But what happens when the NORMAL action is used in an OpenFlow flow?
Basically, what happens is that the traffic is redirected to a completely separated processing pipeline. This is illustrated in the diagram below.
 |
| OVS Hybrid OpenFlow Switch Pipelines |
The OpenFlow pipeline and the Normal Pipeline, each act as a completely isolated switch.
There are, however, some issues with this hybrid approach.
- NORMAL pipeline is not standardized, so it behaves differently on switches from different vendors - There is a variance in the supported features, and no standard way to configure them
- NORMAL pipeline does not play well with some OpenFlow actions, for example if the port is tagged for the NORMAL pipeline (using the ovs-vsctrl), you can not tag it using OpenFlow actions and then forward it to the NORMAL path, because it will end-up dropped due to double tagging error.
The Open virtual Switch extensions to OpenFlow were developed to support these extra features using Flows, for example the LEARN action (Open vSwitch extension to OpenFlow) for MAC learning .
In my next post I will cover the SDN models for managing the forwarding elements in reactive, proactive and mix modes.
No comments:
Post a Comment