Performance evaluation of equivalent forwarding sets in software defined networking

Performance evaluation of equivalent forwarding sets in software defined networking

Journal of Network and Computer Applications 153 (2020) 102532 Contents lists available at ScienceDirect Journal of Network and Computer Application...

4MB Sizes 0 Downloads 44 Views

Journal of Network and Computer Applications 153 (2020) 102532

Contents lists available at ScienceDirect

Journal of Network and Computer Applications journal homepage: www.elsevier.com/locate/jnca

Performance evaluation of equivalent forwarding sets in software defined networking Liang Yang PhD, Bryan Ng PhD ∗ , Winston K.G. Seah PhD, Deepak Singh PhD School of Engineering and Computer Science, Victoria University of Wellington, New Zealand

A R T I C L E

I N F O

Keywords: Software-defined network (SDN) OpenFlow switch multiple flow table (MFT) Equivalent forwarding set (EFS)

A B S T R A C T

Software-Defined Networking (SDN) allows the forwarding sets to be constructed from forwarding rules which are expressed in the form of a single table or multiple linked tables. To reconcile the forwarding behavior of different flow tables, forwarding sets are converted to canonical form also called as equivalent forwarding set (EFS). In this paper, two EFS conversion approaches: match-field oriented approach (MFA) and action oriented approach (ACA) are verified through performance evaluation in various functional test scenarios. Using the concept of Boolean reasoning, we prove the correctness of conversion from multiple-flow-table (MFT) to its equivalent MFA and ACA. Similarly, from our experiment on Open vSwitch, the performance evaluation showed that the ACA approach which converts a forwarding set into an action-indexed dictionary performed well with the truth-table based expression. The performance evaluation shows that the MFA approach which converts a forwarding set into a match-field-indexed dictionary is easier to implement in real network devices with smaller storage capacities.

1. Introduction In a computer communication network, network devices (switches/routers) use forwarding rules to forward packets. Forwarding rules are used by network devices to construct a forwarding set that determines the behavior of incoming packets. In a traditional computer network, forwarding sets are in the form of the access control list (ACL) and the Internet Protocol (IP) routing entries. Whereas, in Software-defined Networking (SDN) which is a new networking paradigm (Kreutz et al., 2015; Saraswat et al., 2019), forwarding sets are implemented as a generic forwarding table. This forwarding table is based on the OpenFlow standard which is a widely used and the de-facto SDN standard (Specification, 2009). A forwarding table consists of flow entries or flow table entries (FTEs) where each flow entry is identified by its unique match fields and matching precedence (priority) value (Pfaff et al., 2009). Each flow entry also has a field for an action that contains instructions for matching packets. Match fields in forwarding tables are dynamically customized by a logically centralized control plane also called as the SDN controller.

SDN enables programmability in a computer network by allowing network applications to control the behavior of forwarding tables via the SDN controller. However, the design and structure of forwarding tables in an SDN have progressively become more complicated to support evolving network applications. According to the OpenFlow Specification 1.5 (ONF, 2014a), forwarding sets are constructed either in the form of a single table or multiple-flow-table (MFT) (Dong et al., 2018). The single table approach advocated by the OpenFlow specification has been widely used in software switches for better manageability while the MFT approach has been used in hardware switches for better performance. A logical single table is usually maintained in an SDN controller because the forwarding sets in a server has far less limitations compared to the rules in a hardware switch. This is because the table structure and size in hardware switches vary significantly due to different hardware specifications. Therefore, the functional equivalence must be guaranteed for any transformation of a forwarding set among various networking elements. On the other hand, MFT is one of the most significant enhancements of OpenFlow 1.1 (ONF, 2011), which adds power and flexibility to an OpenFlow switch (ONF, 2014b; Guo et al., 2018). In recent years, some works have noticed the benefits of MFT and applied it into SDN deploy-

∗ Corresponding author. E-mail addresses: [email protected] (L. Yang), [email protected] (B. Ng), [email protected] (W.K.G. Seah), [email protected]. nz (D. Singh). https://doi.org/10.1016/j.jnca.2020.102532 Received 20 August 2019; Received in revised form 20 December 2019; Accepted 6 January 2020 Available online 9 January 2020 1084-8045/© 2020 Elsevier Ltd. All rights reserved.

L. Yang et al.

Journal of Network and Computer Applications 153 (2020) 102532

ment, which requires a forwarding set to be presented in different forms to adapt to the various networking applications. However, MFT introduces additional complexity and challenges to the software responsible for managing these tables. Thus a systematic way to evaluate the functional equality between two forwarding sets becomes indispensable. There are only a few works focused on the conversion between different types of forwarding tables. The works in (Bosshart et al., 2013) and (Pan et al., 2013) are among the first to study and investigate the conversion between various forwarding tables. However, these works lack the correctness in terms of network functionality upon conversion between a single table and MFT (Yang et al., 2017; Sanger et al., 2019). As a result, the forwarding behavior for the same packets may not always be identical. To address this problem of correctness while converting various forwarding tables, we proposed two approaches in our previous work (Yang et al., 2017). The proposed approaches match-field oriented approach (MFA) and action oriented approach (ACA) convert various forwarding sets into a canonical form called as equivalent forwarding set (EFS). The MFA constructs equivalent flow entries based on matchfields of original flow entries while the ACA constructs equivalent flow entries based on actions. The motivation of the research in this paper lies on following reasons:

uating equivalence between two forwarding sets in terms of networking function by converting any given arbitrary OpenFlow table into an EFS. The research in this paper facilitates the flow table management in controller where an equivalent table and the flow table deployment in switches are maintained. The functional tests and performance evaluation of the MFA and ACA will be exemplified using OpenFlow specification 1.5. However, the approaches presented in this paper targets a generic conversion method which is not limited to OpenFlow (OpenFlow Switch Specifica, ). The rest of paper is organized into following sections. In Section 2, we discuss the background theory for a multi-table forwarding set with an example, Boolean reasoning, formula based and truth table based comparison, the definition of EFS, and related work on EFS approaches. In Section 3, the two approaches for EFS conversion (MFA and ACA) are thoroughly discussed. This is followed by the discussion on functional test designs and scenarios in Section 4. The various stages for a performance evaluation of EFS are discussed in Section 5. Finally, this paper is concluded in Section 6. 2. Background and related work In this section we introduce some background concepts and definition to guide readers through the related work on EFS in SDN. This is followed by discussion on the existing literature related to the research on forwarding pipelines and EFS.

1. Forwarding sets are interpreted in various forms in different networking elements (Chen et al., 2016). The various forms are single table, fixed-width fixed-length multiple table, and dynamicreconfigurable multiple-table. Therefore, there must be a solution to evaluate the equivalence of any two forwarding sets for such networking elements with the various forms. 2. Match fields in an SDN can be naturally expressed as Boolean functions. Intuitively, the research work on Boolean logic is also applicable to networking forwarding set. The related fundamental concepts, equations and theories for Boolean logic are explained very thoroughly in (Brown, 2012; Menini et al., 2019).

2.1. Multi-table forwarding set SDN allows forwarding tables to be chained together as a pipeline to process the incoming packets in a more sophisticated way. Fig. 1 illustrates the structure of MFT in OpenFlow specification. A multi-table forwarding set example with three linked tables (Table 0, Table 1, and Table 2) is presented in Fig. 2. These tables collectively form a forwarding set to match against all incoming packets and execute associated actions. The forwarding set in this example refers to the rules within a single switch with one or multiple tables. In Fig. 2, the packets with the match fields “A” and “B” will be sent to Table 1 and Table 2 for further processing, respectively. The actions in “Table 0” contain “Goto Table” attribute which indicates the matched packets will be passed to the

With the aforementioned motivation, this paper extends our previous work (Yang et al., 2017) through functional tests and performance evaluation of the comparison between the MFA and ACA using boolean functions. This paper formalizes and implements the process of eval-

