Function-Oriented Networking and On-Demand Routing System in Network Using Ant Colony Optimization Algorithm

In this paper, we proposed and developed Function-Oriented Networking (FON), a platform for network users. It has a different philosophy as opposed to technologies for network managers of Software-Defined Networking technology, OpenFlow. It is a technology that can immediately reflect the demands of the network users in the network, unlike the existing OpenFlow and Network Functions Virtualization (NFV), which do not reflect directly the needs of the network users. It allows the network user to determine the policy of the direct network, so it can be applied more precisely than the policy applied by the network manager. This is expected to increase the satisfaction of the service users when the network users try to provide new services. We developed FON function that performs on-demand routing for Low-Delay Required service. We analyzed the characteristics of the Ant Colony Optimization (ACO) algorithm and found that the algorithm is suitable for low-delay required services. It was also the first in the world to implement the routing software using ACO Algorithm in the real Ethernet network. In order to improve the routing performance, several algorithms of the ACO Algorithm have been developed to enable faster path search-routing and path recovery. The relationship between the network performance index and the ACO routing parameters is derived, and the results are compared and analyzed. Through this, it was possible to develop the ACO algorithm.


Introduction
As the era of new communication such as 5G era comes, it is expected that there will be a lot of services that cannot be compared with what existed before.Examples include Internet of Things (IoT) [1], in which everything in everyday life is connected to the Internet, such as a refrigerator and a TV that can be remotely controlled, and services such as Tactile Internet.These services have network requirements [2,3].
The term Internet of Things was first introduced by Kevin Ashton in 1999 [4].IoT network means that things such as sensors are connected to the internet and is freely controllable from the remote.Internet of Things is regarded as one of the emerging technologies in IT.This will enable new services [5].It requires new network characteristics accessing for a high number of devices.
Tactile Service or Tactile Internet is that providing real-time interactions with low delay that humans cannot recognize [6,7].If Tactile Service is realized, many novel services will appear: remote health care, virtual reality, robotics, etc.Each service needs a different delay.
The network requirements for these new services are difficult to achieve at once.So, the core technology of future network proposed in 5G is to be able to dynamically and quickly provide the requirements of such a network [2,3].However, 5G's core enabling technologies, SDN and Network Functions Virtualization (NFV) [8], are designed exclusively for network administrators or managers.This is a powerful solution to many problems, but there are still problems that cannot be solved at the same time.In this paper, we investigate what these problems are and present functional-oriented networking as a solution and complement.
In Section 2, related works are described.In Section 3, Function-Oriented Networking is proposed and how to implement it is explained.In Section 4, we illustrate how to implement Routing using ant colony optimization as FON Function.In Section 5, the previous FON Function is evaluated and network performance analyzed.

OpenFlow
OpenFlow is the most well-known SDN project.It started with the paper [9].Their initial purpose is providing the testing platform for a new experimental network protocol.These days, many papers focus on network centralization characteristic of OpenFlow.The most popular SDN controller-related projects are ONOS and OpenDaylight [10,11].

NFV
NFV strands for Network Function Virtualization.Ref. [12] states that "Network Functions Virtualization aims to transform the way that network operators architect networks by evolving standard IT virtualization technology to consolidate many network equipment types onto industry standard high volume servers, switches and storage, which could be located in Datacentres, Network Nodes and in the end user premises".

Network Slicing
Network slicing may be comprehended in many ways, but it can be accepted as the concept that the portion of all resources including network switches and routers in networks can be allocated for a specific purpose.Also, the allocated network slicing is designated for a specific service.Many papers and projects said that it is the key to make a network more flexible.
One of the old projects related to network slicing is the GENI Project.According to [13], "GENI (Global Environment for Network Innovations) provides a virtual laboratory for networking and distributed systems research and education".

Quagga
According to [15], "Quagga is a routing software suite, providing implementations of OSPFv2, OSPFv3, RIPv1 and v2, RIPng and BGP-4".Zebra, which is the core module of Quagga, abstracts OS layers and provides many APIs for table-driven routing protocols.If some routing protocols like RIP or BGP is needed, it can be easily run.Also, if it is not needed, it can be stopped.From this point of view, Quagga is called as a "virtual routing system".Quagga is an open source project distributed under the term of GPL; you can easily acquire the full source code from [15].

