Integration of Interdomain Flow-Rule in Software-Defined Networks for Embedded Internet of Things Devices

Abstract

Software-defined networking (SDN) is an evolving technology providing proper segregation between the control part and data-forwarding domain of network devices. The expansion of the Internet of Things (IoTs) and embedded mobile devices increases the volume of traffic at the network backbone and causes processing costs in the control plane. This directly affects the Ternary Content Addressable Memory (TCAM) of the switches because insufficient space makes it more challenging to manage the flow-entries. In this situation, providing services to specific users who newly authenticate after the successful handoff from the previous SDN domain is challenging. This paper proposes a method for implanting the users’ primary domain’s flow-rules in the serving SDN domain. As the TCAM is already suffering from a short space, it is hard to handle the flow-tables of multiple SDN domains in limited TCAM storage. The SDN-based Integration of the Interdomain Flow-rule in the SDN (IIF-SDN) scheme maximizes the proficiency of the switches by effectively storing flow-table and flow-entries. The effectiveness of the proposed scheme is benchmarked with proactive and reactive SDN approaches.

1. Introduction

The rapid development of online applications, cloud computing, multimedia applications, and big data analytics demands revolutionary steps for flexible, agile, cost-effective, and specific service provisioning related to individuals [1,2]. The concept of virtualization in the network enhances the functionality of the network, such as network function virtualization (NFV) and software-defined networking (SDN) [3,4]. SDN—which is divided into two parts: the control plane and the data plane—is emerging as a key enabler in the networking field, and it aids in packet transmission between network devices and the IoT. The SDN controller remote virtual machine is placed anywhere in the network to manage policy functions, routing-related jobs, and the whole background processes. The SDN itself accomplishes the run-time configuration and programmatic behavior moderation. In SDN, the packet transmission rules are stored and managed in a flow-table inside the switch. Various schemes have been developed for managing flow information for the improvement of the ability of the network [5,6]. Figure 1 demonstrates the flow-table and the flow-entry fields stored inside the flow-table.

Flow-entry is an element of the flow-table to establish the matching-field, action-field, and stats-field. The matching-field contains packet information, and the action-field holds information about what actions apply when flow-entry matches. The stats-field stores the information about how much time the packet matched [1,2,3]. The OpenFlow switch contains a flow-table, usually implemented with the technology of TCAM. The flow-table is based on rules, access control lists (ACLs), and the IP route table. The SDN controller randomly checks the switches and updates the flow-table by installing new strategies.

There are two approaches for updating the flow-table in SDN: (i) reactive and (ii) proactive; in the reactive approach, the SDN controller does not install the flow-table when the network operation is launched. Instead, the SDN controller sets up rules in the flow-table as packets arrive at the switch during the network operation. On the other hand, the flow-rules are installed into the flow-table in advance in a proactive approach as a network operation begins. The proactive approach can reduce the overhead in the communication between the controllers and switches [4,5,6]. Some more degradation issues related to the SDN performance are (i) topology changes, (ii) network reconfiguration, and iii) re-routing rules creation. The most frequent challenge for the SDN controller is upgrading the switches rapidly and consistently to maintain the quality of service (QoS) [7,8]. Figure 2 shows the taxonomy of SDN performance challenges.

The key finding of this research is (i) hybrid flow-rule integration inside the SDN switches, (ii) packet transmission without any anomaly, (iii) hybrid flow-rule execution, iv) optimized flow entries, and the update process itself. Therefore, the network data can be forwarded generally in the uninterrupted update scenario. Furthermore, the proposed IIF-SDN scheme is applied on account of a rapid response between the controller and switches for services to the continuously connecting users of different SDN domains, which is highly significant to maintain and incorporate the hybrid flow-rule in TCAM and ACLs of switches.

