An example for such QoS parameters are the response time, the connectivity or the availability of a certain service. It must be remarked that these parameters have to be measured and valued from the customer point of view. Most of the QoS parameters (e.g. the connectivity or the availability) of a service are only defined if the customer tries to use this certain service. For the monitoring of these parameters it is necessary for the management system of the provider to be able to measure from the side of the customer, i.e. that in our scenario an agent which performs the monitoring of QoS parameters must be installed at a trader's host.
A customer will allow the provider to install an agent at it's systems only if it meets high security requirements and if no additional or only minimal costs are caused by the agent. This means that such an agent must not initiate connections -- especially for customers which are connected via a dial-up line. The agent has to do its measures locally as far as possible and transfered results should be as small as possible.
Requirements for services, QoS parameters and SLAs could change in course of time. Therefore it is necessary that the architecture is flexible and it is able to react on such changes quickly. It must be possible to extend the agent with additional functionality, e.g. for the monitoring of a new QoS parameter.
In such large-scale corporate networks with thousands of hosts and locations all over Germany and Europe it is absolutely essential that the management system scales very well. A lot of different hardware and software at the customer side, requires a high degree of platform independence for the corresponding agent.