Julia Kantorovitch <kanto@ee.oulu.fi>
Zach D Shelby <zdshelby@ee.oulu.fi>
Tommi Saarinen <tsa@ee.oulu.fi>
Petri Mähönen <pma@ee.oulu.fi>
University of Oulu/Centre for Wireless Communications
Finland

Wireless SNMP

Abstract

This paper analyzes the performance of network management in a wireless environment using Simple Network Management Protocol (SNMP). The accuracy and time delay in responding to the network manager using a wireless SNMP agent are measured and analyzed using various scenarios with varying channel conditions and traffic load.
Also, we outline here one example of how SNMP functionality can be used to benefit the management of wireless environments.

Contents

1. Introduction

Managing wireless networks is a significantly harder task than managing wireline networks for many reasons. One of the main problems is the unpredictable behavior of the wireless channel, due to fading, jamming and atmospheric conditions. Signal quality can vary quite dramatically, which might suddenly reduce the efficiency of the management operation. The bandwidth of wireless links is another issue that will always be limited due to the properties of the physical medium and regulatory limits on the use of radio spectrum. Therefore, it is necessary for network protocols to utilize the available bandwidth efficiently.

Motivation: why SNMP functionality is analyzed?

There are a numbers of interesting studies about network management using Mobile Agent technology [1][2][3], which has received a considerable attention in the network management community. Using mobile agents has some benefits like reduction in network traffic, efficient utilization of computational resources, support for heterogeneous environments and increased flexibility. On the other hand, use of mobile agents absorbs considerable resources from the agent host that can be an essential problem for Mobile Terminals (MT). Also, code migration incurs additional traffic into network and is associated with migration delays depending on agent configuration and functionality [4].
SNMP also has a number of shortcomings that are widely discussed in the literature [5] like bandwidth wastage with needless information, complicated encoding rules, etc. But on the other hand SNMP agents can be extended easily to cover device specific data because a clear mechanism exists for upgrading network management client programs to interface with special agent capabilities (through the use of ASN.1 files). Perhaps the biggest strength of SNMP is its widespread popularity. SNMP agents are available for network devices ranging from computers, to bridges, to modems, to printers. SNMP is favored and strongly supported from the vendor community. In fact, most wireless LAN products offer SNMP to support Network Management through the use of SNMP based management platforms and applications.
That is why in this paper we review the performance of an SNMP-based management system and its acceptability for a wireless environment.
Work described here has been performed in scope of the WINE (Wireless Internet Networks) project [6] partly supported by the European Commission.
The issue of interest is the analysis of the nature/philosophy of the SNMP manager-agent communication and its acceptability for a wireless environment. We tested management functionality in various scenarios with "good" and "bad" channel conditions, with different traffic loads and using different transport protocols (TCP, UDP) for SNMP messages to know how much growth the network can absorb before certain management performance thresholds are crossed.
In addition, we point out the demand for a specific wireless MIB to efficiently control wireless system functions and monitor system performance and outline the possibility to adapt wireless system performance to current channel conditions involving SNMP agent functionality.

2. Test and measurements

In this section we first describe the measurement platform and tools that were used. Subsequently we identify the metrics that allows us to analyze the management system performance. Finally we discuss the obtained results.

2.1 Measurement platform and tools

The UCD-SNMP-4.1.2 management tool [7] from the University of California has been selected as a management tool and WLAN-network IEEE802.11b[8] has been used as testbed.
The manager application and the SNMP daemons run on the Access Point (AP) and Mobile Terminals (MT), respectively.
We use standard PC-based platforms for the Access Point and laptops as the Mobile Terminal both running Linux.
To trace SNMP at the manager and agent sides we used tcpdump [9] and tcptrace [10] tools. Tcpdump monitors a host interface I/O buffers and generates a single log file that is used by tcptrace program to output a lot of useful information about tcp/udp traffics.
Mgen [11] has been used to simulate the network traffic. The schematic picture of testbed with user scenarios is presented on Figure 1.

Figure1

Figure 1 Testbed overview (including user’s scenarios)

2.2 Target metrics