Fig. 1. A multi-table forwarding set specified by OpenFlow (Yang et al., 2017).

Fig. 2. A multi-table forwarding set example. 2

L. Yang et al.

Journal of Network and Computer Applications 153 (2020) 102532

next table for further processing. A flow table entry in “Table 0” with the forwarding set “A, Goto Table 1, 200, 50” is linked to “Table 1”. The “Table 1” is also referred as an associated table for the forwarding set “A, Goto Table 1, 200, 50”. A link is added between a forwarding set and its associated table to represent their association relationship.

products in a DNF or values in a truth table. An n-variable Boolean system on a Boolean algebra 𝔹 is a collection of simultaneously-asserted equations, as follows: p 1 (X ) = q 1 (X ) ⋮ pk (X ) = qk (X ),

2.2. Boolean reasoning

where pi and qi are n-variable Boolean functions on 𝔹, and X denotes the vector (x1 , x2 , …, xn ). The Boolean system is equivalent to the single equation

In this subsection, the basic terminologies related to Boolean reasoning are defined. Boolean function: An n-variable function f ∶ Bn → B where B = {0, 1} is called a Boolean function if and only if it can be expressed by a Boolean formula. For any element b ∈ B, the constant function, defined by f(x1 , x2 , …, xn ) = b∀(x1 , x2 , …, xn ) ∈ Bn , is an n-variable Boolean function. Product Term: The product term of a n-variable Boolean function is defined to be the logical AND of some or all n variables. Minterm (Canonical) Form: A product term in which all variables appear once and only once, i.e., a function with n variables has 2n possible unique minterms. Sum of Product (SOP): SoP is a disjunction (OR) of minterms. A SOP of a Boolean function is a sum (OR) of the minterms which represents all “true” values in the function. Equivalent (≡): Two formulas will be called equivalent(≡) if they represent the same Boolean function, i.e., one formula can be transformed into the other by the application of the rules of Boolean algebra. Congruent (≅): Two formulas in the form of disjunctive normal form (DNF) are congruent if one can be transformed into the other using only the commutative rule. Included (≤): Given two Boolean functions g and h, if the identify gh’ = 0 is satisfied then g is included in h, i.e., g ≤ h. Implicant/Prime Implicant: An implicant of a Boolean function f is a term p such that p ≤ f. Any term of an DNF formula for f is an implicant of f . An implicant p of f is a prime implicant if and only if no other implicant of f contains p, i.e., for any term q, p ≤ q ≤ f → p = q. Absorptive: An DNF formula F will be called absorptive if no term in F is absorbed by any other term in F. The equivalent absorptive formula of a non-absorptive F, also called as ABS(F) can be obtained by successive deletion of terms absorbed by other terms in F. Syllogistic: A formula F will be called syllogistic if for every DNF formula G, G ≤ F → G ≪ F. If a DNF formula F is not syllogistic, it contains terms p and q, having exactly one opposition, such that c(p, q) is not formally included in F. F is syllogistic if and only if every prime implicant of f is a term of F. Blake Canonical Form (BCF): Let F be a syllogistic formula for a Boolean function f. The formula ABS(F) is the Blake canonical form for f which is denoted by BCF(f). The BCF(f) of a Boolean function f is minimal within the class of syllogistic formulas while also comprises the disjunctions of all prime implicants of f. Hence, the BCF of any two equivalent Boolean functions f and g must be identical or congruent, i.e., BCF(f) = BCF(g) or BCF(f) ≅ BCF(g).

f (X ) = 0 , where f is defined by f =

k ∑

(pi ⊕ qi ).

i=1

Thus, for any two forwarding sets Fg and Fh , their equivalence is determined by the equivalence of every Boolean function gi and hi , where gi and hi represent the Boolean function for the same action set ai in Fg and Fh , respectively. It is obvious that any two Boolean functions are equivalent if they comprise the same DNF expression. The method based on the comparison of formula is also called formula based equivalence. One major challenge of this method is that how to transform a Boolean function into a uniform formula. The uniform formula must have one property, i.e., it must have a consistent form for any two equivalent Boolean functions. One solution to obtain a uniform formula is the SOP form in which all “truth” values of a Boolean function are represented by a minterm product. However, the size of SOP is the largest among all disjunctive form. Another solution is to use a truth table in which each row represents a minterm canonical form (truth-table based equivalence). If a Boolean function f has k elements, then the maximum number of rows in its truth table is 2k . The equivalence of two Boolean functions based on the truth-table comparison is a straightforward but time-consuming process, which is an exclusive OR bitwise operation of all entries in truth tables. The width of a Boolean function for a forwarding set is determined by the total number of bits in all match fields. In a formula-based expression, each literal represents a single bit, thus the width also determines the number of literals of all products in a Boolean formula. The number can be further reduced with the introduction of “do not care” bits. If the “do not care” bit exists in the same position for all match fields, it can be removed by the “absorptive” operation. However, the truth-table representation does not benefit from this. It must be expressed using the same width as the original Boolean function. This is because a literal in a formula represents both the value of a bit but also the position of this bit. Let’s take the function in Eq. (1) as an example, f = a′ b′ cde′ + a′ bcde′ + ab′ cde′ + abcde.

(1)

If the literal c in Eq. (1) is set to “do not care”, then its formula-based expression simplifies to f = a′ b′ de′ + a′ bde′ + ab′ de′ + abde.

2.3. Formula vs truth-table comparison

(2)

In Eq. (2), the literal c is omitted because all the value in its specified position is “do not care”. However, in the truth table representation as shown in Eq. (3), the third bit which is represented by the literal c cannot be removed. This is because the position of c cannot be inferred if it is removed from the truth table.

There are two approaches to evaluate the equivalence of two Boolean functions: formula based comparison and truth table based comparison. The formula based approach converts a Boolean function formula into a normal form. Whereas, the truth table based approach transforms all the “truth” value in the Boolean function into a table in which each row represents exact one value. In both approaches, the complexity of comparison depends on two factors: (i) width and (ii) length. The width indicates the number of literals in a formula or the bits of a value in a truth table and the length represents the number of

⎡0 ⎢ ⎢0 f =⎢ ⎢1 ⎢ ⎣1 3

0



1

1



1

0



1

1



1

0⎤ ⎥ 0⎥ ⎥. 0⎥ ⎥ 1⎦

(3)

L. Yang et al.

Journal of Network and Computer Applications 153 (2020) 102532

The minimum length of a Boolean function is equal to the least number of products of its ABS. However, the ABS is not identical for any two given equivalent Boolean function thus it cannot be used to evaluate the equivalence of any two Boolean functions. Whereas, the BCF formula do not pose such problem and can be used to compare two functions. Thus the number of products in the BCF formula of a Boolean function is more valued than the minimum ABS during the evaluation of equivalence. The BCF(f) is the disjunction of all prime implicants of f. It has been shown in (Chandra and Markowsky, 1978) that the prime implicants are related to the number of conjunctions and variables. For a Boolean function in DNF with k conjunctions, the number of prime implicants k is range bound between 3⌊k/3⌋ √ and 2 . If the function has n variables, n it can have at most O(3 ∕ n) prime implicants and at least Ω(3n ∕n) prime implicants. Thus, in a Boolean function f with k conjuncts and n variables, we have: ( ) ( √ ) max 3⌊k∕3⌋ , 3n ∕n ≤ Npi ≤ min 2k , 3n ∕ n , (4) Fig. 3. Equivalent forwarding example.

