the power of SNMP-based monitoring processes, increasing the level of details about the network usage and ... management is not for free. Performance issues ...
Implementation and Bandwidth Consumption Evaluation of SNMP to Web Services Gateways Ricardo Neisse, Ricardo Lemos Vianna, Lisandro Zambenedetti Granville, Maria Janilce Bosquiroli Almeida, Liane Margarida Rockenbach Tarouco Institute of Informatics Federal University of Rio Grande do Sul Av. Bento Gonc¸alves, 9500 - Bloco IV Porto Alegre, RS - Brazil {neisse, rvianna, granville, janilce, liane}@inf.ufrgs.br Abstract Web Services gateways are needed to include SNMP devices into a Web Services based management architecture. We propose in this paper two approaches for such gateways and evaluate these approaches in order to verify the feasibility of using Web Services closer to the network devices interface. We primary tested the bandwidth consumed by these gateways when using SOAP with HTTP, HTTPS, and a compression process. The evaluation shows that Web Services gateways are specially interesting when the number of SNMP object instances retrieved is high. Keywords Web Services, Web-Based Network Management, SNMP, Management Gateways.
1.
Introduction
The management of computer networks has been facing interesting and challenging problems for years. The diversity of network devices lead the standardization bodies to define management protocols that are able to provide a reduced number of device management interfaces. The definition of the SNMP (Simple Network Management Protocol) [1] was a key step towards this direction. Then, network players and users started to build their monitoring solutions based on SNMP, which improved the knowledge about the managed networks and their behaviors. RMON [2] and RMON2 [3] architectures further enhanced the power of SNMP-based monitoring processes, increasing the level of details about the network usage and services consumed. Nowadays, however, other interesting and challenging problems arise, for which the SNMP seems not to be a proper tool for the new solutions needed. For example, there is not a widely accepted architecture for the delegation of management scripts, although the IETF has proposed the Script MIB [4]. Security issues are still open, although the SNMPv3 [5] has been created to address such issues. Configuration management is still a big problem: network administrators do not rely on SNMP to manage the devices configuration, although the IETF has been working on the SNMP for configuration [6]. Other network configuration-related work is being developed by the IETF netconf working group [7], where the use of XML and related protocols, in substitution of SNMP, is investigated. Recently, a set of technologies known as Web Services (WS) [8] was proposed and
captured the attention of software development communities. Although originally intended to support e-commerce processes, WS can actually be used as an integration tool in quite diverse areas, such as grid networking [9], artificial intelligence [10], and network management. In this last one, WS seem to have the potential to solve some of the network management problems pointed before. Due to Web-based interfaces, WS over HTTP traffic crosses Internet firewalls easier than SNMP (although that can be considered an not healthy feature [11]). The gama of available tools to deal with WS and the native support for WS in software development platforms are greater than the available facilities in the SNMP world. Also, WS are implemented through SOAP [12], a protocol whose security issues were taken into account since its beginning. SOAP itself may run on top of secure transport services implemented through protocols like HTTPS, encrypted SMTP, and Secure-FTP. Added to that, while SNMP is almost only used in the communication between management stations and network devices (despite the SNMPv2 efforts), WS could be used to improve the communication between different management platforms or even to build complex management systems based on simpler management services. Probably, one of the most interesting gains obtained with WS is the easier integration of network management with other critical processes, such as e-business. Although this picture may be quite fascinating, the introduction of WS in network management is not for free. Performance issues on the managed devices, and the consumption of network bandwidth with the management traffic imposed by the use of WS may prevent an effective management solution. Also, it is not proper to believe that WS would be deployed along all the elements of the whole network management process. For example, SNMP-based devices surely will still remain in future networks, the same way that CLI-managed devices remain in current networks. This way, we believe that the most common WS-based management scenario will be the one where the established management technologies (e.g. SNMP and CLI) will co-exist with WS. In this scenario, we also believe that WS will be more often found near to the network administrator interface, while SNMP and CLI will be obviously found at the device interface (figure 1). One important issue arises here: where, in the future management systems, will we find the line between WS and the established management technologies?
Administrator interface
Mid Level Managers
Device interface
Web Services Network management software hierarchy
Web Services/SNMP,... border
SNMP, CLI, SSH, HTTP, ...
Figure 1: Network management software hierarchy
In this paper we investigate two main issues: the integration of established management technologies with WS, and the impact of using WS in the managed network. Gateways are a requirement for the integration of the established management technologies and WS. Since we believe that, for more effective gains, WS have to be offered as soon as possible in a bottom-up perspective of the network management software hierarchy, we have developed SNMP to WS gateways intended to be placed closer to network devices. Planning an SNMP to WS gateway, however, involves some important decisions that can impact the performance, bandwidth consumption, and WS deployment. In this paper we are particularly interested in verifying the feasibility of using WS considering the network bandwidth consumption. We mainly measured the bandwidth usage and compared the WS traffic against pure SNMP traffic. The preliminary results collected did not help to choose in favor of WS as management interface for devices. Trying to achieve better results, we used a compressing process over the SOAP traffic in order to decrease the bandwidth consumption. The remainder of this paper is organized as follows. Section 2 presents related work and discusses about WS and WS gateways proposed so far. Section 3 introduces our proposed protocol-level and object-level SNMP to WS gateways. Section 4 presents the results obtained by the evaluation of the bandwidth consumed by the gateways, while Section 5 proposes a compressing process to reduce the WS traffic generated by the gateways developed. Finally, Section 6 finishes this paper presenting conclusions and future work.
2.
Web Services and SNMP Gateways
Web Services (WS) can be broadly described as a set of technologies that allow transactions over the Internet. Each Web Service is a piece of software that, using Internet protocols (e.g. HTTP, SMTP and FTP), receives service invocations from clients. One Web Service is composed by a set of operations exposed to external clients. The clients of a WS can be, for example, Web browsers, end-user applications or even other WS. In this last case, one WS can request operations from other WS, allowing this way an hierarchy of WS requests. Also, it allows the creation of very complex WS based on the invocation of simpler ones. Besides all these procedures, the whole WS architecture is composed by other auxiliary infrastructures to improve the WS applicability (figure 2). UDDI Look up
Publish SOAP
Web Service
Invoke
Client
WSDL described service
Figure 2: General Web Services architecture The UDDI (Universal Description, Discovery, and Integration) [13] is an emerging directory service that works as a repository to register and store WS description and lo-
cation information. Clients explore the UDDI repository searching for available WS and operations. Once an appropriate Web Service is found, the client contacts the Web Service invoking its operations. In order to achieve WS-based integration, one has to describe the available operations in a standard way. WSDL (Web Services Description Language) [14] is used for this purpose. All communications between clients and UDDI, WS and UDDI, and clients and WS are executed through SOAP (Simple Object Access Protocol) [12]. SOAP, UDDI and WSDL are the most important emerging standards for the implementation of the architecture from figure 2. In order to use the WS architecture for network management, translation processes have to be introduced. These processes are required to translate management information retrieved using established protocols into information offered through WS. A common way to implement these translation processes is using protocol gateways in the management systems. Yoon-Jung Oh et al. [15] define SNMP to XML gateways and three methods for interactive translations: DOM-based translation, HTTP-based translation, and SOAP-based translation. In the DOM-based translation an XML-based manager calls a DOM interface that resides in the gateway. Such call is then translated to SNMP operations between the gateway and the target device. With the HTTP-based translation the gateways receive XPath and XQuery expressions coded by an XML-based manager. Such expressions are then translated to SNMP requests. This method of translation is specially interesting because information filtering can be executed directly in the gateway, reducing the management traffic between the XML-based manager and the gateway, although a processing overhead is introduced. Finally, in the SOAP-based translation the gateway exports more sophisticated services accessed by the XML-based manager. With these services the manager can look up information with XPath or proceed with complex queries through XQuery expressions. Strauss and Klie [16] have proposed an SNMP to XML gateway similar to the HTTPbased translation method of Yoon-Jung Oh et al. The gateway accepts HTTP messages with XPath expressions in the URL. The XPath expressions are then verified to be translated to SNMP messages. DOM is then used to access the XML documents inside the gateways, reducing the data transferred between the XML-based manager and the gateway. To proceed with configuration management, HTTP POST messages are translated to SNMP Set requests. SNMP traps are supported inside the gateway through an internal trap buffer accessed by the XML-based manager, and by sending HTTP POST messages from the gateway to HTTP listeners inside the XML-based managers. Ourselves have implemented a system that automatically creates SNMP to XML gateways given a SMI MIB file [17]. The gateways created retrieve information from target SNMP devices and generate XML documents sent back to an XML-based manager to be further parsed and analyzed. As the work of Strauss and Klie before, the translation is executed through the help of the smidump tool [18] that generates XML version of SMI files. The work that has been done up to today uses just a subset of the facilities found in the WS architecture (figure 2). As verified, gateways are created to access SNMP-based devices and export management information on XML documents (real WS, based on
SOAP, are barely used). Besides, the WS description through WSDL and its registration in UDDI are not addressed in the work done so far. Finally, the authors of this paper do not know of a study that investigates the impact of using WS for network management in the gateways proposed until now. In the next section we present two approaches for SNMP gateways that better explore the facilities introduced by the WS architecture. After that, we also present the results obtained with the evaluation of such approaches regarding the bandwidth consumption.
3.
Protocol and Object-Level SNMP to WS Gateways
In our approach, two levels of SNMP to WS gateways are supported: protocol-level and object-level gateways. First, the protocol-level gateway [19] directly maps SNMPv1 primitives to WS operations (e.g. Get, GetNext, Set). An object-level gateway, on its turn, offers operations that reflect the structure of the management information. In this case, a GetIfTable is an example of an operation offered by an object-level gateway. Currently, both protocol-level and object-level gateways do not provide support for SNMP traps to WS translation because we are primarily interested in observing Get, GetNext and Set. In this section we present (a) a protocol-level SNMP to WS gateway, and (b) a system that, given an input MIB file, automatically creates new object-level SNMP to WS gateways. The prototypes [20] for protocol and object-level gateways were developed using PHP4 and NuSOAP. Besides being an open source Web script language, PHP4 simplicity and easiness allow the fast implementation of management scripts. Also, PHP4 was chosen due to its message compression support required in our evaluations (to be presented in Section 4). Since PHP4 has no native SOAP support available yet, NuSOAP [21] was used to provide such support for the PHP4 scripts developed.
3.1 The Protocol-Level SNMP to WS Gateway The protocol-level SNMP to WS gateway provides operations that are direct mappings of SNMPv1 primitives. Figure 3 presents the general picture when a WS-based manager uses such gateway. SNMP :
SNMP device
Web Server WS-based manager
SOAP
SNMP to WS gateway
:
SNMP device :
:
SNMP device
Figure 3: Protocol-level SNMP to WS gateway operations A WS-based manager requests management information accessing the SNMP to WS gateway through SOAP messages. In our prototype implementation, the SOAP messages
run over either HTTP or HTTPS. This allows the management station to be a standard Web browser that accesses a HTTP/HTTPS Web server. Such server (that contains the gateway) receives from the WS-based manager the identification of the operation to be accessed (e.g. Get or Set), and a list of SNMP-related parameters (the address of a target device, an SNMP valid community, and an SNMP OID). With this information, the appropriate operation within the WS gateway is invoked, and the target device is accessed using SNMP in order to proceed with the management primitive requested. We have implemented the Get, GetNext, and Set services that generate, for each WSbased manager request, one exact SNMP request from the gateway to the target device, and one exact SNMP reply from the target device back to the gateway. After the SNMP information is retrieved from the target device, the gateway compiles such information into a SOAP message and sends it back to the WS-based manager. The services implemented allowed us to test, as will be presented in the next section, the impact of a direct mapping gateway on the managed network. Further operations could obviously be provided as well (e.g. GetBulk). As indicated before, the SNMP to WS protocol-level gateway was implemented as a PHP4 script using the SOAP supporting library NuSOAP. Figure 4 presents the operations provided by the protocol-level gateway (the operations of a WS are implemented as functions in PHP4). function Get ($ip, $community, $oid) function GetNext ($ip, $community, $oid) function Set ($ip, $community, $oid, $newvalue) Figure 4: Operations of the PHP4 protocol-level SNMP to WS gateway In a simple use of this gateway, its WS operations (Get, GetNext and Set) have been described in WSDL and registered in a UDDI repository. A WS-based manager looking for management WS can look up in the UDDI and thus discovers the location of the available gateways on the network. It is important to notice that with this approach the WS-based manager still has to be aware of the SNMP OIDs in order to properly request object instances in the gateway. The advantage of this approach, however, is the fact that if new objects are supported by an SNMP agent on the target device the SNMP to WS gateway does not need to be changed or rebuilt. The disadvantage, on the other hand, comes from the fact that it is up to the manager to know the SNMP objects supported on each device managed, even in the presence of UDDI. Also, the manager still needs to deal with SNMP OIDs, i.e. such gateways do not provide easier to use operations than those already available using SNMP.
3.2 The System to Create Object-Level SNMP to WS Gateways An object-level SNMP to WS gateway, in contrast to the protocol-level gateway previously presented, is aware about the MIB objects supported by the target device, and presents such objects as WS operations. For example, a GetIfTable operation is the one that retrieves the whole MIB-II interface table, whereas a SetAdminStatus is an operation that changes the administrative status of one of the available network interfaces on the
target device. The advantage of an object-level gateway is that it not only retrieves and exposes the information as WS, but also presents only the operations allowed to be executed on the target device. This way, a WS-based manager not only searches the UDDI for general management WS, but looks up for specialized WS for specific devices. Thus, the WS-based manager is not forced to keep track of capacities of each device: it is already informed on the gateways used. This approach, however, looses flexibility when the target device SNMP agent is changed (either to support new SNMP objects or to remove the support of other objects). In this case, the associated WS need to be rebuilt in order to reflect the SNMP agent changes. This way, we need an efficient way to create object-level SNMP to WS gateways. We have implemented a systems that, given a SMI MIB file, automatically creates a new WS. Figure 5 presents the architecture that supports the creation of new object-level SNMP to WS gateways. The first step in a gateway creation is the transfer of standard SMIv1 or SMIv2 MIB from a WS-based manager to a Web server trough HTTP or HTTPS. MIB WS-based manager
XML smidump
Web server
New gateway (WS)
SAX parsing
Description (WSDL)
Figure 5: Creating a new object-level SNMP to WS gateway Internally on the server, the smidump tool checks the received MIB and, if no inconsistencies are found, it generates an XML temporary document which is the XML version of the received MIB. The next parsing step, in turn, takes such XML temporary document as input information to build up the new gateway. Each node in the original MIB tree is transformed in operations of the new generated WS. These operations are instrumented with code able to contact, via SNMP, a target device. The target device and its associated SNMP community string are treated, within the instrumented code, as parameters whose values will be further provided when the operation is invoked by the WS-based manager. The just created WS is stored in a standard directory in the Web server and available to be invoked just after its creation. The original MIB provided by the manager is also stored in another standard directory for documentation purpose, as well as the intermediate XML document generated by the smidump tool prior to the parsing step. At the same time the parsing step creates the code for the new WS, it also builds a WSDL document that describes the created WS. The WS-based manager that requested the creation of a new WS optionally informs the URL of a UDDI repository where the created WS is then registered. The WSDL document is stored in a standard directory as well. With the gateway creation process, new MIBs can be easily added to a WS-based management environment. In order to let this process works properly, however, the original MIB files should be correctly defined according to SMIv1 or SMIv2. It is not rare to find MIB files still in use that have definition problems (mainly old MIBs, since more
recent MIBs seem to be more properly defined). For example, according to the output of the smilint tool, the RFC1213-MIB module has 3 errors [22]. In the case of finding MIB definition problems, the intended SNMP to WS gateway will not be created, and the corresponding smidump message describing the errors found will be sent back to the WS-based manager. It is important to notice that the gateway creation system itself is not a WS, but a set of PHP4 scripts running at the same Web server that will host the gateway just created. The WS gateway to be used in a HTTP request is determined by the URL informed by the WS-based manager. The target device and SNMP community are passed as arguments to the WS operation. Each node from the original MIB file is translated to some WS operations. For scalar objects, a Get operation is always built. It uses SNMP Get messages to retrieve the requested object from the SNMP agent in the target device. Another Set operation may be created if the SNMP object is a writable one. In this case, the operation uses an SNMP Set message to change the value of an object in the target device. Figure 6 shows the operations created for the sysLocation object from MIB-II. function GetSysLocation ($ip, $community) function SetSysLocation ($ip, $community, $newvalue) Figure 6: Operations for the sysLocation MIB-II object A Get operation will be also created for table objects. A Set operation, however, will be only created for table objects that is writable. An important difference between operations for scalar and table objects is the identification of the object instances. In the case of scalar objects there is only one instance, but for table objects several instances may exist and such instances have to be determined in order to have their values retrieved through Get operations or to have their contents changed by Set operations. Figure 7 shows the operations created for the ifAdminStatus object of the interface group of MIB-II. function GetIfAdminStatus ($ip, $community, $index=-1) function SetIfAdminStatus ($ip, $community, $index, $newvalue) Figure 7: Operations for the ifAdminStatus MIB-II object The index parameter is optional in Get operations. If it is not provided the operation returns all instances associated; if an index is provided only the instance identified is retrieved. In the case of Set operations the index is not optional and must be always provided.
4.
Measuring the Traffic Generated: SNMP versus Gateways
In the previous section we presented the protocol and object-level SNMP to WS gateways. These gateways allow the management of SNMP-based devices using Web Services. However, the use of WS via gateways unavoidably introduces drawbacks that could prevent an effective WS-based network management. Manager-device end-to-end perfor-
mance is directly affected by the processing overhead introduced by the SOAP support needed on the manager and gateway. Network bandwidth is also affected since SOAP messages are verbose and consume more bandwidth than SNMP messages. The problem here is that the bandwidth consumed by WS, although greater than SNMP, is not currently well-known. In this section we analyze the bandwidth consumption of the gateways presented before, and compare such consumption with the bandwidth consumed by SNMP.
4.1 Evaluation Scenario We have evaluated the bandwidth consumption (figure 8) considering the message exchange between (1) a WS-based manager and an SNMP to WS gateway, and (2) between a gateway and a target SNMP device. We also considered the operations of both protocollevel and object-level gateways. We tested the retrieval of all the objects of a single column of a table that has a variable number of rows. Web Server WS-based manager
SOAP (1)
SNMP to WS gateway
SNMP (2)
SNMP device
Figure 8: SNMP to WS gateway evaluation environment In the SNMP traffic, we solely observed SNMP messages with only one object in the variable bind list, which is one of the most frequent usage of SNMP messages. Also, although Set operations are available on the WS developed, we only verified Get operations. Since configuration traffic (that uses Set) is far less bandwidth consuming than monitoring traffic (that uses Get), Get operations would impact far more significantly the network than Set operations. The SNMP agent used in these evaluations supports the following simple testing MIB (figure 9).
Figure 9: Testing MIB The MIB is composed by a table (wsTable) with just one column wsColumn. The number of rows in the table is controlled by the wsTableRows writable object. This way, it is possible to control the number of wsColumn instances by setting wsTableRows. This feature is specially important to progressively increase the number of objects and
observe the bandwidth consumed by the retrieval operations. We did not use, in this case, a standard MIB, e.g. MIB-II due to the lack of such instance controlling feature. The next subsections present some evaluation results.
4.2 SNMP versus Protocol-Level GetNext Operation
Kilobytes
In the first test we were interested in checking how much traffic is generated by SOAP messages when the protocol-level gateway is used through direct mapping of GetNext messages. In this case, the manager scans out the target device wsTable successively requesting the GetNext operation on the protocol-level gateway. Each GetNext operation request on the gateway generates an SNMP GetNext request from the gateway to the target device. This way, we have a walk on the MIB controlled by the WS-based manager. Figure 10 shows how much bandwidth is consumed by SOAP in the manager-gateway communication, and by SNMP in the gateway-device communication.
200 180 160 140 120 100 80 60 40 20 0
WS GetNext over HTTPS WS GetNext over HTTP SNMP
Retrieved instances 0
20
40
60
80
Figure 10: SNMP versus WS GetNext operation
Here, the greater the number of objects to be retrieved, the greater the difference between SNMP and SOAP traffic. This behavior was expected because SOAP uses verbose, not optimized messages greater than SNMP messages. It is also possible to observe that SOAP over HTTPS consumes much more bandwidth than SOAP over HTTP due to the encrypted information on HTTPS.
4.3 SNMP versus Object-Level Operations In the second test we were interested in checking how more feasible is the use of objectlevel gateway operations. All Get operations in such gateways are implemented through a sequence of SNMP GetNext messages inside the gateway, i.e., an SNMP walk operation coordinated by the gateway, not by the manager. The object-level gateway traffic is plotted in figure 11 below.
14 12 Kilobytes
10 GetWSColumn over HTTPS GetWSColumn over HTTP SNMP
8 6 4 2
Retrieved instances
0 0
20
40
60
80
Figure 11: SNMP versus GetWSColumn operation Initially, the gateway consumes more bandwidth than SNMP. However, the greater the number of instances to be retrieved, smaller is the difference between SOAP and SNMP traffic. When retrieving around 17 instances, the SOAP over HTTP and SNMP traffic is almost the same, and around 39 instances the SOAP over HTTPS and SNMP traffic is almost the same. For more than 17 instances the SNMP traffic is greater than the SOAP over HTTP traffic. The same way, for more than 39 instances the SOAP over HTTPS traffic consumes less bandwidth than the SNMP traffic. This difference in the SNMP and SOAP traffic is due to the many SNMP interactions required in the gateway-device communication, while in the manager-gateway communication just two SOAP messages are exchanged: a WS operation request and its corresponding reply.
4.4 Compressing SOAP to Save Bandwidth: Preliminary Results From the results presented so far, it is possible to realize that the use of SOAP to transport management information effectively impacts the network bandwidth usage, although the SNMP traffic also impacts depending on the number of retrieved instances. Trying to reduce the SOAP traffic impact, we used a compressing process. Such process compresses the SOAP messages before they are sent by the manager to the WS gateway, and decompresses them on the WS gateway before they are processed to determine the WS operation to be invoked. On the way back the SOAP messages are compressed in the WS gateway and decompressed on the manager. We used the ZLIB compressing algorithm [23] for this purpose. Figure 12 presents the bandwidth consumption when the protocol-level gateway uses the compressing process, as well as the results of the compressing process when it was used with the object-level gateway. Even with the introduction of the compressing process, the SOAP traffic required for the protocol-level gateway is always greater than the corresponding SNMP traffic. In the case of the object-level gateway, the compressing process turns the SOAP traffic less bandwidth consuming than SNMP. SOAP over HTTP consumes less bandwidth than SNMP when more than 10 instances are retrieved, while SOAP over HTTPS is better than SNMP when more than 28 instances are retrieved. It is important to notice here that the bandwidth consumption for the compressed SOAP messages grows even more smoothly than the traffic generated by non-compressed SOAP messages. Another interesting point is that compressed SOAP over HTTPS traffic is less bandwidth consuming than (not compressed) SOAP over HTTP traffic if more than 59 instances are retrieved. It means that
200 180 160 140 120 100 80 60 40 20 0
14 12 10 Kilobytes
Kilobytes
if both HTTPS security and bandwidth saving are important, then SOAP over HTTPS is interesting when more then 59 instances are retrieved.
8 6 4 2 0
0
20 40 60 80 Retrieved instances WS GetNext over HTTPS Compressed WS GetNext over HTTPS WS GetNext over HTTP Compressed WS GetNext over HTTP SNMP
0
20 40 60 80 Retrieved instances GetWSColumn over HTTPS Compressed GetWSColumn over HTTPS GetWSColumn over HTTP Compressed GetWSColumn over HTTP SNMP
Figure 12: SNMP versus compressed GetNext and GetWSColumn operations
5.
Conclusions and Future Work
In this paper we have presented two approaches for SNMP to WS gateways: protocol-level and object-level gateways. The protocol-level gateways are quite simple and provide the mapping of SNMP primitives to WS operations (e.g. Get, GetNext and Set). The objectlevel gateways are mapping of MIB structures to WS operations (e.g. GetIfTable). In this last case, we have developed a system that automatically creates new WS given a SMI MIB file. The protocol-level gateway forces the WS-based manager to remain dealing with SNMP OIDs, i.e., there is no new facility provided by gateways. Besides, SOAP traffic is greater than the SNMP traffic (as verified in figure 10). Then, the use of protocollevel gateway imposes an increased consumption of bandwidth between the manager and gateway. The object-level gateway, on the other hand, reduces the bandwidth required in the manager-gateway communication because the gateway sends back the management information to the manager in just one single SOAP message. We have also measured the bandwidth consumption for the two gateways approaches. We have used SOAP messages over HTTP and HTTPS, and verified the traffic with ordinary and compressed (through the ZLIB algorithm) messages. With the results we can say that protocol-level gateways are inefficient and introduces an ever growing bandwidth consumption. Thus, it is only interesting to have protocol-level gateway when the number of SNMP objects to be retrieved is quite low. Even in this case the bandwidth consumed by SOAP is greater than SNMP. Object-level gateways, however, are more interesting than SNMP when the amount of instances is high (more than 17 instances for non-compressed SOAP over HTTP messages, more than 39 instances for non-compressed SOAP over HTTPS messages, more than 10 instances for compressed SOAP over HTTP messages, and more than 28 instances for compressed SOAP over HTTPS messages). This is partic-
ularly interesting in the case of configuration management with a great volume of management information exchanged, or in monitoring of several SNMP objects at the same time. This is so because the SNMP interaction control was pushed to the gateway. At the end, we can safely state that the WS-based network management is interesting when SNMP interaction control is transferred from the manager to the gateways; in this case, object-level gateway provides such control transfer. The results collected and presented in this paper are preliminaries. Currently, we are testing compressing algorithms other than the ZLIB used in this work. We believe that XML-specific compressing algorithms can reduce even more the bandwidth consumption of the object-level gateways. The support for notification through the translation of SNMP traps to WS operations needs to be investigated, as well as the associated bandwidth consumption. Also, the performance evaluation of the presented gateways has to be executed. Although the bandwidth consumption verified in this paper indicates that, in specific conditions, WS gateways may be used, the performance drawbacks imposed by such gateways have to be verified as well.
References [1] J. Case, M. Fedor, M. Schoffstall, and J. Davin. A Simple Network Management Protocol (SNMP), May 1990. IETF RFC 1157. [2] S. Waldbusser. Remote Network Monitoring Management Information Base, May 2000. IETF RFC 2819. [3] S. Waldbusser. Remote Network Monitoring Management Information Base Version 2 using SMIv2, January 1997. IETF RFC 2021. [4] D. Levi and J. Sch¨onw¨alder. Definitions of Managed Objects for the Delegation of Management Scripts, August 2001. IETF RFC 3165. [5] J. Case, R. Mundy, D. Partain, and B. Stewart. Introduction and Applicability Statements for Internet Standard Management Framework, December 2002. IETF RFC 3410. [6] M. MacFaden, D. Partain, J. Saperia, and W. Tackabury. Configuring Networks and Devices with Simple Network Management Protocol (SNMP), April 2003. IETF RFC 3512. [7] Network Configuration. netconf Working Group, 2003. Available at: http://www.ietf.org/html.charters/netconf-charter.html. IETF. [8] 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. [9] G. Goth. Grid Services Architecture Plan Gaining Momentum. IEEE Internet Computing, Vol. 6, Issue 4, pages 11–12, July/August 2002. [10] A. Preece and S. Decker. Intelligent Web Services. IEEE Intelligent Systems, Vol. 17, Issue 1, pages 15–17, January/February 2002. [11] K. Moore. On the use of HTTP as a Substrate, February 2002. IETF RFC 3205. [12] N. Mitra. SOAP Version 1.2 Part 0: Primer, June 2003. W3C Recommendation. http://www.w3.org/TR/2003/REC-soap12-part0-20030624/.
[13] T. Bellwood, L. Cl´ement, D. Ehnebuske, A. Hately, M. Hondo, Y.L. Husband, K. Januszewski, S. Lee, B. McKee, J. Munter, and C. Riegen. UDDI Version 3.0, July 2002. UDDI Spec Technical Committee Specification. [14] R. Chinnici, M. Gudgin, J. J. Moreau, and S. Weerawarana. Web Services Description Language (WSDL) Version 1.2 Part 1: Core Language, June 2003. W3C Working Draft. [15] Y. J. Oh, H. T. Ju, M. J. Choi, and J. W. Hong. Interaction Translation Methods for XML/SNMP Gateway. 13h IFIP/IEEE International Workshop on Distributed Systems: Operations and Management (DSOM 2002), pages 54–65, October 2002. [16] F. Strauss and T. Klie. Towards XML Oriented Internet Management. 8th IFIP/IEEE International Symposium on Integrated Network Management (IM 2003), pages 505–518, March 2003. [17] R. Neisse, L. Z. Granville, M. J. Almeida, and L. Tarouco. A Dynamic SNMP to XML Proxy Solution. 8th IFIP/IEEE International Symposium on Integrated Network Management (IM 2003), pages 481–484, March 2003. [18] F. Strauss. libsmi - A Library to Access SMI MIB Information, August 2003. http://www.ibr.cs.tu-bs.de/projects/libsmi/. [19] J. Sch¨onw¨alder, A. Pras, and J. P. Martin-Flatin. On the Future of Internet Management Technologies. IEEE Communications Magazine, Vol. 41, No. 10, pages 90–97, October 2003. [20] D. O. Ballv´e, L. Z. Granville, R. L. Vianna, and R. Neisse. QAME - QoS-Aware Management Environment, and Analysistool, December 2003. http://noc.metropoa.tche.br and http://gerencia.inf.ufrgs.br. [21] D. Ayala. NuSOAP - Web Services Toolkit for PHP, November 2003. http://dietrich.ganx4.com/nusoap/. [22] B. Fenner. smilint output for all MIBs published in RFCs and Internet Drafts, December 2003. http://www.icir.org/fenner/mibs/htmllint. [23] P. Deutsch and J. L. Gailly. ZLIB Compressed Data Format Specification version 3.3, May 1996. IETF RFC 1950.