The rest of the paper is organized as follows: The background knowledge described in Section 2 briefly enlightens the operations in SDN networks and details of the flow-table and flow-entry management. This is followed by explaining the SDN-based IIF scheme and its function in Section 3. The Section 3 subsections describe the complete performance evaluation of IIF according to the defined performance metrics. Finally, Section 5 is the conclusion of the paper.

2. Related Work

The OpenFlow switch in an SDN-based Wi-Fi network is located at the access point, and OpenFlow provides interoperability between the controller and data plane. The centralized control in SDN technologies minimizes many problems, such as handover delay, overload or load balancing issues, and packet losses as compared to conventional Wi-Fi network technologies. The controller takes all decisions for policy implementation, including packet processing, such as the addition, modification, and deletion of entries in the OpenFlow switch’s TCAM [9]. In addition, the OpenFlow switches are used as forwarding elements in the SDN-based Wi-Fi network.

SDN is designed and developed for flow-based network applications and has complex matching patterns for packet transmission. TCAM produces more complexity because of its limited storage size for forwarding rules, and the OpenFlow technology has an essential concern regarding its deployment [10,11,12]. The solution to this problem is to reduce the demand for TCAM and aggregate the required entries by merging the flow-entries, and preserving its original semantics through wildcard rules. For the fast-updating flow-entries, there are more solutions: (i) delegate control back to the switch, (ii) common flow entries, (iii) cluster allocation in the SDN switch. However, the bandwidth can affect the update flow-rule speed between the controller and switches; for this kind of issue, some researchers proposed a solution to delegate the control back to the switch to release the overloaded SDN controller [13,14,15]. Another solution proposed in [16] is that the intermediate switch does not need any controller for rule installation if sending and receiving switches update the flow-table by parsing information in the packet header. This scheme helps to release the controller’s burden and improve the network’s speed.

An SDN-based wireless network (SWN) [17] is the scheme proposed for seamless handover, load-balancing, and unified authentication with the cooperation of the SDN controller. The author used software as a bridge between the mobile node and the access point, namely, the software access point (SAP). Although the researchers of this scheme claim good results of throughput of SAP-based handover, experimental tests are not included in this study.

After the successful handoff, it is necessary to allocate resources to the newly registered mobile user. The user frequently complains that the serving domain cannot provide the same services as the primary domain. Therefore, maintaining the QoS of the primary domain in the serving domain is crucial. SDN-based Heterogeneous Inter-Domain Handoff system for IoT (SDN-HIIoT).

The mobility-aware hybrid flow-rule cache scheme [18] chooses whether to install the flow-rule either proactively or reactively for the target-candidate-forwarding nodes based on a comparison between the delay requirement of the incoming flow and the response delay of the controller. Considering the flow-rule cache constraints, the heuristic technique is used to define and resolve the integer linear programming (ILP) issue to determine the ideal number of proactive flow rules.

SDN-HiIoT proposed in [3] is based on the heterogeneous SDN domains handoff system for mobile devices. This methodology is used to exchange the flow rules by using east-bound and west-bound APIs between two SDN controllers. Here, novel technology experiments are used based on the simulation of two SDN RYU controllers and OpenFlow switches.

The proposed solution was invented to provide the primary SDN domain’s quality of services (QoS) to those users who register from any SDN domain in the current SDN domain. SDN-HiIoT is established by the “C” controller and all “M” flow-tables. In this proposed technology, the existing SDN domain obtains the primary domain flow-rules for the newly authenticated user for the provision of quality of services (QoS). The equation before the installation of the obtained flow-rules in the current SDN domain looks like C(current) = ${{\displaystyle \sum }}_{i=1}^{m}M$, where i = {1, 2, 3 … m}; after installation of the primary domain flow-rules, the equation becomes C(current) = ${{\displaystyle \sum }}_{i=1}^{m+k}M$, where k is considered as an obtained flow-rule of the primary domain. Figure 3 shows the flow-rule exchange.