where Npi is the number of prime implicants in f. Thus any complexity reduction on BCF(f) lies upon the decreasing the conjunctions or variables in f. 2.4. Equivalent forwarding set (EFS) Definition 2.1. [Equivalent Forwarding Set (EFS)]. For any two given forwarding sets Fg and Fh , no matter what their structures and forms are, if they perform the exact same operations for all incoming packets pin ∈ ℙ, they are considered as the EFSs. In Definition 2.1, the operations include any modification on the packets themselves and their output interface(s), i.e., (Pout (g) = Pout (h))∧(Pi f (g) = Pi f (h)), where Pout represents the egress packets and Pi f represents the output interface(s). The typical modifications of IP packets include a medium access control (MAC) address replacement and a virtual local area network (VLAN) tagging, etc. The interfaces include physical egress ports as well as the next hop in a logical pipeline which has been widely used in networking virtualisation (Yang et al., 2017; Li et al., 2018). According to Definition 2.1, the incoming packets will have the same modifications and egress port(s) on a switch with two EFSs. Fig. 3 illustrates two EFSs in the form of a single table and MFT. The multi-table forwarding set consists of three tables which are labelled “Table 0”, “Table 1” and “Table 2”, respectively. In this multi-table structure, the actions in “Table 0” contains “goto table” attributes which indicate that the matched packets of the forwarding entry in “Table 0” will be passed to another table for further processing. In this case, the specified table in “goto table” attribute becomes the entry’s associated table and a link is added between the entry and the table. It can be easily verified that all the incoming packets will be forwarded to the same destinations without any modification in these two EFSs. Using Definition 2.1, an MFT can be replaced by a single equivalent table and vice versa, i.e., these two sets are interchangeable.

Fig. 4. Match Fields distribution of OTN conversion proposed by (Pan et al., 2013).

tion of MFTs for the existing hardware (Nakagawa et al., 2013; Bosshart et al., 2013; Lazaris et al., 2014; Pan et al., 2013). Particular attention about MFTs should be paid to the research in (Bosshart et al., 2013) and (Pan et al., 2013). The former proposed a reconfigurable match tables (RMT) model, which allows the forwarding plane to be changed in the fields by reorganizing the tables (Bosshart et al., 2013). The latter proposed a middle layer to convert flow rules (entries) from the controller to switch hardware flow table pipeline, in which the transformation from one single policy to a multi-table rule is usually required so that the rules can be fitted into different types of hardware (Pan et al., 2013). Both works are concerned with the conversion between different types of forwarding tables, which motivates the underpinnings of this paper, i.e., guaranteeing that the conversion

2.5. Related work MFT is one of the most significant enhancements between OpenFlow 1.1 and OpenFlow 1.0, which adds power and flexibility to an OpenFlow switch (ONF, 2014b). However, MFT introduces additional complexity and challenges to the software responsible for managing forwarding tables. In recent years, some works have noticed the benefit of MFTs and applied them into their SDN deployment. From the perspective of networking architecture, these works focus on two major problems: (1) the transformation between high-level policies and multitable rules (Yao et al., 2014; Heller et al., 2013; Bosshart et al., 2014; Sun et al., 2015; Zhang et al., 2013; Voellmy et al., ) and (2) the adap-

Fig. 5. A multi-table forwarding example (Yang et al., 2017). 4

L. Yang et al.

Journal of Network and Computer Applications 153 (2020) 102532

between a single table and MFT is equivalent in terms of networking functionality. We have found the OTN (the conversion of a One-stage flow table into N-stage flow tables) proposed in (Pan et al., 2013) is NOT always correct. Its core idea is to fill the corresponding match field value of an one-stage flow entry to multi-stage entries based on their containing match field types, as illustrated in Fig. 4. In this conversion, the original single table (Table 1) has been converted into a multi-table structure (Tables 2 and 3). Take the first entry in Table 1 as an example, the original match fields {A, B} are decomposed and distributed into {A} in Table 2 and {B} in Table 3, respectively. Closer analysis reveals that packets matching either {A, B} or {C, D} will behave the same while the packets with {A, D} or {C, B} will not. The packets with attributes {A, D} will NOT match any entries in the single table and will be dropped by default; however, in the converted multi-table, the same packets can match the first entry in Table 2 and then second entry in Table 3 sequentially, which means the matching packets will egress out of port 2. Thus for the same packets, the forwarding behavior will not be the same, which means the single table is not equivalent to the multi-table. This flaw can be easily detected by our algorithms proposed in (Yang et al., 2017) which we are thoroughly going to discuss in the following section.

Algorithm 1 (continued) 16: e.pri ← ek.pri + el.pri∕MAX_PRI 17: insert e into Ti 18: end for 19: remove ek from Ti 20: Convert all priorities to integer in Ti 21: end if 22: end for 23: end for 24: remove Tn−1 from T 25: if T.cnt = 1 then 26: S←T 27: else 28: Multi_table_join(T) 29: end if 30: end procedure Note. (1) A table (T) consists of multiple flow entries (el, ek, e). Every flow entry contains multiple properties (match field (.m), action (.act) and priority (.pri)). (2) The operator ∧ in Line 13 is a logical “AND”-alike operation. The result of a ∧ operation on two match files yield a new match field which means the incoming packet must match both of them.

3. Approaches for EFS conversion

Algorithm 2 Two-tables-comparison (Yang et al., 2017). 1: T1 , T2 ← input: Arrays of two single tables 2: True, False ← output: Equivalence of T1 , T2 3:.cnt ← count of an array (T1 , T2 ) 4:.m, .act ← properties: match fields and actions of a flow entry 5: procedure Table_comparison(T1 , T2 ) 6: for i = 0 to T1 .cnt − 1 do 7: for j = 0 to T2 .cnt − 1 do 8: if T1 [i].act ≠ T2 [j].act then 9: if T1 [i].m ∧ T2 [j].m ≠ ∅ then 10: return False 11: end if 12: else 13: if T1 [i].m = T2 [j].m then 14: if (i = T1 .cnt − 1)&(T2 .cnt = 1) then 15: return True 16: end if 17: remove flow entry j from T2 18: break 19: else if T1 [i].m ⊂ T2 [j].m then 20: T2 [j].m ← T2 [j].m ∧ (¬T1 [i].m) 21: break 22: else if T2 [j].m ⊂ T1 [i].m then 23: T1 [i].m ← T1 [i].m ∧ (¬T2 [j].m) 24: remove flow entry j from T2 25: else if T1 [i].m ∧ T2 [j].m ≠ ∅ then 26: T1 [i].m ← T1 [i].m ∧ (¬T2 [j].m) 27: T2 [j].m ← T2 [j].m ∧ (¬T1 [i].m) 28: end if 29: end if 30: if j = T2 .cnt − 1 then 31: return False 32: end if 33: end for 34: end for 35: end procedure

To convert a forwarding set into an equivalent uniform single table and facilitate the comparison of two forwarding sets, two EFS conversion approaches were proposed in (Yang et al., 2017). The two approaches are (i) match-field oriented approach (MFA) which builds indexing on “match-fields” and (ii) action oriented approach (ACA) which constructs its forms on “actions”. In this section, we will present these two approaches with the multi table forwarding example as shown in Fig. 5. 3.1. MFA conversion In the MFA approach, a flow table entry in one table and its associated tables will generate a new composite entry. This new composite entry preserves the functionality of the original entry. This removes the link between multiple tables once the original entry and the link are replaced by an “equivalent” composite entry. The MFA conversion is shown in Algorithm 1 that describes the conversion process until a new composite single table is achieved. Algorithm 1 Match fields oriented table join (Yang et al., 2017). 1: T ← input: An array of all the tables in a switch 2: e ← input: Forwarding table entries in table T 3: S ← output ∶ EquivalentSingleTable 4: MAX_PRI ← constant: Maximum value of priority 5:.cnt ← count of an array (T) 6:.m, .act, .pri ← match fields, actions and priority of a flow (el, ek, e) 7: Procedure Multi_table_joinT 8: n ← T.cnt, e ← new empty flow 9: for ek ∈ Ti 10: for i = 0 to n - 1 do 11: if ek.act has goto_table_id = n − 1 then 12: for el ∈ Tn−1 do 13: e.m ← ek.m ∧ el.m 14: e.act ← ek.act ∪ el.act 15: remove goto_table_id in e.act

