Design the DNS-like Smart Switch for Heterogeneous Network base on SDN Architecture

2016 International Computer Symposium Design the DNS-like Smart Switch for Heterogeneous Network base on SDN Architecture Jih-Ching Chiu, An-Ting Liu*, Chien-Chin Liao* Department of Electrical Engineering, National Sun Yat-sen University Kaohsiung, Taiwan Email: chiujihc@ee.nsysu.edu.tw, *{m033010041, m053010053}@student.nsysu.edu.tw Abstract In the development of the Internet of Things (IoT) nowadays, there are a lot of wire and wireless communication standards. Therefore, heterogeneous network gateway plays an important role in IoT network. However, current management of the processing in data routing technique for heterogeneous network gateway is not efficient. Also, Modbus RTU is an industrial standard protocol used in physical layer network. Will cause the node ID conflict while slave nodes have the same identical number connected to the gateway. Furthermore, if traditional gateway is used in different network architecture, the adaptability will decrease because packet forwarding control plane and data plane have been in tight couple state. To deal with these problems, this paper uses software defined networking architecture to design the DNS-like heterogeneous network smart switch. Separating control and data plane through OpenFlow can make switch become more flexible. The Slave ID problem in Modbus heterogeneous network can be solved by using smart routing in smart switch. The node connected to smart switch has to be registered in smart switch first and managed by the node name. And use two methods the exchange data: Find Path by ID and Find Path by Name, proposed in this paper and unfixed string. It improves the connection experience substantially. Eventually, we implement the node registration flow, client connection flow and client data access through the OpenFlow module in NS3 and then show our algorithm result by using Wireshark. Keywords Software-Defined Networking, heterogeneous network, gateway, OpenFlow, DNS-like service. I. INTRODUCTION This paper investigates how to use the concept of naming to register IoT terminal devices. We proposed an integrated framework architecture based on Software-Defined Networking over Modbus protocol. Let user connecting to the IoT terminal devices more simple and internet manager deploying more flexible. Internet of Things (IoT) is a trend of future network. Everyone just use terminal device like mobile phone and PC to monitor or control the IoT terminal devices. Institute for Information Industry [1] proposed three layer of the IoT architecture: 1) Application Layer. 2) Network Layer. 3) Sensor Layer. We focus on the Sensor Layer, which is composed of sensor nodes and low power communication interfaces. User often used TCP packet to access data from the terminal devices so the data over TCP protocol has to covert to other protocol like ZigBee, Bluetooth or Modbus RTU protocol. Since These nodes have the different communication interfaces and protocols, the IoT nodes must exist in the heterogeneous network and linked together with heterogeneous gateway. About the heterogeneous gateway, a lot of articles discuss how to let nodes connect to the network. The Personal Belonging Network system (PBN system) [2], through device virtualization lets non-ip terminal devices have IP address. For instance, non-ip based computer (like sensor devices) send user-defined data that combined pseudo address with sensor data. Through PBN system, gateway receive sensor data, convert it to specific data format like TCP and analyze which pseudo device the data should be sent to. Although this method let sensor devices have ability to communicate with the Internet terminal devices, we propose several doubtful points for heterogeneous gateway: 1) Like PBN system, PBN gateway provides the service that lets data sent to the Internet from sensor nodes. However, the direction of data transfer is still one-way transmission. Actually, data may need to be transmitted from the sensor node to the Internet terminal devices, but terminal devices may not have ability to send back to the sensor node. This problem causes the devices or users cannot communicate with each other. 2) Generally speaking, gateway use communication chips or ICs to design their architecture. In this way, hardware chip can indeed improve the processing speed. However, the data plane and control plane coupled in one communication chip may not be able to adapt to future network architecture. Nowadays, since the increment of microprocessor processing rate and capacity of storage device like flash drives, we think there is a new way to make the gateway architecture more flexible. 3) As for heterogeneous gateway, it only has convert protocols service nowadays. We think the future gateway will communicate to the low-speed network device like ZigBee, Bluetooth etc., and not only has the convert protocols service but more and more service in the future gateway. For instance, gateway can connect to the sensor node by using naming mechanism [3,4] to identify every sensor node, or gateway can analyze the topology of the sensor network so that user just only need to use command or human machine interface to know how 978-1-5090-3438-3/16 $31.00 2016 IEEE DOI 10.1109/ICS.2016.44 187

