SINMS A Slow Intelligence Network Manager based on SNMP Protocol

1. SINMS A Slow Intelligence Network Manager based on SNMP Protocol Francesco Colace1 – fcolace@unisa.it Shi-Kuo Chang2 – chang@cs.pitt.edu Massimo De Santo1 – desanto@unisa.it 1Department of Information and Electrical Engineering, University of Salerno, Italy 2Department of Computer Science, University of Pittsburgh, USA DMS 2010 – Chicago, IL

2. Outline • The Network Management • Towards a Slow Intelligence Network Manager • The Slow Intelligence System Approach • The Ontology • The SNMP Protocol • SINMS • The proposed architecture • A first prototype • Evaluation Parameters • Experimental Results • Conclusions

3. The Network Management • The Network Management: the process of controlling a network so as to maximise its efficiency and productivity • Network Management Tasks • Fault management • Configuration management • Accounting management • Performance management • Security management

4. The Network Management • The are a small number of accessories methods to support network and network device management. • Access methods include • the SNMP • command-line interface (CLIs) • custom XML • CMIP • Windows Management Instrumentation (WMI) • Transaction Language 1 • CORBA • NETCONF • Java Management Extensions (JMX).

5. Towards A Slow Intelligence Network Manager • The aim of this paper is to design and implement a Network Manager able: • To detect automatically faults in a computer network • To infer the actions to do in order to recover the faults • To share knowledge about faults and actions with other similar networks • The proposed results can be reached by the use of • Slow Intelligence System Approach • Ontology

6. Slow Intelligent System • SISs are general-purpose systems characterized by being able to improve performance over time through a process involving an Enumeration Phase

7. Slow Intelligent System • SISs are general-purpose systems characterized by being able to improve performance over time through a process involving a Propagation Phase

8. Slow Intelligent System • SISs are general-purpose systems characterized by being able to improve performance over time through a process involving an Adaptation Phase

9. Slow Intelligent System • SISs are general-purpose systems characterized by being able to improve performance over time through a process involving an Elimination Phase

10. Slow Intelligent System • SISs are general-purpose systems characterized by being able to improve performance over time through a process involving a Concentration Phase

11. Slow Intelligent System • A SIS continuously learns, searches for new solutions and propagates and shares its experience with other peers • A SIS differs from expert systems in that the learning is not always obvious. • From the structural point of view, a SIS is a system with multiple decision cycles such that actions of slow decision cycle(s) may override actions of quick decision cycle(s), resulting in poorer performance in the short run but better performance in the long-run

12. Slow Intelligent System and Network Management • A network manager has to find a possible solution starting from a fault signal. So it has to enumerate all the possible solutions: Enumeration Phase • A network manager can share with other systems or experts knowledge in order to acquire new solution’s approaches: Propagation phase • A network manager has to adapt a candidate solution to the context of the managed network: Adaptation Phase • A network manager has to select only one solution: Elimination Phase • A network manager has to execute at its best the selected solution: Concentration Phase

13. Slow Intelligent System and Ontology Ontology

14. Ontology for Network Management • Ontology • the definition of ontology is still a challenging task • a good practical definition is: “an ontology is a method of representing items of knowledge (ideas, facts, things) in a way that defines the relationships and classification of concepts within a specified domain of knowledge” • O = {C, A, RT, R, AX}

15. Ontology for Network Management • The development of the ontologies’ system has been obtained • By the use of SNMP protocol • It is more than just a protocol. In fact it defines an architecture for extracting information from the network regarding the current operational state of the network, using a vendor-independent family of mechanisms • By the use of experts

16. Ontology for Network Management • In the case of the proposed Network Manager the following ontologies have been developed: • OSNMP = {CSNMP, ASNMP, HSNMP, RTSNMP, RSNMP}. This ontology aims to define the entire structure of SNMP protocol by analyzing the various messages and the relations between them • OFault = {CFault, AFault, HFault, RTFault, RFault}. This ontology describes each kind of possible errors that can occur within a LAN • OCause = {CCause, ACause, HCause, RTCause, RCause}. This ontology defines the causes of the faults that may occur in a LAN • OSolution = {CSolution, ASolution, HSolution, RTSolution, RSolution}. This ontology defines the solutions that can be taken to recover from fault situations which occurred within a LAN • OAction = {CAction, AAction, HAction, RTAction, RAction}. This ontology aims to identify the actions to be taken in order to recover from fault situations • OComponent = {CComponent, AComponent, HComponent, RhComponent, RAction }. This ontology describes the components that may be present within a LAN • OEnvironment = {CEnvironment, AEnvironment, HEnvironment, RhEnvironment, REnvironment}. This ontology describes the operative context where the LAN works