In Fig. 5, Table 0 (with its entries) has two associated tables, Tables 1 and 2. Each entry in Table 0 generates a new composite entry for every entries in its associated tables. Therefore, for a multi-table forwarding example in Fig. 5, the equivalent single table will have 24

(continued on next page)

5

L. Yang et al.

Journal of Network and Computer Applications 153 (2020) 102532

Fig. 6. Successive elimination comparison (Yang et al., 2017).

entries. This number is far more than the sum of entries from the original three tables, i.e., 14 entries. For a MFT with N entries and t tables, the number of flow entries in its equivalent single table will be in the order of O(Nt ). This is the worst case scenario which can be constructed with a chained MFT in which every table (except for the last table) has an associated table(s). Once an MFT forwarding set has been converted into a single-table forwarding set, the equivalence of these two sets is a Boolean comparison of the entries between two individual tables. A Boolean comparison of two tables in which all items of one table will be successively eliminated is presented in Algorithm 2. Let say T1 and T2 are two tables, and i1 represents an individual item in T1 . Every item i1 will be compared with all the items in T2 in the decreasing order of priority. If two items share same match fields but have different actions, then these two tables cannot be equivalent (as shown in Line 8–11 of Algorithm 2). Similarly, for those two items with the same action, the common match fields will be removed from both items (as shown in Line 19–28 of Algorithm 2). This process is repeated until i1 is subsumed by T2 , that is until the match fields in i1 yields an empty set. Otherwise, these two sets are not equivalent (as shown in Line 30–31 of Algorithm 2). Since the forwarding sets are sorted in the decreasing order of priority, this will accelerate the process of the successive elimination comparison between two tables (Fig. 6).

Fig. 7. Single table preprocessing: deprioritisation (Yang et al., 2017).

AND ( ∧) operation between each item’s match fields and the negation of all match fields with higher priorities. Algorithm 3 Single table preprocessing: deprioritisation and merging (Yang et al., 2017). 1: e ← input: forwarding table entries in table T 2: d ← output: equivalent forwarding dictionary set 3:.cnt ← countofanarray 4:.m, .um, .act ← matchfields, unmatchfields, actions 5: procedure Single_table_Preprocessing(T) 6: e0 .um ← ∅ 7: d.key[e0 .act] ← e0 .m 8: for i = 1 to T.cnt − 1 do 9: ei .um ← ei−1 .m ∨ ei−1 .um 10: d.key[ei .act] ← ei .m ∧ (¬ei .um) 11: end for 12: end procedure

3.2. ACA conversion In the ACA approach, a forwarding set has a dictionary structure in which every item has a key and a value attached to it. In this structure, key is “action” while value represents the conditions that trigger this action. Therefore, two forwarding sets are identical in the ACA approach if two forwarding sets can be transformed into two dictionaries in which all keys and the associated values are identical. If multiple entries share the same action then all match fields associated with these entries will be merged with the logical AND ( ∧) operation. However, due to the “priority” attribute, the match fields in one table are not always independent. This is because a packet is matched against all forwarding tables in the sequence of decreasing priority. As a result, the condition to trigger an action for this packet will NOT match any item with higher priority. Therefore, the “priority” attribute should be removed for a forwarding set with a dictionary structure. Fig. 7 illustrates the deprioritisation process with a five-entries example. The deprioritisation process removes the “priority” attribute while preserving the same forwarding functionality. In the original table (i.e. Table 1 of Fig. 7), each item is associated with a priority which determines the matching sequence of an incoming packet. After adding an “unmatch” attribute and removing the “priority” attribute, the dependence among the items have been removed in Table 2 of Fig. 7. This means the positions of items in Table 2 are exchangeable and forwarding functionality remains preserved. The deprioritisation process with steps is shown in Algorithm 3. In Algorithm 3, the process of deprioritisation has been transformed to the

The core idea of converting MFT into a dictionary-based table is achieved by a mapping from the linked table structure to a trie in which each edge represents a match field as shown in Fig. 8. Each leaf node in a MFT converted trie represents an action set which can only be reached by the packets matching all the fields along the path from the root to that leaf node. In the example shown in Fig. 8, there are four different actions: {A1_1 , A1_2 , A2_1 , A2_2 } which are the “keys” in the converted forwarding sets. The associated match fields for these actions are the composite attributes: {M0_1 , M1_1 }, {M0_1 , M1_2 }, {M0_2 , M2_1 }, and {M0_2 , M2_2 } which are determined by the match fields in each respective path. In a real-world scenario, the structure of a MFT pipeline is more complicated than the example in Fig. 8. Usually a table is composed of multiple entries which contain more than one “goto-table” ids. Here the id is the identification of a forwarding table, for example, the table ids in Fig. 8 are 0, 1 and 2. Correspondingly, it is very common that there exist more than one table whose traffic is directed to a same table, which means multiple tables share the same “goto-table” id. The table represented by the id should be cloned for all the tables if they contain “goto-table” action with the same id. The multi-table trie conversion process is illustrated in Algorithm 4. Algorithm 4 guarantees that the same “goto-table” id in different tables will be directed to different 6

L. Yang et al.

Journal of Network and Computer Applications 153 (2020) 102532

Fig. 8. Multi-table trie conversion (Yang et al., 2017).

table. In the MFT converted trie, the number of nodes (denoted by total in Algorithm 4) is the same or greater than the number of tables due to the clone processing (as shown in Line 11 of Algorithm 4). Once a clone happens, the original “goto-table” id must be replaced by the new generated table id (as shown in Line 12 of Algorithm 4). An example of this algorithm will be demonstrated in Fig. 27 (Function test scenario 4 in section 4).

combinations of this entry and all entries in its associated table. Finally all the “goto-table-id” will be removed, which means the remaining actions become the “key” and the match fields of new entries become their corresponding “value” in the final dictionary. Algorithm 5 Multi-table trie traversal (Yang et al., 2017). 1: T ← input: An array of all tables in a switch 2: D ← output: EFS Dictionary [key, value] - [action, match] 3:.cnt ← Properties: Count of an array 4:.m, .act ← Match fields and actions of an entry 5: procedure Multi_table_traversal(T, D) 6: for i to T.cnt − 1 do 7: for ek ∈ T[i] do 8: if goto_table_id ∉ ek.act 9: D[ek.act] ← ek.m ∪ D[ek.act] 10: else 11: j ← ek.goto_table_id 12: for el ∈ T[j] do 13: e.m ← el.m ∧ ek.m 14: e.act ← el.act ∪ ek.act 15: remove goto in ek from el.act 16: insert e into T[j] 17: remove el from T[j] 18: end for 19: end if 20: end for 21: end for 22: end procedure

Algorithm 4 Multi-table trie conversion. 1: T ← input: An array of all tables in a switch 2: T′ ← output: An array of tables converted from T 3: D ← A dictionary [key, value] - [original table id, cloned table id] 4: procedure Multi_table_conversion(T, T′ ) 5: T′ [0] ← T[0] 6: for i = 0; i ≤ total; i + + do 7: S ← a set of all ids in table T′ [i]’s “goto table” actions 8: S′ ← ascendingsortforalltableidsinS 9: for j = 1; j ≤ S′ .count; j + + do 10: build a dictionary with D[S′ (j)] = total + j 11: clone table T′ [D[S′ (j)]] ← T[S′ (j)] 12: replace goto table id S′ (j) with D[S′ (j)] in T’[D[S′(j)]] 13: total + + 14: end for 15: end for 16: end procedure The process to compute a dictionary is detailed in Algorithm 5 which uses a typical breadth-first search strategy. All entries in one table are iterated and the “goto-table-id” in these entries will be replaced by the