many nodes have connected to the heterogeneous gateway and topology of the network. Modbus protocol is a standard industrial protocol used in the sensor layer of IoT for data monitoring. Using requestreply mechanism between master and slaves. In the heterogeneous gateway, it may have problem. Fig. 1 is a illustration of Modbus slave number conflict of the network over heterogeneous gateway. If different nodes have identical slave id due to the different network interfaces connected to the gateway at the same time, master cannot identify the direction of the send packet or receive packet. This problem will be solved by using the traditional concept of the Modbus gateway: Any interface and node cannot use same slave id after the device is connected to the Modbus gateway. But we proposed a better method to solve this problem: Find Path by Name. This method will be discussing in chapter III. Figure 1. Modbus slave id overlapping II. RELATED WORK For heterogeneous gateway architecture, Universal Plug and Play (UPnP) standard [5,6] is a good way for the heterogeneous network for the future. UPnP proposed three essential elements: 1) device, 2) service and 3) control point: Device means the device which has the UPnP service. Service provides several actions or state variables to record the current state of this service. For example, there is the action called time service, it has several state variables like seconds, minutes and hours, and actions like modify current time or get time etc. Control point is a device which has the authority to control the UPnP devices. It executes four services: 1) Get devices descriptions and services. 2) Get interest service and service descriptions. 3) Send command and actions to UPnP devices. 4) Subscribe the service which control point get interested in; control point will receive the acknowledge from subscribed UPnP device when the device changes the service s state variables. Fig. 2 shows the component of the UPnP. Figure 2. Component of UPnP UPnP standard has a great concept for the heterogeneous network. UPnP device will register to the control point before exchanges the data. If the device has registered to the control point, it can communicate between UPnP network devices instantly when the device connected to the UPnP network. UPnP registration requires several steps: 1) Addressing, 2) Discovery, 3) Description, 4) Control, 5) Event and 6) Presentation. First, UPnP device used DHCP request to get the dynamic IP address, and the control point will look around the device with or without adding to network. If there is a device has registered to this network, control point gets the device s description file and obtains the functions of the device, and then the control point can use action message to control the specific device. This method can manage sensor nodes more easily and flexible. Once nodes added into the local network, heterogeneous gateway can manage and control the terminal node through operating mechanism like UPnP. To solve the control plane and data plane coupled problem, Software-defined networking (SDN) [7,8] provides decoupling or disassociating solutions for the future network environment. In the traditional network, a forwarding device like switches or routers, used communication chips and TCAM to decide the forwarding path. But in some situations, network administrators can t manage the network service because of control plane and data plane coupled in the network communication chip. For example, when a host be invaded by a cyber-attack, network administrator may not know the where source comes from. It is difficult to analyze solution due to the limitation of the device hardware and software. Using software-defined network architecture can decouple the data plane and control plane, network administrator can use simple command or monitor program to control forwarding device. SDN let network administrator manage the network more flexible and efficient. Fig. 3 shows the SDN architecture. SDN mainly composed of three layer: 1) Application layer, 2) Control layer and 3) Infrastructure layer. Infrastructure layer, also called data plane, is decoupled by control layer, only has forwarding function, remove the packet analyzing and packet direction decision. About packet decision is handed by the control 188

