network faults. Four managed object modules are used by the algorithm. The details of these modules are as follows.
Link Monitor: In OMNeT++ communication links are realized by creating “channels.” To implement a module that monitors the utilization of a link and can trigger an event if a threshold is reached, we extended the cDatarateChannel class. This allows us to place a monitoring object in arbitrary locations in a network topology. The Link Monitor is typically used to indicate the onset of a challenge that is causing anomalous traffic volumes
Entropy Reporter: entropy is the typical measure of information, could be used as the effective and efficient method to assess the changes of the traffic features. Consequently, we have implemented an entropy-based detection module, which monitors the source IP, source port, destination IP, destination port and transport protocol type for changes in entropy. The module computes the entropy of these five features using Shannon’s entropy algorithm. A threshold can be defined that triggers an event.
Entropy could be used to evaluate the uncertainty with the traffic features. When the network faults happens, some of the destination couldn’t be reached in the short term, so the entropy of the Destination IP will become more concentrated. The entropy value quantifies the degree of uncertainty with the traffic feature.
Fault Recovery: once the network fault is detected, the next stage is helping the network to fully recover. The recovery strategy will
90
eventually affect the reliability of the network. A large scale of network should tolerate elements/nodes failures while continuing normal operation. As the number of network failures increase, the difficulty of network recovery increases. The alarm will be raised when the network fault is identified. At this stage, either the automatic or network operator initiated fault recovery solutions are activated to address the fault and bring the network back to normal operation.
A few corresponding solutions will be proposed to correct the fault, for example, the packets could be re-routed to a backup link. The recovery stage may need to deal with complex dependencies issues between network elements. To simply replace or reset the network element may not right, since other network elements may need to be reconfigured or reset. Any mis-replacement may worsen the scenario.
The algorithm for network fault resilience is shown in Figure 27. At the beginning, the local manager will set the threshold and activate the link monitor, also the entropy reporter will start calculating the entropy value for five traffic features, which include Destination IP, Destination Port, Source IP, Source Port and Protocol. Once the traffic volume rises above the threshold, the alert will be raised in order to do further in depth analysis. Then the entropy reporter will check the entropy value changes for each of the traffic features, if both the entropy of the destination IP and source IP drop significantly, then we could assume that this is the behavior of a network fault.
This is based on Lakhina [2005]’s findings. At this stage, the network operator will receive an alarm for the network fault event, and have the options to choose either automatic recovery, for example, re-route the packets another link, or manual recovery, such as manually reset/reconfigure the individual network element.
91
Fig. 27. Entropy based network fault resilience algorithm
7.2.1 Experiment of the network fault resilience
For the case study, our simulated network consists of 35 Autonomous Systems (ASes): 26 stub ASes connected by 9 transit ASes, 1700 hosts, 80 web servers and 20 interactive servers generate background traffic.
Our resilience strategy is simulated at a stub AS. Within a single stub AS, two links between the edge router and gateway router is down as demonstrated in Figure 28. The network fault we simulated is the intermittent fault. The connection failure happens at 10 sec and last for 5 sec. Then the network is back as usual for another 5 sec. After that, the links fails again. The various resilience mechanisms are activated on a gateway router of the AS and its ingress link from a core router. Initially, a Link Monitor module is invoked on each of the ingress links to monitor link utilization, a threshold parameter is defined, which if exceeded results in an event being generated. An Entropy Reporter module is also invoked and configured with a list of features that it is to monitor.
As mentioned earlier, the Entropy Reporter module continuously monitors the traffic features’ distributions using Shannon’s entropy algorithm. In the previous chapters, we show the Entropy Reporter
92
module could be applied to detect malware attacks, for example a worm or port scan. In this experiment, the same Entropy Reporter module is deployed to capture network faults. Based on the distribution of the traffic features, the Entropy Reporter module could differentiate network faults from other types of malicious attacks.
Fig. 28. AS level network topology
Figure 29 shows the volume of the traffic on the ingress link between gateway router and core router for the simulated network fault. The overall traffic drops between 10s and 15s when the connections are broken, then the network operation back to the normal after 15s. The traffic falls down again at 20s. Figure 30 and figure 31 represent the entropy of the destination IP and source IP drop correspondingly when the network fault occurs.
93
Fig. 29. Traffic changes with the intermittent network fault
Fig. 30. Destination IP Entropy changes
Fig. 31. Source IP Entropy changes
94
7.3 Network Fault Resilience Using a Classifier