3.3. MFA vs ACA The evaluation of the MFA and ACA can be achieved either by the comparison of actions for the same match field or by the comparison of match fields for the same action. Both MFA and ACA are built on the comparison of match fields. The difference between them lies in the fact that the MFA intends to preserve original match fields while the ACA combines all match fields of the same action. The MFA enumerates all the combinations among the match fields in different tables while the ACA constructs the union set for the same actions. Take the multi-table forwarding set in Fig. 5 as an example, there is a total number of 14 entries in all three tables. However, the total number of entries in the MFA results in 24 as shown in Fig. 9 while the ACA reduces this number to eight due to the limited actions as shown in Fig. 10. 4. Functional test Fig. 9. Match-fields oriented conversion approach (MFA) yielding a “tall” table with 24 FTEs (Yang et al., 2017).

The function test adopts black box model in which the switch is a black box while the incoming packets and outgoing packets are this 7

L. Yang et al.

Journal of Network and Computer Applications 153 (2020) 102532

table of the next clause. For the unmatched packets, they will be sent to the next table(s) to match against the negative fields. With this design, the “OR” operation between two fields inside a clause is represented by the action “goto next table” between any two adjacent tables. This process is demonstrated in Fig. 19. Algorithm 6 ACA associated Boolean function deployment. 1: S ← input: single ACA associated match fields in the form of CNF 2: C.negCount ← input: (the count of negative fields in each clause C) + 1 3: ct ← input ∶ theindexofthetableinprocessing 4: procedure Aca_deployment 5: ct ← 0 6: for each clause C in S do 7: rt ← C.negCount 8: if C is the last clause in S then 9: act ← S.action 10: else 11: act ← “goto (ct + rt)th table” 12: end if 13: for each non-negative field m in C do 14: install flow {match = m, action = act} in table ct 15: end for 16: install flow {match = ∗ , action = “goto(ct + 1)st table”} in ct 17: ct ← ct + 1 18: for each negative field ¬m in C do 19: if ct ≠ rt − 1 20: install flow { match = m, action = “goto (ct + 1)st table”} 21: else 22: install flow {match = m, action = DROP} 23: end if 24: install flow {match = ∗ , action = act} in table ct 25: ct ← ct + 1 26: end for 27: end for 28: end procedure

Fig. 10. Action oriented conversion approach (ACA) yielding a “fat” table with 8 FTEs (Yang et al., 2017).

Fig. 11. Test environment design: functional test principle.

box’s input and output, respectively (Fig. 11). In each test, the same incoming packets will be sent to the switch in which the forwarding set will be presented in the different form (Original MFT, Equivalent MFA and ACA). Open vSwitch has been adopted as a networking operating system by many platforms (for example, OpenStack) and physical switches (for example, Pica 8 (PicSupport for OpenFlo, 2111)). To balance the flexibility and applicability, the latest Open vSwitch 2.6.1 (The Linux Foundation and Ope, 2017) is chosen as the test platform. Open vSwitch maintains the exact same design and implementation as the one on the physical switch but offers stronger multi-table capability. Therefore, this paper uses Open vSwitch to investigate the functionality of SDN switches without being dependent on hardware. Similarly, Ryu (version 4.11) (Ryu, 2015) is installed as a controller to provision OpenFlow rules and retrieve the packets statistics while Scapy (Philippe Biondi Guillaume Valadon) is used as a packet generator due to its flexible customization ability.

Algorithm 6 also illustrates the process to verify the forwarding behavior of a single action in an ACA table. However, the table(s) occupied by an action cannot be shared by other actions. Otherwise, associated match fields of the action that are installed later with a lower priority in a table might not get the chance to match against the incoming packets. Thus, it is not possible to deploy an entire ACA table into the existing Open vSwitch, only one action’s match fields can be installed in each functional test. Therefore, an ACA table’s verification will involve multiple rounds of a single action based test. The functional test is to verify if a given MFT table forwards all incoming packets to the same destinations or not as done by its converted MFA and ACA table. In the black box of Fig. 11, three types of forwarding tables will be verified. Among them, the original table(s) and its equivalent MFA are compatible with Open vSwitch and can be installed without any transformation. For each action in an ACA table, the associated match fields can be written into Open vSwitch using Algorithm 6.

4.1. ACA forwarding table deployment In the conversion process from an arbitrary table to a MFA or ACA table, the original MFT and its equivalent MFA are still compatible with the existing switch (for example, Open vSwitch). This means MFA tables can be installed into a switch without any transformation. Compared to the MFA, the match fields in the ACA can also be transformed into conjunctive normal form (CNF). However, each clause in the ACA’s CNF is not a simple match field, it becomes DNF (defined in Section 2.2) of the simple match fields and their negatives. Thus ACA tables cannot be written into the OpenFlow table of a switch directly. Algorithm 6 illustrates the process to convert a single action’s associated match fields into a switch compatible table. All non-negative fields (a field without unary operation “¬“) in a clause will be installed into a single table in sequence (as shown in the lines 13–15 of Algorithm 6). Every negative field (a field with a unary operation “¬“) occupies a separate table with two installed entries. These two installed entries are: (i) an entry with the original non-negative match field to pass packets to the next table (or drop if it is already the last table) and (ii) a default entry to pass packets to the next clause (or execute the action if it is the last table) are installed. These two entries are then combined to represent a negative field (as shown in the lines 18–26 of Algorithm 6). Thus for each clause, the incoming packets will be proceed by the nonnegative table firstly and all matched packets will be sent to the first

4.2. Functional test scenarios In this section, three typical scenarios in traditional networking are verified: i) Forwarding information base (FIB) for OSI layer 2 switching, ii) simple IP table for layer 3 routing, and iii) Multiprotocol Label Switching (MPLS) to VLAN translation. To cover the various types of forwarding set, a comprehensive multiple inward outward pipeline is also presented in the end of this subsection. 8

L. Yang et al.

Journal of Network and Computer Applications 153 (2020) 102532

Fig. 12. Functional test scenario 1 - MAC forwarding.

4.2.1. Scenario 1: FIB An FIB also known as a forwarding table or MAC table is the most commonly used in OSI layer 2 switching to find a proper interface to which an input interface should forward a packet. It is a dynamic table that maps MAC addresses to ports based on their VLAN groups. In the case of Fig. 12, the packets with VLAN 1001–1002 and destination MAC (DMAC) ending with 11 and 22 will be forwarded to the port 1 or 2 while the packets belonging to VLAN 1003–1004 will be forwarded to the port 3 or 4 based on their respective DMAC. The equivalent MFA and ACA of the test case in Fig. 12 have been demonstrated in Fig. 13 and Fig. 14, respectively. During the verification, all the converted FTEs in a MFA table can be written in Open vSwitch but the FTEs in an ACA table cannot be written directly to Open vSwitch because they contain the “OR (∨)” operations. With the help of Algorithm 6, after converting “OR (∨)” to multiple entries, every action can be verified separately by deploying them to Open vSwitch. The detailed process will be exemplified in the next test scenario. During the functional test, various types of traffic with the specific VLAN and MAC in the range of match fields in Fig. 12 have been fed. As illustrated in Fig. 15, for each test, the same packets are replayed for MFT, MFA and ACA to observe their respective actions.

Fig. 15. Functional test scenario 1 - summary of the MAC forwarding table in Fig. 12.

For the given example of an IP routing in Fig. 16, its equivalent MFA and ACA are illustrated in Figs. 17 and 18, respectively. The match fields in the MFA table are in CNF in which every clause is a single match field. Thus it can be easily verified by Open vSwtich. However, the ACA table cannot be written to Open vSwitch directly because it contains the “OR (∨)” and “NOT (¬)” operations. Fig. 19 illustrates the deployment of an ACA table on Open vSwitch for action “output port 5” in Fig. 18 by applying Algorithm 6. Here four tables are used to represent the equivalent match fields of a single action in ACA. Once the same packets are replayed in the switch, all packets egressing from port 5 will be identified. This process is repeated for other output ports until all ACA’s actions have been tested. During the functional test, the various combinations of VLAN, DMAC and DIP in the range specified in Fig. 16 have been tested. As shown in Fig. 20, the packets matching multiple entries in MFT are forwarded based on their original priorities. For example, the packets with destination IP 192.168.1.1 (row 3 in Fig. 20) which matches the first two entries in Table 2 (Fig. 16) are correctly sent to the output port 1 in all three tables.

