Network Administration Using Web Services - IEEE Xplore

3 downloads 19 Views 514KB Size Report
definition of low level telecommunication services; the use of common interfaces that don't require the operators to know the inner details of each single service; ...

Network Administration using Web Services Paolo Anedda

Luigi Atzori

Department of Electric and Electronic Engineering University of Cagliari Cagliari, Italy Email: [email protected]

Department of Electric and Electronic Engineering University of Cagliari Cagliari, Italy Email: [email protected]

Abstract—This paper investigates the design of a network management solution that relies on the SOA concepts to access low level network services. The intent is to reduce the gap between the application and the network management, by defining an unique view on the management of the technological assets of an enterprise. In the proposed architecture, the single devices as well as groups of devices are accessed using a web service proxy, which is responsible for dispatching the commands to the devices. To expose those functionalities, the proxy makes use of an object oriented library that hides the inner details of the communications with the physical devices. The resulting solution is made of four levels, which have been defined to simplify the typical management procedures and the implementation of the architecture. An architectural prototype has been developed to evaluate the main advantages, which are: the use of a common formalism for the definition of low level telecommunication services; the use of common interfaces that don’t require the operators to know the inner details of each single service; telco services at the higher levels can be obtained as a composition of other services in the lower layers using a composition and coordination logic.

I. I NTRODUCTION One of the major challenges in networking field is the design of networking platforms that allow the operators to easily deploy new services in a dynamically and flexibly way so as to follow the rapid evolution of the user needs and market trends. Herein, dynamicity is intended as the capability of the network to bind on-demand services and relevant resources, often provided by different operators through separate domains, at user request and according to his profile. Even if creating new market-driven applications by reusing an extensible set of existing service components has been a key aspect of telecom platforms for years, this has almost exclusively characterized the application/service layer. Indeed, application provisioning is currently carried out without the cooperation of the lower layers, which are responsible for the delivery of the data between distributed services entry-points. Contrarily, to meet the previously mentioned challenge of dynamically providing on-demand services, there is the need for network management solutions which respond to the following demand: provide the upper layers with interoperable and open interfaces so that dynamic binding of distributed application layer services is synchronized with dynamic activation, configuration and monitoring of networking services, at any layer.

This challenge is the subject of this paper, which specifically investigates the use of the Service Oriented Architecture (SOA) and the Web Services (WS) technologies in this context to leverage the way the network management services are made available internally and externally to the enterprise, whereas maintaining the traditional objectives: performance management, aimed at monitoring, assessing, and adjusting the available bandwidth and network resource usage; configuration management, to gather/set/track configurations of the devices; accounting management; fault management; and security management. In our work we start focusing on the configuration and fault management areas through the definition of different services that participate in the creation of a flexible and adaptable architecture for the management of the networks. In the proposed architecture every service is equipped with a standard web service interface. The access to the network devices is also carried out through simple web servirces. Essentially, a single as well as a group of devices are accessed using a web service proxy that is responsible for dispatching the commands to the devices. To expose such functionalities, the proxy makes use of an object oriented library that hides the inner details of the communications with the physical devices. The final proposed solution is made of four levels, which have been defined to simplify the typical management procedures and the implementation of the architecture. The SOA concepts have been extensively used for the deployment of telecomunication services. However, few works have proposed solutions that exploit the advantages to this approach for the management of network resources at the low network layers. The main advantages of the proposed solution are: the use of a common formalism for the definition of low level telecommunication services; the use of common interfaces that don’t require the operators to know the inner details of each single service; telco services at the higher levels can be obtained as a composition of other services in the lower layers using a composition and coordination logic. This paper is structured as follows. Section 2 discusses related works that are being conducted in this area. Section 3 describes our idea and also comments on design and implementation choices of the system’s architecture. Section 4 presents a practical example and reports on preliminary tests results. Finally, Section 5 presents the conclusions and our plans for future work.

978-1-4244-4148-8/09/$25.00 ©2009 This full text paper was peer reviewed at the direction of IEEE Communications Society subject matter experts for publication in the IEEE "GLOBECOM" 2009 proceedings.