Function-Oriented Networking
Related-works above SDN and NFV are all researches for network managers.OpenFlow is a technology which separates date-plane from control-plane so that a network manager can easily control the entire network.NFV is a technology that is actively deploying a network function such as Deep Packet Inspection (DPI), Firewall, even mobile communication equipment-eNode B, Mobility Symmetry 2017, 9, 272 3 of 25 Management Entity (MME), and Home Subscriber Service (HSS)-according to a network manager's requirement.Because such technologies (SDN, NFV) are designed entirely for network managers, some requirements of network users are hard to meet.For instance, Quality of Service (QoS) policies are decided/set by network managers.Thus it could be different from network users' requirements.In addition, if network users' requirements are reflected only through network managers, immediate policy change is impossible when needed.In this context, existing technologies have unsolvable problems when these are taken into the network managers' point of view.
This paper proposes a novel user-centered network to solve the problems mentioned above: Function-Oriented Networking (FON).The network element supporting FON in a network is defined as FON Switch.Assume that the FON Switch can handle such a complex process including OpenFlow and classical functions (sort of Router, L2 Switch).In each FON Switch, FON is being processed as depicted in Figure 1.Multiple FON Functions can be operated.FON Function is defined as a network function which processes something not specific.It can run classic routing protocols such as RIP and OSPF.This aspect is similar with NFV.However, FON enables network users to change network policy; FON Function can be dynamically deployed/deactivated on FON Switch by network users.Figure 2 shows this scenario.Assume that: (1) a network user begins a new service.This new service needs the network policy corresponding to it; (2) this service requires End-to-End Delay to be the lowest.Then, by using FON system, network users can apply new policy that is matched to each Service's characteristic immediately by deploying New FON Function to each FON Switch.Because such technologies (SDN, NFV) are designed entirely for network managers, some requirements of network users are hard to meet.For instance, Quality of Service (QoS) policies are decided/set by network managers.Thus it could be different from network users' requirements.In addition, if network users' requirements are reflected only through network managers, immediate policy change is impossible when needed.In this context, existing technologies have unsolvable problems when these are taken into the network managers' point of view.This paper proposes a novel user-centered network to solve the problems mentioned above: Function-Oriented Networking (FON).The network element supporting FON in a network is defined as FON Switch.Assume that the FON Switch can handle such a complex process including OpenFlow and classical functions (sort of Router, L2 Switch).In each FON Switch, FON is being processed as depicted in Figure 1.Multiple FON Functions can be operated.FON Function is defined as a network function which processes something not specific.It can run classic routing protocols such as RIP and OSPF.This aspect is similar with NFV.However, FON enables network users to change network policy; FON Function can be dynamically deployed/deactivated on FON Switch by network users.Figure 2 shows this scenario.Assume that: (1) a network user begins a new service.This new service needs the network policy corresponding to it; (2) this service requires End-to-End Delay to be the lowest.Then, by using FON system, network users can apply new policy that is matched to each Service's characteristic immediately by deploying New FON Function to each FON Switch.What follows is each Enabling technology needed to realize such FON.The first one is OpenFlow.As a matter of fact, the network manager is not a critical point in the first article of OpenFlow.Rather, Ref. [9] proposed a 5-Tuple by analyzing common functions need to realize QoS, Firewall for each vendor.It tried to develop a network switch where various experimental policies can be applied by using the open-API OpenFlow.This paper focuses on the early OpenFlow philosophy that could be a useful tool to realize a policy for constructing a Programmable Network.The second one is a Network slicing technology that can fulfill FON.If network users can totally control the network resources on the network, a serious security problem can be caused.This problem can be solved if a certain amount of resources is assigned through network slicing.Because such technologies (SDN, NFV) are designed entirely for network managers, some requirements of network users are hard to meet.For instance, Quality of Service (QoS) policies are decided/set by network managers.Thus it could be different from network users' requirements.In addition, if network users' requirements are reflected only through network managers, immediate policy change is impossible when needed.In this context, existing technologies have unsolvable problems when these are taken into the network managers' point of view.This paper proposes a novel user-centered network to solve the problems mentioned above: Function-Oriented Networking (FON).The network element supporting FON in a network is defined as FON Switch.Assume that the FON Switch can handle such a complex process including OpenFlow and classical functions (sort of Router, L2 Switch).In each FON Switch, FON is being processed as depicted in Figure 1.Multiple FON Functions can be operated.FON Function is defined as a network function which processes something not specific.It can run classic routing protocols such as RIP and OSPF.This aspect is similar with NFV.However, FON enables network users to change network policy; FON Function can be dynamically deployed/deactivated on FON Switch by network users.Figure 2 shows this scenario.Assume that: (1) a network user begins a new service.This new service needs the network policy corresponding to it; (2) this service requires End-to-End Delay to be the lowest.Then, by using FON system, network users can apply new policy that is matched to each Service's characteristic immediately by deploying New FON Function to each FON Switch.What follows is each Enabling technology needed to realize such FON.The first one is OpenFlow.As a matter of fact, the network manager is not a critical point in the first article of OpenFlow.Rather, Ref. [9] proposed a 5-Tuple by analyzing common functions need to realize QoS, Firewall for each vendor.It tried to develop a network switch where various experimental policies can be applied by using the open-API OpenFlow.This paper focuses on the early OpenFlow philosophy that could be a useful tool to realize a policy for constructing a Programmable Network.The second one is a Network slicing technology that can fulfill FON.If network users can totally control the network resources on the network, a serious security problem can be caused.This problem can be solved if a certain amount of resources is assigned through network slicing.What follows is each Enabling technology needed to realize such FON.The first one is OpenFlow.As a matter of fact, the network manager is not a critical point in the first article of OpenFlow.Rather, Ref. [9] proposed a 5-Tuple by analyzing common functions need to realize QoS, Firewall for each vendor.It tried to develop a network switch where various experimental policies can be applied by using the open-API OpenFlow.This paper focuses on the early OpenFlow philosophy that could be a useful tool to realize a policy for constructing a Programmable Network.The second one is a In order to implement the FON proposed in this study to run on real network devices, and additionally to conduct experiments using ACO in FON, we built a physical device-based test bed.The test bed was tested by running a software image that implements the FON function on the Linux operating system on real Raspberry Pi Single Board Computer (SBC).The FON is designed to operate on Layer 3 IP protocols and layer 2 Ethernet, Bluetooth, and WLAN.For this purpose, a function to receive and forward FON messages in layer 2 upper layer and layer 3 upper layer has been developed.The reason for using Raspberry Pi in building a testbed is because you can construct a large-scale real network, and you can directly create network devices that send and receive traffic.However, it is relatively inexpensive and offers the advantage of being able to operate the same as real network equipment.In addition, it supports OVS to support OpenFlow, and it is possible to receive control of the actual SDN controller.In the case of the OpenFlow controller, ONOS was used, and the configuration and performance evaluation of the various shapes considered in the papers were performed through the corresponding test bed.In addition to wired Ethernet, wireless networking has been experimented with.

FON Identifier
Each Node can have several physical interfaces.To represent these interfaces, the Unique Identifier is needed.So FON Identifier is defined as the Unique Identifier and assigned to each FON Switch.For the compatibility with existing OSPF for IPv4 and IPv6, FON ID have a length of 32 bits, which is the same length of router ID in OSPF.For FON Adv packet, its purpose is to synchronize and notify adjoining nodes, which is similar to LLDP.FON Adv packet uses ETH_P_FON_ADV(0xFF03) as a ethertype field.This type of packet is generated and received only through FON, not by FON Function.

FON Forwarding
FON data packet is a packet for FON Function.FON Function exchanges each other using it.FON data packet uses ETH_P_FON(0xFF05) as a ethertype field.Figure 3 shows the design of packet.Each field is described in Table 1.

