Julia
Kantorovitch <kanto@ee.oulu.fi> Wireless SNMPAbstractThis 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. Contents
1. IntroductionManaging 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].
2. Test and measurementsIn 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 toolsThe 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. Figure 1 Testbed overview (including user’s scenarios) 2.2 Target metricsSeveral issues have been considered to analyze the performance of network management.
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]: 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. 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. 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. 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. 2.3 Results and discussion2.3.1 Response Time and Number of managed devicesMeasurements
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). a 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. a 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. 2.3.2 Bandwidth consumptionIn 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. 2.3.3 TCP transport issuesThe 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. 3. Management Information BaseOther 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. 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. 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. 4. ConclusionsIn 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. AcknowledgementsThis 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). ReferencesNotes |