4.2.2. Scenario 2: IP routing table An IP routing table is used to determine routing paths for data packets over an IP network. The packets matching a certain range of VLAN and destination MAC address will be sent to a routing table for IP lookup to determine its output port. In traditional networking, a MAC address usually points to a switch or router rather than any host in the same subnet to indicate the packets should be further forwarded based on its destination IP (DIP) address. Hence, the actual match fields for an IP routing table include VLAN, DMAC and DIP, which are represented by the three separate tables shown in Fig. 16.

4.2.3. Scenario 3: MPLS to VLAN translation Another typical networking scenario is the MPLS label push, swap and pop. When a packet passes through the gateway from wide area network (WAN) to local area network (LAN), the MPLS label it carries will be popped and replaced by the local VLAN tag. The matching condition of an MPLS to VLAN translation can be represented by the tables in Fig. 21 in which the ingress port and DMAC are added as match fields. This is because the ingress port and DMAC are often used to identify whether a packet should be further processed with MPLS operations or not. In a real MPLS translation case, the actions include MPLS pop, VLAN tagging, source and destination MAC replacement. Whereas in this scenario, only output port is specified because the MFA and ACA focus on the conversion of match fields. Since the original MFT of the MPLS translation is very similar to the IP routing table of second scenario, they have similar MFA and ACA (Fig. 22 and Fig. 23). A difference is that MPLS does not support wildcard, thus the deprioritisation can be avoided, which makes the ACA deployment easier because every single action only requires one

Fig. 13. Functional test scenario 1 - MFA of the MAC forwarding table in Fig. 12.

Fig. 14. Functional test scenario 1 - ACA of the MAC forwarding table in Fig. 12. 9

L. Yang et al.

Journal of Network and Computer Applications 153 (2020) 102532

Fig. 16. Functional test scenario 2 - IP routing table.

cases due to the existence of the multi-inward links. To make Algorithm 5 applicable to this case, all the inward links need to be removed by the clone process implemented in Algorithm 4. The left trie in Fig. 27 depicts the actual table jumping relationship in which a same table might be traversed for more than one time. Similarly, the right trie in Fig. 27 converts the original four-nodes trie into a six-nodes trie by cloning and reindexing all nodes in sequence. After this transformation, the equivalent ACA can be acquired following the process in Algorithm 5. The final result shown in Fig. 28 is a composition of all match fields for the same action (output ports 1 and 2) as shown in Fig. 25. In Fig. 28, the match fields are separated according to their respective traversing path to better demonstrate the packet matching sequence in the original forwarding pipeline. The correctness of the ACA conversion for this strategy can also be proven with the same deployment strategy illustrated in Algorithm 6. Fig. 29 summarises all the test cases in this scenario. All the ports, VLAN, DMAC and DIP in the original MFT are enumerated to guarantee its equivalence to the MFA and ACA. This multi-inward multi-outward scenario can be interpreted as the various conditions for a packet to be proceeded by an IP routing table. The various conditions are the combination of: i) ingress port and VLAN; ii) DMAC and DIP; iii) Port, VLAN, and DMAC. More importantly, this case represents a generic MFT structure which proves the feasibility of MFA and ACA tables.

Fig. 17. Functional test scenario 2 - MFA of the IP routing table in Fig. 16.

5. Performance evaluation The EFS evaluation consists of two stages: i) the conversion from any arbitrary types of forwarding tables into either MFA or ACA table, and ii) the comparison between two converted MFA or ACA tables. Both stages are involved with a large amount of space-hungry and timeconsuming Boolean operations. Therefore, MFA and ACA are performance evaluated in terms of complexity and Boolean operations.

Fig. 18. Functional test scenario 2 - ACA of the IP routing table in Fig. 16.

table. The test cases to verify this scenario are also listed in Fig. 24. 4.2.4. Scenario 4: A multiple-inward multiple-outward case The last test scenario depicts the conversion of a multiple inward outward MFT. Fig. 25 demonstrates a case which contains Tables 0 and 1 with two outward links and Tables 2 and 3 with two inward links. Fig. 26 presents the equivalent single table which is converted from the multi-table example in Fig. 25. All the flows in the converted MFA table are the compositions of the original match fields which can be still written into Open vSwitch. Thus the same method which has been used for the other scenarios can be also used to verify the equivalence of the MFA in Fig. 26. In the processing of ACA computation, the conversion from the original pipeline to the trie structure is different from the previous simple

5.1. Complexity analysis The conversion complexity of forwarding tables into MFA or ACA, moreover, the potential methods to reduce the computation time and the applicable scenarios for MFA and ACA are discussed in this subsection. Fig. 30 compares the number of FTEs in the original MFTs and their corresponding converted MFA and ACA tables for the four scenarios discussed in Section 4.2 for the functional tests. The number of MFA entries (denoted as NM ) is determined by the number of tables and the number

Fig. 19. Functional test scenario 2 - the deployment of the ACA with action “Output port 5” in Fig. 16. 10

L. Yang et al.

Journal of Network and Computer Applications 153 (2020) 102532

Fig. 20. Functional test scenario 2 - summary of the IP routing table in Fig. 16.

Fig. 21. Functional test scenario 3 - MPLS to VLAN translation.

Fig. 24. Functional test scenario 3 - summary of the IP routing table in Fig. 21.

Fig. 22. Functional test scenario 3 - MFA of the MPLS to VLAN translation in Fig. 21.

higher than the original total number of entries (100 + 100 = 200). However, the size of its converted ACA table is determined by the number of actions which is smaller than the original MFT. The MFA introduces not only the greater number of FTE but also the higher complexity. As illustrated in Fig. 31, the conversion complexity ( )t of MFT is proportional to ft because every entry in a table operates with the FTEs in all other tables. The conversion of ACA has two steps: i) the removal of priorities and the merging of the FTEs for the same action, and ii) the trie conversion and traversal. The first step occurs in each individual forwarding table and the complexity is proportional to the number of FTE ( (f )). The second step intends to combine all the action indexed FTEs in different tables whose complexity is determined ( )t by the number of tables and their actions ( at ). The complexity of the second step is determined by the number of FTEs in the converted tables. In the worst case, two equivalent MFTs with different types of structure might yield two completely different MFA tables. Therefore all FTEs in one table must compare with all FTEs in another MFA, this is why the comparison complexity is  (( ft )2t )

Fig. 23. Functional test scenario 3 - ACA of the MPLS to VLAN translation in Fig. 21.

of FTEs in each table while the number of ACA entries (denoted as NA ) is only associated with the final action(s). Supposing there is a MFT ( )t while with t forwarding tables, f FTEs and a actions, NM will be ft

rather than  (( ft )t ). Such complexity will not occur for the ACA because all the FTEs have been indexed based on actions. Besides MFA and ACA, the closest research on equivalent forwarding set is MTO which aims to convert M-stage multiple flow tables into a One-stage flow table (Pan et al., 2013). MTO also chooses a similar strategy as MFA thus have the same complexity as MFA. However, MTO

NA is always the same as a. For a MFT with two linked tables in which one contains 100 MAC address entries and the other contains 100 IP addresses, NM will reach 100 × 100 = 10, 000 which is significantly 11

L. Yang et al.

Journal of Network and Computer Applications 153 (2020) 102532

Fig. 25. Functional test scenario 4 - a multiple-inward multiple-outward case.

Fig. 28. Functional test scenario 4 - ACA result of the multiple-inward multipleoutward case in Fig. 25.

Fig. 26. Functional test scenario 4 - MFA of the multiple-inward multipleoutward case in Fig. 25.

Fig. 29. Functional test scenario 4 - summary of the multiple-inward multipleoutward case in Fig. 25.

