1. The FlowAdapter: Enable Flexible Multi-Table Processing On Legacy Hardware
Heng Pan ,
Hongtao Guan, Junjie Liu (ICT, CAS)
Wanfu Ding, Chengyong Lin (Huawei Technologies Co. Ltd.)
Gaogang Xie (ICT, CAS)

2. Motivation Heterogeneous OpenFlow Switches
Different number of flow tables.
Various match field types
Diversity of controller-issued rules
Elimination to the heterogeneity of OpenFlow switch
Abstraction of hardware capabilities for rules
Flexibility and programmability in the heterogeneous OpenFlow network.
OpenFlow network consists of heterogeneous OpenFlow switches even if they are based on the same specification. The heterogeneity exists in flow table number and match field types.
However, it is not good for the controller. Why? Because, programmers want to issue rules arbitrarily without regard to the hardware capabilities. If do like this, it can provide more flexibility and programmability for the whole network.
HotSDN 2013

3. Motivation (cont.) HotSDN 2013 Hardware Capability Hardware Capability
For example, a heterogeneous OpenFlow network consists of a controller and four OpenFlow switches. Supposing switch A has three flow tables, switch B consists of two flow tables. The hardware capabilities of them are showed in the slice.
HotSDN 2013

4. Motivation (cont.) HotSDN 2013 Rules Hardware Capability Legacy Switch
At this time, programmers want to issue a flow entry rule with TCP_SRC and TCP_DST match fields to the table 3 of the switch A. However, switch A doesn’t has the table 3. In addition, programmers want to issue a flow entry rule with IP_SRC and VLAN match fields to the table 0 of the switch B. Unfortunately, the table 0 does not support for VLAN.
HotSDN 2013

