SINMS A Slow Intelligence Network Manager based on

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

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 DMS 2010 – Chicago, IL

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 DMS 2010 – Chicago, IL

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). DMS 2010 – Chicago, IL

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 DMS 2010 – Chicago, IL

Slow Intelligent System • SISs are general-purpose systems characterized by being able to improve performance over time through a process involving an Enumeration Phase DMS 2010 – Chicago, IL

Slow Intelligent System • SISs are general-purpose systems characterized by being able to improve performance over time through a process involving a Propagation Phase DMS 2010 – Chicago, IL

Slow Intelligent System • SISs are general-purpose systems characterized by being able to improve performance over time through a process involving an Adaptation Phase DMS 2010 – Chicago, IL

Slow Intelligent System • SISs are general-purpose systems characterized by being able to improve performance over time through a process involving an Elimination Phase DMS 2010 – Chicago, IL

Slow Intelligent System • SISs are general-purpose systems characterized by being able to improve performance over time through a process involving a Concentration Phase DMS 2010 – Chicago, IL

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 DMS 2010 – Chicago, IL

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 DMS 2010 – Chicago, IL

Slow Intelligent System and Ontology DMS 2010 – Chicago, IL

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} DMS 2010 – Chicago, IL

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 DMS 2010 – Chicago, IL

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, Rh. Component, RAction }. This ontology describes the components that may be present within a LAN OEnvironment = {CEnvironment, AEnvironment, HEnvironment, Rh. Environment, REnvironment}. This ontology describes the operative context where the LAN works DMS 2010 – Chicago, IL

Ontology for Network Management: Faults DMS 2010 – Chicago, IL

Ontology for Network Management: Actions DMS 2010 – Chicago, IL

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

SINMS – The Proposed Architecture Zabbix_Server Ontologies SNMP-Message Reader SNMP_ Events Ontologies Local_Server_i Central_Server SINMS Local_Server_i Actions SINMS Central_Server Actions Other_Local_servers Device_1 Device_2 Zabbix_Agent ……… Zabbix_Agent Device_N Zabbix_Agent DMS 2010 – Chicago, IL

SINMS – The Operative Workflow Local Server Comparator Empty Set Local_Server_Actions Action Builder Actions Actuator Comparator Empty Set Action Builder Ontology Updating Comparator Empty Set Central Local_Server_Actions Action Builder Ontologies Action Selector Ontology Updating Ontology_Nodes Ontologies Action Builder Ontology Selector Local_Servers Ontology_Nodes DMS 2010 – Chicago, IL Report Generator

SINMS – The Prototype • Adopted Technologies for the framework development • • • Java My. Sql SNMP Zabbix OWL Protegè DMS 2010 – Chicago, IL

SINMS – The Prototype DMS 2010 – Chicago, IL

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 DMS 2010 – Chicago, IL

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: DMS 2010 – Chicago, IL

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. Index CA IS KC 10 20 30 40 50 90, 00 % 95, 00 % 93, 33 % 92, 50 % 94, 00 % 50, 00 % 66, 67 % 70, 00 % 74, 00 % 60, 00 % 76, 67 % 80, 00 % 82, 00 % DMS 2010 – Chicago, IL

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 DMS 2010 – Chicago, IL

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 DMS 2010 – Chicago, IL

Experimental Scenario 2 SNMP_Signals Managed_Signals_ After_Central_ Server_Request Local_Server_1 4128 4058 29 41 Local_Server_2 4007 3926 28 53 Local_Server_3 3824 3749 32 43 Not_Managed_ Signals 24 hours M/MAR/NM 48 hours M/MAR/NM 72 hours M/MAR/NM Local_Server_1 1222 – 12 - 17 1244 – 11 - 10 1592 – 6 - 14 Local_Server_2 1104 – 13 - 11 1321 – 10 - 24 1501 – 5 - 18 Local_Server_3 1281 – 12 – 8 1309 – 13 - 19 1159 – 7 - 16 DMS 2010 – Chicago, IL

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 DMS 2010 – Chicago, IL