17. Ontology for Network Management: Faults

18. Ontology for Network Management: Actions

19. SINMS – The Proposed Architecture Device_k_1 Device_k_2 Device_k_n Device_m_1 Device_m_2 Device_m_n … … … … … … • Ok-SNMP • Ok_Fault • Ok_Cause • Ok_Solution • Ok_Action • Ok_Component • Ok_Environment • Om-SNMP • Om_Fault • Om_Cause • Om_Solution • Om_Action • Om_Component • Om_Environment Local_Server_k Local_Server_m • Ocentral-SNMP • Ocentral_Fault • Ocentral_Cause • Ocentral_Solution • Ocentral_Action • Ocentral_Component • Ocemtral_Environment Central_Server • Oi-SNMP • Oi_Fault • Oi_Cause • Oi_Solution • Oi_Action • Oi_Component • Oi_Environment • Oj-SNMP • Oj_Fault • Oj_Cause • Oj_Solution • Oj_Action • Oj_Component • Oj_Environment Local_Server_i Local_Server_j Device_i_1 Device_i_2 Device_i_n … … … Device_j_1 Device_j_2 Device_j_n … … …

20. SINMS – The Proposed Architecture Zabbix_Server Ontologies Local_Server_i Ontologies Central_Server SINMS Local_Server_i SINMS Central_Server SNMP-Message Reader SNMP_Events Actions Actions Actions Actions Actions Device_1 Device_2 Device_N Other_Local_servers … … … Zabbix_Agent Zabbix_Agent Zabbix_Agent

21. SINMS – The Operative Workflow Local Server Comparator Empty Set Local_Server_Actions Action Builder Actions Actuator Comparator Empty Set Comparator Empty Set Action Builder Central Server_Actions Local_Server_Actions Ontology Updating Action Builder Action Selector Ontologies Ontology Updating Ontology_Nodes Ontologies Ontology Selector Action Builder Local_Servers Ontology_Nodes Report Generator Ontology_Nodes

22. SINMS – The Prototype • Adopted Technologies for the framework development • Java • MySql • SNMP • Zabbix • OWL • Protegè

23. SINMS – The Prototype

24. Experimental Scenario 1 • The network manager has to manage two different LANs. • The first one is composed by a Cisco switch and 30 personal computers • The second LAN is composed by a Nortel switch, 30 personal computers equipped with various operative systems and a HP network printer. • Each local server has SNMP ontology able to cover the 80% of the SNMP messages that the hosts in the LAN can launch

25. Experimental Scenario 1 • The experimental phase aimed to evaluate the following parameters: • The system’s ability to identify the correct management actions to apply in the LAN after a SNMP signal. This parameter, named CA, is so defined: • The system’s ability to select in a LAN a viable solution that was previously adopted in a similar case in another LAN. This parameter, named IS, is so defined: • The system’s ability to manage the introduction of a new component in a LAN. In particular the system has to recognize components that were previously managed in other LANs. This parameter, named KC, is so defined:

26. Experimental Scenario 1 • The previous indexes were calculated in the following way: • The CA index: this index was calculated after 10, 20, 30, 40 and 50 SNMP signals. In this case there was not variations in the LANs • The IS index: this index was calculated forcing some SNMP events in the LAN not expected in its SNMP reference ontology. This index was evaluated after 10, 20, 30, 40, 50 SNMP signal not expected. • The KC index was estimated after the introduction of new components in a LAN. In particular for five times a component belonging to a LAN has been shifted in the other LAN and the index was evaluated after 10, 20, 30, 40, 50 SNMP signal launched from the host.

27. Experimental Scenario 2 • The Network Manager has been tested for 72 hours monitoring the following LANS • Lab_1: • 1 Switch Cisco Catalyst • 1 HP Network Printer • 40 Personal Computer • Lab_2 • 1 Switch Nortel • 1 Canon Network Printer • 35 Personal Computer • Lab_3 • 1 Switch Cisco Catalyst • 50 Personal Computer

28. Experimental Scenario 2 The network manager can recognize 237 OID Each local server can recognize and manage 80 OID (selected in a randomatic way) The overlapping among the systems is the following: S_L_1 and S_L_2 = 45 S_L_1 and S_L_3 = 39 S_L_2 and S_L_1 = 37

29. Experimental Scenario 2

30. Conclusions • In this paper a novel method for network management has been introduced • This method is based on • SNMP • Ontology • Slow Intelligence System approach • The approach has been tested in various operative scenario with good results • The future works aim to improve the system by the introduction of some modules based on Artificial Intelligence for the automatic inference of actions when the network manager does not find any solutions