UBC Theses and Dissertations

UBC Theses Logo

UBC Theses and Dissertations

Agent-based network management system Luo, Huawen 2002

Your browser doesn't seem to have a PDF viewer, please download the PDF to view this item.

Item Metadata


831-ubc_2002-0479.pdf [ 7.29MB ]
JSON: 831-1.0051383.json
JSON-LD: 831-1.0051383-ld.json
RDF/XML (Pretty): 831-1.0051383-rdf.xml
RDF/JSON: 831-1.0051383-rdf.json
Turtle: 831-1.0051383-turtle.txt
N-Triples: 831-1.0051383-rdf-ntriples.txt
Original Record: 831-1.0051383-source.json
Full Text

Full Text

Agent-based Network Management System by Huawen Luo B.Sc, YunNan University, 1996 M.Eng., Beijing Institute of Technology, 2000 A THESIS SUBMITTED IN PARTIAL F U L F I L L M E N T OF THE REQUIREMENTS FOR THE DEGREE OF Master of Science in THE F A C U L T Y OF G R A D U A T E STUDIES (Department of Computer Science) We accept this thesis as conforming to the required standard T H E UNIVERSITY OF BRITISH C O L U M B I A August 2002 © Huawen Luo, 2002 In presenting t h i s thesis i n p a r t i a l f u l f i l m e n t of the requirements for an advanced degree at the Un i v e r s i t y of B r i t i s h Columbia, I agree that the Li b r a r y s h a l l make i t f r e e l y a v a i l a b l e f o r reference and study. I further agree that permission for extensive copying of t h i s thesis f o r s c h o l a r l y purposes may be granted by the head of my department or by his or her representatives. I t i s understood that copying or p u b l i c a t i o n of t h i s thesis for f i n a n c i a l gain s h a l l not be allowed without my written permission. Department of L^-^U^y ^ U & ^ The U n i v e r s i t y of B r i t i s h Columbia Vancouver, Canada Date ^Qpt^Uy $Q . 2 - ^ 7 Abstract Contemporary network management systems as represented by Simple Network Management Protocol(SNMP) are based on the client-server centralized paradigm which may lead to inefficiency when the managed networks are large in scale. Mobile Agent(MA) as an approach has been investigated by many researchers. M A can be used to alleviate the manager workload and reduce the bandwidth usage by delegation of authority from manager to M A . M A could also be instantly customized by user's requirement. It can be launched from the manager, visiting each network element according to the itinerary table, computing and compressing the management data locally, only returning the result back to the network manager. There are several benefits: distribution of management workload; adaptability and flexibility; programmability and customization. A mobile agent based network management system has been implemented using the JADE agent platform. The network element's status monitoring platform is supported and several performance management applications are implemented using mobile agent, such as SNMP table filtering, global filtering. Issues related to security and scalability are also discussed. ii Contents Abstract i i Contents i i i L ist Of Tables v List o f Figures vi Acknowledgements vi i Dedication vi i i 1 In t roduct ion 1 1.1 Motivation 1 1.2 Goal 2 1.3 Thesis Outline 2 2 Background 4 2.1 JADE 4 2.2 Network Management 6 2.2.1 SNMP 6 2.2.2 MbD 8 2.2.3 R M O N 9 2.2.3 M A 9 3 System Design and Implementat ion 11 3.1 System Architecture 11 3.1.1 Network Manager 11 3.1.2 Network Element 13 3.2 Manager Agent 13 i i i 3.2.1 Communication of those Components 14 3.2.2 Manager Agent Behaviours 16 . Manager Agent Behaviours' Scheduling 16 Implementing Agent Behaviour Classes 17 3.3 Daemon Agent (NEAgent) 19 3.4 Health Function (Performance Indicators) 20 3.5 Message Definition 23 3.6 Example Communication of Manager Agent with Daemon Agent 24 3.7 Mobile Agent(MA) 25 3.7.1 SNMP Table Filtering 26 3.7.2 Global Filtering 30 4 Related Problems 33 4.1 Security Problem 33 4.1.1 Protecting NE from Malicious M A 34 4.1.2 Protecting the Important Data in M A 36 4.1.3 Secure the Communication Channel 37 4.2 Scalability 38 5 Conclusions and Future Work 41 Bibliography 44 iv List of Tables Table 3.1 MIB II Variables for Computing Interface Utilization 21 Table 3.2 MLB II Variables for Computing Interface Error Rate and Accuracy 22 Table 3:3 Definition of MIBTreeObjectGet A C L Message 24 Table 4.1 Response Time of SNMP and M A 39 Table 4.2 Communication Overhead of SNMP and Daemon Agent 40 List of Figures Figure 2.1 Software Architecture of One JADE Agent Platform 5 Figure 2.2 The SNMP Architecture 7 Figure 3.1 System Architecture 12 Figure 3.2 Class Components of Manager Agent 14 Figure 3.3 Registeration Example 15 Figure 3.4 Behaviours' scheduling of the Manager Agent 17 Figure 3.5 Code Segment of ManagerNEInMsgBehaviour Class 18 Figure 3.6 Communication between Manager and Daemon Agent 20 Figure 3.7 MainGui of Manager Agent 25 Figure 3.8 SNMP Filtering M A Generator GUI 28 Figure 3.9 SNMP Table Filtering Flow Diagram 29 Figure 3.10 Results Table of SNMP Table Filtering M A 30 Figure 3.11 Example of Global M A Generator GUI 31 Figure 3.12 Global Filtering Flow Diagram 32 Figure 3.13 Results Table of Global Filtering M A 32 Figure 4.1 Authentication of M A 36 Figure 4.2 Encrytion of Data Using JCE API 37 Figure 4.3 Decryption of Data Using JCE API 37 vi A c k n o w l e d g e m e n t s I would like to express my gratitude to my supervisor, Professor Alan Wagner, for his guidance, inspiration and supervision of this thesis. I would also express sincere appreciation to Professor Son Vuong for being my second reader and giving me useful comments for improvement. Many thanks to all my friends at U B C . Without their generous help, continous encouragement and moral support, this work could not have been completed. HUAWEN LUO The Department of Computer Science The University of British Columbia August 2002 v i i To my dearest parents, I 'm nothing without them. Chapter 1 In t roduc t ion 1.1 Motivation Contemporary network management systems as represented by Simple Network Management Protocol(SNMP) are based on the client-server centralized paradigm, where a central station collects and analyses data retrieved from physically distributed network elements. In those systems, management data are stored in a standard structure maintained on the elements to be managed, such as a Management Information Base(MIB) Objects Tree in SNMP. There is a daemon agent at each network element, such as snmpd running on Linux, which periodically fetches and returns management data in response to inquiries from the manager. Network management system based on Client/Server paradigm normally requires transferring large amount of management data between the manager and agents. The large amount of data not only requires considerable bandwidth, but also can cause a processing bottleneck at the manager. As current networks grow larger and more complicated, the problem becomes more severe. The solution to such problem is straightforward; distributing the management mechanism to overcome the limitations of the centralized Client/Server architecture. There are several solutions which have already been put forward, such as Remote Monitoring(RMON) and Management by Delegation(MbD), which introduce some 1 degree of decentralization. A third solution, the use of Mobile Agent(MA) technology to distribute and delegate management tasks has also been investigated[l][9][10][ll][12]. Mobile Agent frameworks have already attracted a lot of attention in recent years. A lot of research is currently being carried out to assess the applicability of agent technology to network management and control environment. It has been argued that M A have some superior features over SNMP, MbD and R M O N [1][13][10]. There is a general agreement that M A can be used to alleviate the manager workload and reduce the bandwidth usage by delegation of authority from the manager to M A . M A is more flexible and could be instantly customized by user's requirement and launched from the manager. It can visit each network element according to the itinerary table, compute and compress the management data locally, only returning the result to the network manager. By moving a portion of the "intelligence" to the nodes where data are resident, many of the management decisions could be taken locally, thus avoiding the transferring of large amounts of data from the remote nodes to the central manager! 10]. 1.2 Goal In order to demonstrate the applicability of M A to network management, we investigated the related problems and implemented a network management system based on mobile agents using the JADE agent platform. Applications implemented in this system are network element's status monitoring, SNMP table filtering, and global filtering. In this thesis, I will describe the architecture, design and implementation details of those applications. I also investigated the security problem of mobile agent. Security is a crucial problem to the feasibility of mobile agent, especially to the network management domain which has stringent security requirements. Finally, we tested the performance of the system and analyzed potential problems. 1.3 Thesis Outline 2 In Chapter 2 we give an introduction to some background knowledge related to the thesis, including a brief overview of JADE, SNMP; a brief description of the R M O N , MbD and M A . In Chapter 3, we give an overview of the architecture of our system and the detailed design and implementation issues are discussed. The related problems, such as securing the whole system and scalability test is explained in Chapter 4. Finally, the conclusions and possible future work are given in Chapter 5. 3 Chapter 2 Background 2.1 J A D E Java Agent Development Environment(JADE) is a software framework to aid the development of agent applications in compliance with the Foundation for Intelligent Physical Agents(FLPA) for inter-operable intelligent multi-agent systems[2]. FLPA is an international non-profit association of companies and organizations sharing the effort to produce specifications for generic agent technologies. JADE complies with FLPA, which includes the Agent Management System(AMS), the default Directory Facilitator(DF) and the Agent Communication Channel(ACC). JADE automatically activates these three agents when the agent platform starts-up. The platform provided by JADE is distributed. It can be split over several hosts with one of them acting as a front end for management and inter-platform communication^]. A JADE platform comprises one or more agent containers, each living in one Java virtual machine(JVM) and providing the execution environment for the agents. There is one Main Container acting as the front end. It has the supervisory control over the JADE platform. The A M S , the DF and the A C C are in the Main Container. The general architecture of one JADE platform is shown in Figure 2.1. 4 1 Host 1 Front-End (Main Container) RMI Registry Message Dispatch A D A A M F G C S E N T • • • C < HOP Host 2 Agent Container A A G G E E N N T T Message Dispatch Java RMI Host 3 Agent Container A A G G E E N N T T Message Dispatch Figure 2 .1: Software Architecture of One JADE Agent Platform Message passing is used to communicate between agents. The FIPA A C L is the language used to represent messages. JADE tries to choose the most efficient way to pass messages between agents as the message protocol. The goal is to minimize the communication overhead. JADE uses three ways to pass messages[5]: 1. Receiver in the same container of the same platform: Java events are used; the cost is a cloning of the ACLMessage object and a local method call. 2. Receiver in a different container of the same platform: Java RMI is used, the cost is a message serialization on the sender side, a remote method call and a message unserialization on the receiver side. 3. Receiver on a different platform: CORBA HOP is used; the cost is the conversion of the ACLMessage object into a String object and an HOP marshalling on the 5 sender side, a remote method call and an HOP unmarshalling followed by A C L parsing on the receiver side. Regarding the agent execution model, JADE uses a thread-per-agent concurrency model instead of a thread-per-behavior model in order to keep small the number of threads required to run the agent platform. JADE uses Behaviour abstraction to model the tasks that an agent is able to perform. Therefore, the agent developer should extend the Agent class and implement the agent-specific tasks through one or more Behaviour classes. Finally behaviours are instantiated and added to the agent. In addition, JADE also provide ready-to-be-used library of FEPA interaction protocols. JADE is still an ongoing project, its development and improvement is continuing. 2.1 Network Management Network management has been the subject of intense research over the last decade, with the relevant progress being twofold: on the one hand, architectures and algorithms for solving management problems have been devised; on the other hand, different management technologies have been proposed and standardized [11]. Currently, network management systems adopt a centralized paradigm represented by SNMP. Although it is a standard protocol, it has many limitations and inefficiency. Most reasons are rooted in the centralized architecture. The rational approach to overcome it is to distribute the network management operations. There are several ways which have been under investigation, Management by Delegation (MbD), Remote Monitoring(RMON), and Mobile Agent(MA). The following will give brief overviews of those approaches. 2.1.1 S N M P 6 The Simple Network Management Protocol(SNMP) was developed in the late 1980's to provide network operators with a simple tool they could use to manage their networks. It has gained widespread acceptance since 1993, making it a standard to manage TCP/LP networks, including individual network devices, and devices in aggregate. The more sophisticated Common Management Information Protocol(CMLP) never replaced SNMP. CMLP has only been deployed in the telecommunication networks and not IP networks. The architecture of SNMP[8] is shown in Figure2.2. It defines a client/server relationship. S N M P Network Management System Network Management Applicat ion get , response trad SNMP Manager UDP LP Link SNMP Messages S N M P Network Managed Device anaged Resource M I B S N M P Managed Object set response trap SNMP Agent UDP LP Link Underlying Network Figure 2.2: The SNMP Architecture The SNMP Manager makes the connections to a SNMP Agent which executes on a remote network device, and serves information to the manager regarding the device's status. The database, controlled by a SNMP agent, is referred to as the SNMP Management Information Base(MIB), and is a standard set of statistical and control values. Directives, issued by the network manager to a SNMP agent, consist of the identifiers of SNMP variables (referred to as MIB object identifiers or MIB variables) along with instructions to either GET the value for identifier, or SET the identifier to a new value. Through the use of private MIB variables, SNMP agents can be tailored for a myriad of specific devices, such as network bridges, gateways, and routers. The definitions of MIB variables supported by a particular agent are incorporated in descriptor files, written in Abstract Syntax Notation(ASN.l) format[7]. The popularity of SNMP is due to a number of features. It could cover a large range of devices to be managed, and it is a very flexible and extensible management protocol. It also proved to be good under poor network conditions. However, SNMP is not a particularly efficient protocol. Bandwidth is wasted with needless information, such as the SNMP version(transmitted in every SNMP message) and multiple length and data descriptors scattered throughout each message[8]. Those shortcoming did not stop the widespread use of it. 2.1.2 MdD The Management by Delegation(MbD) model was proposed in 1991 to address this problem of difficult to manage centralized systems[20]. The key idea behind the MbD approach is to delegate management functions to remote devices in order to reduce communication costs, to avoid a single point of failure, and to increase the scalability of management applications. The management architecture of MbD still includes a management protocol and agents, yet an elastic process run-time support is assumed on each device. Instead of exchanging simple messages, the management station can specify a task by packing into a program a set of commands to agents and send it to the devices involved, thus 8 delegating to them the actual execution of the task. This execution is completely asynchronous, enabling the management station to perform other tasks in the meantime and introducing a higher degree of parallelism in the management architecture. Moreover, since the code fragments(which the authors claim can be written in any language) are not statically bound to devices, they can be changed and re-sent by the management station at any time. This enables more flexibility, because the management station can customize and enhance dynamically the services provided by the agents on the devices[20]. 2.1.3 RMON R M O N assumes the availability of network monitoring devices called monitors or probes. By monitoring packet traffic and analyzing the headers, probes provide information about links, connections among stations, traffic patterns, and status of network nodes. Hence, R M O N can be regarded as traffic-oriented approach because the status of the network is determined by direct inspection of the packets flowing in it, rather than inspection of the status of each device. A probe in R M O N can detect failures, misbehaviors, and identify complex relevant events even when not in contact with the management station, which is likely to happen when the network is overloaded or in critical conditions. In addition, the agent on the probe can also do periodic checking and semantic compression, which further increases decentralization[21]. 2.1.4 MA The emergence of mobile agent frameworks has led many researchers to examine their applicability to network management and control environments. It is believed that mobile agents can provide better solutions at least to performance and fault management problems, given the large amount of data that needs to be transferred in respective solutions based on traditional approaches]!]. 9 Mobile agent frameworks are currently addressed by two standards bodies. The Federation of Intelligent Physical Agent(FIPA)[2] looks at high-level semantically rich interactions between software agents that deploy some form of intelligent adaptability. It has its roots in Distributed Artificial Intelligence(DAI). O M G looks mostly at the issue of mobility according to a standard interoperable framework through its Mobile Agent System Interoperability Facility(MASBF)[5]. In the latter, agent systems model the execution environment able to host mobile agents. 10 Chapter 3 System Design and Implementat ion This chapter describes the design and implemenation of the agent-based network management system. First, I will describe the system architecture and design. Then, I will present the implementation details. This system is created on top of the JADE agent platform. A l l the code is written in Java. 3.1 System Architecture As shown in Figure 3.1, the system consists of two main parts: Network Manager(NM), Network Element(NE). At the N M , there is a Manager Agent which first needs to be created and started up. Network administrator uses it to monitor the network status and control the manipulation of the system through its Graphical User Interface(GUI). At each NE, there is a daemon agent which is dispatched by the N M when the NE registers itself into the management domain. At the N M , there are also Mobile Agent Generators(MAG) which could be used to create customized mobile agents. 3.1.1 Network Manager The N M is the control center for the system. It is responsible for launching mobile agents and displaying the results returned by them. Considering its importance and also for security purpose, users need to be authenticated before logging into the system. After 11 the system checks the correctness of the provided user ID and corresponding passward, it will show the first GUI(register GUI) to users, waiting for the N E to register and join into the management domain. Once one NE has joined the system, the N M dispaths one type of mobile agent, the daemon agent, to the registered N E which remains there until it is killed by the N M or the N E is down. After initialization, the N M communicates with the dispatched daemon agents to do the network status monitoring. Figure 3.1: System Architecture 12 At the N M , users can also use M A G to create the mobile agent skeleton and use the M A G GUI to customize it for specific purposes. After customization, it is dispatched to the rest of the network to do some domain or global management. The functionalities realized by the Manager Agent and related parts are described in the following sections. 3.1.2 Network Element If some NE, such as a router, switch, or workstation, wants to join into the management domain, the mobile agent container needs first to be deployed at the N E or at a nearby polling station if the deployment is inhibited. The container at that N E is then started and the register agent is used to send REGISTER message to N M . Once the message is accepted by N M , N M dispatchs a daemon agent to the N E which resides at the N E for getting and setting the MIB values. For the device to be managed, it needs to support SNMP. At its polling station, we also need to deploy the AdventNet package[24] as the SNMP API to connect with the SNMP agent. 3.2 Manager Agent The Manager Agent is the core part of N M . It performs monitoring and control operations through its interaction with devices runing agent processes. It contains several GUI and behaviour classes as shown in Figure 3.2. GUIs include PasswordGUI, RegisterGUI, MainGUI, MobileGeneratorGUIl and MobileGeneratorGUI2 which are used by N M to view the network. The behaviour classes include GetavailableLocationBehaviour, ManagerNEInMsgBehaviour PingBehaviour, and AgentRegisterBehaviour. 13 Manager Agent — GUI-Behaviour-RegisterGUI PasswordGUI MobileGeneratorGUI 1 MobileGeneratorGUI2 M a i n G U I AgentRegisterBehaviour managerNEInMsgBehaviour PingBehahiour GetAvailableLoctionsBehaviour Figure 3.2: Class Components of Manager Agent 3.2.1 Communication of those components Manager Agent implements its GUIs by extending the jade.gui.GuiAgent class, which is a simple extension of jade.core.Agent class. In JADE, it defines that: A thread(in particular the GUI) wishing to notify an event to an agent should create a new object of type jade.gui.GuiEvent and pass it as a parameter to the call of the method postGuiEvent() of the jade.gui.GuiAgent object. After the method postGuiEvent() is called, the agent reacts by waking up all its active behaviours, and in particular the behaviour that causes the agent thread to execute the method onGuiEvent(). As a consequence, an agent wishing to receive events from the GUI should define the types of events it intends to receive and then implement the method onGuiEvent()[4]. In the Manager Agent, there are two possible means of interaction. First, modifying the GUI when an Agent Communication Language(ACL) message is received. Second, executing some behaviour according to the posted event from the GUI thread because of the user's action through the GUI. The following section illustrates some possible interactions. 14 • Receiving a Register Message RegisterBehaviour is responsible for waiting for the coming register message sent by the NE. After receiving a message, it fetchs the content of the message, gets the NE host name and site location, and calls the doRegister(Location site, String hostname) of the Manager Agent. In this function, it first creates a NEAgent(daemon agent) and sends it to the NE. It then calls the registerGui's method addlist(agentname, hostname) to reflect the updated list in the registerGUI. Finally, it adds the PingBehaviour corresponding to the N E site in the Manager Agent by calling function addBehaviour(new PingBehaviour(this,agentid)). It is responsible for checking the status of the NE just registered. For example, if one NE(host moretti.cs.ubc.ca) wants to register itself into the management domain, it sends the register A C L message to the Manager Agent. After the message is received by the RegisterBehaviour, it informs the Manager Agent. The Manager Agent sends daemon agent NEAgent2(there is a NE lindemans.cs.ubc.ca already registered and NEAgentl has been sent to it) to moretti.cs.ubc.ca and updates the list in the RegisterGUI as shown in Figure3.3. "Ok" means the registered N E is runing fine. It will show "DOWN" whenever the manager finds the N E is down. K Register GUI for ME Agents • H U H NEAgentl <—> lindemans cs.ubc.ca <—> OK NEAgent2 <—> moretti.cs.ubc.ca <—> OK View Monitor Panel Snmp Table Filtering MA Global Filtering MA j Exit | Figure 3.3: Registration Example 15 • Cl ick on the View Mon i to r Panel But ton on RegisterGui At the registerGui shown in Figure 3.3, the administrator may try to view the monitor panel for the chosen N E element from the list by clicking on the View Mon i to r Panel button. This action creates a GuiEvent REG_VIEW_EVENT, sets the parameters as agenffD and hostname and posts it to the Manager Agent. Manager Agent reacts to this event by creating the MainGui and communicating with the chosen NE by sending and receiving A C L messages. 3.2.2 Manager Agent Behaviours Manager Agent Behaviours' Scheduling As previously mentioned, a JADE agent is implemented as a single Java thread. Although it has its own internal thread of control, it can engage in multiple simultaneous conversations. JADE uses the Behaviour abstraction class to model the tasks to that an agent is able to perform and agents instantiate their behaviours according to the needs and capabilities. The Manager Agent must be able to carry out several concurrent tasks in response to different external events. This implies that the behaviours of the Manager Agent must be scheduled cooperatively. A scheduler, implemented by the base Agent class and hidden to the programmer, carries out a round-robin non-preemptive policy among all behaviours available in the ready queue, allowing the execution of a Behaviour-derived class until it releases the execution control on it own. If the task relinquishing the control has not yet completed, it will be rescheduled for the next round unless it is blocked. The Manager Agent has two behaviours, RegisterBehaviour and ManagerNEInMsgBehaviour which are added at the agent setup stage. The behaviour, 16 GetavailableLocationBehaviour, is added when the mobile agent is first created. PingBehaviour is added after a NE is registered with the Manager Agent. Each N E has one corresponding PingBehaviour. The scheduling of behaviours after all behaviours have been added is shown in Figure 3.4. ->RegisterBehaviour -> ManagerNEInMsgBehaviour PingBehaviour l-> GetAvailableLocationBehaviour <-PingBehaviourN ...< Round-robin Non-preemptive Scheduler Figure 3.4: Behaviours' scheduling of the Manager Agent Implementing Agent Behaviour Classes In detail, the agent scheduler executes the action() method of each behaviour present in the ready behaviours queue, when action() returns, the method done() is called to check whether the behaviour has completed its task or not. If so, the behaviour object is removed from the queue. If not, the behaviour is scheduled for next round. There is no stack to be saved and there is no way to interrupt a behaviour in the middle of its action(). As a result, it is important to avoid the use of endless loops and performing long operations within actionQ method. If an operation is too long to be run in a single step, it is broken into several sub-operations. For example, Figure 3.4 lists the code segment of the ManagerNEInMsgBehaviour. In ManagerNEInMsgBehaviour, it is necessary to wait for several kinds of A C L messages from NE, such as Performancelndicator, MIBTreeObjectSet, MIBTreeObjectGet, SNMPTablePolling and Warning. As the code illustrates in Figure3.5, the problem can be solved by calling to receive just one kind of message at a time. While in the interval, it gives other behaviours , such as PingBehaviour, the chance •to execute. 17 class ManagerNElnMsgBehaviour extends SimpleBehaviour I final int FIRST = I; final int SECOND = 2; final int THIRD = 3; private int state = FIRST; public boolean done(){ return false; } public void action() { switch (state){ case FIRST: (opl(); state = SECOND; break;} case SECOND: (op2(); state = THIRD; break;} case THIRD: (op3(); state = FORTH; break;} ; } private void op](){ MessageTemplate ml = MessageTemplate.MatchPerformative(ACLMessage.INFORM); MessageTemplate m2 = MessageTemplate.MatchLanguage("PlainText"); MessageTemplate m3 = MessageTemplate.MatchOntology("performanceIndicators'j; MessageTemplate mlandm.2 = MessageTemplate.and(ml,m2); MessageTemplate andm3 - MessageTemplate. and(mlandm2,m3); ACLMessage msg = my Agent.receive(andm3); if(msg!= null){ System.out.println("per_indi="+msg.getContent()); //post the indicator to the appropriate place ((Manager)myAgent).postlndicator( msg.getContent()); } else return; } private void op2(){ } private void op3(){ } Figure 3.5: Code segment of ManagerNElnMsgBehaviour Class 18 3.3 Daemon Agent (NEAgent) NEAgent is a mobile agent which is created at the time of N E registration. After it is created, it is launched to the NE site and stays there as a daemon agent. As mentioned in the introduction, we could use a mobile agent to move around to fetch data while doing some filtering. Why is it still necessary to have a daemon agent at the N E site? The reason is that we need to monitor the status of the N E and obtain feedback in real time. Mobile Agents could be launched anytime as required. However, if it is not sent out in time, we may miss detecting a fault. It may cause more problems if not handled as soon as possible. This problem could be solved by the daemon agent which will check the current status of the NE, get values and send them back to manager at the time interval set previously by users. NEAgent has no GUI but has several behaviours, NEAgentlnMsgBehaviour, NEPingBehaviour, and CheckPIBehaviour. The class implementation and behaviours scheduling are similar to Manager Agent. NEPingBehaviour is responsible for responding to the ping inquery from Manager Agent and sends the pong message back. NEAgentlnMsgBehaviour checks the messages from Manager Agent, such as setPollinglnterval, getMibValue, stopPolling. CheckPIBehaviour continues computing the required performance indicators at the polling interval after the NEAgent arrived at the NE site. After NEAgent arrived at its destination, it instantiates the InterfaceUtilization class, which tries to negotiate with the SNMP Agent to get the MLB values by using the AdventNetAPI. After computation, it sends the result back to the manager. If the value is higher than a fixed threshold as definded by the user, it sends a warning message back to the N M to notify potential problems that may have occurred or will occur. The NEAgentlnMsgBehaviour listens to the coming GET/SET requirements from the Manager Agent. In the case of a GET message, it checks the value for the specified MLB node in the MLB tree and creates another A C L reply message to send the 19 results back. In the case of the SET message, it tries to set the MLB value according to the user specified new value. If value is successfully set, it informs the manager of the success. Otherwise, it informs the manager of the failure of this operation. Figure 3.6 shows the communication between the manager and daemon agent. It also shows the health function calculation and MIB value getting/setting by the daemon agents. / / ( l ) / (2) / / / o A / //Undpflyin-g' Network '. O) (1) • Migration and execution on the remote node of Daemon Agent ( 2 ) • MIB value or Performance Indicator sending back (3) a Warning message: threshold value is exceeded Daemon Agent O Health function calculation • MIB node value fetching Figure 3.6: Communication between Manager and Daemon Agent 3.4 Health Function (Performance Indicators) Polling is a frequent operation in network management as there are often several object values that require constant monitoring. There are cases however, where one or two MIB variables are not a representative indicator of system state and hence an aggregation of 20 multiple variables is required, known as its health function(HF)[14]. There are several important health functions computed by the daemon agent. • Interface Uti l izat ion Utilization measures the use of a particular resource over time. The measure is usually expressed in the form of a percentage in which the usage of a resource is compared with its maximum operational capacity. Through utilization measures, administrators can identify congestion(or potential congestion) throughout the network[14]. The primary measure used for network utilization is interface utilization. The following formulas is used, depending on whether the connection you measure is half-duplex or full-duplex. Shared L A N connections tend to be half-duplex mainly because contention detection requires that a device listen before transmitting. W A N connections are typically full duplex because the connection is point to point; both devices can transmit and receive at the same time since they know there is only one other device sharing the connection[14]. For half duplex media, use the following formula for interface utilization, the meaning of each parameter is shown in Table 3.1. (iflnOctets + ifOutOctets)*8 *100 ifSpeed * SysUpTime N O T A T I O N E X P L A N A T I O N IflnOctets Represents the count of inbound octects of traffic IfOutOctets Represents the count of outbound octets of traffic IfSpeed The speed of the interface SysUpTime The time duration after the system start up Table 3.1: M I B I I Variables for Comput ing Interface Ut i l izat ion 21 For full duplex media, the following formula is used for interface utilization. For example,with a full T-1 serial connection, the line speed is 1.544Mbps. This means that T-1 interface can both receive and transmit 1.544Mbps for combined possible bandwidth of 3.088 Mbps. max(iflnOctets, ifOutOctets)*8 *100 ifSpeed * SysUpTime However, this method hides the utilization of the direction(in or out) that has the lesser value and provides less accurate results. A more accurate method would be to measure the input utilization and output utilization seperately. • Error Rate and Accuracy Accuracy is the measure of interface traffic that does not result in error and can be expressed in terms of a percentage that compares the success rate to total packet rate over a period of time[14]. It is first necessary to measure the error rate. For instance, if two out of every 100 packets result in error, the error rate would be 2% and the accuracy rate would be 98%. Some common causes of interface errors include[14]: o Out-of-specification wiring o Electrical interface o Faulty hardware or software The following variables are used in accuracy and error rate formulas: NOTATION EXPLANATION IfTnErrors Represents the count of inbound packets with an error IflnUcastPkts Represents the count of inbound unicast packets IflnNUcastPkts Represents the count of inbound non-unicast packets (muticast and broadcast) Table 3.2: MIB II Variables for Computing Interface Error Rate and Accuracy 22 The formula for error rate is usually expressed as a percentage: A iflnErrors HOO Error Rate = ( L\iflnUcastPkts + AiflnNUcastPkts) The formula for accuracy takes the error rate and substracts it from 100: 100 - L\iflnErrors *100 Accuracy = ( l^flnUcastPkts +/StflnNUcastPkts) • IP output datagrams discard rate The discard rate defines the percentage E(t) of IP output datagrams discarded over the total number of datagrams sent during a specific time interval. It is caculated by combining the five MIB-II objectsfl]. (ipOutDiscards + ipOutNoRoutes + ipFragFails)*100 E(t)= IpOutRequests + ipForwDatagrams As described above, the health functions are computed by the daemon agent. Only the final result will be sent back. While in tranditional network management, all the MIB II values will be fetched by the centralized manager. A l l the computation workload are at the manager which degrades its efficiency. Although the daemon agent becomes the static agent once it has arrived at its destination, it also helps release some burden of the manager by doing the health function computation locally. 3.5 Message Definition A C L Messages are transferring back and forth between Manager Agent and Daemon Agent. The A C L messages are one of the following types: • Register and Unregister 23 • Ping and Pong • Performance Indicators • MffiTreeObjectGet • MIBTreeObjectSet • MIBSNMPTablePolling • Warning For example, the A C L Message for MfBTreeObjectGet is defined in Table 3.3: Language PlainText Ontology MTBTreeOjectGet Content (Manager->NEAgent) . Content (NEAgent->Manager) 2 Table 3.3: Definition of MIBTreeObjectGet A C L Message 3.6 Example Communication of Manager Agent with Daemon Agent As an example, Figure 3.7 shows the Monitor Panel(MainGui) of host moretti.cs.ubc.ca. In the health function panel, it shows that the current utilization is 46%, the error rate is 0% and accuracy is 100%, the IP output discard rate is 0%. These data are refreshed at the specified polling interval which will be set by the user and sent to the daemon agent. In the middle panel, the user could choose from the MIB tree which node he/she want to poll or set new value in the set TextField. Users can also poll the table by specifying the table name in SNMP table TextField. In the description TextField, user can also get more detailed information about this chosen MTB tree node. User's requirement will be sent to the daemon agent as the A C L message. After the daemon 24 agent gets the message, checks the value, replies back with the value, the result will be shown at the manager side as Figure 3.7 shows. j ^ ^ t o ^ W i l l for iiiiirelonng HE In ter face U t i l i z a t i o n 46 Set Thresho ld I 1 In ter face Error Rate o Set Thresho ld I In ter face .Accuracy 100 Set Thresho ld I | IP da tag ram d iscarded: 0 Set Thresho ld I i Pol l ing i n te rva l : [To I Seconds Set t h r e s h o l d MIB Tree Obj . loaded MibModuies fig RFC1213-MIB I? Korg S) dod 9 Si internet directory 9 Sj mgmt 9 H m*-2 9 Si s y s f e sys sys Global View SNMP Table Pol l ing Enterred Table name to be po l led : Ok Exit MIBTree Node Descr ip t ion I D e s c r i p t i o n j • • x . Syntax:TimeTicks Access: read-only ; Status mandatory Reference: OID:. MlMode:.iso.org.dod. intern et.mgmt.mib-2.sy stem.sysllpTime j iDescriptionThe time (in hundredths of a second) since the network management portion of the system was last re-init ialized. Set MIB va lue: Get MIB va lue: .1.3 6 1 2 1.1,3.0 < > 27 days, 13 hours, 20 minutes, 0 seconds Figure 3.7: MainGui of Manager Agent 3.7 Mobile Agent (MA) We have implemented two type of mobile agents in the system to do some intelligent filtering applications. The M A can be created through the M A G . One for SNMP table intelligent filtering, the other for global filtering. Those ideas are based on the work in the paper: Advanced Network Monitoring Applications Based on Mobile/Intelligent Agent Technology[l]. The design and implementation is based on the J A D E Agent Enviroment. 25 To quickly create M A and easily tailor it to some specific requirement, mobile agent skeleton are created beforehand. Users can customize the service-oriented M A through the M A G GUI. A M A object is identified by its code(behavioural description), state information(modifiable variables) and attributes(static/permanent information). From the programmer's perspective, MAs are Java classes extending jade.core.Agent class. As defined in JADE, MAs need to be location aware in order to decide when and where to move. The public method doMoveQ of the Agent class allows a JADE agent to migrate elsewhere. The method takes a jade.core.Location as its single parameter, which represents the intended destination for the migrating agent. Moving an agent involves sending its code and state through a network channel, as a result, user defined mobile agents must manage the serialization and unserialization process. Among the various resources, some used by the mobile agent will be moved along, while some others will be disconnected before moving and reconnected at the destination. This is the same distinction between transient and non-transient fields used in the Java Serialization API. For agent migration, the beforeMoveQ method is called at the starting location just before sending the agent through the network(with the scheduler of behaviours already stopped), whereas the afterMoveQ method is called at the destination location as soon as the agent has arrived and its identity is in place. M A also needs to register with the Jade-mobility-ontology by using registerOntology(MobilityOntology.NAME, MobilityOntology.instance()). It contains all the concepts and actions needed to support agent mobility. 3.7.1 SNMP table filtering 26 Most network management applications normally involve the transferring of bulk monitoring data, e.g. large SNMP tables. In SNMP, the SNMP table is obtained by repeatedly using the GET-NEXT operation or using the G E T - B U L K operation. Those methods have some drawbacks. For each GET-NEXT operation, we need to wait for its response before we can go on to the next GET operation. But for each GET, we can only receive one table row. If the table was large, containing thousands of entries, this operation would have apparent impact on network resources. It also experiences significant latency, especially when the management of remote LANs is considered. In addition, the non-negligible time intervals between acquisition of each individual object value leads to potential inconsistencies[l]. The G E T - B U L K operation improves this siduation by transfering bulk of data. But users need to guess previously the maximum number of data to be get. If it is larger than the number needed, more useless data will be fetched and the network usage will be wasted. However, if it is smaller, it may result in too more message exchanges. In addition, the object identifiers(OLDs) of the objects involved in bulk transfers also result in higher overhead because there is a lot of redundancy. M A have the potential to improve the retrieval of SNMP tables in terms of network overhead. M A could be launched to N E where we wish to retrieve SNMP values. Using the successive GET-NEXT request, M A gets the snapshot of the table, encrypts it and saves it. Traditionally, those bulk data fetched back would be filtered by the N M for further analysis. By pushing the filtering operation down onto N E we can significantly reduce the latency and bandwidth needed to obtain the result. Once the M A has the SNMP table it can flexibly filters the values according to a filter saved in it. The filtering expression was defined by the user through the M A Generator GUI. For example, Figure 3.8 shows one customized M A Generator GUI. 27 ~H Mobile Agent Generator Set Mob i l e Aoen t a r g u m e n t s : MA: M o b i l e A g e n t O n e Enter C o l u m n o r HF: A p p l y in t e r m s o f the C o l u m n o r HF i f l n Error Number o f Rows L i m i t a t i o n L im i t n u m b e r o f rows per hos t L im i t o v e r a l l n u m b e r o f r o w s : 10 F i l te r ing t x p r e s s i o n : | i fTable:2 :10$OR : i f lnError :B i g g e r : 7 Ava i lab le s i tes : ID C o n t a i n e r - 2 i S J A D E - I M T P : / / m o r . . . J C o n t a i n e r - 2 C o n t a i n e r - 1 3 > J A D E - I M T P : / / l i n d . . . C o n t a i n e r - 1 M a i n - C o n t a i n e r 3 > J A D E - I M T P : / / . . . M a i n - C o n t a i n e r Select sites to visit Vis i ted Loca t i ons ID N a m e C o n t a i n e r - 2 S > J A D E - I M T P : / / m o r . . . j C o n t a i n e r - 2 C o n t a i n e r - 1 < 1 > J A D E - I M T P : / / I i n d . . . C o n t a i n e r - 1 Ma in -Con ta ine r<S>JADE- IMTP: / / . . . i M a i n - C o n t a i n e r Table: i fTab le F i l te r ing Method : O Match Value O Exclude Value O Maximum Value O Minimum Value • Bigger Value O Lesser Value JADE- IMTP JADE- IMTP JADE- IMTP I X P r o t o c o l JADE- IMTP [SDJE-IMTP M A D n o r e t t i . c s . u b c . c a M n d e m a n s . c s . u b c . c a i s l e e m a n . c s . u b c . c a A d d r e s s m o r e t t i . c s . u b c . c a M n d e m a n s . c s . u b c . c a J E- IMTP s l e e m a n . c s . u b c . c a B U I Figure 3.8: S N M P Table Filtering M A Generator G U I As shown in the Figure 3.8, the user needs to give a name to the M A , which would be used to instantiate itself at the destination. At the table and column TextField, user sets which SNMP table needs to be fetched and which column needs to be filtered. Several columns' filtering could be combined by using " A N D " , "OR". A l l the available NE sites are listed when the M A G GUI shows up. The itinarery table is formed by choosing from the available N E sites and the last destination needs to be set as the Main-Container(where Manager Agent exists). Then M A moves from N E to N E and returns to the starting place to report the results. The example shown in Figure 3.7 is to fetch the ifTable at moretti.cs.ubc.ca, lindemans.cs.ubc.ca and filter according to column iflnErrorfiflnError.value >7). 28 The filtering method can be specified in terms of the following operations: Match, Exclude, Max, Min, Bigger, Less. SNMP table acquired will be fed into those filtering operations, only keeping the row which corresponding columns meet the criteria. Figure 3.9 shows the flow diagram of SNMP table filtering by M A . Arrive at destination and start execution J Get the S N M P table and set the row index to 0 Set rowcount to 0 Set totalcount to 0 check the row according to the filtering expression 1 r Yes encrypt this row in the slot rowcount++ totalcount++ r Migrate to the Manager Figure 3.9 : SNMP Table filtering Flow Diagram 29 The results for the example SNMP table filtering by M A is listed in the table GUI shown in Figure 3.10. H i ® iflndex ifD.. ifT.. if... ifS... ifP... IfA.. ifO.. IfL... I fL . Ifl... ifl... ifl... ifl... ifl... if... ifO... ifO... ifO... ifO... ifO... ifS... moretti.cs.ubc.ca 1 loO so... 8... 1 . . u... up... 0 ... 0 4... 0 0 0 0 0 42... 0 0 0 0 .0.0 2 h... et... 1... 1... u... up... 0 12... 3... 93... 13 0 0 8... 34... 73... 0 0 0 .0.0 lindemans.cs.ubc... 1 loO so... 8... 1... u... up.. 0 ... 0 4... 0 0 0 0 0 42... 0 0 0 0 .0.0 2 h... et... 1... 1 08 u... up... 0 ... 12... 3... 93... 13 0 0 8... 34... 73... 0 0 0 "oo Kill L J ____ — i — Figure 3.10: Results Table of SNMP Table Filtering MA 3.7.2 Global Filtering Another kind of M A can be used for domain or global filtering by comparing/merging the results already saved with those just have been fetched. In this level, M A could bring more benefits. Not only the manager relieved from handling heavy processing tasks, but also the M A ' s state size is prevented from growing rapidly. Right now, in the implementation, we only support domain/global filtering based on the following health functions: InputUtilization, OutputUtilization, IflnErrorRate, IfAccuracy, IPOutputDiscardRate. For example, we may want to fetch the two more heavily loaded interface, the results will be returned back to manager site and displayed in a table GUI. The skeleton for this type of M A is also created beforehand. After user entered the specific requirement in the M A G GUI and click on the CreateandMove button, this M A will be instantiated and customized with those specific features saved in it and brought along with it while migrating. Figure 3.11 shows one example of this type of agent generator. 30 X -M Mobile ftgertt Generator I B M Set Mobile Agent arguments: MA name: Mobi leAgentTwo Filtering Method: O Match Value • Bigger Value O Lesser Value If Accuracy OfOutOctects*8)/(ifSpeed*SysUpTime*100) Input the row limit: 2 input filtering mode: |70 Available sites: ID Name Protocol Address Main-Container@JADE... Main-Container JADE-IMTP Container-2@JADE-IM... Container-2 IjADE-IMTP Container-1@JADE-IM... Container-1 JADE-IMTP albani.es.ubc.ca jlindemans.es. ubc.ca jmoretti.es.ubc.ca Selea sites to visit Visited Locations ID Name Protocol Address Container-1@JADE-IM... Container-1 JADE-IMTP moretti.cs.ubc.ca Container-2 @JADE-IM... Container-2 JADE-IMTP lindemans.es.ubc.ca Main-Container@JADE... |Main-Container JADE-IMTP albani.es.ubc.ca Create and Move Cancel Figure 3.11: Example of Global MA Generator GUI As the example shows, we need to fetch the two NEs whose interface accuracy are the highest among the chosen N E list with at least 70% accuracy. After M A get this task, it will go around, compute and compare, finally return the two NEs names and interface accuracy values back and show in a graphical table. The flow diagram for global filtering is shown in Figure 3.12. 31 Arrive at destination and start execution Get the SNMP table Set totalcount to 0 Filter according to the filtering expression no Yes Sort and compare And keep only the Maxtotalcount line Encrypt the result Migrate to the next host Figure 3.12 : Global Fi l ter ing Flow Diagram The results brought back by global filtering M A customized in Figure3.11 is listed in the the table GUI shown in Figure 3.13. GUI of ni2 H o s t N a m e m o r e t t i . c s . u b c . c a l i n d e m a n s . e s . u b c . c a 100.0 100 0 I f A c c u r a c y m m m K i l l T~~ — = Figure 3.13 : Results Table of Global Fi l ter ing M A 32 Chapter 4 Related Problems The current prototype has demonstrated the usefulness of the properties provided by M A to help N M to do network management. In this Chapter, we discuss some related problems that have arisen during the work. There are also several interesting future directions that could be explored as an extension of this work. First, we discuss the security problem. Second, we address the scalability problem of this system. 4.1 Security Problem Network management normally involves transferring many important management data through the network. Some are critical to the network safe status and disasters may happen if they are evesdroped and improperly set by malicious users. Introducing the M A into this picture brings new security problems because automatically executing code on any host is potentially dangerous. Thus, security plays a decisive role in terms of acceptance and applicability of agent-based network management system. Security issues have been considerred in SNMP. But in S N M P v l and SNMPv2, only a community-based simple security scheme is used. The practice of transmitting community strings(passwords) in clear text posed a severe security problem. The new version, SNMPv3 ,was developed mostly to address this shortcoming. New security features were introduced to ensure message authenticity, integrity and confidentiality, and to provide fine-grained control over access to SNMP capabilities[6][8]. In the system 33 that I developed, the M A needs to communicate with the SNMP to GET/SET MIB object. It uses AdventNetAPI SNMPv3 to ensure more security protection. However, securing the MIB value polling at the N E end is not enough, the whole system is based on Agent-platform, especially relies on M A which needs more consideration of security. Security is a relative concept: it makes no sense to claim a system is secure without explicitly stating what kinds of threats the system can successfully withstand. The threats could be considered in three different ways. First, security threats by a malicious M A ; Second, security threats by a malicious host; Third, security threats from network communication[22]. Considering these three kinds of threats, we tried to protect the network management system in three different ways. 4.1.1 Protecting N E from malicious M A In JADE, after M A arrived at its destination, the NE, it needs to be first instantiated and then executed. It is the container that acts as the complete run time environment for agent execution. Each Agent Container is a Remote Method Invocation (RMI) server object that locally manages a set of agents. It controls the life cycle of agents by creating, suspending, resuming and killing them. In the current version of JADE, there is no security mechanism at this point. The following is the design to secure the M A in this system. After the N E received the serialized instance of the M A , before reconstruct it, the Container at that location needs to verify the authenticity of the received M A through the use of security keys, ensuring only the trusted agents, dispatched by authorized manager, are allowed to be instantiated. The RSA algorithm, based on the public-private pair of keys paradigms could provide both authentication and encryption features. We designed a way to authenticate the M A and make sure the data integrity of the M A . It uses certificates and digital signatures. In digital signature, instead of encrypting the data 34 itself, the signing software creates a one-way hash of the data, then uses the private key to encrypt the hash[17]. The encrypted hash, along with other information, such as hashing algorithm, is known as its digital signature. The digital signature will be sent along with the data to the receiver. The receiver first uses the signer's public key to decrypt the hash. Then receiver uses the same hashing algorithm that generated the original hash to generate a new one-way hash of the same data. Finally, the receiver compares the new hash against the original hash. If the two hashes match, the data has not changed since it was signed. Receiver can also be confident that the public key used to decrypt the digital signature corresponds to the private key used to create the digital signature. A certificate is an electronic document used to identify an entity assiociate that indentity with a public key[17]. It is like a passport to identify a person. A certificate is normally issued by Certificate authorities(CAs). The following describes the authentication of M A for the network management system. Here we assume that the communication channel has already been secured through the use of the Secure Socket Layer(SSL) connection as described in the later section. As well we assume the manager has received the certificate from the CAs. Figure 4.1 shows the authentication step: 0 Manager plans to send a M A agent. It retrieves its private key and uses it encrypt the M A ' s code as the digital signature. © Send the certificate and digital signature along with the M A across the network. CD After N E container gets the M A , it retrieves the public keys from the certificate and try to make sure that the arriving M A is sending from authorized host (Manager) and it has not been tampered with during the traveling. If it passes all the checks, the M A can be instantiated and further executed. ® Travel to the next NE according to the itinerary table. 35 NE n NE2 Figure 4.1 Authentication of M A There are many related issues regarding the Public Key Infrastructure(PKI), such as public key distribution, private key distribution and protection, etc. A l l those are out of the scope of this thesis, interested readers could refer to the paper[17]. 4.1.2 Protecting the important data in M A The whole system's function is based on MAs, both daemon agent and filtering mobile agent. They transfer or carry important management data which needs to be protected from eavesdropping and tampering. I choose the Java Cryptography Enviroment(JCE) API[16] to do the encryption and decryption of the data in M A . In the daemon agent, after it gets the MIB value or computes the health function, it needs to encrypt the data, and send it as the content of an A C L message to the Manager Agent. After the message is received by the Manager Agent, it is decrypted for use. 36 In the filtering mobile agent, after it fetchs the MIB node value and computes the result, it encrypts the data before moving to the next one. At the next stop, if the comparison is needed, it decrypts the data first, does the comparison, re-encrypts the data, and repeats these steps until finally returning back to the manager. At the last destination, the message decryptes and shows the result in the table GUI. In Figure 4.2 and Figure 4.3, the encryption and decryption of a message in the daemon agent are illustrated: SecureRandom sr = new SecureRandom("password".getBytes()); KeyGenerator kg = KeyGenerator.getInstance("Blowfish"); kg.init(sr); SecretKey sk = kg.generateKey(); Cipher bf = Cipher.getInstance("Blowfish"); bf.init(Cipher.ENCRYPT_MODE,sk); byte[] cleartext = "This is the message to be encrypted".getBytes(); byte[] ciphertext = bf.doFinal(cleartext); Figure 4.2: Encryt ion of Data Using J C E A P I // decrypt the data back // fetch the sk bf.init(Cipher.DECRYPT_MODE,sk); byte[] decryptedtext = bf.doFinal(ciphertext); Figure 4.3: Decrypt ion of Data Using JCE A P I 4.1.3 Secure the Communication Channel Although we made an effort to protect the NE and management data, the effort would be useless if the network communication is insecure. The attacker may change the content 37 of the message and intercept the message although he may not able to read the content because of the encryption. So, we need to secure the communication channel. In JADE, the communication is normally through RMI. RMI is a distributed object broker above TCP/LP socket. To make it secure, we only need to secure the TCP/LP socket. We could use SSL. The SSL protocol runs above TCP/IP and below higher-level protocols such as HTTP or IMAP. It uses TCP/IP on behalf of the higher-level protocols, and in the process allows a SSL-enabled server to authenticate itself to a SSL-enabled client, allows the client to authenticate itself to the server, and allows both machines to establish an encrypted connection. The job is not difficult, we just replace the standard socket with the SSL sockets. The version of RMI included in Java 2 SDK enables the RMI developer to use custom socket types. A l l an application has to do is to install the RMI socket factory that creates sockets of the desired type(SSL socket)[19]. 4.2 Scalability We compared two different solutions for gathering MLB-II variables on managed elements to test network overhead imposed by the mobile Agent. SNMP table filtering M A is compared to the centralized SNMP using AdventNet SNMPv3. The topology used on this experiment consists of one management station (sleeman.cs.ubc.ca) and two managed NEs (moretti.cs.ubc.ca, salvator.cs.ubc.ca) interconnected through a 100Mbps Ethernet L A N . A l l machines run Linux Red Hat7.2. The deamon snmpd, which is included in the Linux Red Hat, is an SNMP agent that responds to SNMP request packets. In order to evaluate the performance of two prototypes for a great number of managed elements, we alternately repeat the two elements, e.g., if we want to manage 5 elements, we use an itinerary!moretti, salvator, moretti, salvator,moretti,sleeman}. 38 The M A approach used the SNMP table filtering M A . It fetches the SNMP table and does some filtering based on the user's requirement. The counterpart, centralized solution is implemented using AdventNet SNMPv3 package. The manager sends SNMP UDP packets to a SNMP agent that responds to the manager. The manager sends requests to all elements to be managed, one after the other, .i.e. a new request is started after receiving the response from the previous one, until the last NE receives a request and sends the response to the manager. It has been implemented in Java directly over the Java Virtual Machine. The response time of M A is measured as the meantime of the M A lauching time and returning time. The centralized SNMP approach is measured as the meantime of the first GET message was sent out and the last result fetched back. The following table listed the testing result: Centralized S N M P Approach Mobile Agent Approach 1 host 0.7 Second 0.9 Second 2 host 0.91 Second 1.447 Second 4 host 1.3 Second 1.81 Second 10 host 1.68 Second 3.51 Second 20 host 3.01 Second 6.62 Second 50 host 8.01 Second 16.62 Second Table 4.1: Response Time of S N M P and M A As we can see from the table 4.1, for the listed number of managed elements, the SNMP takes less time than the mobile agent to perform the task. This is due to the fact that the M A is built above Jade which is not efficient for handling mobility. 39 Java as the implementation language had an influence on the speed. The mobile agent infrastructure makes the execution of Java code slower, mainly because of serialization/deserialization, threads creation , handling security and internal message transmission. If the agent platform was written in C code, the speed may not be a problem. This is demonstrated by other graduate students using the W A V E , a mobile agent platform written in C code, to do some similar migrating and fetching data. The speed is much faster than JADE. The SNMP get request/response message is 90 bytes long, on average(at M A C layer), while every extra value included in the SNMP packet's varbind list represents an additional overhead of 17 bytes[l]. Regarding the health function computation, the daemon agent transfers less number of messages comparing to the SNMP method as shown in table 4.2. Thus, the total message size is reduced and the bandwidth is saved. SNMP Daemon Agent Number Total Number Total of Messages Message size of Messages Message size Interface Utilization 4 364Byte 1 36Byte Interface Accuracy 3 275Byte 1 35Byte IP Discard Rate 5 458Byte 1 40Byte Table 4.2: Communication Overhead of SNMP and Daemon Agent 40 Chapter 5 Conclusions and Future W o r k 1. Conclusions Tranditional network management based on centralized architecture has the inefficiency problem when the managed networks are large in scale. M A based approaches have been widely investigated to solve those problems. It has several benefits comparing to the centralized system: • Distribution of Management Workload One of the problems of the centralized system is most of the work needs to be done at the central manager. It needs to fetch and analyze a lot of the management data. If a large number of NEs are involved, the manager becomes the system bottleneck. MAs could be launched with the task delegated to it, which will automatically finish its job and only return those results to the manager. In this way, the manager is not as loaded and can do more things simultaneously. The other good effect is that many management could be taken locally, thus avoiding transfer large amount of data back to the manager. As a result, the network bandwidth usage may also be reduced. • Adaptability and Flexibility Due to its intrisic mobility and no need for pre-installation, mobile agents represent a promising technology to cope with changing environment and user mobility. 41 • Programmability and Customization Mobile agent could be created and customized according to the user's request, enabling dynamic programmable functionality to be provided. The customization of mobile agent behavior can provide a powerful mechanism for "intelligence on demand"[ll]. In this thesis, we have shown how users can use class inheritance to customize basic performance monitoring functions to their needs. On the other hand, while mobile agent has many superior features over centralized one, it has some performance overhead and other related problems. Due to the agent migration, normally remote method invocation, serialization and . deserialization, latency might be a problem. Security is also a crucial issue of mobile agent, especially in the network mangement domain where a more secure enviroment needs to be provided. In summary, we believe that mobile agent as a promising approach to network management could provide a new range of opportunities in the future. But a lot of research is still needed to reach an acceptable usage of M A technology in network management domain. 2. Future Work As described in chapter 4, we have made some effort to make the system more secure. But given the extensive scope of the topic, a complete software implementation of the system is beyond the scope of this thesis. A detailed design and implementation of the whole secure framework should be considered as future works. The current system implemented is only used for network status monitoring and some performance management applications. Enormous number of potential services are possible in the area of network fault and configuration management. More researchers 42 and manufacturers are interested in combining intelligent agents and mobile agents in the area of proactive fault management. Allow mobile agent to have some properties of intelligence and self-healing might help the automation of network management. 43 Bibl iography [1] D.Gavalas, D.Greenwood, M.Ghanbari, Mike O'Mahony. Advanced Network Monitoring Applications Based on Mobile/Intelligent Agent Technology. Computer Communications Journal, special issue on "Mobile Agents for Telecommunication Applications", Jan 2000. [2] F.Bellifemine, G.Rimassa and A.Poggi. JADE - A FEPA-Compliant Agent Framework. Proceedings of the 4th International Conference and Exhibition on the Practical Application of Intelligent Agents and Multi-Agents, UK, 1999. [3] F.Bellifemine, G.Caire, T.Trucco, G.Rimassa. JADE Administrator's Guide http://sharon.cselt.it/projects/jade. [4] F.Bellifemine, G.Caire, T.Trucco, G.Rimassa. JADE Programmer's Guide http://sharon.cselt.it/projects/jade., [5] F. Bellifemine, A . Poggi, and G. Rimassa. Developing multi agent systems with a FIPA-compliant agent framework. In Software - Practice Experience, volume 31, pages 103-128. John Wiley Sons, Ltd., 2001. [6] Simple Network Management Protocol (Software Technology Review) http ://w w w. sei .cmu.edu/str/descriptions/snmp_body .html. [7] J.Case, M.Fedor, M.Schoffstall, J.Davin. A Simple Network Management Protocol (SNMP) RFC 1157, May 1990. 44 [8] DDRI, Diversified Data Resources, Inc. ACE-SNMP An Overview of SNMP. http://www-t.zhwin.ch/it/ksy/Block07/SNMP_Overview.pdf. [9] D.Griffin, G.Pavlou, P.Georgatsos. Providing Customisable Network Management Services Through Mobile Agents. Proc. of the 7th International Conference on Intelligence in Services and Networks (IS&N'OO), Athens, Greece, February 2000. [10] A.Piliafito, O.Tomarchio. Using Mobile Agents to implement flexible Network Management Strategies. Computer Communication Journal, 23(8): 708-719, April 2000. [11] C. Bohoris, G. Pavlou and H. Cruickshank. Using mobile agents for network performance management. IEEE/IFIP Network Operations and Management Symposium (NOMS'00), Honolulu, Hawaii, pp. 637— 652, Apr. 2000. [12] A.Bivens, P.H. Fry, L i Gao, M . F. Hulber, B.K. Szymanski. Agent-Based Network Monitoring. "Agent based High Performance Computing" Workshop at Agents '99 Conference, 1999. [13] M . G. Rubinstein, O. C. M . B. Duarte, G. Pujolle. Scalability of a Network Management Application Based on Mobile Agents. http://citeseer.nj.nec.com/503561.html, March 2002. [14] Cisco White Paper. Performance Management: Best Practices White Paper. http://www.cisco.com/warp/public/126/perfmgmt.htm. [15] D. Gavalas, D. Greenwood, M . Ghanbari, M . O'Mahony. An Infrastructure for Distributed and Dynamic Network Management based on Mobile Agent Technology. Proceedings of the IEEE International Conference on Communications (ICC'99), pp. 1362-1366, June 1999. 45 [16] Java Cryptography Extension (JCE) Reference Guide For the Java 2 SDK, Standard Edition, vl.4 http://java.sunxom/j2se/1.4/docs/guide/security/jce/JCERefGuide.html. [17] Introduction to Public-key Cryptography http://developer.netscapexom/docs/manuals/security/pkin/contents.htm. [18] H. Reiser, G. Vogt. Security Requirements for Management Systems using Mobile Agents. Proceedings of the Fifth IEEE Symposium on Computers and Communications: ISCC 2000, Antibes, France, 3-6 July 2000. [19] A.Poggi, G.Rimassa, M.Tomaiuolo. Multi-User and Security Support for Multi-Agent Systems. Proceedings ofWOA 2001 Workshop, Modena, Sep 2001. [20] G.P.Picco. Understanding, Evaluating, Formalizing, and Exploiting Code Mobility. Ph.D. Thesis, February 1998. [21] M.Baldi, S.Gai, G.P.Picco: Exploiting Code Mobility in Decentralized and Flexible Network Management. Mobile Agents 1997: 13-26. [22] P.Fu. A Security Architecture For Mobile Agent Systems CS-UBC master thesis 2001. [23] H.E.Hia Secure SNMP-Based Network Management in Low Bandwidth Network • Master thesis, Virginia Polytechnic Institute and State University, April. 23, 2001. [24] AdventNet http:// www.adventnet.com/. 46 


Citation Scheme:


Citations by CSL (citeproc-js)

Usage Statistics



Customize your widget with the following options, then copy and paste the code below into the HTML of your page to embed this item in your website.
                            <div id="ubcOpenCollectionsWidgetDisplay">
                            <script id="ubcOpenCollectionsWidget"
                            async >
IIIF logo Our image viewer uses the IIIF 2.0 standard. To load this item in other compatible viewers, use this url:


Related Items