II. R ELATED WORKS Past works have focused on different issues of SOA adoption in the network management field: business concerns, dynamic composition, performance issues, implementations aspects. In the following we briefly review the major papers focused on these aspects. The evolution of SOA concepts in telecommunication from a business point of view is analysed by [1]. It shows how the converge-driven need to deliver seamless services across different access networks has forced operators to embrace new technologies, starting from the Intelligent Network, until the IP Multimedia Subsystem. In [2] instead, the authors trace a brief description of how web services are been used today in the telecommunications. They show how the SOA and the web services have become a major agenda item for the majority of the telecommunication network operators. After presenting a brief survey of SOA and web services, they describe the key enablers in telecommunications: Web services, eventdriven architectures, Parlay X/ECMA specifications [3], and the enterprise service bus. Service composition is a technique that helps in the development of management systems by aggregating smaller services to produce more sophisticated ones. [4] provides a review of service composition in the context of network management. The authors have evaluated the use of traditional management technologies such as the IETF Script MIB, as well as technologies specifically defined to support workflow compositions, like WS-BPEL (Web Services Business Process Execution Language). Their evaluations have been executed considering a management environment composed of BGP routers that need to be monitored in order to detect anomalies related to the advertisement of BGP routes from remote autonomous systems. In [5] instead, authors analyze the use of service composition with respect to the Quality of Service (QoS) aspects. Using an ontology language to describe Web Services, they investigate the issue of QoS driven service selection for composite services and provide some mathematical models for service selectio. Comparing web services with SNMP (Simple Network Management Protocol) is an intensive research area with very important, although preliminary, results. Some studies already show that Web service can consume less bandwidth than SNMP when a large number of management objects needs to be retrieved from a management entity [6]. On the other hand, other studies show that performance issues may prevent the WS usage [7], while one can argue that WS ease of use is an advantage that could surpass the performance aspect [8]. The current Web service versus SNMP investigations are characterized by the fact that they are taken from a quite broad view, where the SNMP is considered in a general perspective, without paying closer attention to particular management situations or scenarios. We believe that such particular situations, however, can reveal aspects of the use of web service for network management that are currently hidden by the broader, more general investigations.

Current network programmability implementations addressing network management are mostly based on legacy distributed programming models such as OMGs Common Object Request Broker Agent (CORBA), Microsofts Distributed Component Object Model (DCOM) and Suns Remote Method Invocation (RMI). To the best of our knowledge there are very few implementations that leverage the emerging web services paradigm for distributed applications. In [9], the authors concentrate on implementing programmable network management and service management applications based on the Web Services distributed technology. They aim at demonstrating that several characteristics of Web Services are perfectly tailored to supporting implementations of Programmable Network Interfaces (PNIs). One of their objectives is to provide a framework for implementing programmable interfaces that comply with the IEEE P1520 [10] initiative and exporting them as W3C Web Services. Furthermore, management information and commands are implemented and exchanged using XML. Thus, Web Services implementations are more lightweight compared to conventional CORBA and DCOM implementations. In [11] the authors outline how the SOA and web services concepts can be a challenge to telecom service providers for the management of their infrastructures. They show how, the migration from the traditionally ITU-Ts FCAP-based model [12] for network management systems to the next generation service management systems based on the eTOM model [13], can be leveraged from the adoption of SOA which provides a very robust integration technology. III. A RCHITECTURE DESIGN In this section we describe our approach in the design of an architecture for the management of next generation telecom services. The deployment of new network management services, starting from a new idea or a new user’s driven need, implies a sequence of actions and processes that span from the service design to the network’s devices configuration. Each of these actions belongs to a specific domain of knowledge and implies different processes that involve different divisions inside the same company. For example, the bandwidth management procedure in Differentiated-Service-aware Traffic Engineering (DS-TE) in Multiprotocol Label Switching (MPLS) networks [14] relies on the possibility to set bandwith constraints in each link of the network according to a general bandwith allocation scheme, computed in real-time, that allows to minimize the network’s bandwith occupation. The deployment of such a service implies the execution of different operations, which span from the physical network device’s configuration, to the collection of the network’s key performances indicators (KPI), through the execution of the code to compute the best bandwidth model to satisfy the Quality of Service (QoS) constraints and the execution of constrained-based routing algorithms. Going from the bottom to the top, starting from the technical operations and ending with the deployment of complex services, the modeling activity proceeds defining different layers, each one with an higher level of abstraction.