Several issues have been considered to analyze the performance of network management.

  • The time delay in notifying the network manager
  • This is the total time to transfer a set of management data between an agent and manager. The quantity depends on a number of factors [12]:

    1. processing time to generate a request at the management station
    2. network delay from manager to agent
    3. processing time at the agent to interpret message
    4. processing time at the agent to generate response
    5. network delay from agent to manager
    6. processing time at manager to receive and interpret response
    7. number of request/response exchanges to obtain all the desired information from an agent.

  • Number of agents managed by a single manager
  • To estimate the maximum number of agents managed by a single manager we monitored SNMP managers using the tcpdump tool. Each of the managers, ucd-snmp management application and SNMPc manager [13] continuously polled three agents to get statistics concerning the total number of octets received on the node’s interfaces (mibII/ifInOctets). We found that each of the tested managers handles only one agent at a time. That means, that the manager polled a particular agent involving a series get/response transactions and then continues to work with another one.
    Therefore, considering above described situation common, as discussed in the literature [12], we can determine the maximum number of nodes that the management station can handle by as follow:

    Figure1_

    where N is number of agents, T is desired polling interval or the time between the successive polls of the same agent, and lambda denotes the average time required to perform a single poll.

    In our further estimation we assume that each managed station is to be polled every 15 minutes. The average time required to perform a single poll could be considered equal to the network delay, because the time to process and interpret the SNMP messages (about 50 ms) is significantly less than network latency and could be neglected.

  • The amount of traffic generated by the managed application
  • With this we mean the portion of the network bandwidth or number of bytes used, for the management which is thus unavailable for the transport of user data.
    We used mgen tool to simulate the network load and tcptrace tool to estimate the bandwidth consumption by the management application in two different environments with good and bad signal strength, using get-next and get-bulk1 operations and different transports.

  • An additional transport: SNMP messages over TCP
  • Currently, the preferred transport mapping for SNMP messages is UDP, in which case the manager must send the query and await a response. This operation is quit efficient if the SNMP message fits into a single UDP packet. But SNMP over TCP transport could be beneficial in the case of retrieving long table objects or performance of the get-bulk operation, when a large amount of data is transferred from agent to network manager.
    TCP has a window mechanism that allows several portions of data to be transferred in parallel and accordingly to remove the additional round trip time latencies, which is essential for a wireless link.
    Also, if multiply responses are generated by an agent, it is not necessarily true that they will arrive to the remote manager in the same order as they were generated. Therefore, because TCP has its own error correction and flow control mechanisms this could be applied for the benefit of management in wireless erroneous environments.
    Ucd-snmp software, supporting the transfer of SNMP traffic over TCP has been used in order to test the above mentioned features and their usefulness applying to wireless communication.

    2.3 Results and discussion

    2.3.1 Response Time and Number of managed devices

    Measurements of response time have been recorded as a function of the system load. As an example of objects to be retrieved we chose the SNMP MIB-II [14], that is currently existing and widely used standard management information base for Internet-based networks. The get-next operation has been tested first. We set the retransmission timeout to 1 sec and retransmission maximum number to five. The results have been recorded at the manager and averaged for each system load value. UDP has been used as a transport protocol for SNMP messages. The mobile terminal has been set in different environments with signal to noise ratio > 35 dB ("good" signal strength) and with signal to noise ratio about 5-10 dB ("bad" signal strength). And as was mentioned above, the mgen tool has been used to generate the system load. The number of managed devices has been calculated using (1).
    The obtained results for response time and number of managed devices are shown in figure 2a and 2b, respectively.

    Figure2a

    a

    Figure2b

    b

    Figure 2 Response time (a) and Number of devices (b) as a function of the system load using get-next operation

    Figure 2 demonstrates that response time in notifying the network manager depends on the wireless link quality. It can vary from several seconds to even several minutes depending on the link condition. We have found that management functionality is unusable2 in scenarios with bad link quality and of system load 20% of the whole capacity of the system.
    Accordingly, a management station can manage almost six times more devices when the signal strength is good than when it is bad with the same system load. Hence, the designing of wireless network management must be careful taken in account wireless environment characteristics.
    Otherwise the behavior of the system is as expected. The response time increases in an exponential way as the load of the system grows. Some deviations from this can be found in the middle area of the graph but this could be explained by the fluctuations of the wireless channel quality.
    We made the same measurements using SNMP get-bulk operation. In contrary to the get-next operation, get-bulk uses BULK Requests to query for a tree of information about a network entity. A variable put in command line specifies which portion of the object identifier space will be searched using BULK Requests. All variables in the subtree below the given variable are queried as a single request and their values presented to the user.
    The results are depicted in Figures 3a and 3b for response time and number of managed devices, respectively.
    Figures 3a and 3b shows that management scalability can be easily improved by using get-bulk. It is especially very useful in the case of bad channel conditions. Even with the system load up to 70 %, about 140 devices could be still managed. The reason for this improvement is that the number of RTTs is reduced, which provides considerable boost in a wireless environment. And the probability of possible loss is also much less, because the manager’s traffic is reduced.

    Figure3a

    a

    Figure3b

    b

    Figure 3 Response time (a) and Number of devices (b) as a function of the system load using get-bulk operation.

    To sum up obtained results, let us return for the moment to get-next measurements. Those seem to be alarming in the case of poor signal strength. In fact, these results were expected. The get operation is good for short transactions, such as retrieving of individual scalar objects when the query and response messages fit into a single UDP packet. Otherwise, if the MIB contains a considerable amount of tables, the retrieving process involves a high number of PDU exchanges over the network, which in case the of bad link quality could make management performance worse.
    In addition, using a single get operation, it is much easier to adapt channel conditions for the current transaction. The user can specify the relevant options like timeout for response message or maximum number of retransmission on respect of the link quality. In our measurements we obtained information about current link quality using Linux Wireless tools [15], but the SNMP agent itself could be an indicator of the link condition. For instance, information about the number of retransmissions performed by the manager/agent application or maximum delay time on receiving a response measured by the manager could be very useful for managing wireless LAN. In fact it is a known shortcoming of SNMP or rather MIBs, although SNMP allows of managing others from afar, there is not a standardized way to manage SNMP agents themselves via SNMP.

    2.3.2 Bandwidth consumption

    In IEEE802.11 standard based WLANs management traffic and user traffic are transferred via the same transmission link. Therefore, it is important to guarantee that the QoS of user traffic is not degraded by the additional management traffic.
    We made some estimations of the network overhead due to the get-next and get-bulk operations in case of different wireless link conditions. As was expected, the bandwidth consumption by the get-bulk method is almost five times less than by the get-next operation.
    It was found also that in the scenarios with "bad" link quality, the management application retransmits a maximum of about 2% of packets using the get-next operation and correspondingly about 35% using the get-bulk operation. And it is interesting that mostly manager request messages are lost. Therefore, these retransmissions influence mostly on the response time, not on network overhead because of the small size of SNMP query messages.

    2.3.3 TCP transport issues

    The amount of data returned for a single get-bulk operation can be quite large. For instance, to retrieve all MIB-II information efficiently we queried about 100 objects in the same request. Using UDP as a transport would not give any benefits because of the limitation in message size. Hence, TCP could be a better choice in this case. The TCP transport cares about the order of the multiple response messages returned by the agent that can be transmitted concurrently because of the window mechanism. As a result the latency could be minimized. Because of the significant problems with latency in wireless environment we have been interested in to test TCP for this purpose.
    The obtained results are not what one would trivially expect. Experimental observation showed that in spite of the benefit from the message size and transmission in parallel, the time needed to establish a TCP connection especially in an environment with "bad" link quality could be quit long. As a result, TCP transport does not improve the latency statistics in manager notification and accordingly the scalability of the network.
    We found also, that using TCP transport for SNMP messages has to be designed very carefully because the SNMP protocol has its own mechanism to control message loss like number of retransmissions and retransmission timeout. And these parameters have to be in correspondence with TCP flow control parameters.

    3. Management Information Base

    Other interesting research done in scope of the WINE project is the possibility of adapting the wireless system performance to the current link condition involving the capability of SNMP agent. The WINE project deals with the performance enhancement of Internet protocols over WLANs. The core of the project’s proposal is so called Wireless Adaptation Layer (WAL), laying between IP and link layer and invoking the appropriate link layer service modules (FEC, SNOOP, etc) with corresponding parameters to improve channel reliability [6]. To determine the optimal module parameters, WAL coordinator monitors the channel conditions between Access Point and Mobile Terminal using LLCT module. The "good" and "bad" link states are specified according the SNR value. If the state of the channel changes, WAL coordinator invokes the appropriate modules to adapt channel conditions. The SNR thresholds for particular type of application traffic are different and also environment (indoor, outdoor) depended. To make WAL functionality even more flexible, the thresholds and module configuration parameters3 can be set remotely via SNMP agent in the local "wireless" MIB. In addition, all other statistics related with the WAL functionality, considered later in this section are exported to the Linux /proc virtual File System (FS). The SNMP functionality is schematically depicted in Figure 4.

    Figure4

    Figure 4 SNMP functionality

    SNMP agent is divided into: WAL-embedded part of the SNMP functionality, which reads and writes information from the WAL Coordinator and its various modules and the SNMP daemon, which runs in the Linux User Space, and manages the MIB.
    These two daemons communicate via the /proc File System, which can be seen as a very efficient shared memory, and which can remain as means of checking the WAL behavior in the case of light MTs with neither SNMP daemon nor MIB management.
    We found six MIB groups, that are presented in Figure 5 to control and monitor our wireless LAN functionality.

    Figure5

    Figure 5 WAL MIB (main groups)

    The General group contains the static parameters related with the current WAL configuration, indicating such information as whether the managed entity is an Access Point or Mobile Terminal, whether the QoS module and WAL are enabled on the node and when the WAL has been last initialised.
    The IfStatistics group includes wireless interface statistics. Such information as wireless channel link quality, data delay, jitter, average number of packets discarded on interface because of the some errors in packets and etc. This information is used to set up module parameters and WAL configuration.
    The ModuleInform group specifies the parameters related with the modules (FEC, SNOOP, Header Compression) implemented inside the WAL.
    The AssocInform group reports the dynamic statistics about associations4 currently running on the managed node and the statistical information about up/down traffics per association.
    The WalStatist group contains the statistical information about the data and signalling traffic going through the WAL. Knowledge about the average number of packets processed/discarded since WAL has been first initiated allows us to analyse its performance.
    The ClassInform group contains the statistics related with class parameters. For instance, SNR thresholds are keeping in this group and as was mentioned above they could be set remotely via am SNMP agent.
    The ucd-snmp software tool [7] has been used to extend SNMP agent functionality in respect to the developed WAL MIB.

    4. Conclusions

    In this paper we considered the acceptability of SNMP as a management protocol for wireless communication. We tried to find the knowledge about how many nodes the network can absorb before the certain management performance thresholds are crossed. Such metrics as network manager notification delay, bandwidth consumption, management availability has been analyzed for this purpose. We looked at bulk transfers of MIB data. It was found that the GetBulk operator considerably improves the management performance especially in the scenarios with poor signal strength. We tested TCP as additional transport for SNMP messages and realized that UDP is more efficient transport for management in wireless environments.
    Also we outlined here the SNMP functionality which makes the management more flexible and allows adapting of wireless system performance to the current link condition involving the capability of SNMP agent.

    Acknowledgements

    This work is in part funded by European Commission through 5th Framework Research Program IST-project (IST-1999-10028 WINE). Petri Mähönen acknowledges the research funding through the Academy of Finland (AWIS, grant-50624).
    We are grateful for collaboration and useful discussion with our colleagues in WINE-project, especially we wish to thank Luis Muñoz, Diego Melpignano and Fabrice Lucas.

    References

    1. D.Gavalas, D.Greenwood, M.Ghanbari, M.O’Mahony, "Advanced Network Monitoring Applications Based on Mobile/Intillegent Agent Technology", Computer Communications Journal, 23(8), pp.720-730, 2000
    2. C. Bohoris, G. Pavlou, H. Cruickshank, "Using Mobile Agents for Network Performance Management", Proceedings of the IEEE/IFIP Network Operations and Management Symposium (NOMS 2000).
    3. Pagurek B., Wang Y., and White T., "Integration of Mobile Agents with SNMP: Why and How", EEE/IFI Network Operations and Management Symposium, (NOMS 2000), Honolulu, 2000.
    4. C. Bohoris, A. Liotta, G. Pavlou, Software Agent Constrained Mobility for Network Performance Monitoring, Proceedings of the 6th IFIP Conference on Intelligence in Networks (SmartNet 2000).
    5. R.Sprenkels, J.P.Martin-Flatin, "Bulk Transfers of MIB Data", The Simple Times, 7(1):1-7, 1999, http://www.simple-times.org
    6. P.Mähönen, N.Passas, G.Orphanos, L.Muñoz, A.Marshall, D.Melpignano, T.Inzerilli, F.Lucas, M.Vitiello, M.García, "Platform-Independent IP Transmission over Wireless Networks: The WINE Approach", reviewed version submitted to IEEE PCM for publication in August 2001.
    7. http://net-snmp.sourceforge.net
    8. "IEEE Standard for Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specification", P802.11, Nov.1997
    9. ftp://ftp.ee.lbl.gov
    10. http://www.tcptrace.org/new.html
    11. http://manimac.itd.nrl.navy.mil/MGEN
    12. W.Stalings,SNMP, SNMPv2, SNMPv3, and RMON 1 and 2, 3st ed. Reading, MA: Addison-Wesley, 1999
    13. http://www.castlerock.com
    14. K.McCloghrie, M.Rose, "Management Information Base for Network Management of TCP/IP-based internets: MIB-II", RFC1213, March 1991
    15. http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/Tools.html

    Notes

    1. According some papers [5] this operation is defined as a get-subtree operation
    2. Unusable means that we could not be able to update whole MIB tree using above mentioned options for get-next operation
    3. Here we mean to set the work range, not the value itself
    4. Association identifies a stream of IP datagrams belonging to the same class. And class defines the service offered to a particular type of application traffic (e.g., audio/video streaming, bulk transfer, Web [6]).