layer. Control layer and infrastructure layer use southbound API like OpenFlow to communicate each other. OpenFlow is the first standard communications interface defined between the control and forwarding layer of and SDN architecture. It defined a lot of communication standards to allow direct access to and manipulation of the forwarding plane of network devices such as switch and routers. We use OpenFlow specification v0.8.9 [9] to build our smart switch architecture, and we will discuss more detail at the next chapter. Figure 4. System architecture TABLE I. NODE INFORMATION COMPONENTS Figure 3. Software-defined network architecture III. THE DNS-LIKE SMART SWITCH ARCHITECTURE A. System Architecture Fig. 4 shows the system architecture consisting of user, smart switch and terminal nodes. Smart switch has multiple interfaces, including Ethernet port, so that terminal nodes can use their specific interface to connect to the smart switch. Smart Switch has IP address and is registered to the DNS server. User just use smart switch s domain name could find location of the smart switch or control the smart switch. The smart switch provides two connection mode: 1) traditional Modbus connection mode and 2) node domain name connection mode, administrator can switch the connection mode through user-defined software. Every terminal node has non-repeating name; it doesn t matter users do not know the node s slave number. In addition, user also use slave node name to find the terminal node s location and send the Modbus packet to the specific node. Client and user can use the program which is designed by DNS Smart Routing Framework (DSRF). Once user input the smart switch s domain name, DSRF will ask the DNS server and find the smart switch s IP address. Then, user can access the terminal node through Modbus on TCP packet. We focus on terminal nodes, which support Modbus protocol. Node device administrator must add some information before deploy the Modbus slaves. Table I shows the information must be added into the Modbus slave devices, especially including the node name in the information memory. Node name is a string that maximum supports to eight characters. Smart switch will use node name to register this device. After registered, user can use non-fixed-length string to connect terminal nodes. Slave ID Node Information Interface Number Node Name MAC Address B. Smart Switch Architecture Smart Switch is composed of three important elements: 1) Smart Routing Controller, 2) OpenFlow hybrid switch and 3) Protocol convert module (PCM). Fig. 5 shows the smart switch architecture. Smart Routing Controller executes the packet decision. For example, OpenFlow controller uses OpenFlow protocol to transfer the decision command to OpenFlow hybrid switch. Smart Routing Controller includes DNS-like Smart Routing Framework to handle connected client, registered nodes and packet forwarding decision. Smart Routing Controller has a big storage named Node Information Database, storing every registered terminal node s information, and every node will be assigned a pseudo IP port after the terminal node is registered. OpenFlow hybrid switch consists of OpenFlow switch and traditional switch. OpenFlow hybrid switch has a flow table to store the flow which comes from Smart Routing Controller. OpenFlow hybrid switch has the advantage of a good compatibility. Although this switch support OpenFlow protocol, when it connects to the traditional forwarding device or hosts, it also supports the minimum spanning tree algorithm. Only thing needs to notice that the configuration of the controller must be able to support OFP_FLOOD output port. The protocol converts module, such as protocols in traditional gateway, and furthermore it adds a registration service. Protocol converting module filter the same cluster, a cluster means number of devices around the same interface port, if the same cluster has the same slave id devices. The registration operation will ignore the later added node. Registered information will be sent to the Smart Routing Controller by protocol converting module. 189

shows the format of the NURL, the red area of the format will be sent to the DNS server and the blue area of the format will be sent to the smart switch to analyze which node will receive the Modbus packet. Figure 7. NURL format Figure 5. Smart switch architecture C. Node Registration Flow As shown in Fig. 6, after booting up, node will enter a passive state and wait for broadcast packet. Once the node receive the registration message broadcasted from smart switch, node will extract node information from internal memory, send back to switch as reply and then set registered flag on. If the registered flag has already been set, node won t respond when receive registration message again. If the registration reply packet occurs error or node doesn t respond, the smart switch will ignore registration this time and wait for 500ms to start next registration broadcast. When receiving the registration message, smart switch will execute cluster node repeats registration mechanism to prevent duplication of nodes within a cluster. If all the information is correct, the message will be transmitted to the node registration information database nodes within the information table storage node to complete registration. Finally, we proposed a prerequisite condition. Because of the UART port doesn t have the CSMA/CD mechanism, UART devices must use Non-simultaneous boot when it adds to the smart switch. There is connection flow shown in Fig. 8: First, user will analyze the NURL via Modbus program to obtain original URL and node topology. Next, client will get smart switch IP and port from the DNS server through the URL, then connecting to the IP by Socket. During the connection process, the client socket management service in DSRF will manage user information, and send user s node topology to node name service in the DSRF, to look up node information. If the node name is registered in node information database, client will obtain the slave ID and virtual port from the node information table. Otherwise, smart switch will return failure message. Once getting the slave ID and virtual port, client will reconnect to the node, but using the virtual connection information transmission port number this time. Figure 8. The association modules in DNS-like connection mode Figure 6. The operation of node registration D. Client Connection Mode We proposed two client connection modes support to the smart switch: 1) Traditional Modbus connection mode and 2) DNS-like connection mode. We discuss the Traditional Modbus connection mode first. Client will get the smart switch IP through DNS server, and port number is Modbus dedicated connection number: 502. After user connect through a TCP Socket and smart switch, once connected successfully, OpenFlow controller will begin Flow build. When the Client Manager consents the connection, client information will be transmitted to the client management services of DSRF, stored in the internal of the client accept table. At this moment, the connection process is completely done, and then user can access the registered node. The DNS-like connection mode use Node Uniform Resource Locator (NURL) to connect the smart switch. Fig 7. E. Data Access Data access also has two modes, the traditional mode and DNS-like mode. When user establishes a connection, smart switch routing mode will depend on data access mode. If user uses traditional mode, switch will get interface and routing path based on Slave ID, we call Find Path by ID; In contrast to traditional mode, DNS-like mode will acquire virtual port for packet routing through node name, we call Find Path by Name. In Find Path by ID, once client connects to destination port number 502 of smart switch, client manager in smart switch will accept requests sent from client. After that, there are two actions: One is to copy and send the packet to Modbus packet analyzer to extract ID and convert the ID to private IP address of the gateway device through Lookup Table Service; the other one is to add client ID in the client accept table, the purpose of which is to recognize the destination when PCM 190

