In NETQOS, network operation is optimized during runtime by adapting the currently employed policies.  The policy adaptation modules are based on some type of analytical / empirical / etc. models that require information about the current (and previous) state of the network.  This information must be provided by the monitoring and measurement (MoMe) system.

In order to foster research on the adaptation modules, the measurement system should impose no restrictions on the type of feasible measurements and metrics than can be measured.

Further major requirements on the measurement system are:

• Ability to integrate existing MoMe tools
  The networking community has produced an enormous amount of MoMe tools.  The Europen IST project MOME has searched for these tools and cataloged them.  In deliverable D11 from 2004 they report on as many as 413 (!) tools.  Of course, the NETQOS measurement system doesn't want to reinvent the wheel but tries to leverage the power and applicability of the existing tools.
  
  
• Programmable infrastructure
  The users of the measurement system are no humans but NETQOS system components.  These components need programming interfaces to access the functionality of the measurement system.
  
  
• Unified programming interface
  Existing tools are very heterogenous w.r.t how they have be configured and run.  Additionally, there is a large diversity in the way they generate their results and the result format.  If the clients of the measurement system have to take care of all these tool specific peculiarities the system will be cumbersome to use.  Moreover, this approach doesn't scale well (at all) to a large number of tools.  The goal of the measurement system is to provide tool agnostic APIs.
   
• Persistent storage
  There are several entities that the measurement system has to store persistently.  This includes primarily the measurement scenarios, their executions and the results.
  
  
• Flexible result storage
  The result storage system must be very flexible in the types of results it accepts.  It must support different granularities from full packet traces to aggregate statistics.  To enable maximum flexibility, it must be possible to extend the storage capabilities to new types of results.
  
  
• Conditions and alarms
  Policies can contain conditions that are imposed on measured values, e.g. that the 1-way delay from ingress router A to egress router B must not exceed X ms.  The measurement system must provide facilities to specify such conditions as part of the measurement scenario specification.  When executing a measurement, an alarm has to be generated as soon as a measured value exceeds its defined threshold.  This alarm is then routed to the policy adaptation modules that take care of the situation.