For the management of the flow-table, the Authority Switches scheme is also used to speed up the process of the installation of rules, which requires large-scale modification but is not sure of the OpenFlow protocol specification. An automatic flow-table control technique is proposed in [19] for the OpenFlow switch to solve insufficient flow-table resources. However, this optimization scheme needs to fulfill the requirement of the switch and real network environment. The reduction in the update and time provided some more solutions, for example, caching flow entries, storage structure modification, and some algorithms proposed for the free spacing in TCAM [20,21,22,23].

As explained in the above paragraph, the flow-table cannot handle all necessary forwarding rule entries concerning enhancing the efficiency of the flow-table, as illustrated in Figure 4. More studies have been published to manage and control the flow-table rules using the adaptive time-out mechanism [24,25,26,27,28]. Additionally, some other solutions are designed to reduce the flow-table’s size by using the aggregation concept. Other solutions focused on splitting the rules and distributing them in the network based on device capacity. Another proposed method is to limit the switch’s concurrent forwarding rules and overhead. There are some machine-learning techniques to predict patterns for traffic flow and observe the proper flow being installed in the flow-table of the switch [29,30,31].

The multi-switching delay is also part of this discussion, which reduces the delay by combing and filtering rules in a global view. The size of the storage of switches varies and is used to constrain flow-entries for the fast updating speed of the flow-table in the entire network.

The table underneath shortly describes the comprehensive research.

Table 1. Comparison of the improvement of TCAM, flow-table, and flow-entry utilization.

SDN	Controller Placement	Scheme	Target	Zone
[29]	Reactive	Directed acyclic graph used to solve the replacement problem	Under the dependency-constraints replacement problem of TCAM	Distributed ACL
[30]	Reactive	Hidden Markov model using the Quine–McCluskey algorithm	Reduce the flow process time and manage-multiply the flow-table	Flow-table management
[31]	Proactive	“One big switch”	One big switch: using the forwarding element distribute rules	The distributed load balancer and ACL
[28]	Proactive	Split flow-tables into smaller tables and distribute them on the data layer	Minimize the TCAM shortage storage problem by distributing flow-rules	Distributed ACL
[3]	Reactive	SDN-HiIoT	The provision of QoS to mobile users is the same as the primary domain	Heterogeneous SDN domain flow-rule exchange
	Hybrid	IIF-SDN	SDN controllers use proactive, and switches use reactive approaches to reduce lookup efforts and enhance the TCAM functionalities	Fusion of different SDN domain flow-table management

is based, somehow, on the SDN controller placement approach, and the zone represents the area where researchers applied their proposed scheme and obtained the results in the target column of the table.

The above work is selected from different journals on SDN-based services and technologies. Researchers have proposed very considerable techniques and methods in various areas of SDN. However, existing schemes do not significantly impact the performance of a single switch and need to resolve the complete problem of update processes. For rapid updating and providing certain services to the specific user, new schemes are required that increase system functionality, provide an optimized solution, and impact the OpenFlow network performance.

3. Proposed Work

This research focuses on making the network dynamic by implanting the different SDN-domain flow rules in the current SDN domain without disturbing the existing users’ flow rules and services. The proposed scheme is developed to provide services to specific users of different SDN-domains. The TCAM was designed for fast lookup and packet matching but is less dense than the RAM and can store fewer bits in the same chip area. Therefore, it is hard to install multiple SDN-domain flow-rules on a single SDN-domain. We have proposed a scheme for the fast lookup of entries and high-speed flow-rule installations, especially for large-scale networks. It is obligatory to enable the switches to adapt to the new policy and provide quick responses to the newly registered user of different SDN domains. Figure 5 clearly describes how our proposed scheme facilitates the SDN components without adding hardware.

3.1. IIF-SDN Formulation