978-1-4244-4148-8/09/$25.00 ©2009 This full text paper was peer reviewed at the direction of IEEE Communications Society subject matter experts for publication in the IEEE "GLOBECOM" 2009 proceedings.

The main functionalities of each layer can be associated to different objects and those who share similar funtionalities can be grouped togheter in order to create new independent components. The latters expose those functionalities as services. This approach starts from the basic services to the most complex. The services at the higher levels can be obtained as a composition of other services in the lower layers so, for example, the setting of the QoS parameters in each router can be associated to some specific services while the setting of the overall network’s bandwith constraints can also be implemented by composing the simple services associated with the devices in order to deploy a more complex service for the management of the network’s bandwidth. As depicted in the figure 1, in our work we have identified four different layers. The bottom layer is composed by the services that are responsible of providing access to the network’s devices functionalities. A specific sequence of basic operations can determine a specific process like, for example, the creation of a VLan inside a network. These operations can be associated to specific services belonging to the second layer. The third layer is composed from more specific as well as complex services. These services carry out their job recalling the functionalities of the lower layers. Their behaviour as well as the logic that drive them, can be expressed using workflows of coordinated services. On the top of this pyramid, we found the applications. Applications are the primary interfaces to the final user. They expose the methods to access the system’s resources and allow to deploy vertical services with very specific functionalities. Using common interfaces as well as protocols, operators without any knowledge of the inner details of each single service, can compose new services tailored to their needs. For example, web programmers can deliver applications that make use of network’s devices, without boring with the protocols or primitives for the communication to the devices. Using this approach, integrating a short message service into a portal using an sms proxy equipped with a web service interface, would be very easy. Starting from these principles, in our work we have developed a framework for the construction of such an architecture. For the pratical implementation of these concepts, we choose to use web services as well as standard Internet technologies. Every service is equipped with a standard web service interface. The access to the network devices is also carried out through simple web servirces. Actually, a single as well as a group of devices are accessed using a web service proxy, which is responsible for dispatching the commands to the devices. To expose these functionalities, the proxy makes use of an object oriented library that hides the inner details of the communication with the physical devices. All the proxies constitute the simple services layer. On top of this, complex services are created. The logic behind the complex services, is designed using workflows of coordinated webservices. The implementation of the latters is made using

standard languages for web services workflows as, for example, the BPEL [15] or Jolie languages [16]. The following subsections illustrate the main features of the proposed architecture.

Fig. 1.

The system’s architecture.

A. Simple services: The proxy architecture Almost every network environment is an evolving system in which bleeding edge devices can be used togheter with older apparatus. In such a situation it could be very easy to run into web-services enabled devices; nevertheless, in order to integrate newer as well as legacy devices, it could be very usefull to have a proxy capable of communicating with bare bone hardware trough a common and well known interface. In our architecture, the Web Proxy is the component that grants the access to the network resources. It is the main entry point for each hardware communication. The use of a web-service interface allows to have a common layer to communicate to each device in the network, regardless of its “age”. The inner architecture of the Web Proxy is composed by two main components: the web-service interface and the device communication component. The former exposes the methods available, through a standard web service interface, for the device configuration; the latter is responsible for the device communication details using an ad-hoc communication library. The implementation code of the WS interface is responsible for the mapping of the configuration operations into the specific commands of the device. Each method allows to exploit a single or a group of functionalities available in the device’s operative system. The number of methods available through the WS interface and their input parameters, as well as their output, depends on the level of abstraction chosen during the interface’s design phase. Basically we are supporting two abstraction profiles: a very flexible, but generic interface and a more specific but hard-shelled one. Figure 2 depicts the inner details of the proxy architecture. It is composed by three main components: the web interface layer, the business logic layer and the device communication layer. The interface layer exposes the methods available through a standard web service interface. It is responsible for the management of all the incoming as well as outcoming messaging operation involved in the proxy communication. It supports the SOAP and the REST messaging protocols. The

978-1-4244-4148-8/09/$25.00 ©2009 This full text paper was peer reviewed at the direction of IEEE Communications Society subject matter experts for publication in the IEEE "GLOBECOM" 2009 proceedings.

system. They can represent applications directly accessible by the final user or can offer a business service to other systems. Through the use of standard web services protocols and services’ composition, applications can realize a perfect integration between the telecommunication and the IT worlds.

Fig. 2.

The proxy’s architecture.

business logic layer is constituted by all the code for the realization of the logic behind the methods implementation. Each method of the web interface is translated into a list of specific procedures that are sent to the device using the device layer communication’s primitives. The device communication layer is the component used by the implementation layer to translate the interface’s methods into specific device’s commands. It offers a complete set of primitives that map all the functionalities of the device. The communication layer is also responsible for the communication’s session management. It opens a communication socket with the device’s console and sends all the commands to it using different communication protocols. B. Complex services: realizing a control plane for services orchestration The logic behind the creation and the management of complex services, can be expressed in terms of workflows of business processes, using workflow languages. According to our philosophy to follow the SOA requirements, we choose standard languages such as the BPEL (Business Process Execution Language) and the Jolie language. Workflow languages define business processes that interact with external entities through Web Service operations defined using WSDL 1.1 (Web Service Definition Language, [17]). They define business processes using standard based languages but do not define a graphical representation of processes or provide any particular design methodology for processes. Each business process has inputs, method and outputs and so, also the workflow exports a web-service interface. Workflows can be nested, so it is possible to call a workflow from inside another one. This allows us to define very complex execution processes. Once it is defined, a workflow is executed by a workflow engine which is responsible for the instantiation of all the components defined and to coordinate their execution. The execution of a specific workflow is started by the invocation of a method defined by his interface. The creation of complex process can be represented as a sequence of coordinated actions performed by single components. C. Applications Applications are the top of our architecture’s pyramid. They export all the system’s functionalities to the final user. Applications make use of all the stacks of our architecture and can be run in any webservice compliant communication

IV. A BSTRACTING NETWORK OBJECTS As stated in the previous section, the network devices expose their functionalities through a web proxy component. This component is implemented as a web service and constitutes the key building blocks of the entire system. In order to easily access the devices’ functionalities we have developed a Java library. This library is used by the web proxy for the communication with the network device. The main requirements of the library are: • The designing of the network devices’ model should be Object Oriented (OO). • All the network devices should be accessible as well as manageable through the use of simple Java APIs. • The APIs should abstract all the devices functionalities. • All the functionalities should be organized into packages. • For the sake of simplicity, the functionalities related to the communication with the devices should be grouped togheter in a separate package. • The APIs methods should not depend on the device’s vendor or model. • The device’s should be pluggable at runtime. Starting from those requirements, we started to create an object model of the network apparatus. This is composed by two main packages: the devices package and the connection package. 1) The devices package: The use of an object oriented representation to model the network devices has been done because of the intrinsic benefits of the OO approach, which mainly consist in the possibility to design by components and the easiness of code reusability. Actually tring to categorize the network devices isn’t a simple job and we must make a few assumptions. First of all, the vendors of the devices don’t adopt the same principle to categorize their products. For example, Cisco divides them on the basis of the target market to which they are offering their products. So they have an enterprise bouquet, a SOHO one and so on even if, the products belonging to these categories often share the same functionalities. The Nortel’s offer, on the contrary, is based on the product’s technical features: wireless devices, optical apparatus, and so on. Our approach consists in trying to categorize the devices on the basis of their functionalities, following the market’s classification, using a top-down approach. So at the root of the classes’ tree, we have defined the GenericDevice interface, from which all the other classes are derived. This interface exposes simple methods, like attach and detach for opening and closing connection sessions with the device, that are common to all the appliances. From this one two main groups of devices’ classes are derived: switches and routers. These

978-1-4244-4148-8/09/$25.00 ©2009 This full text paper was peer reviewed at the direction of IEEE Communications Society subject matter experts for publication in the IEEE "GLOBECOM" 2009 proceedings.

two interfaces represent the basic operations common to all switches or routers. Starting from the principle that each interface represents an abstraction of a device, it exposes the methods common to all the devices that belong to it. In this way it is possible to represent different devices using the same interface. For each specific device a new class implementing this interface has been derived. When a device has functionalities that belong to different categories, its related class will implement both. So, for example, if a device has switches’ as well as routers’ functionalities, it will implement both these interfaces. For the functionalities tipical of a specific vendor, a series of specific classes has been designed. So, for example, the GenericCisco class represents an abstraction of the functionalities supported by all the Cisco devices. Finally, we have defined the devices that are available in the market. Using this approach, they are categorized by their functionalities as well as their brand. The figure 3 reports a simple extract of the class diagram.