Fig. 27. Functional test scenario 4 - trie conversion for the multiple-inward multiple-outward case in Fig. 25.

has limited applicable networking scenarios because it did not consider the effect of priority and multiple-inward multiple-outward structure. From Figs. 30 and 31, it can be observed that ACA has lower complexity than MFA. However, it does not imply that MFA always requires

less storage space and conversion time. It only indicates that ACA has fewer Boolean operations than MFA but each operation might take longer time because ACA retains all the original match fields for the same action. 12

L. Yang et al.

Journal of Network and Computer Applications 153 (2020) 102532

for the ACA becomes extremely complicated and the number of prime implications turns to be extremely large. However, the ACA can be easily implemented in real-world applications with the help of truth table which makes it more favorable in practice. 5.3. Truth-table based boolean operation Fig. 30. Total number of entries in original multiple flow tables, MFA and ACA for afore-mentioned four function test scenarios.

Another way to compare two Boolean functions is to convert them into truth tables and then compare all the elements one by one. This is achieved by electronic logic gates or software. The comparison of two Boolean values is an exclusive logical OR operation. The performance of two Boolean functions with different widths and lengths is illustrated in Fig. 32. Fig. 32 demonstrates the time consumption of bitwise operation between two truth-tables on a Dell OptiPlex 9020 server with Intel i7 Quad-Core CPU and 8 GB RAM. The conversion time from Boolean functions to a truth-table is excluded. It is observed that the execution time is not sensitive to the width of Boolean values. The comparison time of 128 bits width truth-table is only increased around 14.4% compared with the 32 bits truth-table with the case of 232 elements. However, the comparison time is linearly proportional to the number of elements. It takes approximately 24 min for the comparison of two 232 elements. This result demonstrates that the number of Boolean values is the decisive factor in the comparison of two Boolean functions. Hence, the truth-table based comparison favors the ACA than the MFA because it has a smaller number of FTE. In the conversion between Boolean function and a truth-table, the length of a truth-table can be further reduced with the introduction of wildcard. In this scenario, each element must strictly represent one prime implicant, otherwise, the same Boolean functions with different form of truth-tables might be determined as inequivalent. Therefore, the performance of a formula-based approach primarily relies on the number of prime implicants which are determined by width and length. Whereas, a truth-table based approach gives more priority to the length than the width. Since the width in a forwarding set is fixed (determined by the match fields in original MFT), the complexity reduction relies on the reduction of the number of length (i.e. the reduction of the number of operations). Thus, the ACA achieves better performance than the MFA because it intends to push merging operations ahead in every stage as seen in the deprioritisation process and trie traversal. However, the MFA can be easily verified by a hardware or Open vSwitch because the match fields of the MFA are the simple “AND (∧)” operation of all the original individual match fields.

Fig. 31. Complexity comparison of MFA, ACA and MTO.

5.2. Formula based boolean operation The storage and computation of Boolean functions are proceeded in the format of either formula or truth-table as discussed in Section 2.3. Eq. (4) demonstrates that the number of the prime implicants is constrained by variables and conjunctions. Take IPv4 as an example which requires 32 bits (as thus requires 32 variables). IPv4 will have at least 3⌊32/3⌋ = 310 = 59, 049 prime implicants if no limitation of conjunctions is imposed. In practice, the width of match fields might be far larger than 32 due to the existence of various fields such as MAC address, VLAN ID, MPLS label and their combinations. Usually these values are spread in various ranges which makes the reduction of prime implicants difficult using the elimination method. Referring again to Eq. (4), another way to limit the number of prime implicants is to reduce the number of conjunctions. In most cases, the number of variables should be in the same order-of-magnitude for the MFA and ACA because both of them rely on the same composition of match fields. It is possible for the MFA to use fewer variables to represent a match field because it involves far less conjunctions than the ACA. However, the number of prime implicants for the MFA is still considerably large. Suppose there are two forwarding entries with different match fields, one for an IP address and other one for a MAC address. If these forwarding entries share the same action, they will be merged into one forwarding set in the ACA. This means the total number of variables in the ACA will become the sum of IP and MAC address. While in the MFA, they should always belong to different forwarding sets and will be compared in their respective width. Though there is not much difference on the number of variables between the ACA and MFA, their conjunctions vary significantly. In the ACA, all match fields with the same action will be merged into one big set which contains all the conjunctions from the original forwarding entries. The situation becomes worse during the process of deprioritisation where the compliment of the match fields with higher priority will be introduced which is huge compared to the original conjunctions. Let’s take a forwarding table with only two entries as an example. If both entries contain an IPv4 address (IP1 and IP2 ) as match fields while their actions vary, the match fields of the second entry will become {IP1 ∧ (¬IP2 )} after deprioritisation. According to the wildcardsupported “compliment” operations, it will have 32 conjunctions. Thus in the final ACA forwarding set, the number of conjunctions equals to the sum of original conjunctions and their compliments. However, this problem does not exist in the MFA which does not involve deprioritisation and merging among multiple forwarding entries. In summary, the ACA defers the normalization and comparison to the final step of the conversion process. It then compares the large and complexed forwarding sets that are generated. The final number of conjunctions are usually a factor of ten which is more than the number of original entries. As a result, the computation of prime implicants

Fig. 32. Time of Boolean operations with variable lengths and widths. 13

L. Yang et al.

Journal of Network and Computer Applications 153 (2020) 102532

This makes the MFA entries still compatible with the existing forwarding pipeline. In a word, the truth-table based ACA is the most realistic approach to verify EFSs. No matter which procedure and sequence are chosen during the ACA conversion, two forwarding sets are considered to be equivalent as long as they share the same truth-table for same action.

