# A Design for SDN-Based Identifier-Locator Separation Architecture on IoT Networks
## 3 Proposed SDN-Based Identifier-Locator Separation Architecture for IoT Networks
### Main Procedure
#### 3.4.2 Route Optimization Process  
When the packets are forwarded with the established routes, the packets are always passed to the OFSs of the CN's AR through the routes which include several intermediate OFSs that are located in the MN's AR and the CN's h_AR. The routes established via the IP domain are optimized by IP routing, but all of the routes from the MN to the CN may not be. If the interconnected OFSs between the MN and the CN have the appropriate flow table entries for forwarding packets through the IP domain, it is clear that the entire route from the MN to the CN will be optimized. During the packet forwarding process, the MN's s_AR does not have information about the CN, so it sets a flow table entry to its OFSs and forwards the packet to the n_AR that is adjacent to the CN. At this stage, the MN's s_AR also sends a query request to the CN's AR by using its EID as the source address and the CN's EID as the destination address to get the CN's LOC. If the destination CN is in  
Figure 2: Registration and packet forwarding processes. the local domain, similar to the registration process, then the n_ARs transmit the query request to the CN's AR. After the CN's AR receives the query request, it verifies the validity and sends a reply to the s_AR with the LOC. After the s_AR receives the reply, the AR is able to save the CN's <EID, LOC> mapping information. It gives orders to the OFS that is connected to the CN for adding or modifying the flow table entries. The orders include an action set that converts the destination address field from the CN's EID to the CN's LOC and changes the out port of the packets. If the CN's EID does not exist on EID blocks in the local domain, then the CN is located in the other domain. The s_AR verifies the validity of the EID, and, if the EID is not invalid, it requests query to the other domain through the IP domain. In this case, the CN's EID cannot be used for the destination address field within the SN's local domain because the CN's EID is only allowed to be used within the CN's local domain. After receiving the reply, the LMC of the AR which has a role of the gateway (GW) updates its flow table entries, and it sends the reply to the s_AR. Then, the s_AR gives an order to its OFS to update its flow table entries. When the route optimization (RO) process ends, the packets toward to the CN can be directly forwarded between the OFSs of the MN and the CN via the IP domain. Algorithm 2 describes the RO processes between the MN and the CN, and Figure 3 shows the packet forwarding after RO. In order to provide an optimized path between the MN and the CN, a route optimization algorithm for the AR was designed, as shown in Algorithm 2, and it should be inserted at the end of the AR in Algorithm 1. ```
1:Require: the AR acts as s_AR
2:if pktsrc is in BindingUpdateList then
3: send EID query request to pkt:dst
4:else if pkt:dst is MY EID ADDRESS(EID of s_AR) then
5:if pkt:type is EID query reply then
6: add a flow table entry (pkt:dst \(\rightarrow\) pkt:loc)
7:else
8: drop packet
9:endif
10:else
11: if pkt:dst is in MY EID address block then
12: if pkt:type is EID registration request then
13: add <EID,LOC> to BindingCache; add a flow table entry(pkt:EID \(\rightarrow\) pkt:LOC)
14: send EID registration reply to pkt's src
15:endif
16:endif
17:Require: the AR acts as h_AR
18:if pkt:dst is in MY EID ADDRESS BLOCK then
19:if pkt:type is EID query request then
20: lookup BindingCache(pkt:dst); send EID query reply with (LOC\({}_{MN}\)) to pkt.src
21:else
22: drop packet
23:endif
24:else
25: if pkt:dst is not in MY EID address block then
26: LOOKUP EID routing table(dst) for next hop port(D); add a flow table 27: entry (EID\({}_{MN}\), D)
28: Packet-Out(pkt)
29: else
30: drop packet



+++ ==WARNING: Truncated because of repetitions==



++

## 4 Cost Model Analysis

For calculating costs for signaling and packet forwarding, we configured the network topology, as shown in Figure 4, based on [28]. The network consists of six ARs and six OFSs with two MNs.