5. Questions How to issue rules to switch hardware correctly?
How to express packet processing functionality in a way that is independent of the specific capabilities of the switch hardware?
How to capitalize on legacy data-plane hardware?
This example let’s think about, How does the controller issue rules to switch hardware correctly? How could Programmers express packet processing functionality in a way that is independent of the specific capabilities of the switch hardware? How could SDN capitalize on more sophisticated[sə'fɪstɪkeɪtɪd] data-plane hardware?
We want to realize the programmers’ dream.
HotSDN 2013

6. Challenges Our goals Challenges
To address the mismatch between the controller-issued rules and the capabilities of the hardware switches
Challenges
The unpredictability of controller-issued rules
The types of match fields
The flow tables involved
The hardware capabilities of diverse switches ……
The equivalent conversion of multi-stage flow tables
The match result
The actions
In this paper, we aimed to address the mismatch between the controller-issued rules and the capabilities of the hardware switches. So, we have to face those challenges, like the unpredictability of controller-issued rules and the equivalent conversion of multi-stage flow tables.
HotSDN 2013

7. Contributions
Convert M-stage flow tables into N-stage flow tables equivalently
Packet match result
Packet match fields’ modification
Packet execution actions
Design and implement a adapter layer
Allow programmers to write rules more flexibly
Capitalize on more legacy switches
The main contributions of this paper are as follows:
Based on the equivalent packet match result, packet match fields’ modification and packet execution, we proposed a algorithm['ælgə'rɪðəm] to implement the conversion of the M-stage flow tables into the N-stage flow tables.
And then, based on the algorithm, we design and implement a adapter layer, called FlowAdapter, to let controller-issued rules fit switch hardware.
HotSDN 2013

8. Overview Architecture Software data plane Hardware data plane
To support flexible multi-stage
rule tables
Hardware data plane
To achieves high-speed packets
forwarding
The FlowAdapter
A mid layer let controller-rules
fit hardware capabilities
We proposed a three-tier architecture in the switch. Software data plane, the hardware data plane and the FlowAdapter. The software data plane communicates with the controller directly. The controller can issue rules arbitrarily to the software data plane considering its flexibility. And the hardware data plane, achieving high-speed packets forwarding, shows the limited hardware capabilities. The mission of the FlowAdapter is to let the flexible rules fit into the limited hardware.
HotSDN 2013

9. The FlowAdapter Enable controller-issued rules fit into hardware
MTO
Convert M-stage flow tables into One-stage flow table
M-stage flow tables are from software data plane
Flexibility and Scalability
OTN
Convert One-stage flow table into N-stage flow tables
N-stage flow tables are based on hardware capabilities
Limited by hardware
Based on OpenFlow1.2
The FlowAdapter has two processing. The frist one is to convert M-stage flow tables into One-stage flow table. We called it MTO. The M-stage flow tables are stored in the software data plane. They contain flexibility and scalability. The other is to convert One-stage flow table into N-stage flow tables. We called it NTO. The N-stage flow tables are based on hardware capabilities.
We implement the FlowAdapter based on OpenFlow 1.2.
HotSDN 2013

10. Observation
The pipeline processing of multi-stage flow tables is complex
A flow entry may belong to many rules.
Not all rules begin from flow table 0.
What are Complete rules?
Rules consist of many flow entries.
The flow entries of the last table of the pipeline don’t contain the Goto-table instruction.
Our approach is based on a key observation. We found that the pipeline processing of multi-stage flow tables is complex. For example, a flow entry may belong to many rules. In addition, not all rules begin from flow table 0. Facing the complex pipeline processing, we should find out the all rules at first. So, we defined Complete rules. But, what are complete rules? In fact, rules consist of many flow entries. And the flow entries of the last table of the pipeline don’t include the Goto-table instruction. So, we called those rules complete rules.
Look at the figure! If the flow entry 0 of the flow table 2 does not contains Goto-instruction, this is a complete rule.
HotSDN 2013

11. Data structure Representing the pipeline Node type Default:
This type nodes don’t contain match fields.
It is a table miss when the packet does not match a flow entry in a flow table.
The behavior storing in this type node will be executed when it occurs a table miss.
Normal:
This type nodes contain match fields.
The Instruction set of the node will be executed if packets are matched against the node.
Let’s take more attention on the data structure that we will use. We use N-tree structure to represent the pipeline. In fact, every flow table has a default flow entry to process the table-missing. This type flow entries do not include any match fields. So, we define two types of nodes of the N-tree. The first one is the default type. It represents the default flow entry. The other type is the normal type, which has match fields.
HotSDN 2013

12. Data structure (cont.) Representing the pipeline N-tree Type one
Root node is from flow table 0.
The root node and child nodes are normal type.
Type two
Root node is the default type.
Child nodes are default type or normal type. Those normal type nodes are the root of type three N-tree.
Type three
Root node is not from flow table 0.
The root node and Child nodes are normal type.
To represent the pipeline processing of the flow tables, we also define three types of N-tree. The type 1 can be described as follow: Root node is from flow table 0. The root node and child nodes are normal flow entries. The type 2’s root node is the default flow entry. And its child nodes are default flow entries and normal flow entries. Those normal flow entries are the root of type three N-tree. The type 3’s root node is not from flow table 0. Its root node and child nodes are normal flow entries.
HotSDN 2013

13. Data structure (cont.) HotSDN 2013
For example, there are three flow tables. Some simple pipeline are stored in those flow tables. Based on our definition, we can get a N-tree of type 1, 2 and 3 respectively.
HotSDN 2013

14. Design and Implementation
MTO
Construct three types N-trees
Using metadata to achieve the pipeline of M-stage flow tables
Obtain leaf nodes
Only need to get the leaf nodes of type 1 and type 3 N-trees
A leaf node can represent a completed rule
Generate One-stage flow table
To construct a one-stage flow entry
Eliminate redundant match fields and instructions
E.g. Goto-Table and Write-Metadata instructions
Based on the observation and data structure, we will talk about the design and implementation of our FlowAdapter.
For the MTO process, we also first construct three types N-tree as we describe above.
Next, we should get the all leaf nodes of type 1 and type 3 N-trees by traversing those N-trees. Why? Because, each one of those nodes represents a complete rule as we defined.
At last, we should generate the One-stage flow table. At the same time, we could eliminate redundant match fields and instructions.
HotSDN 2013

15. Design and Implementation
MTO (cont.)
For example, through those flow tables, we can get a type 1 N-tree like this. And then we get a leaf node list. For the leaf node, flow entry 0 of the table 1, we can get a complete rule like this. We just suppose that their match fields types, values and instructions can be set as the figure shows.
Through the MTO processing, we can get a flow entry of a One-stage flow table like this. We eliminate TCP_SRC match fields and Set_TCP_SRC and Goto_table instructions.
HotSDN 2013

16. Design and Implementation
OTN
Initializing N-stage flow tables
Being configured flexibly by programmers
Including numbers and each table match fields
Splitting One-stage flow table rules
Constructing a flow entry for each N-stage flow table
Padding match fields and instructions into those flow entries
Based on the configuration of N-stage flow table
Deleting those flow entries which don’t contain any match field
Inserting the flow entries into N-stage flow tables
Next, we will describe the OTN processing.
First we should initialize the N-stage flow tables based on the hardware capabilities, including the number of flow tables and each table match field types. Then, we should split the one-stage flow table rules. It includes constructing a flow entry for each N-stage flow table, padding match fields and instructions into those flow entries and deleting those flow entries which don’t contain any match field. At last, we should insert the flow entries into N-stage flow tables.
HotSDN 2013

17. Design and Implementation
OTN (cont.)
Flow table Initialization
For example, we can suppose the One-stage flow table rule which has been got at the MTO process above. And the number of N-stage flow tables is 4. The types of match fields of each flow table are like this. And then we should spilt the One-stage flow table rule based on the N-stage flow tables. Then, we find that the flow entry of the table 0 and table 3 have no match fields. They should be deleted.
One-stage flow table rules split
HotSDN 2013

18. Conclusions and Future work
The FlowAdapter is a efficient Adaptation layer to enable controller-issued rules fit into hardware
The conversion between M-stage flow tables and N-stage flow tables
Improve the existing model
Incremental update of the N-tree
Improve the scalability of the FlowAdapter
Now, I will conclude our work. We design and implement the FlowAdapter to address the mismatch between the controller-issued rules and the capabilities of the hardware switches. It can convert M-stage flow tables into N-stage flow tables equivalently.
Our future work is to improve the existing model, like improving N-tree construction algorithm, considering about incremental update of the N-tree and improving the scalability of the FlowAdapter.
HotSDN 2013

19. More information: http://fi.ict.ac.cn
Thank you!
More information: