Designing the Architecture of P2P-Based Network Management Systems

Designing the Architecture of P2P-Based Network Management Systems Andr´e Panisson, Diego Moreira da Rosa, Cristina Melchiors, Lisandro Zambenedetti Granville, Maria Janilce Bosquiroli Almeida, Liane Margarida Rockenbach Tarouco {panisson, diegoro, granville, janilce}@inf.ufrgs.br, {cristina, liane}@penta.ufrgs.br Institute of Informatics – Federal University of Rio Grande do Sul Av. Bento Gonc¸alves, 9500 - Bloco IV – Porto Alegre, RS - Brazil

Abstract P2P-based network management has been recently proposed. However, the entities involved in this new management model have not been detailed up to today. In this paper we introduce the internal architecture of management peers. According to the set of elements internally employed, a management peer may act in the role of a top level or mid level manager, or in the role of a hybrid entity with mixed duties. The presented architecture can then be used as basis for the development of P2P-based management systems, such as the system prototype we also present in the paper. Keywords: Network Management, Management Components, Peer-to-Peer.

1 Introduction Network management is a critical discipline whose main objective is to keep the communication services of organizations working properly in order to allow computers to exchange information in a fast and reliable way. Neglecting network management to a secondary plane usually results in weak networks and, most important, economic losses due to communication failures. Several network management models and technologies have been proposed and investigated, from simple centralized manager-agent models [8] to more sophisticate but usually unemployable approaches using mobile agents [2] and artificial intelligence [10]. Recently, with the deployment of distributed processes across virtual organization (VO), the increasing use of the Internet as a transit network, and the adoption of distributed computing models such as grids, the necessity of new highly distributed network management models has been sensibly growing. In such a new scenario, traditional management models fail because they were conceived to operate in the restricted environment of a single network administrative domain, while modern management requires operations to be executed along different domains

in a distributed fashion. In addition, entities of modern managed multi-domain networks are autonomous from entities of other domains in the sense that they are concerned only about their own local duties, being free from other entities forcing them to accomplish an external ordered task. The peer-to-peer (P2P) communication model [1], different than traditional management solutions, has been built on the top of Internet protocols in order to operate as very highly distributed systems. Although initially popularized by tools that allow illegal music sharing, today one can find several P2P-based applications devoted, for example, to distributed calculation, voice over IP (VoIP), and content distribution. A P2P network is formed by the set of peers and their logical links. Since P2P networks operate over a physical network, they form overlay networks independent from Internet addressing and routing. This allows the construction of very dynamic and versatile environments able to address problems of diverse computer science disciplines, which include network management. This is particularly interesting because P2P fits well in the currently required highly distributed network management mentioned before. In this paper we present the conceptual model and practical experiences in evaluating the P2P approach for network management [6]. In particular, we elaborate on the design of P2P-based management architectures focusing on key management entities such as top-level and mid-level management peer. In order to effectively materialize P2P-based network management, we introduce the definition of basic building blocks for P2P-based management systems. The integration of P2P-based management entities with traditional management solutions, such as the SNMP framework [7]), is introduced as well. In addition, we present a system prototype developed to evaluate the P2P-based management approach: the evaluation tests and associated results are also presented and analyzed. The remaining of this paper is organized as follows. In Section 2 we review the P2P-based network management model, while in Section 3 we describe the basic building blocks used to construct P2P-based network management