returns. Finally, the packet is transmitted to the terminal node via the PCM socket of node information manager. In Find Path by Name, first, user will get a virtual port to send the packet during the process of connection established. However, OpenFlow hybrid switch can t recognize the first packet sent from client, so it will send it to the Smart Routing Controller which will create a matching key to compare packet header and node information. When it finds the virtual port matched in the vport table, Smart Routing Controller will make a flow to the OpenFlow hybrid switch to modify the destination IP address, port number and destination MAC address of the packet in forwarding plane and send the output port command to the switch. Eventually, the Modbus packet will be forwarded to specific port of the switch. IV. TEST RESULTS AND DISCUSSION We used Network Simulation 3 (NS3) to simulate our architecture. The simulation result shown in Fig. 9 and Fig. 10, in Fig. 9, after Host obtains the node name, given by the virtual port number (port number: 10000) to send data to the smart switch, smart switch will change the destination of PCM s TCP port number through Smart Routing Controller, and send Modbus request to the terminal node. We can find the No. 18 of the packet in Fig. 9, it comes from user, and destination is smart switch. And the content of packet data is: from the device whose slave id is 1 and read the holding register data from number 40006 to offset 5 units. Figure 9. The result of data access from Wireshark (Modbus request) Shown in Fig. 10, in the number 22 of the packet, we find the Modbus reply from smart switch, and get the holding register data from the terminal devices. Figure 10. The result of data access from Wireshark (Modbus reply) V. CONCLUSION We proposed the smart switch architecture using SDN conception, solve the network closed coupled and let it more flexible, Finally, we design our OpenFlow module on NS3 platform, and successfully simulate process of node registering and user connection. In the simulation, we can observe user get packets from nodes through Wireshark. In future, we hope we can not only implement this plane on real device but also specifically extend Node Information Database by extending node topology or smart switch topology, and analyzing topology structure to make it become a smart device applied in IOT. REFERENCES [1] Instutute for Information Industry, iii, http://www.iii.org.tw/. [2] Hiroshi Sakakibara, Jin Nakazawa, Hideyuki Tokuda. A Seamless Network Infrastructure of heterogeneous network nodes 2009. [3] Zhang, Lixia, et al. "Named data networking." ACM SIGCOMM Computer Communication Review 44.3 (2014): 66-73. [4] Zhang, Lixia, et al. "Named data networking (ndn) project." Relatório Técnico NDN-0001, Xerox Palo Alto Research Center-PARC (2010). [5] Chin-Ta Lin; Pu-Chen Wey, Chun-Chou Chien. An Integrated Service Architecture for Heterogeneous Service Network, ICL Technical Journal, 2006. [6] UPnP Forum. UPnP Device Architecture v.2.0, 2015. [7] McKeown, Nick, et al. "OpenFlow: enabling innovation in campus networks." ACM SIGCOMM Computer Communication Review 38.2 (2008): 69-74. [8] ONF, "Software-Defined Networking: The New Norm for Networks", Whitepaper, April 2012. [9] ONF, OpenFlow Switch Specification Version 0.8.9, December 2008. 191