Telecommunication Design between FON and FON Function
There are two communication messages/channels between FON and FON Function.One is Synchronous message/channel, where FON Function asks for FON and FON sends a response.The other one is Asynchronous message/channel, where FON Function is notified when some event occurs.

For Synchronous Message
All kind of messages in this type are messages that request to FON from FON Function.They have a typical Request-Response design.Figure 4 shows the format of Request message.Table 2 represents the definitions of every field.Table 3 lists all message types and describes them.Figure 5 shows the format of response message.Table 4 represents the definitions of response message's every field.

Telecommunication Design between FON and FON Function
There are two communication messages/channels between FON and FON Function.One is Synchronous message/channel, where FON Function asks for FON and FON sends a response.The other one is Asynchronous message/channel, where FON Function is notified when some event occurs.

For Synchronous Message
All kind of messages in this type are messages that request to FON from FON Function.They have a typical Request-Response design.Figure 4 shows the format of Request message.Table 2 represents the definitions of every field.Table 3 lists all message types and describes them.Figure 5 shows the format of response message.Table 4 represents the definitions of response message's every field.

Telecommunication Design between FON and FON Function
There are two communication messages/channels between FON and FON Function.One is Synchronous message/channel, where FON Function asks for FON and FON sends a response.The other one is Asynchronous message/channel, where FON Function is notified when some event occurs.

For Synchronous Message
All kind of messages in this type are messages that request to FON from FON Function.They have a typical Request-Response design.Figure 4 shows the format of Request message.Table 2 represents the definitions of every field.Table 3 lists all message types and describes them.Figure 5 shows the format of response message.Table 4 represents the definitions of response message's every field.

Field Description result
Inform success of failure to the request.0 for success, error codes for failure tot_len Inform entire response length including header error_string Inform specific error type in text when occurring an error data notify all other information except success or failure to FON Function (filled in target field)

For Asynchronous Message
All kind of messages in this type are messages which notify FON Functions when some event occurs in FON.In this context, an event is such that: change of FON ID, FON Forward Table, etc.Typical Asynchronous message is passing FON data packets to a FON Function according to func_type filed in FON packet.

FON Function-Ant Colony Optimization Routing in Network
The previous section explains that OpenFlow is a novel technology and it can do many things such as QoS Policy.But it has a limit; many papers only focus on the perspective of central managing but not the needs of users such as datacenter, game server, etc.To overcome the limit of OpenFlow, this paper proposes and illustrates FON and its architecture.This section will discuss FON function and its implementation in a specific condition.
Assume that a certain network service, such as a real-time game server, needs two requirements: (1) minimum End-To-End Delay; (2) Fast path recovery if a link failure occurs.In this case, it is reasonable to choose ACO algorithm as a routing, because the ACO algorithm has these characteristics.
Actually, ACO routing does not minimize the delay of transmission but the distance (hops) of a source and destination [16,17].But, if a packet passes though the shortest path, then we can assume that the first sentence is true because if all network elements have same performance, the assume is true.
In the rest of this section, the ACO algorithm background is explained.Then, how to implement ACO routing in the Ethernet network is illustrated.