V. T HE VL AN C REATION E XAMPLE In the following, we clarifies the use of our methodoly through a practical example related to the use of our architecture for the creation of vlan. Figure 5 shows the network’s scenario that have been used in the laboratory to perform the tests. Eight computers are connected to two switches of different brands (Cisco and HP). Each switch is controlled

Fig. 5.

Fig. 3.

The devices class diagram.

2) The connection package: All the details regarding the physical connection to the device, are hidden by the ConnectionManager interface. The definition of a separate connection package allows to decouple the operations for managing the device from those necessary to connect and send data to it. Moreover, it allows to implements different communication protocols, without changing the code related to the device’s administration functionalities. For each type of connection a new class has been developed. At the moment we have developed a TelnetConnectionManager class and a SSHConnectionManger class. Calls to a specific device are carried out using the ConnectionMangerProxy. Figure 4 reports a fragment of the connection package’s class diagram.

Fig. 4.

The connection class diagram.

Topology of the network used for the experiments.

by a web service, the Switch Manager. This service allows to access the switch’s management functionalities through a standard WSDL interface. In particular it allows to set a new vlan giving an id and an optional name. It also allows to associate a particular port to the specified vlan. The creation of a vlan on such a network environment, where many network devices are connected togheter, requires the execution of numerous procedures for the devices configuration. Without our solution the user should set the vlan on both the switches and then add each port, on which the specified computers are connected, to the vlan itself. When we want to create a vlan among different switches, actually on each switch we should also associate the new vlan to the trunking port of the switch. This would allow the switch to let the traffic belonging to the specified vlan to flow to the other switches. Actually, since on almost every switch each new vlan is attached to the trunking port by default, in our example we won’t care about this procedure. In the following, we summarize all the necessary steps for the creation of a new vlan: 1) Define a new Vlan ID. 2) Select the hosts to add to the vlan. 3) Retrieve the informations about the ports on which the hosts are connected. 4) For each switch: a) Set the vlan giving the Vlan ID. b) For each host: • Move the specified port to the Vlan. These steps can be expressed as a workflow of different methods invocations on the Switch Manager proxies. This workflow defines the inner business logic of the Vlan Manager service as depicted in Figure 6 and is implemented using the Jolie language. The execution of the workflow is triggered by an external user’s request, who should only supply the list of

978-1-4244-4148-8/09/$25.00 ©2009 This full text paper was peer reviewed at the direction of IEEE Communications Society subject matter experts for publication in the IEEE "GLOBECOM" 2009 proceedings.

develope our reasonings in the application of the Web services to the main network management topics. In particular we will focus our attention on the development of a Web based approach for the deployment of new QoS services. On the other hand, we will continue to develop our network management architecture by adding more and more network devices. R EFERENCES

Fig. 6.

The vlan creation workflow.

the nodes to connect to the new vlan to the Vlan Manager service. Once the above code is executed, using the Jolie language interpreter, a new process listening to the specified port is activated. When the Vlan Manager service receives a new request, the code associated with the method defined in the request is executed. If a request to an external service is necessary, it sends a message request to the external service specified in the workflow. From the point of view of the performances and the impact of the communications among the different services on the network utilization, some consideration should be made; as we demonstrate, the solution proposed allows a great flexibility in the deployment of new network management services and facilitate the reuse of existing services. Nevertheless some aspects should be taken into account. When compared to classical management solutions, like SNMP, it is very important to watch out to the way the web services are designed. In fact, the use of the SOAP protocol for the communication with the devices, can add a not negligible amount of data that can have a significant impact on the network utilization. For this reason it is not convenient to create device’s web proxies that map each specific functionality into a service’s method. The best benefits can be obtained when complex management operations are organized in a predefined sequence of multiple commands that export their functionalities (as we explained for the setting of a new vlan) through a unique methods. Using this approach, the development of new services can be very easy and the communication among the various services have a minimal impact on the network, compared to other solutions. VI. C ONCLUSIONS In this paper we presented a novel solution for efficient management of network infrastructures. We started with an overview of related works, then we introduced the architecture that has been developed to support our solution. Subsequently, we gave a description of the preliminary tests that we have conducted starting from a pratical example of network management. The test assessed the feasibility and the flexibility of our solution. At the moment, we are focusing our work on two different directions: On one hand, we intend to continue to