Lazaris, A., Tahara, D., Huang, X., Li, E., Voellmy, A., Yang, Y.R., Yu, M., 2014. Tango: simplifying sdn control with automatic switch property inference, abstraction, and optimization. In: Proceedings of the 10th ACM International on Conference on Emerging Networking Experiments and Technologies. ACM, pp. 199–212. Li, J., Li, D., Yu, Y., Huang, Y., Zhu, J., Geng, J., 2018. Towards full virtualization of sdn infrastructure. Comput. Network. 143, 1–14. Menini, L., Possieri, C., Tornamb, A., 2019. Boolean network analysis through the joint use of linear algebra and algebraic geometry. J. Theor. Biol. 472, 46–53. Nakagawa, Y., Hyoudou, K., Lee, C., Kobayashi, S., Shiraki, O., Shimizu, T., 2013. Domainflow: practical flow management method using multiple flow tables in commodity switches. In: Proceedings of the Ninth ACM Conference on Emerging Networking Experiments and Technologies. ACM, pp. 399–404. ONF, 2011. Specification, OpenFlow Switch. http://archive.openflow.org/documents/ openflow-spec-v1.1.0.pdf. Version 1.1.0. ONF, 2014. Specification, OpenFlow Switch. https://3vf60mmveq1g8vzn48q2o71awpengine.netdna-ssl.com/wp-content/uploads/2014/10/openflow-switch-v1.5.0. pdf. Version 1.5.0. ONF, The benefits of multiple flow tables and TTPs. https:// 3vf60mmveq1g8vzn48q2o71a-wpengine.netdna-ssl.com/wp-content/uploads/ 2014/10/TR_Multiple_Flow_Tables_and_TTPs.pdfVersion Number 1.0. OpenFlow Switch Specification, Version 1.5.1, https://www.opennetworking.org/wpcontent/uploads/2014/10/openflow-switch-v1.5.1.pdf. Pan, H., Guan, H., Liu, J., Ding, W., Lin, C., Xie, G., 2013. The FlowAdapter: enable flexible multi-table processing on legacy hardware. In: Proceedings of the Second ACM SIGCOMM Workshop on Hot Topics in Software Defined Networking. ACM, pp. 85–90. Pfaff, B., Heller, B., Talayco, D., Erickson, D., Gibb, G., Appenzeller, G., Tourrilhes, J., Pettit, J., Yap, K., Casado, M., Others, 2009. OpenFlow Switch Specification. Philippe Biondi Guillaume Valadon, P.L., Scapy. http://www.secdev.org/projects/ scapy/. PicOS support for OpenFlow 1.3. https://docs.pica8.com/display/PICOS2111cg/PicOS+Support+for+OpenFlow+1.3. Ryu, S., 2015. Framework community: Ryu sdn framework, Online. http://osrg.github. io/ryu. Sanger, R., Luckie, M., Nelson, R., 2019. Identifying equivalent sdn forwarding behaviour. In: Proceedings of the 2019 ACM Symposium on SDN Research. ACM, pp. 127–139. Saraswat, S., Agarwal, V., Gupta, H.P., Mishra, R., Gupta, A., Dutta, T., 2019. Challenges and solutions in software defined networking: a survey. J. Netw. Comput. Appl. 141, 23–58. Specification, O.S., 2009. (wire Protocol 0x01. https://3vf60mmveq1g8vzn48q2o71awpengine.netdna-ssl.com/wp-content/uploads/2014/10/openflow-switch-v1.5.0. pdf. Version 1.0.0. Sun, X., Ng, T.S.E., Wang, G., 2015. Software-defined flow table pipeline. In: Cloud Engineering (IC2E), 2015 IEEE International Conference on. IEEE, pp. 335–340. The Linux Foundation, 2017. Open vSwitch, an Open Virtual Switch. A. Voellmy, Y. R. Yang, X. Shi, Towards Automatic Generation of Multi-Table Datapath from Datapath-Oblivious Algorithmic Sdn Policies. Yang, L., Ng, B., Seah, W.K.G., Groves, L., 2017. Equivalent forwarding set evaluation in software defined networking. In: 2017 IFIP/IEEE Symposium on Integrated Network and Service Management. IM, pp. 576–579. Yao, J., Wang, Z., Yin, X., Shiyz, X., Wu, J., 2014. Formal modeling and systematic black-box testing of {SDN} data plane. In: 2014 IEEE 22nd International Conference on Network Protocols. IEEE, pp. 179–190. Zhang, Y., Beheshti, N., Beliveau, L., Lefebvre, G., Manghirmalani, R., Mishra, R., Patneyt, R., Shirazipour, M., Subrahmaniam, R., Truchan, C., 2013. Others, Steering: a software-defined networking for inline service chaining. In: 2013 21st IEEE International Conference on Network Protocols (ICNP). IEEE, pp. 1–10.

6. Conclusion SDN allows the forwarding sets to be interpreted as a single table or multiple linked tables. Two approaches namely the MFA and ACA are discussed and verified in this paper to convert an arbitrary table into an uniform representation called EFS. The former converts a forwarding set into a match-field-indexed dictionary in which the “key” represents “match fields” yielding a tall dictionary. The latter converts a forwarding set into an action-indexed dictionary in which the “value” represents composite “match fields” sharing the same action yielding a fat dictionary. The experiment on Open vSwitch proves the correctness of the conversion from a MFT to its equivalent MFA and ACA. Similarly, the performance analysis shows that the ACA advances in the truth-table based expression and goes on to show that the MFA is easier to implement in today’s devices. The practical implications of the study can be seen from the following two perspectives. First, the equivalent forwarding set evaluation is an effective tool for a network administrator to verify and optimise FTE placement. The truth-table based ACA approach is easily programmed and implemented in real-world to check against the various types of forwarding tables. Second, it can also be used to detect routing problems such as loopback and redundancies. CRediT authorship contribution statement Liang Yang: Investigation, Validation, Formal analysis, Software, Methodology, Conceptualization. Bryan Ng: Supervision, Conceptualization, Methodology, Writing - review & editing. Winston K.G. Seah: Supervision, Conceptualization. Deepak Singh: Writing - original draft, Writing - review & editing. Acknowledgement This research is partly supported by Victoria’s Huawei NZ Research Programme, Software-Defined Green Internet of Things project (E2881) and Victoria Doctoral Scholarship. References Bosshart, P., Gibb, G., Kim, H.-S., Varghese, G., McKeown, N., Izzard, M., Mujica, F., Horowitz, M., 2013. Forwarding metamorphosis: fast programmable match-action processing in hardware for {SDN}. In: ACM SIGCOMM Computer Communication Review, vol. 43. ACM, pp. 99–110. Bosshart, P., Daly, D., Gibb, G., Izzard, M., McKeown, N., Rexford, J., Schlesinger, C., Talayco, D., Vahdat, A., Varghese, G., 2014. Others, P4: programming protocol-independent packet processors. Comput. Commun. Rev. 44 (3), 87–95. Brown, F.M., 2012. Boolean Reasoning: the Logic of Boolean Equations. Springer Science & Business Media. Chandra, A.K., Markowsky, G., 1978. On the number of prime implicants. Discrete Math. 24 (1), 7–11. Chen, T.S., Lee, D.Y., Liu, T.T., Wu, A.Y., 2016. Dynamic reconfigurable ternary content addressable memory for openflow-compliant low-power packet processing. IEEE Transactions on Circuits and Systems I: Regular Papers 63 (10), 1661–1672. Dong, L., Chen, L., He, B., Wang, W., 2018. The research on designs of multiple flow tables in the openflow protocol. In: 2018 27th International Conference on Computer Communication and Networks (ICCCN). IEEE, pp. 1–2. Guo, Z., Xu, Y., Liu, R., Gushchin, A., Chen, K.-y., Walid, A., Chao, H.J., 2018. Balancing flow table occupancy and link utilization in software-defined networks. Future Gener. Comput. Syst. 89, 213–223. Heller, B., Scott, C., McKeown, N., Shenker, S., Wundsam, A., Zeng, H., Whitlock, S., Jeyakumar, V., Handigol, N., McCauley, J., 2013. Others, Leveraging {SDN} layering to systematically troubleshoot networks. In: Proceedings of the Second ACM SIGCOMM Workshop on Hot Topics in Software Defined Networking. ACM, pp. 37–42. Kreutz, D., Ramos, F., Esteves Verissimo, P., Esteve Rothenberg, C., Azodolmolky, S., Uhlig, S., 2015. Software-defined networking: a comprehensive survey. Proc. IEEE 103 (1), 14–76.

Liang Yang received the Dr.Eng. degree from Victoria University of Wellington, New Zealand, in 2018. He is a senior software engineer and data scientist. Prior to this, he has worked for more than 15 years in commercial research laboratories such as Motorola, Ericsson and IBM. His latest research interests include cloud computing, networking virtualisation, data visualization and data analysis.

Bryan Ng completed his PhD (2010) in the area of communication and networking. He held teaching & research positions in Malaysia and France in addition to attachments to commercial research laboratories Intel, Motorola, Panasonic and Orange Labs. His research interest include performance analysis of communication networks, modelling networking protocols and software defined networking.

14

L. Yang et al.

Journal of Network and Computer Applications 153 (2020) 102532

Deepak Kumar Singh received the Dr.Eng. degree from Victoria University of Wellington, New Zealand, in 2019. He is currently working as a Research Assistant in Victoria University of Wellington, New Zealand. His research focuses on modelling of Software-Defined Network, data modelling and recommendation system.

Winston K.G. Seah received the Dr.Eng. degree from Kyoto University, Kyoto, Japan, in 1997. He is currently Professor of Network Engineering in the School of Engineering and Computer Science, Victoria University of Wellington, New Zealand. Prior to this, he has worked for more than 16 years in missionoriented industrial research, taking ideas from theory to prototypes, most recently, as a Senior Scientist in the Institute for Infocomm Research, Singapore. His latest research interests include Internet of Things, wireless sensor networks powered by ambient energy harvesting, wireless multi-hop networks, software defined networking, and 5G access protocols for machine-type communications.

15