Background
ACO was first studied and established by M. Dorigo.It observes ants' behavior and imitates it.The original study of ACO algorithm was to solve TSP or vehicle routing problems and network routing problems.Especially, ACO is expected to be a good solution for dynamic topology and ad-hoc networks such as mobile ad-hoc network (MANET) [18][19][20][21][22][23][24][25].
Compared to the existing network, MANET has different characteristics.So existing proactive routing protocol has disadvantages in MANET; dynamically forming network, no infrastructure, etc.To overcome these problems, the reactive routing protocol such as DSDV, TORA, and AODV was proposed [26].However, refs.[18,19,27] showed that novel routing algorithms that applied the ACO algorithm can be more effective than AODV or DSR.According to our research [16,[18][19][20][28][29][30][31][32], most of the papers were studied using a simulator, and there is no ACO routing implementation for the real network.But this paper focuses on the real network routing problem, so our first objective is the implementation of ACO routing agent running in the complex enough but not dynamic topology real network.We will propose algorithms which are powerful when the assumption holds, analyze them, and evaluate their performance using our ACO routing agent.

FON Function-Ant Colony Optimization Routing in Network
The previous section explains that OpenFlow is a novel technology and it can do many things such as QoS Policy.But it has a limit; many papers only focus on the perspective of central managing but not the needs of users such as datacenter, game server, etc.To overcome the limit of OpenFlow, this paper proposes and illustrates FON and its architecture.This section will discuss FON function and its implementation in a specific condition.
Assume that a certain network service, such as a real-time game server, needs two requirements: (1) minimum End-To-End Delay; (2) Fast path recovery if a link failure occurs.In this case, it is reasonable to choose ACO algorithm as a routing, because the ACO algorithm has these characteristics.
Actually, ACO routing does not minimize the delay of transmission but the distance (hops) of a source and destination [16,17].But, if a packet passes though the shortest path, then we can assume that the first sentence is true because if all network elements have same performance, the assume is true.
In the rest of this section, the ACO algorithm background is explained.Then, how to implement ACO routing in the Ethernet network is illustrated.

Background
ACO was first studied and established by M. Dorigo.It observes ants' behavior and imitates it.The original study of ACO algorithm was to solve TSP or vehicle routing problems and network routing problems.Especially, ACO is expected to be a good solution for dynamic topology and ad-hoc networks such as mobile ad-hoc network (MANET) [18][19][20][21][22][23][24][25].
Compared to the existing network, MANET has different characteristics.So existing proactive routing protocol has disadvantages in MANET; dynamically forming network, no infrastructure, etc.To overcome these problems, the reactive routing protocol such as DSDV, TORA, and AODV was proposed [26].However, refs.[18,19,27] showed that novel routing algorithms that applied the ACO algorithm can be more effective than AODV or DSR.According to our research [16,[18][19][20][28][29][30][31][32], most of the papers were studied using a simulator, and there is no ACO routing implementation for the real network.But this paper focuses on the real network routing problem, so our first objective is the implementation of ACO routing agent running in the complex enough but not dynamic topology real network.We will propose algorithms which are powerful when the assumption holds, analyze them, and evaluate their performance using our ACO routing agent.

Ant Density
Ant Density model [29] has the characteristic that the pheromone is updated without considering any distance or length concept like the length of the path that an ant passed.Therefore, the pheromones of all nodes an ant passed are increased by the same amount.The model is represented in where Q is a constant, ρ is an evaporation rate of the pheromone.

Ant Quality
Ant Quality model [16] considers the distance of neighbors when updating the pheromone.So unlike Ant Density model, the pheromone updating is influenced by the distance, and the pheromones of all nodes an ant passed are increased by each specific amount.But this model does not consider the total length of the path; the optimization is accomplished locally.So in some bad cases, this model cannot find the optimized path.The model is represented in: where Q is a constant, ρ is an evaporation rate of the pheromone and d i,j is a distance between neighbor nodes i and j.

Ant System
Ant System model [16] is an advanced model of Ant Quality.Unlike Ant Quality model, this model considers the total length of the path that an ant passed.So this model reflects the global information and updates the pheromones using this; the performance is better than the Ant Quality model's.However, there is a disadvantage.If the pheromones of the nodes are far from a source node, they are very slowly converged.The model is represented in: where Q is a constant and L is the tour length of the ant, ρ is an evaporation rate of the pheromone.

Ant-Q
Ant-Q model [33] is the Ant Colony Optimization Model applied to the Q-learning algorithm.The significant characteristic of this model is that it does not only consider neighbor nodes, but also next-next nodes.Because of this feature, non-adjacent nodes also must be taken into consideration and this non-adjacent node information should be exchanged to implement this model in real networks.For this, our previous work concluded that it is improper in the real network because exchanging the pheromone tables has a very high cost.The model is represented in: where J j (i) is to be visited nodes of the given ant k at node i.Any Colony System [17,34] is a very similar model with Ant System.But it updates the pheromone only when the ant passed the optimized path.With the simple principle, the performance is better than Ant System's.
if given ant came from the optimized path 0, else Every ant knows that he passed the optimized path or not.So every ant must share the information and the colony (also called node) keeps information as a pheromone table.Ref. [14] called this "communication".

The Structure of the Pheromone Table
To apply a ACO algorithm into a network routing problem, Ref. [28] suggested a data structure to represent pheromone information-the pheromone table.According to [28], the pheromone table consists of rows-destinations and columns-neighbors.The table structure is depicted in Figure 7.In the rest of this paper, the concentration of a pheromone is represented as τ D,i when given a destination D and a neighbor node i.Every ant knows that he passed the optimized path or not.So every ant must share the information and the colony (also called node) keeps information as a pheromone table.Ref. [14] called this "communication".

The Structure of the Pheromone Table
To apply a ACO algorithm into a network routing problem, Ref. [28] suggested a data structure to represent pheromone information-the pheromone table.According to [28], the pheromone table consists of rows-destinations and columns-neighbors.The table structure is depicted in Figure 7.
In the rest of this paper, the concentration of a pheromone is represented as , when given a destination D and a neighbor node .

Source Update
Ref. [20] proposed a Source Update algorithm which suggests new ways to update pheromones.Figure 8a illustrates the way pheromone update in general ACO algorithm.In this paper, the way will be called as Destination Update.Destination Update works this process: (1) select a neighbor node which ant will go through.The selected neighbor node will be called neighbor_out; which is a concentration of pheromone in the pheromone table given a pair of destination and neighbor_out.But Source Update works in slightly different ways.Figure 8b illustrates Source Update: (1) when ant come in a node from a neighbor, the neighbor will be called neighbor_in; which is a concentration of pheromone in the pheromone table given a pair of source and neighbor_in (in fact, the way of Source Update is widely used already.Network routing protocols, such as RIP and OSPF, calculate the distance and update the routing table when receiving the routing information corresponding to the ant.But [28] is meaningful that this method is applied for the first time).
Source Update is superior to Destination Update; Source update prevents the wrong increment of pheromone concentration.Because Destination Update selects a next node (neighbor_out) and increases the pheromone concentration with no guarantee that an ant will reach a destination, so the ant may not find a destination.It leads to the wrong increment of pheromone concentration.But Source Update increases the pheromone concentration with the guarantee that ant can reach a source through the neighbor, neighbor_in.It makes a huge difference and source update-related experiment will be discussed in the next section.

Source Update
Ref. [20] proposed a Source Update algorithm which suggests new ways to update pheromones.Figure 8a illustrates the way pheromone update in general ACO algorithm.In this paper, the way will be called as Destination Update.Destination Update works this process: (1) select a neighbor node which ant will go through.The selected neighbor node will be called neighbor_out; (2) increase τ destination, neighbor_out which is a concentration of pheromone in the pheromone table given a pair of destination and neighbor_out.But Source Update works in slightly different ways.Figure 8b illustrates Source Update: (1) when ant come in a node from a neighbor, the neighbor will be called neighbor_in; (2) increase τ source, neighbor_in which is a concentration of pheromone in the pheromone table given a pair of source and neighbor_in (in fact, the way of Source Update is widely used already.Network routing protocols, such as RIP and OSPF, calculate the distance and update the routing table when receiving the routing information corresponding to the ant.But [28] is meaningful that this method is applied for the first time).
Source Update is superior to Destination Update; Source update prevents the wrong increment of pheromone concentration.Because Destination Update selects a next node (neighbor_out) and increases the Symmetry 2017, 9, 272 10 of 25 pheromone concentration with no guarantee that an ant will reach a destination, so the ant may not find a destination.It leads to the wrong increment of pheromone concentration.But Source Update increases the pheromone concentration with the guarantee that ant can reach a source through the neighbor, neighbor_in.It makes a huge difference and source update-related experiment will be discussed in the next section.

Ant Local
Our previous work [35] presented a new perspective about Ant Colony Optimization.Ref. [35] pointed out a problem about classic ACO algorithms: Ant System and Ant Colony System.These ACO models focus on the distance between source and a given node.But in fact, to optimize the path at a given node, the desirable consideration is the distance between a given node and destination.In this reason, we proposed Ant Local model in [35].
Also using (6), at our previous project [36], proposed and implemented Ant Normalizing model:

Simple Backtracking Update
The ACO algorithm is a kind of depth-first search (DFS) based on probability and also it is called a metaheuristic algorithm.If an ant enters into a wrong node that cannot lead to a destination, it does backtracking.Our previous work proved that if backtracking occurs, that information can be used for pheromone updates for a better search in [35].
All ants are divided into two types: Forward Ant and Backward Ant.Forward Ant is a request packet to find a destination.If it finds a destination, it changes into Backward Ant.Backward Ant is a response packet corresponding to the given Forward Ant.At a node, Forward Ant has three options; changing into Backward Ant, starving (exceeding the given TTL) and backtracking.If a Forward Ant finds a destination, backtracking never happens.Backtracking occurs only when a Forward Ant cannot find the destination D through a neighbor node i.In other words, there is no destination D in any nodes that can be reached through the node i, so we can assert that if a Forward Ant goes to the node i again then it will never find a destination D. So from this analysis, we propose the Simple

Ant Local
Our previous work [35] presented a new perspective about Ant Colony Optimization.Ref. [35] pointed out a problem about classic ACO algorithms: Ant System and Ant Colony System.These ACO models focus on the distance between source and a given node.But in fact, to optimize the path at a given node, the desirable consideration is the distance between a given node and destination.In this reason, we proposed Ant Local model in [35].
Also using ( 6), at our previous project [36], proposed and implemented Ant Normalizing model:

Simple Backtracking Update
The ACO algorithm is a kind of depth-first search (DFS) based on probability and also it is called a metaheuristic algorithm.If an ant enters into a wrong node that cannot lead to a destination, it does backtracking.Our previous work proved that if backtracking occurs, that information can be used for pheromone updates for a better search in [35].
All ants are divided into two types: Forward Ant and Backward Ant.Forward Ant is a request packet to find a destination.If it finds a destination, it changes into Backward Ant.Backward Ant is a response packet corresponding to the given Forward Ant.At a node, Forward Ant has three options; changing into Backward Ant, starving (exceeding the given TTL) and backtracking.If a Forward Ant finds a destination, backtracking never happens.Backtracking occurs only when a Forward Ant cannot find the destination D through a neighbor node i.In other words, there is no destination D in any nodes that can be reached through the node i, so we can assert that if a Forward Ant goes to the node i again then it will never find a destination D. So from this analysis, we propose the Simple Backtracking Update algorithm (Algorithm 1):

The Fast Path Recovery Algorithm
The Fast Path Recovery Algorithm is our past proposed algorithm in [35].In fact, the ACO algorithm has a mechanism to recover the path even without this algorithm.But without this, it takes a long time to recognize an occurrence of link failure.So this algorithm is used to force to rediscover a new path between a source and destination if a network link failure occurs.This algorithm introduces a new variable called Endurance; this variable has the same concept of Timeout used in existing TCP. Figure 9 and Algorithm 2 explain how this algorithm works.The Fast Path Recovery Algorithm is our past proposed algorithm in [35].In fact, the ACO algorithm has a mechanism to recover the path even without this algorithm.But without this, it takes a long time to recognize an occurrence of link failure.So this algorithm is used to force to rediscover a new path between a source and destination if a network link failure occurs.This algorithm introduces a new variable called Endurance; this variable has the same concept of Timeout used in existing TCP. Figure 9 and Algorithm 2 explain how this algorithm works.

Design of ACO Packet
The packet format is depicted in Figure 10.Each field is described in Table 5.These walks, path, visited are similar in that these fields record an array of nodes but these fields have their own purpose.walks record all nodes so it is useful when debugging.path field is used to know shortest path.visited field comes from [20] and prevents revisit and the graph cycle.

Design of ACO Packet
The packet format is depicted in Figure 10.Each field is described in Table 5.These walks, path, visited are similar in that these fields record an array of nodes but these fields have their own purpose.walks record all nodes so it is useful when debugging.path field is used to know shortest path.visited field comes from [20] and prevents revisit and the graph cycle.
Whenever an ant packet visits a node, the size of the packet increases.So the maximum number of visited nodes depends on the value of init_ttl.init_ttl having an upper bound as ( 8 In the Ethernet network, the default MTU is 1500 Bytes.But nwalks, npath, nvisted, ndists are not fixed so init_ttl cannot be calculated.But in the worst case, init_ttl can be calculated.Assume that the ant visits a new node always.Then (9) holds true.Finally, Equation ( 10) can be obtained: init_ttl <= 91.5 (10) So in the Ethernet network, the ant packet can visit at least 91 nodes.This field is a 2 bytes padding for a 4 bytes-align.

walks
The array of FON ID.This field records all nodes that ant (packet) dropped by.So, this field includes all nodes that backtracked nodes.

path
The array of FON ID.This field records all nodes that ant (packet) dropped by, but does not include backtracked node.Using this field, the shortest path from source to destination can be calculated.

visited
Visited field is the array of node IDs and where all visited nodes will be recorded in.It is used to confirm that duplicate visits have been made and to prevent the graph cycle.

dists
Visited field is the array of the distance.Each element has 2 byte length.And nth element is the distance between source and nth visited' element.
In other words, dists[i] == Dist(source, visited[i]) where i is the index of array.

Decision of Ant Model
Before implementing ACO routing, ACO model must be determined because only one of them, ant system, ant colony system, ant local, ant normalizing, etc., can be used.In fact, the previous section illustrates how to process an ant packet implicitly assuming that ant colony system model and source update are chosen.In the next section, each ant model performance will be shown.It will be the answer to why we chose the combination of ant colony system with simple backtracking update, source update and fast path recovery; this combination showed the best performance.

Performance Evaluation and Analysis
In this section, the AS and ACS models are set as the control group because these are typical and representative models of ACO algorithm.The Source Update, Simple Backtracking Update, and Fast Path Recovery algorithm are applied with AS and ACS and these cases were conducted and analyzed.A focus on the destination discovery time (as discrete time) shows how the theoretical performance improves.

Decision of Ant Model
Before implementing ACO routing, ACO model must be determined because only one of them, ant system, ant colony system, ant local, ant normalizing, etc., can be used.In fact, the previous section illustrates how to process an ant packet implicitly assuming that ant colony system model and source update are chosen.In the next section, each ant model performance will be shown.It will be the answer to why we chose the combination of ant colony system with simple backtracking update, source update and fast path recovery; this combination showed the best performance.

Performance Evaluation and Analysis
In this section, the AS and ACS models are set as the control group because these are typical and representative models of ACO algorithm.The Source Update, Simple Backtracking Update, and Fast Path Recovery algorithm are applied with AS and ACS and these cases were conducted and analyzed.A focus on the destination discovery time (as discrete time) shows how the theoretical performance improves.
In addition, when applying ACO algorithm as on-demand routing into an Ethernet network, two network performance measures are defined based on actual time rather than discrete time and the relationship between them is derived and verified from the experiment.

Performance Evaluation of Each ACO Model
All experiments were conducted in the topology depicted in Figure 12 using Mininet [37].The topology came from [28].The node index was randomly assigned a value from 0 to 54. Common parameters in experiments are listed in Table 6.The reason why we did not build the test bed based on the actual physical equipment mentioned above is that the structure of the network is composed of more than 50 nodes and the complexity of building a test bed based on actual equipment is taken into consideration.However, since all the nodes operating on Mininet are the software created in Section 3 above, they send and receive the actual Ethernet on the virtual machine.
The performance of each case is measured using the frequency distribution and the mean distance.Average n is defined as the average length of nth received ants when repeating the same experiment.Average n is expressed in (11).
where J is the number of repeated experiments.
Symmetry 2017, 9, 272 15 of 25 In addition, when applying ACO algorithm as on-demand routing into an Ethernet network, two network performance measures are defined based on actual time rather than discrete time and the relationship between them is derived and verified from the experiment.

Performance Evaluation of Each ACO Model
All experiments were conducted in the topology depicted in Figure 12 using Mininet [37].The topology came from [28].The node index was randomly assigned a value from 0 to 54. Common parameters in experiments are listed in Table 6.The reason why we did not build the test bed based on the actual physical equipment mentioned above is that the structure of the network is composed of more than 50 nodes and the complexity of building a test bed based on actual equipment is taken into consideration.However, since all the nodes operating on Mininet are the software created in Section 3 above, they send and receive the actual Ethernet on the virtual machine.
The performance of each case is measured using the frequency distribution and the mean distance.Average is defined as the average length of nth received ants when repeating the same experiment.Average is expressed in (11).
where is the number of repeated experiments.First, this is the experimental result of Ant System.When the pheromone evaporation coefficient was increased from 0.1 to 0.9, it was confirmed that the optimized pheromone evaporation coefficient(ρ) was about 0.1.The average path length was 22.740940 when it was repeated 100 times.The time series graph of Figure 13a shows that it is slowly approaching the optimal path.The histogram of Figure 13b shows that the frequency of the path length between 21 and 23 is largest.
Second, this is the experimental result of Ant Colony System.When the pheromone evaporation coefficient was increased from 0.1 to 0.9, it was confirmed that the optimized pheromone evaporation coefficient(ρ) was about 0.1.The average path length was 24.748670 when it was repeated 100 times.The time series graph of Figure 14a shows that it is not approaching the optimal path.This result is unexpected because the ACS algorithm is known to have the best performance [14].This result will be explained in a later section.The histogram of Figure 14b shows that the frequency of the path length between 21 and 23 is largest.In the control groups, the performance of the pure Ant System and Ant Colony System algorithms with no additional algorithms was measured.
First, this is the experimental result of Ant System.When the pheromone evaporation coefficient was increased from 0.1 to 0.9, it was confirmed that the optimized pheromone evaporation coefficient(ρ) was about 0.1.The average path length was 22.740940 when it was repeated 100 times.The time series graph of Figure 13a shows that it is slowly approaching the optimal path.The histogram of Figure 13b shows that the frequency of the path length between 21 and 23 is largest.
Second, this is the experimental result of Ant Colony System.When the pheromone evaporation coefficient was increased from 0.1 to 0.9, it was confirmed that the optimized pheromone evaporation coefficient(ρ) was about 0.1.The average path length was 24.748670 when it was repeated 100 times.The time series graph of Figure 14a shows that it is not approaching the optimal path.This result is unexpected because the ACS algorithm is known to have the best performance [14].This result will be explained in a later section.The histogram of Figure 14b shows that the frequency of the path length between 21 and 23 is largest.

Simple Backtracking Update
In this section, it was measured that the performance of Ant System and Ant Colony System algorithms with Simple Backtracking Update.
First, this is the experimental result of AS with Simple Backtracking Update.When the pheromone evaporation coefficient was increased from 0.1 to 0.9, it was confirmed that the optimized pheromone evaporation coefficient(ρ) was about 0.1.The average path length was 20.325750 which is better than the result of Ant System only.The time series graph of Figure 15a shows a similar result but it is approaching the optimal path faster than Ant System only.The histogram of Figure 15b shows a similar result of AS only.
Second, this is the experimental result of ACS with Simple Backtracking Update.When the pheromone evaporation coefficient was increased from 0.1 to 0.9, it was confirmed that the optimized pheromone evaporation coefficient(ρ) was about 0.1.The average path length is 22.015080 which was a better result than ACS only.The time series graph of Figure 16a shows that it is not approaching the optimal path and is similar to Figure 14.But the histogram of Figure 16b shows that the frequency of 14 (the optimal path) is 3-times than Figure 14b.

Simple Backtracking Update
In this section, it was measured that the performance of Ant System and Ant Colony System algorithms with Simple Backtracking Update.
First, this is the experimental result of AS with Simple Backtracking Update.When the pheromone evaporation coefficient was increased from 0.1 to 0.9, it was confirmed that the optimized pheromone evaporation coefficient(ρ) was about 0.1.The average path length was 20.325750 which is better than the result of Ant System only.The time series graph of Figure 15a shows a similar result but it is approaching the optimal path faster than Ant System only.The histogram of Figure 15b shows a similar result of AS only.
Second, this is the experimental result of ACS with Simple Backtracking Update.When the pheromone evaporation coefficient was increased from 0.1 to 0.9, it was confirmed that the optimized pheromone evaporation coefficient(ρ) was about 0.1.The average path length is 22.015080 which was a better result than ACS only.The time series graph of Figure 16a shows that it is not approaching the optimal path and is similar to Figure 14.But the histogram of Figure 16b shows that the frequency of 14 (the optimal path) is 3-times than Figure 14b.

Network-Related Performance Measure
In this paper, we apply the ACO algorithm to network routing.Therefore, it is important how the ACO algorithm affects network performance.One of the main concerns of this paper is the path recovery time in the end-to-end delay and link failure and the link overhead caused by the routing itself.In this section, we analyze how these two network performance indicators can be related to the ACO parameters and how there is a relation between the two values.

Definition of Network Performance Measure
If transmission delay and processing delay can be ignored, the ( ) can be expressed as a sum of ( ) and − ℎ ( ).So it is written as (12): And ℎ ( ) is defined as Load (bit-per-sec) caused by routing and satisfies these conditions: (1) All ants travel only through a single path.
(2) There is no loss, so 100% of the response (backward ant) is received.
These two conditions mean the worst case.In other words, ℎ ( ) means the upper bound of the actual measured load.

Relation of Overhead and Recovery Time
To figure out the relation of Overhead and Recovery Time, we calculate how many messages can pass to a given link.According to the variables definition in Table 7, N ants (packets or messages) occur per cycle.Considering the round trip of the packet and assuming that request packet size and response packet size are the same, the message flows twice in total.So, the number of messages per second can be written as (13): The Link Overhead can be easily obtained by multiplying by the size of the packet as ( 14): It is not easy to calculate ( 14) because the size of the packet T is variable.But the upper bound of Link Overhead can be easily obtained by substituting MTU from T.

Network-Related Performance Measure
In this paper, we apply the ACO algorithm to network routing.Therefore, it is important how the ACO algorithm affects network performance.One of the main concerns of this paper is the path recovery time in the end-to-end delay and link failure and the link overhead caused by the routing itself.In this section, we analyze how these two network performance indicators can be related to the ACO parameters and how there is a relation between the two values.

Definition of Network Performance Measure
If transmission delay and processing delay can be ignored, the Recovery Time(R) can be expressed as a sum of Link Error Detection Time(T e ) and Re − Searching Time(T s ).So it is written as (12): And Link Overhead(O) is defined as Load (bit-per-sec) caused by routing and satisfies these conditions: (1) All ants travel only through a single path.
(2) There is no loss, so 100% of the response (backward ant) is received.
These two conditions mean the worst case.In other words, Link Overhead(O) means the upper bound of the actual measured load.

Relation of Overhead and Recovery Time
To figure out the relation of Overhead and Recovery Time, we calculate how many messages can pass to a given link.According to the variables definition in Table 7, N ants (packets or messages) occur per cycle.Considering the round trip of the packet and assuming that request packet size and response packet size are the same, the message flows twice in total.So, the number of messages per second M can be written as (13): M = 2NC −1 (13) The Link Overhead can be easily obtained by multiplying M by the size of the packet T as (14): It is not easy to calculate (14) because the size of the packet T is variable.But the upper bound of Link Overhead O upper can be easily obtained by substituting MTU from T.
Recovery Time R can be expressed using ACO parameters listed in Table 7. First, Link-error detection time T e and Shortest Path Search time T s are random variables.Both Link-error detection time and Shortest Path Search time can be expressed in multiples cycle.This is because the computation time of the ACO algorithm is proportional to the cycle.T e and T s are expressed as T s = qC ( 16) Also ( 14) can be re-expressed as ( 17) using ( 15) and ( 16): R = (p + q)C (17 where p, q are discrete random variables depending on the selected ACO algorithm.Finally, ( 18) can be obtained by multiplying the ( 14) by the (17): Even the values of p, q are random variables, but they can be treated as constants since they are very small in the measurement.Therefore, the right side of Equation ( 4) can be treated as a constant.From Equation (4), we can see that the overhead increases exponentially with decreasing Recovery Time.

Network Performance Measure
With Ant System; N = 10, E = 0.2, the average of p and q was measured to be about 2 and 2, respectively.C (Cycle) value is 50 ms, 100 ms, 200 ms • • • • • • 2000 ms, etc., the upper bound value of the overhead is given by (19): O * R = 960 (19) Based on the experimental data, a regression curve was obtained by the regression analysis as (20): The curve of Equations ( 1) and ( 2) are depicted in Figure 19.The X-axis is the Recovery Time in sec.The Y-axis is expressed as overhead in Mbps and expressed in log-scale.Figure 19 shows that the upper bound and actual values are quite different because the packet size is calculated assuming MTU (1500 bytes) when deriving the theoretical value.As a result of the actual measurement, it is analyzed that the packet size is about 10% of the MTU and 20% of the MTU when the packet is transmitted.Also, it shows that if Recovery Time decreases, then Link Overhead increases exponentially.Therefore, there is a limitation in reducing the recovery time in real networks.

Conclusions
In this paper, we proposed and developed Function-Oriented Networking, a platform for network users.It has a different philosophy as opposed to technologies for network managers of Software-Defined Networking technology, OpenFlow.It is the technology that can immediately reflect the demands of the network users in the network, unlike the existing OpenFlow and NFV, which do not reflect directly the needs of the network users.It allows the network user to determine the policy of the direct network, so it can be applied more precisely than the policy applied by the network manager.This is expected to increase the satisfaction of the service users when the network users try to provide new services.
In addition, we developed a FON function as a method to demonstrate actual FON.This FON function performs on-demand routing for Low-Delay Required service.We analyzed the characteristics of the ACO algorithm and found that the algorithm is suitable for low-delay required services.It was also the first in the world to implement the routing software using Ant Colony Optimization Algorithm in the real Ethernet network.In order to improve the routing performance, several algorithms of the Ant Colony Optimization Algorithm have been developed to enable faster path search-routing and path recovery.The relationship between the network performance index and the ACO routing parameters is derived, and the results are compared and analyzed.Through this, it was possible to develop the ACO algorithm.
In this paper, we aimed to solve the problems where conventional biology-inspired networking such as ACO algorithm cannot be implemented in actual networks.Although there have been various researches for Biology-Inspired-Networking, it was the goal of this paper to solve the problem that it is almost impossible to send and receive real network traffic by applying technology such as ACO to network equipment.Through this paper, the proposed technology has made a great contribution to enabling traffic sending and receiving based on technologies such as ACO in real networks.Therefore, biology-inspired-networking research such as ACO is being carried out on real networks instead of simulations, and improvement of the Biology-Inspired-Networking algorithm is part of future research.
In the future, based on the Biology-Inspired-Networking algorithm, we will analyze the difference between theory and practice in sending and receiving of the Internet traffic, and we will continue to research the improvement of Biology-Inspired-Networking based on this.

Figure 3 .
Figure 3.The FON Packet architecture encapsulated in Ethernet frame.

Figure 4 .
Figure 4. Format of Synchronous Request Message Header.

Figure 3 .
Figure 3.The FON Packet architecture encapsulated in Ethernet frame.

Figure 3 .
Figure 3.The FON Packet architecture encapsulated in Ethernet frame.

Figure 4 .
Figure 4. Format of Synchronous Request Message Header.Figure 4. Format of Synchronous Request Message Header.

Figure 4 .Figure 5 .
Figure 4. Format of Synchronous Request Message Header.Figure 4. Format of Synchronous Request Message Header.

Figure 5 .
Figure 5. Format of Synchronous Response Message Header.

3. 5 .
Processing and Exchanging FON Data Packets between FON Switches

Figure 6
Figure 6 illustrates how FON switches process and exchange the FON Packet.

Figure 6 .
Figure 6.Sequence diagram of processing and exchanging FON Packet.

Figure 6 .
Figure 6.Sequence diagram of processing and exchanging FON Packet.

Figure 7 .
Figure 7.The structure of the pheromone table.

Figure 7 .
Figure 7.The structure of the pheromone table.

Algorithm 2 1 :
The Fast Path Recovery Algorithm For all neighbor nodes i 2

Figure 9 .
Figure 9. Flow Chart: The Fast Path Recovery Algorithm.

Figure 9 .
Figure 9. Flow Chart: The Fast Path Recovery Algorithm.

Figure 11 .
Figure 11.Flow chart of processing ant packet.

Figure 11 .
Figure 11.Flow chart of processing ant packet.
Network slicing technology that can fulfill FON.If network users can totally control the network resources on the network, a serious security problem can be caused.This problem can be solved if a certain amount of resources is assigned through network slicing.To realize the scenario in Figure2, FON must provide such technologies as below.(1) According to network user requirements, a new network function, FON Function, can be deployed/deleted on/from FON Switch; (2) FON should provide APIs by making network resources abstractive so that FON function can be easily implemented to apply new network policy.Especially, new policy is related directly to Routing policy.Because FON requests direct policy change, On-demand method is more well-matched than the Table-Driven method.

Table One of FON's main purposes is to provide FON Function with an API abstracting system's routing related-resource. Let us take the Linux machine as an example. For communication, ARP table and Routing table have to be controlled in a lump and also Flow table of Virtual Bridge has to be managed as well. In order to do this, FON constructs FON Forwarding Table by using FON ID. It manages various
tables uniformly through this.FON manages these tables and provides APIs related with FON Forward Table, and FON Function can change easily network policy by modifying a FON Forwarding Table only; in other words, FON Function does not have to modify ARP, Routing, and Flow tables directly.

Table 1 .
Fields of FON data packet.

Table 1 .
Fields of FON data packet.
Description sid Source FON identifier did Destination FON identifier type Field for identifying FON Function.2 byte Paylen Payload length. 2 byte Payload Variable length

Table 1 .
Fields of FON data packet.
Field Description sid Source FON identifier did Destination FON identifier type Field for identifying FON Function.2 byte Paylen Payload length. 2 byte Payload Variable length

Table 2 .
The fields of Synchronous Request Message Header.
func_type Represents Identifier in FON Function.FON can recognize in which FON function the message generated through this Field.msg_type Represents types of message.Refer [Table 1].tot_len Represents the length of message including message's header length in bytes.data Include Payload matched with given message type (func_type).

Table 3 .
Synchronous Message Type Values.For registering a new FON Function on FON MSG_TYPE_DEREG = 1 For deregistering a new FON Function on FON MSG_TYPE_SENDTO = 2 Request to Request FON for Transmitting FON Packet MSG_TYPE_TABLE_ADD = 3 Add (modify) Entry to FON's Forward Table MSG_TYPE_TABLE_DEL = 4 Remove Entry in FON's Forward Table MSG_TYPE_TABLE_GET = 5 Acquire All entries in FON's Forward Table MSG_TYPE_HOST_GET = 6 Check current FON ID in FON

Table 4 .
The fields of Synchronous Response Message Header.

Table 2 .
The fields of Synchronous Request Message Header.
func_type Represents Identifier in FON Function.FON can recognize in which FON function the message generated through this Field.msg_type Represents types of message.Refer [Table 1].tot_len Represents the length of message including message's header length in bytes.data Include Payload matched with given message type (func_type).

Table 3 .
Synchronous Message Type Values.

Table 4 .
The fields of Synchronous Response Message Header.All kind of messages in this type are messages which notify FON Functions when some event occurs in FON.In this context, an event is such that: change of FON ID, FON Forward Table, etc.Typical Asynchronous message is passing FON data packets to a FON Function according to func_type filed in FON packet.

Table 5 .
Description of ant packet fields.
direction It means the type of ant.There are two types of ant; forward is a request packet.backward is a response packet.init_ttl It is an initial time-to-live.Using this filed, each node can calculate the distance between source and current node.cur_ttl Current time-to-live.nwalks The length of walks field.npath The length of path field.nvisted The length of visited field.ndists The length of dists field.padding

Table 7 .
ACO algorithm variable and network-related variable.