1. 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.
2. Related Works
2.1. 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].
2.2. 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”.
2.3. 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”.
The recent project NGMN [
13] defined network slicing in their final deliverable [
2,
14].
2.4. 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].
3. 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 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.
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.
To realize the scenario in
Figure 2, 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.
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.
3.1. 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.
3.2. FON Forwarding 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.
3.3. Design and Processing of FON Packet
FON Packet is a packet used in a communication between FON switches. FON is not using IP protocol so FON Packet is encapsulated directly into Ethernet Frame. FON Packet is divided into FON data packet and FON ADV packet by ethertype field in Ethernet header.
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 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.
3.4. 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.
3.4.1. 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.
3.4.2. 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.
3.5. Processing and Exchanging FON Data Packets between FON Switches
Figure 6 illustrates how FON switches process and exchange the FON Packet.
(1) | A network user sends a FON packet to FON Switch 1. |
(2) | FON Switch1 sends it to proper FON Function through func_type of FON Packet. |
(3) | After proper process, requests FON to send FON Packet. |
(4) | Deliver packet to FON Switch 2. |
… | Repeat (2)–(4). |
4. 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.
4.1. 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.
4.1.1. 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
is a constant,
is an evaporation rate of the pheromone.
4.1.2. 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
is a constant,
is an evaporation rate of the pheromone and
is a distance between neighbor nodes
i and
j.
4.1.3. 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
is a constant and
is the tour length of the ant,
is an evaporation rate of the pheromone.
4.1.4. 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
is to be visited nodes of the given ant
k at node
i.
4.1.5. Ant Colony System
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.
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”.
4.1.6. 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
and a neighbor node
.
4.1.7. 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
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
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.
4.2. Previous Works
4.2.1. 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:
4.2.2. 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):
Algorithm 1 Simple Backtracking Update |
1: Ant packet has been received |
2: if Ant is a backtracked from a neighbor node I then |
3: Where is the destination of an ant. |
4: else |
5: Do nothing |
6: end if |
4.2.3. 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.
Algorithm 2 The Fast Path Recovery Algorithm |
1: For all neighbor nodes i |
2: Visited ← False |
3: Endurance ← MAX Endurance |
4: Pheromone ← 0 |
5: End for |
4.3. 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:
So in the Ethernet network, the ant packet can visit at least 91 nodes.
4.4. Design of ACO Packet Packet Transmission Process
Figure 11 illustrates how packets (ants) are handled on the ACO algorithm.
(1) | Packet in |
(2) | If the ant is not registered in the node’s pheromone table, it registers in the pheromone table. |
(3) | If the ant is backtracked, perform the Simple Backtracking algorithm. Then proceed to step (5). |
(4) | Updates RX statistical information of the pheromone table. The received number, the byte, and the shortest distance to the transmission destination. |
(5) | Update the pheromone concentration for the destination entry in the pheromone table using the Source Update algorithm and the Ant Colony System algorithm. |
(6) | When you reach the destination, change the ant type from Forward (Request) to Backward (Response). |
(7) | Decrease TTL. |
(8) | If TTL is 0, go to step (11) and finish. |
(9-1) | If it is a Forward type |
(9-2) | If it is Backward type |
(10) | And updates the TX information of the pheromone table. |
(11) | End |
As shown in
Figure 11, not only ACS but various models such as AS, ACS, Ant Local, and Ant Normalizing are implemented.
4.5. 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.
5. 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.
5.1. 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.
is defined as the average length of nth received ants when repeating the same experiment.
is expressed in (11).
where
is the number of repeated experiments.
5.1.1. Control Groups
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.
5.1.2. 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.
5.1.3. Source Update
In this section, the performance of Ant System and Ant Colony System algorithms with Source Update was measured.
First, this is the experimental result of AS with
Source 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.3. This is a different coefficient(
) compared with AS only. The average path length was 14.998210. This performance overwhelmed the previous cases. The time series graph of
Figure 17a shows that it is very fatly approaching the optimal path than AS only. The histogram of
Figure 17b shows a totally different result compared with a result of AS only. Almost ant packets passed the optimized path.
Second, this is the experimental result of ACS with
Source 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.3. It is a different result compared with the previous cases. These results imply that if Source Update is applied, then the optimized pheromone evaporation coefficient(
) will be larger. The average path length is 14.219080 which was the best result than any other case. The time series graph of
Figure 18a shows that it is very fatly approaching the optimal path than ACS only. After about 2 evaporation cycles, the Optimized path was established. The histogram of
Figure 18b shows a totally different result compared with the result of ACS only. Almost ant packets passed the optimized path except for a very small number.
5.2. 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.
5.2.1. 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.
5.2.2. 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.
Recovery Time R can be expressed using ACO parameters listed in
Table 7. First,
Link-error detection time and
Shortest Path Search time 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.
and
are expressed as
Also (14) can be re-expressed as (17) using (15) and (16):
where
,
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 , 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.
5.3. Network Performance Measure
With Ant System;
, the average of
and
was measured to be about 2 and 2, respectively.
(Cycle) value is 50 ms, 100 ms, 200 ms
2000 ms, etc., the upper bound value of the overhead is given by (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.
6. 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.