As already discussed in the introduction of this article, the SDN controller works on two basic concepts—the reactive and proactive approaches—for updating the flow-table in the switch based on the occurrence of certain events in the network. In the case of a reactive approach, the SDN controller does not install any flow-rule in the switch because it waits for the packet influx, then populates the rules accordingly and installs them on the switch [32,33]. On the other hand, the SDN controller installs the flow-rules in advance as the network begins the operation. The selection of the flow-rules has a significant value for enhancing the network performance, especially in large networks, such as data centers. In our proposed IIF-SDN, we have used a proactive approach. In this case, the SDN controller obtained all other SDN domain flow-rules in advance. This technique is used for the enhancement of the efficiency of the network.

In IIF-SDN, the SDN controller stores the flow entries after becoming priority-wise from the other SDN domains; high-priority entries are saved on the top of the list. Then, as the switch is requested for installation in the switch, the controller installs the customized flow-rules list on the switch, considering the priority of each entry). This technique reduces the lookup efforts in ACL and TCAM. Figure 6 shows the IIF-SDN proactive approach on the SDN controller layer.

3.2. Network Model

The set of SDN domains represented by “SDN_dom” and all flow-tables of one domain represented by “β” are shown in

Table 2. System Notations.

Notations	Description
SDNdom	SDN Domain
SDNC	SDN Controller
SDNSw	Switches
SDNSw-TCAM	TCAM
Β	Flow-table
frs	Flow-rules
µ	Flow-entry
βc	Controller’s Flow-table
frs-c	Controller’s Flow-rules

and explained in Equations (1) and (2).

$$SD{N}_{\mathit{dom}}={{\displaystyle \sum }}_{i=1}^{n}C, \mathrm{where} i=\left\{1, 2, 3\dots n\right\}$$

(1)

$${\rm B}={{\displaystyle \sum }}_{j=1}^{m}frs , \mathrm{where} j=\left\{1, 2, 3\dots m\right\}\hspace{1em}\beta \in SD{N}_{\mathit{dom}}$$

(2)

The new SDN_dom is registered in the network of SDN_doms; they share flow-rules with the newly registered SDN_dom (as shown in Figure 7). After obtaining f_rs, the new SDN_c sort “f_rs” on a priority base and organize all entries in the “β”, as shown in Equations (3) and (4).

βj = f_rs(1), f_rs(2), f_rs(3)… f_rs(m)

(3)

βj = f_rs(1) ≥ f_rs(2) ≥ f_rs(3)… f_rs(m−1) ≥ f_rs(m)

(4)

After increasing the SDN domains, Equation (1) is extended, as represented below (Equation (5)):

$$SD{N}_{\mathit{c}}={{\displaystyle \sum }}_{i=1}^{n+1}C, \mathrm{where} i=\left\{C1, C2, C3\dots Cn, C\left(n+1\right), C\left(n+2\right), C\left(n+3\right)\dots C\left(n+n\right)\right\}$$

(5)

Additionally, after increasing the SDN domains, the value of “m” will also increase by “m + 1”; then, Equation (2) of the flow-table is extended, as follows (Equation (6)):

Β = {β1, β2, β3… βm, β(m + 1), β(m + 2), β(m + 3)… β(m + m)}

(6)

Initially, calculate the “β” at “S_w” and differentiate the active flow-table β_act ∈ SDN_dom(B) and inactive flow-tables λ ∈ SDN_dom(B) (as shown in Equations (7) and (8)). In this equation, the flow-rule function “f()” has some operation in TCAM for the flow-entries to make them useful for the SDN controller and switches. Equations (9) and (10) make the space by removing “λ” from the SDN_Sw-TCAM(B) of the corresponding switch where i, j, and k represent the number of flow-tables, and n, m, and p are the maximum value of the flow-tables.

• Active flow-rules of the SDN_dom(B) switch:

$$f\left(SD{N}_{\mathit{Sw}-\mathit{TCAM}}\left(\mathrm{B}\right)\right)={{\displaystyle \sum }}_{j=1}^m\beta ; \mathrm{where} j=\left\{1, 2, 3\dots m\right\}, \beta \in SD{N}_{\mathit{dom}}\left(\mathrm{B}\right)$$