Proceedings of the 11th IEEE Symposium on Computers and Communications (ISCC'06) 0-7695-2588-1/06 $20.00 © 2006 IEEE

architectures. Section 4 presents our system prototype and describes its associated Application Programming Interface (API) to be used by developers of P2P-based management software. In Section 5 we evaluate the P2P-based management approach presenting some performance results and a comparison between SNMP and P2P for management. Finally, Section 6 closes this paper presenting concluding remarks and future work.

The P2P-based network management model redefines the roles of three main traditional management entities: top-level manager (TLM), mid-level manager (MLM), and agents. Figure 1 shows a hypothetical management scenario where the P2P-based network management model is used.

2 The P2P-Based Network Management Model Network management is traditionally accomplished by the manager-agent model [8]. In such a model, network managers query agents (normally located inside network devices) in order to retrieve or set the devices’ management information. Usually, agents are also able to asynchronously report to interested managers the changes occurred in the status of managed devices, issuing event messages (or notifications). Besides being currently widely deployed, the manager-agent model is also strongly supported by standardization bodies. For example, the core SNMP framework [7], defined by the Internet Engineering Task Force (IETF), is based on the manager-agent model. From time to time, new management models that extend the manager-agent model are defined, usually resulting in more sophisticate solutions and introducing new management entities with special duties. For example, in the management by delegation (MbD) [4] approach managers can delegate to other managers the responsibility of executing management tasks. Here, mid-level managers (MLMs) are entities that act in the role of agents when receiving delegated tasks from higher level managers, but also act as managers when managing lower level agents, that may happen to be other lower level MLMs. P2P networks [9] are overlay networks composed of nodes (peers) located in the edges of the Internet, usually in inexpensive personal computers. P2P networks are able to self-organize, adapt to network faults, and support nodes with intermittent connectivity. Modeled using totally decentralized or partially decentralized architectures, a P2P network uses resources distributed in several peers in order to implement applications such as file sharing, distributed computing, and cooperative work. As in MbD, the P2Pbased network management model [6] extends manageragent incorporating in this model features and characteristics of P2P networks, such as highly distribution of entities, self-organization, fault tolerance, proper scalability, and ad hoc connectivity. These features allows the improvement of current management systems, for example, by enabling the introduction of proper support for inter-domain management, reliable management messages exchange, and load balancing of management tasks.

TLM

MLM for device access

Managed device with agent

Figure 1. P2P-based network management model TLMs are defined as management peers that host graphical user interfaces (GUIs) used by remotely located human operators to communicate with one another in order to accomplish a management task in a cooperative fashion. Essentially, TLMs provides the management front-end using not only traditional management visual facilities (e.g., topology maps, alarm lists) but also P2P collaboration services (e.g., instant message, file sharing, multi-user document editing). MLMs are peers that react to TLMs or other MLMs requests providing reliable communication services between management entities via application-layer routing. Some special MLMs are peers responsible to retrieve information directly from managed devices contacting the devices’ agents. These MLMs work as protocol gateways that translate P2P traffic to management traffic when interacting with managed devices. A key concept of the P2P-based network management model is notion of Management Service. A Management Service is a service provided by management entities to other management entities and whose result is the execution of a management task. Each Management Service is addressed by its service identification and reached through a P2P management network regardless the location of the entities (peers) that provide and expose the service. A basic Management Services is the one implemented by MLMs for device access: the service allows remote peers to retrieve information from physical devices throughout a MLM for device access. In fact, MLMs can also be organized in groups of peers to expose Management Services. In this case, a Management Service, instead of being provided by a single MLM,

Proceedings of the 11th IEEE Symposium on Computers and Communications (ISCC'06) 0-7695-2588-1/06 $20.00 © 2006 IEEE

MLM

is provided by a group of MLMs. From the service user perspective, however, these service provisioning details (e.g., number of peers in a group, the location of each peer in the P2P network) are transparent: the user are interested in the Management Service itself, and do not need to worry about the service implementation. Organizing MLMs in group of peers eases the administration and improves the availability of Management Services because while at least one peer is active in a group, the Management Services of such group will be available to the remaining network. In a group with more then one peer, if one MLM goes down the group’s Management Services will still be provided because other MLMs implement the same services. Of course, if a group lost all its peers no Management Service will be provided: thus a pro-active self-management of the members of a group is required in P2P-based network management. Finally, the last entity of a P2P-based management system is its agents (e.g., SNMP agents), which are software daemons (but not peers) normally located inside managed devices that, under request of MLM gateway peers, retrieve or change the status of managed devices and report devicerelated events issuing notifications.

3 Building Blocks for P2P-Based Network Management Architectures In this section we introduce the basic building blocks required to create P2P-based management architectures that follow the previously presented management model. To do that, we focus and detail the components of a management peer (Figure 2) and present how such components interact with one another in order to provide a P2P-based management infrastructure. Peer TLM Profile

MLM Profile Container

User Application

descriptor

Communication Service

Management Component

Managed device with agent

P2P Services

Figure 2. P2P-based network management system architecture

Each management peer may present two different profiles: the TLM profile and the MLM profile. While a pure TLM peer has only the TLM profile and a pure MLM peer has only the MLM profile, a management system may have hybrid peers that implements the two profiles at the same time.

The TLM profile presents a set of visual facilities that forms the management GUI. Each peer with the TLM profile may have a different set of visual facilities, thus presenting different management front-ends. Those facilities used to directly connect human operators (e.g., instant message, topology map sharing) need to be present on each party of a communication, otherwise the human information exchange would be compromised. At the MLM profile side we find the most basic element of a MLM: the Management Component. Management Components are responsible for implementing the Management Services offered to remote management peers. Management Components and associated Management Services may vary from very simple ones (e.g., a protocol gateway to access management devices via SNMP, SSH, or HTTP) to more complex ones (e.g., support for script execution, traffic metering and monitoring). Management Components are described in the descriptor element (to be detailed in the next section) and controlled by compositive elements named Containers. Containers intermediate the communication between Management Components and the remaining P2P management system using a Remote Procedure Call (RPC) paradigm that can be implemented, for example, using Web services [3]. This allows Containers to control the access to Management Components, preventing unauthorized clients to have access to protected Management Services. Containers also administrate the life cycle of Management Components, being responsible for instantiating Management Components, publishing their description and associated Management Services, and replying searching queries issued by other peers that are looking for particular Management Services. A Container may additionally enforce restrictions related to the computing resources a Management Component can use during its execution, for example, limiting the amount of volatile and non-volatile memory, CPU processing power, and execution priority. The Management Services implemented by the set of Management Components are advertised, searched, discovered, and invoked in a P2P management network via Communication Services. Communication Services are P2P meta-services that each peer interested in participating in the management process must instantiate. Both TLM and MLM profiles use the Communication Services. TLMs instantiate Communication Services to search and use Management Services. MLMs, in turn, instantiate Communication Services to advertise Management Services. In order to exemplify how all these elements interact with each other to accomplish a management task, we present the followings steps depicted in Figure 3: 1. TLM searches for a Management Service; 2. MLM receives the search request and replies with the

Proceedings of the 11th IEEE Symposium on Computers and Communications (ISCC'06) 0-7695-2588-1/06 $20.00 © 2006 IEEE

Management Service information; 3. TLM receives the Management Service information; 4. TLM makes a request to one of the Management Service operations; 5. MLM receives the operation request and pass the execution flow to the Container; 6. The Container invokes the operation on the Management Component; 7. The Management Component accesses the network agent; 8. After the Management Component performed its job, it returns the resulting data to the Container;

Management Components in a peer Container. The use of this API allows Containers to instantiate, initialize, and call the operations of Management Components implementing Management Services. The MComponent interface is the central abstraction of the Management Component API. All Management Components implement this interface either directly or, more frequently, by extending the GenericMComponent class that also implements the interface. Figure 4 represents the Management Component API. MComponentConfig

MComponent + init(config : MComponentConfig) : void + getMComponentConfig() : MComponentConfig + getMComponentInfo() : String + destroy() : void

+ getMComponentName() : String + getMComponentContext() : MComponentContext + getInitParameter(name : String) : String + getInitParameterNames() : Enumeration

- config GenericMComponent

9. The Container sends the Management Component’s response to the TLM;

+ GenericMComponent() + destroy() : void + getInitParameter(name : String) : String + getInitParameterNames() : Enumeration + getMComponentConfig() : MComponentConfig + getMComponentContext() : MComponentContext + init(config : MComponentConfig) : void + init() : void + getMComponentName() : String

10. TLM receives the response and performs next additional management tasks.

MyManagementComponent

TLM

MLM

+ init() : void + operation(params : Object[]) : Object + destroy() : void

Container Management Component

User Application

1

6

4 3

10

2

Communication Service

P2P Services

5

8

7

9

Communication Service

P2P Protocols

Figure 4. Management Component API

Managed device with agent

P2P Services

Figure 3. Steps of interaction between elements of the architecture

We also defined an API for Management Services. Through this API, Containers in MLMs can publish Management Services using JXTA advertisements, while TLMs can search, find, and invoke operations of remote Management Components. Figure 5 shows the interface of the Management Services API.

4.2

4 Implementation of a P2P-Based Management System Prototype Our implementation of a P2P-based management prototype has been coded in Java, using the Sun’s P2P JXTA framework [5] as the underlying P2P infrastructure. In the following subsections we detail this prototype design and implementation.

4.1

Interfaces for the Management Component and the Management Services

In our implementation, we have defined an Application Programming Interface (API) that developers of new Management Components must use in order to integrate their

A Management Component is managed through a well defined life cycle that specifies how the Component is loaded, instantiated, and initialized, how it is requested to handle operations, and how it is unloaded. The load and unload phases are expressed in the Management Component API by the init and destroy methods of the MComponent interface. Containers are responsible for loading and instantiating Management Components. Loading and instantiation occur when the Container is started. The Container first loads the Management Component classes using regular Java class loading facilities. After loading each Management Component class, the Container instantiates components objects to be used. After instantiation, the Container must initialize each Management Component object before operations can

Proceedings of the 11th IEEE Symposium on Computers and Communications (ISCC'06) 0-7695-2588-1/06 $20.00 © 2006 IEEE

Management Components Life Cycle

CommunicationService + searchManagementSvc(srch : String, type : String, listener : ManagementListener) : void + getManagementSvcInCache(srch : String, type : String) : Enumeration + publishManagementSvc(adv : ManagementSvcAdvertisement) : void + addListener(listener : ManagementListener) : void + removeListener(listener : ManagementListener) : boolean + getManagementSvc(adv : ManagementSvcAdvertisement) : ManagementService

ManagementService + getManagementSvcAdvertisement() : ManagementSvcAdvertisement + getOperations() : Operation[] + getOperation(opId : String) : Operation

Operation

ManagementListener

+ execute(args : Object[]) : Object

+ managementEvent(event : ManagementEvent) : void

ManagementEvent + ManagementEvent(source : Object, advertisement : ManagementSvcAdvertisement) + getManagementSvcAdvertisement() : ManagementSvcAdvertisement - advertisement ManagementSvcAdvertisement - name : String - description : String - type : String - id : ID

Figure 5. Management Service API be invoked. Initialization is provided so that a Management Component can read persistent configuration data, initialize costly resources, and perform other one-time activities. The Container initializes the object instance by calling the init method of the MComponent interface with a single object implementing the MComponentConfig interface. This configuration object allows the Management Component to access name-value initialization parameters from the peer’s configuration information. The configuration object also gives the Management Component access to an object (implementing the MComponentContext interface) that describes the Management Component’s runtime environment. During initialization, the Management Component object may fail to perform some task and then throws an exception. In this case the Management Component becomes unavailable and is released by the Container.

4.3

Advertising, Searching, and Using Management Component Operations

The set of operations of a Management Component is known by the Container after the component class loading. The Container uses the Java Reflection API to discover all public methods of each component class. The signature of each method is used as the operation identifier. The only public methods that are considered as operations are those methods that implement the MComponent interface.

The components descriptor is an XML document that describes the Management Components to instantiate, the name and type of each Management Component, and the Java class to be used. The descriptor is organized by the XML element, where each element informs the init parameters that will be used to create a MComponentConfig object, used during initialization of the Management Component. The descriptor also contains an element that indicates a class that know all information about how the Container will handle access control to the operations of Management Components. This class check the user credentials and verifying whether the user has access to execute the called operations. The Container uses the set of operations, the information and init parameters conveyed by the Components descriptor to construct the ManagementSvcAdvertisement. The ManagementSvcAdvertisement, an XML document that describes all Management Component information and functionalities, is published to the P2P network using the Communication Services API. In the Components descriptor, a service identifier (also known as group identifier) is associated to each Management Component. When the Management Component is instantiated, the Container, verifies the existence of a group identifier, and inserts the Management Component in that group, or creates a new group if it does not exist yet. All Management Components that join a group have the same operations. These operations, exposed by the Container, form the Management Services. The Management Services are then provided by the group of all peers that have an instance of that Management Component. In this way, groups of peers improve the availability of the Management Services, as the services of a group are available to the remaining system as long as there is at least one peer active in that group.

4.4

The Management Component is also able to discover other Management Components in the same group, and start a communicate with them. Through this, Management Components can do state synchronization and selfmonitoring, checking the group for a reasonable number of active Management Components, ensuring that a group will not become empty and thus avoiding group services unavailability. When the number of members falls to a critical value, TLMs are notified indicating that the Management Services of a group are in danger. The set of Containers that own an instance of a particular Management Component also participates in the group, which also enables not only the direct communication among Management Components, but also the direct communication among the Con-

Proceedings of the 11th IEEE Symposium on Computers and Communications (ISCC'06) 0-7695-2588-1/06 $20.00 © 2006 IEEE

Intra-group Components Communication

proaches, for instance, validation using LDAP servers. Traditional technologies, in contrast, are very dependent of the protocol implementation, while in technologies such as SNMP the access restriction can only be performed by the physical network structure. Other benefits are related to the programming language and APIs used. The Management Components API developed has all the advantages of the Java language, including ease of development and platform independence. Besides, it use a standard API (JXTA) supported by many P2P platforms and was developed using the P2P services provided by the underlying P2P system.

5 Evaluation Although the use of P2P technologies for network management bring interesting advantages over traditional management approaches, it may also impact on the management performance. In order to evaluate such impact, we have tested our system prototype using Management Components that implements P2P to SNMP gateways to access SNMP-enabled managed devices. We then measured how long each phase of the system prototype life cycle lasts. Many measurements presented in this Section deeply depend on the P2P platform adopted. In our case, using the JXTA framework, much of the time is spent in connecting to application level routers and JXTA rendezvous [5]. Figure 6 shows the measures of each phase.

Phase

tainers of such Components. In our implementation, groups are managed through the PeerGroup Services of the JXTA platform [5]. The existence of groups of Management Components enable the load balancing between instances of Management Components in the same group. If a single peer has a Container that is responsible for instantiating a Management Component to provide its Management Services, this peer can easily have performance problems; but the use of groups allows the distribution of tasks. The Container, through load balancing policies that is implemented by the group, verifies to which Management Component instance in the group the request need to be forwarded, avoiding overloaded peers to receive further requests that could be performed by less loaded peers. In this way, the Containers themselves control the distribution of management tasks, contrasting with traditional management by delegation, where TLMs are responsible for the distribution of tasks. Some management tasks like network analysis, script execution, and accounting fall in this category of tasks that demand a high amount of resources. After a Management Component is properly initialized and its Management Services are published, the Container use it to handle TLM requests. TLMs search for ManagementSvcAdvertisements, and call Management Component operations through Communication Services, passing an array of objects as argument to the operation. The Container receives the operation request, and do all tasks related to the Container, such as access control and load balancing. After that, the Container passes the arguments to the proper Management Component method, calling it through the Java Reflection API. The returned object of the method is then sent to the TLM as a response to the operation call. If an exception occur during the method execution, that exception is sent as result to the TLM.

Container Initialization P2P Services Initialization Communication Services Initialization Management Component Initialization Management Service Publishing Management Service Search Operation Request Load Balancing Access Control Network Device Access Operation Response 0

4.5

Further Aspects of the P2P-Based Management Architecture and APIs

2000

4000

6000

8000

10000 12000 14000

Time Average (ms)

Figure 6. Time Spent in each phase In functionality, Management Components lie somewhere between gateway managers, but have advantages over other gateway mechanisms. The architecture and API presented have characteristics that provides benefits to network management deployment. One important aspect of the architecture is that a Management Component can be instantiated in different peers, at different Containers. In this way, the multiple instances of the same Management Component at different peers can provide fault tolerance and load balance functionalities inherent to all P2P systems. Besides, access control functions are performed through implementations in Containers. These functions can be implemented using several access control validation ap-

The independence of protocol achieved with the use of this model allows the development of more optimized and sophisticate levels of communication between the user application and the MLMs. Compared with the traditional management protocol SNMP, for example, such advantages can be noticed when management tasks that require several messages between SNMP managers and SNMP agents need to be executed. Figure 7 shows the delay when downloading the routing table of a network device located at a different domain. While SNMP download time is proportional to the delay between agent and manager times the number of routing table entries, the use of the P2P architecture turns down the download time proportional to the number of bytes that

Proceedings of the 11th IEEE Symposium on Computers and Communications (ISCC'06) 0-7695-2588-1/06 $20.00 © 2006 IEEE

need to be exchanged, due to the fact that only one reply needs to be sent to the TLM. 6000

Download delay (ms)

5000 4000 SNMP

3000

P2P

2000 1000 0 0

20

40

60

80

100

120

Number of routing table rows

Figure 7. Time required to download the routing table of a network device

ditional management approaches, such as the widely deployed SNMP framework. One of the key features of a P2P-based management architecture is the notion of group of peers, where a set of Management Components implementing the same Management Services are grouped together in order to provide more reliable services in terms of service availability. A future work of our research is to evaluate this important feature when used in the context of large management networks (e.g., with more than 1000 managed devices). In addition, further research is required to develop load balancing algorithms specifically devoted to balance the execution of network management tasks, such as monitoring and distributed network configuration.

References These results show that besides providing interesting new features, the performance of P2P-based network management is not a major problem, at least compared with the performance of SNMP. This is important because the performance of a management system needs to be adequate with the network to be managed.

6 Conclusions and Future Work In this paper we have defined the basic building blocks required to develop management architectures that follow the P2P-based network management model. According to the building blocks used inside a management peer, such a peer acts as a top-level manager, a mid-level manager, or a hybrid management entity with mixed roles. We also introduce Communication Services that are used by TLMs to search and use Management Services implemented by Management Components. MLMs also use the Communication Services to advertise the Management Services implemented by internal Management Components. In addition, MLMs implement Containers that provide access control and manage the life cycle of these internal Management Components. All these elements are administered through two APIs also introduced: the Management Components API and the Management Services API. We have also presented the design and implementation of a P2P-based network management system prototype used in this paper to evaluate the P2P-based management model. In such evaluation, we have measured the performance of our prototype when a set of management operations needs to be executed. In addition, we have compared the P2Pbased approach against SNMP (the de facto TCP/IP management solution) when retrieving routing tables with increasing number of rows. The evaluation results showed that with proper care the performance of a P2P-based management system may be better than the performance of tra-

[1] S. Androutsellis-Theotokis and D. Spinellis. A Survey of Peer-to-Peer Content Distribution Technologies. ACM Comput. Surv., 36(4):335–371, 2004. [2] A. Bieszczad, B. Pagurek, and T. White. Mobile Agents for Network Management. IEEE Commun. Surveys Tuts., 1(1):2–9, September 1998. [3] F. Curbera, M. Duftler, R. Khalaf, W. Nagy, N. Mukhi, and S. Weerawarana. Unraveling the web services web: an introduction to soap, wsdl, and uddi. IEEE Internet Computing, Vol. 6, Issue 2, pages 86–93, March/April 2002. [4] G. Goldzmidt and Y. Yemini. Distributed Management by Delegation. 15th Int’l. Conf. Distrib. Comp. Sys., pages 333– 340, May/June 1995. [5] L. Gong. JXTA: A Network Programming Environment. 5(3):88–95, 2001. [6] L. Granville, D. Rosa, A. Panisson, C. Melchiors, M. Almeida, and L. Tarouco. Managing Computer Networks Using Peer-to-Peer Technologies. IEEE Commun. Mag., 43(10):62–68, October 2005. [7] D. Harrington, R. Presuhn, and B. Wijnen. An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks. RFC 3411, STD 62, Dec. 2002. [8] ITU-T. Recommendation X.701 - Systems Management Overview, Aug. 1997. [9] D. S. Milojicic, V. Kalogeraki, R. Lukose, K. Nagaraja, J. Pruyne, B. Richard, S. Rollins, and Z. Xu. Peer-to-Peer Computing. Technical Report HPL2002-57, Palo Alto: HP Laboratories, March 2002. http://www.hpl.hp.com/techreports/2002/HPL-200257.html. [10] M. Mountzia and G. Rodosed. Using the Concept of Intelligent Agents in Fault Mananagement of Distributed Services. J. Net. and Sys. Mgmt., 7(4):425–446, 1999.

Proceedings of the 11th IEEE Symposium on Computers and Communications (ISCC'06) 0-7695-2588-1/06 $20.00 © 2006 IEEE