[1] T. Magedanz, N. Blum, and S. Dutkowski, “Evolution of soa concepts in telecommunications,” IEEE Computer, vol. 40, no. 11, pp. 46–50, 2007. [2] D. Griffin and D. Pesch, “A survey on web services in telecommunications,” IEEE Communications Magazine, vol. 45, no. 7, pp. 28–35, 2007. [3] o. s. a. o. Parlay-X Group. 3gpp, “Parlay x web services (release 6), ts 29.199 v6.x.y.” [4] R. Vianna, E. Polina, C. Marquezan, L. Bertholdo, L. Tarouco, M. Almeida, and L. Granville, “An evaluation of service composition technologies applied to network management,” in Integrated Network Management, 2007. IM ’07. 10th IFIP/IEEE International Symposium on. IEEE Computer Society, 2007, pp. 420–428. [5] Y. Yang, S. Tang, Y. Xu, W. Zhang, and L. Fang, “An approach to qos-aware service selection in dynamic web service composition,” Networking and Services, 2007. ICNS. Third International Conference on, pp. 18–18, June 2007. [6] R. Neisse, R. L. Vianna, L. Z. Granville, M. J. B. Almeida, and L. M. R. Tarouco, “Implementation and bandwidth consumption evaluation of snmp to web sevices gateways,” in IEEE/IFIP Network Operations and Management Symposium, NOMS, 2004, p. 715728. [7] G. Pavlou, P. Flegkas, S. Gouveris, and A. Liotta, “On management technologies and the potential of web services,” IEEE Communications Magazine, vol. 42, no. 7, pp. 58–66, 2004. [8] T. Drevers, R. van de Meent, and A. Pras, “On the standardisation of web services management operations,” in Proceedings of the 10th Open European Summer School and IFIP WG6.3 Workshop, EUNICE, 2004, p. 143150. [9] D. Alexopoulos and J. Soldatos, “Programmable network management based on the web services paradigm,” in WSEAS ’03: Proc. of the 4th WSEAS conference, 2003. [10] J. Biswas, A. Lazar, J. Huard, S. Koonseng Lim Mahjoub, L. Pau, M. Suzuki, S. Torstensson, and S. Weiguo Wang Weinstein, “The ieee p1520 standards initiative for programmable networkinterfaces,” Communications Magazine, IEEE, vol. 36, no. 10, pp. 64–70, 1998. [11] D. Wong, C. Ting, and C. Yeh, “From network management to service management - a challenge to telecom service providers,” in ICICIC ’07: Proceedings of the Second International Conference on Innovative Computing, Informatio and Control. Washington, DC, USA: IEEE Computer Society, 2007, p. 280. [12] “Itu-t recommendation m. 3100.” [13] “Enhanced telecom operations map (etom), the business frame work,” in TeleManagement Forum, February 2007. [14] L. Atzori and T. Onali, “Operators challenges toward bandwidth management in diffserv-aware traffic engineering networks,” IEEE Communications Magazine, vol. 46, no. 5, pp. 154–160, May 2008. [15] “Oasis. web services business process execution language version 2.0, working draft.” http://docs.oasis-open.org/wsbpel/2.0/wsbpelspecificationdraft.pdf. [16] F. Montesi, C. Guidi, and G. Zavattaro, “Composing services with JOLIE,” in Proc. of 5th IEEE European Conference on Web Services (ECOWS 2007), 2007, pp. 13–22. [17] “Oasis. web services business process execution language version 2.0, working draft.” http://docs.oasis-open.org/wsbpel/2.0/wsbpelspecificationdraft.pdf.

978-1-4244-4148-8/09/$25.00 ©2009 This full text paper was peer reviewed at the direction of IEEE Communications Society subject matter experts for publication in the IEEE "GLOBECOM" 2009 proceedings.

Suggest Documents