(7)

• Inactive flow-rules of the SDN_dom(B) switch:

$$f\left(SD{N}_{\mathit{Sw}-\mathit{TCAM}}\left(\mathrm{B}\right)\right)={{\displaystyle \sum }}_{k=1}^p\lambda ; \mathrm{where} k=\left\{1, 2, 3\dots p\right\}, \beta \in SD{N}_{\mathit{dom}}\left(\mathrm{B}\right)$$

(8)

For the new rule installation at SDN_Sw-TCAM(B), consider Equation (4). β_act are the existing rules of SDN_dom(B) and β_c are the new rules of the primary domain of the user followed by the SDN_C ∈ SDN_dom(B).

$$f\left({\beta }_{\mathit{act}}\left(B\right)\right)={{\displaystyle \sum }}_{j=1}^m\beta -{{\displaystyle \sum }}_{k=1}^p\lambda ; \mathrm{where} \beta \in SD{N}_{\mathit{dom}}\left(\mathrm{A}\right) \mathrm{and} \lambda \in SD{N}_{\mathit{dom}}\left(\mathrm{B}\right)$$

(9)

$$f\left(SD{N}_{\mathit{Sw}-\mathit{TCAM}}\left(\mathrm{B}\right)\right)=f\left({\beta }_{\mathit{act}}\left(B\right)\right)+{{\displaystyle \sum }}_{j=1}^m\beta c \in SD{N}_{\mathit{dom}}\left(\mathrm{A}\right)$$

(10)

As discussed above, the “f_rs“ are acquired from the heterogeneous SDN domains and organized at the controller level. Thus, this scheme is very lightweight for the SDN_dom by implanting the flow-rules in advance. The effectiveness and advancement of SDN are shown in the results section of the proposed scheme.

3.3. Approximation Algorithm

Algorithm 1 of the IIF-SDN scheme shows how the newly registered SDN controller will obtain the flow-rules “f_rs” from different SDN domains and will store them using a proactive approach. Furthermore, the IIF-SDN scheme arranges the flow-entries “µ” on the controller side, as shown in Algorithm 2. This scheme is designed to reduce the organization of the flow rules “f_rs” and the searching efforts at the SDN switch level. Here, we take an example between two SDN domains, “SDN_dom(A)” and “SDN_dom(B)”, as described in Algorithm 1.

Algorithm 1: For a new Mobile Node Serving SDN Domain

Data: SDN Controller and Switches Result: Flow-rules assignment to a single Mobile Node begin Initialization SDNdom = B; SDNC; SDNSw; SDNSw-TCAM; frs-c;//∈ SDNdom(B) MN ∈ SDNdom(A) for all SDNSw if (MN==New) //generate a “prob-request” to SDNC for installation of frs-c If (f(SDNC)== prob-request) execute Algorithms 2 and 3 else assign frs end

The supporting Algorithm 2 is designed to facilitate Algorithm 1, which provides services to arrange the “f_rs“ priority-wise.

Algorithm 2: Priority-Wise Sorting of Heterogeneous SDN Domains in the Serving SDN Domain

Data: flow-table in current SDN controller Result: permutation of flow-entries “µ” in flow-table priorities wise such that, //create and initialize an array for flow-entries arr[µ1] ≤ arr [µ2], arr [µ3] ≤ … arr [µm] Procedure Frs_priority(arr [],m) if(m ≤ 1) then return; else for i ←1 to m-1 do if (arr[µi]< arr[µm]) then swap (arr[µi], arr[µm]) end Frs_priority (arr [],µm-1]) end

The phenomenon of the switch in SDN is to match the packet with “µ” of the “β” as the packet arrives; if the packet does not match, the switch requests the controller to install or update the flow-table in the switch. Indeed, the SDN controller switches are homogeneous by nature. Thus, all switches are configured on a reactive approach in the IIF-SDN scheme because of the short storage of TCAM. The main advantage of this scheme is that all hybrid flow-rules “frs” of the SDN domains are available locally, thus can easily deploy on the data layer as required. Figure 8 shows the heterogeneous SDN_doms.

