As seen before there is a strong requirement for Service Level Monitoring to be considered from a customer's perspective. QoS parameters of SLAs are only reasonable if the user actually tries to use a service. If it does not try to use a special service there cannot be a violation of an SLA caused by the provider. Through the use of Flexible Management Agents (FMA) positioned in the corporate network of the customer, our solution enables the measurement of the actual Service Levels provided to the customer.
In order to avoid additional costs for a customer connected by a dial-up link the following solution was examined: The agent transmits the collected information to the manager only when the link is up and free. In addition packets from the agent do not affect the idle timer responsible for the disconnection of the link if it was unused for a predefined period of time. That would mean that only the (otherwise useless) timeout intervals are used for management traffic. However, the needed functionality is not available in ISDN routers commonly used today, as there is no way to distinguish between packets that should affect the idle timer and packets that should not. As a trade-off the following solution was chosen: Management traffic is created only when the link is up. Although being suboptimal this approach avoids establishing a connection solely for management purposes and thus reduces the additional cost to a minimum. To check whether the link is up or down, some kind of status information needs to be available. Two different solutions have been examined. Many routers send SNMP traps whenever a link is established or goes down. The router can be configured to deliver these traps to the agent. So the agent gets informed immediately about any change in link status. As not all routers send traps concerning the link status the second approach might be necessary: If the agent has management information to transmit, it polls the variable ifOperStatus (operational state of the interface) from MIB-II [#!rfc1213!#] on a regularly basis. Both variants mean that from the perspective of the router, the agent acts in the role of a SNMP manager. As a relatively high polling interval can be chosen (about half of the idle timeout value for the link) the additional load induced by polling is minimal.
Every time the SLAs change or new means of measurement are needed, new functionality must be installed in the corporate network of the customer. As the customer network is typically located far from the management center of the provider a solution is necessary that allows dynamic download of new functionality. This requirement is one of the main reasons why the presented solution is based on JDMK. The CMF has to be installed only once at the customer site and from then on all the functionality needed can easily be downloaded as an M-Bean using e.g., the M-Let Service. To prevent data from being accidentally destroyed, the agent can regularly be serialized to local disk. When the system comes up - for example recovering from a system crash - the JDMK Bootstrap Service tries to load the local copy of the agent before it contacts the central repository. Of course this does not prevent a customer from explicitly deleting the information collected by the agent before it is transmitted to the manager. Another benefit of using the JDMK was its ability to use different adaptors. The provider uses a management platform and also wants to use web browsers to configure the agents. By using JDMK's SNMP and HTML adaptors this could be achieved easily. A manager application was built to receive the performance data sent by the agents using the RMI adaptor. In the current version it writes the data to a database where management tools can access it.