# A Design for SDN-Based Identifier-Locator Separation Architecture on IoT Networks
## 3 Proposed SDN-Based Identifier-Locator Separation Architecture for IoT Networks
### Proposed Architecture  
In the proposed scheme, the underlying network is partitioned into a local EID domain and a global IP domain, and the network consists of OpenFlow-enabled switches (OFSs) and access routers (ARs) that are equipped with the functions of SDN controllers. The network resource is virtualized to accommodate the local EID domain and global IP domain. Figure 1 shows the proposed network architecture in which the local domain is overlaid onto the IP domain.  
LOCs, the global addresses, are transmitted via the IP domain by using common IP routing, through ARs with a local mapping controller (LMC) [26; 27]. The general IPv6 address packets are forwarded to a destination as in SDN environments. In contrast, the local EID domain is used to deliver packets that have the address field with an EID. The local EID domain is a virtual d-dimensional Cartesian coordinate space as shown in a DHT-based CAN network [11]. The EID domain is logically overlaid over the IP network and bears no relation to any physical coordinate system.  
In the EID domain, the virtual coordinate space is used to store and maintain the \(<\) EID, LOC \(>\) pairs on the controller. The entire virtual coordinate space is dynamically divided into the number of controllers in the system. All EIDs are distributed to EID blocks consisting of blocks, the number of which is equal to the number of zones, and each EID block is assigned to each zone. An AR with an LMC is located in each zone, and each AR is responsible of taking care of the allocated EID block and MNs that have EIDs. Also, these ARs are responsible to register EID-LOC mapping information. All ARs of the local EID domain own their individual, distinct zone within the space, and they manage the \(<\)EID, LOC\(>\) pairs using the DHT mechanism. The ARs have the following functions: first, network attachment detection; second, mapping the LOC to the EID of the MNs and updating the EID-LOC mapping; third, mapping information maintenance and management; and last, flow table configuration for EID routing.  
PMIPv6 assumes that a link layer protocol notifies the mobile access gateways (MAGs) about the MN's identifier to detect the MN's attachment and to acquire the MN's identifier when the L2 authentication process is finished. The same assumption of the detecting an MN in the PMIPv6 is utilized in the proposed scheme. After the detecting process, the generation of the MN's EID and LOC is possible at ARs.  
For the maintenance and updating of EID-LOC mapping information, the local EID domain utilizes key registration, lookup, and routing mechanisms from the CAN [11]. When an AR detects an  
Figure 1: System architecture of the proposed scheme.  
MN's attachment, the AR is able to generate an MN's EID and LOC, and \(<EID_{MN}\), \(LOC_{MN}>\) pair. The AR stores the \(<EID_{MN}\), \(LOC_{MN}>\) pair to its binding cache only if the \(EID_{MN}\) is included in the range of an EID block that is maintained by itself. In this case, the EID has a responsibility for maintaining this MN and replying to the corresponding LOC when the other ARs request the LOC of the MN. If the \(EID_{MN}\) is located outside the range of the attached AR's EID block, the AR stores the binding information in its binding update list. After that, the AR registers the \(<\) EID, LOC \(>\) pair to the AR that is responsible to maintain that pair. The updating procedure is also similar.  
All the ARs in the system have to preconfigure the flow table of their OFSs. Through this pre-configuration, the ARs can obtain the route for the EID packets to the nearest zone to get the destination of the packet, and OFSs are able to forward EID packets to OFSs of the nearest zone.