The primary SDN_dom of MN is “B”, and the serving SDN_dom is “A”. The frs of SDN_dom(B) have already been stored in the SDNc ∈ SDN_dom(A) controller’s repository under this scheme. The controller installs the frs at the corresponding SDN_Sw on request of the corresponding SDN_Sw. The proposed scheme and its algorithms are very effective and enhance the network capabilities without disturbing the performance of the SDNc, SDN_Sw-_TCAM, and existing network users.

Algorithm 3: Flow-Rule Integration in TCAM for the New Mobile Node

Data: SDN Controller and Switches Result: Flow-rules integration in serving SDN domain’s TCAM begin Initialization SDNc; SDNSw-TCAM; βc; λ; i; k; n; for all SDNSw do βact(A); λ[k];//∈ SDNSw-TCAM(A) β(B) [i];//∈ SDNc(A) n = i++; p = k++; while (n ≥ p)//n is top index of βc ∈ SDNc and p is top index of λ ∈ SDNSw-TCAM ∈ SDNdom(A) f(β(B)) + f(βact(A)) − ${{\displaystyle \sum }}_{k=1}^p\lambda \left(A\right)$ +  ${{\displaystyle \sum }}_{i=1}^m\beta c$;//where A and B represent domain A and domain B. end

Only one thing is added in this scheme that makes it distinguished. It accommodates the user as per its primary domain flow-table. The benefit is to enable the switch to work for all users without any anomaly of the rules. Moreover, the controller can organize the flow-tables of heterogeneous SDN domains.

After obtaining information about a new user’s registration in the network from the switch, the controller distinguishes the user’s domain and sends a request to the primary domains of the user for flow-rules. The user’s primary domain will send the upgraded and organized coy of the flow-rules to the controller. Then, the controller updates/installs the required flow-rules at the corresponding switch as shows in Figure 9.

Algorithm 3, designed for the SDN switches, clearly describes the story of the inner side of the switch and how the IIF-SDN scheme deployed and worked in switches. Under the proposed scheme, Figure 10 is the broader preview of the SDN domains, including hosts, switches, controllers, and other network components.

3.4. System Model

For the proposed IIF-SDN scheme experiment, software and packages are required to install, for example, processing power and memory size. Underneath,

Table 3. Experimental Environment.

Hardware/Software	Specifications
Processor	3.30 GHz
CPU	i5-4590
RAM	6 GB
OS	Ubuntu 20.04 (64-bit)
Virtual Network	Oracle VM VirtualBox, Mininet, MiniEdit
SDN Controller	RYU
Access Points	OVS (Open Virtual Switch) ovs_version 2.13.3
OpenFlow Messages	V1.3.0
Traffic Generator	IPerf v2.0.5
Type of Traffic	TCP and UDP

describes the environment for the experiments of the proposed scheme.

4. System Implementation and Experimental Demonstrations

The experiment of the IIF-SDN scheme is summarized in

Table 4. Experimental setup.

Scheme	Small System	Large System
Processing Time (ms)	0.28	0.28
Reactive (number of flows)	21,550	58,000
Proactive (number of flows)	22,220	60,998

, which is carried out on the small and large system environments separately. A small system experiment is based on two or three nodes only, and an extensive system is based on more than three nodes. Here, the node is considered an SDN domain which shares flow rules. We have separately passed “21,550 and 22,220” flows between the small system and “58,000 and 60,998” in the extensive system under reactive and proactive approaches, as shown in Table 4. We obtained the results of which showed the effectiveness and efficiency of the proposed scheme.

Numerous flow-tables can be stored in the SDN controller and can be installed on request of the switches in the data layer. The SDN controller communicates with the data layer using the south-bound/north-bound Application Programming Interface (API). A flow-entry is an element of the flow-table that matches and processes the packet. One SDN domain can have many flow-tables. If the SDN domains increase, then the flow-table also increases manifold. In the proposed scheme, we have shared flow-tables of all SDN domains with each SDN domain. Figure 11 and Figure 12 show the SDN domains, flow-table, and flow-table update cost at the SDN controller.

We have evaluated the updated cost of the flow-table. The increase in the SDN controller has a direct impact on flow-tables, as shown in Equation (11) below. The graph shows that the IIF-SDN scheme takes more time than the normal SDN domains; this is because we have processed the flow-table priority-wise in descending order on the SDN controller to avoid the switch labor.

$$f\left(\beta \right)={{\displaystyle \sum }}_{i=1}^n{C}^{\ast } f\left(SD{N}_{\mathit{Sw}-\mathit{TCAM}}\right); \mathrm{where} i=\left\{1, 2, 3, \dots n\right\}$$

(11)

Figure 13 and Figure 14 show the two nodes’ flow-rules and the multiple SDN nodes’ flow-rule exchange. Figure 15 and Figure 16 show the IIF-SDN result with the two and multiple nodes’ flow-rule exchange.

We analyzed, through an experiment, two SDN domains and multiple SDN domains under reactive and proactive approaches. The result is that after passing several flows, the proactive approach is more efficient than the reactive approach. However, there are better fits for our scenario than the reactive approach because this approach demands the flow-rules when it needs them, and the proactive approach stores them in advance.

We applied the experimental parameters to the IIF-SDN scheme; this scheme was found to be much better than the proactive approach of the SDN domain. The SDN controller worked proactively in our proposed scheme, and the switches used a reactive approach. This hybrid scheme resolved the flow-table management problems of TCAM and ACls. Figure 17 and Figure 18 show the flow-tables’ updating cost and overall performance.

The above graphs are generated based on simulation results. Initially, communication between all nodes of the proposed topology was established; then, some changes were made in the flow-tables and applied to the nodes of the network. After establishing the connections and some changes between nodes, data were transmitted from one domain to another, and the data transmission stats were achieved.

Once the flow-tables were arranged under the IIF-SDN priority rules, as defined, the complexity of the updating cost remained the least. The overall performance indicated that the results of the proposed scheme are efficient, even if there is an increase in users.

5. Conclusions

It is hard to handle the other SDN domain users’ requests for the provision of the same services in comparison to the primary SDN domain in the current domain. As discussed, the TCAM is already overloaded and has a low, dense storage element of the switch. Therefore, it is necessary to reduce the other activities of the switch related to the management of the flow-table and flow-entries. This paper proposed a solution for reducing the lookup activities of TCAM and managing the flow-rules at the switch level. The IIF-SDN scheme is designed to minimize the switch’s tasks. A proactive approach is used for the SDN controller to obtain all flow-rules of different SDN domains in advance, and a reactive approach is used for the switches. The proposed scheme is tested on two SDN domains and multiple SDN domains. The scheme is effective and efficient because the switches can obtain all flow-rules locally from the controller. Moreover, the controller arranged all flow-entries priority-wise and saved them in its repository. On the request of the switch, the SDN controller installs flow-rules from its repository for the specific user. The key findings of this paper are the incorporation of the hybrid flow-rule inside the SDN switch, packet transmission without any anomaly, parallel hybrid flow-rule execution, organized flow-entries, and the update process itself. Thus, the network data can be forwarded normally in the continuous update scenario. The proposed scheme is applied because of the quick response between the controller and switches to the service of continuously connecting the users of heterogeneous SDN domains; this is very substantial in maintaining and integrating the hybrid flow-rule in TCAM and ACLs of the switch. In the future, the SDN controller will be assisted by the server that will organize the same flow-tables of different SDN domains on the controller demand of flow-rules for mobile users.