1	Network Information Service
1.1	Introduction
Traditionally, the main driving forces behind network monitoring have been fault detection and performance prediction. While this remains true in Grid environments, a significant new concept is introduced. Publishing performance data to Grid applications, middleware and the network fabric will allow systems to both adapt to changing network conditions and provide aspects of the much touted self-healing capability.
Middleware, applications and the network fabric will require historic, real-time and predicted data, all available on both on demand and by notification.
The Network Information Service will provide an interface onto the front of a sefsadfsa <SOME SORT OF OVERALL DESCRIPTION, EH?>
The Network Information Service provides the ability to alert applications, middleware and the networks to changes in the networks. In combination with the ability to schedule new tests with a Network Monitoring Service (see section 2), application may also demand new information in response to changes or unusually events.
1.2	Requirements for retrieving network information
1.2.1	AAA control
1.	It must be possible to restrict access to any service, or any part of any service, based on the client’s identification.
2.	Services must be able to authorise and authenticate between different administrative domains. 
3.	The service should report if a request is to be refused.
4.	It should be possible to explain the reasons for denial of access with any degree of granularity. It is expected that some implementations may want to explain to the client exactly the reason for denial of a test whilst other implementation may wish to restrict information about their services and so not explain the reasons for a denial. 
1.2.2	Discovery
1.	It must be possible to discover the services responsible for a particular host (given the proper authorisation).
2.	It should be possible to discover the types of measurement available (the characteristics available) from a particular service, and the parameters that can be set for those measurements and their acceptable values. This information is likely to be used in a resource discovery context when searching for services.
3.	Information might be made available to allow services to evaluate the capabilities of measurement points in order to choose tools and settings for a measurement. See also section 1.2.7, point 3.
1.2.3	Delegation
1.	It must be possible for the negotiation of and taking of measurements to be delegated to other components within the system.
For example: in piPES, the PMC fields requests for new measurements, but other components, PMPs, themselves negotiate a free space. (In the real piPES system, the negotiation is done with other protocols). In this case, the PMP receives a measurement request much like the PMC does.
2.	It must be possible, in general, for services to handle requests for measurements that do not directly involve the hosts in which those services run.
3.	It should be possible for services to refer clients onto another service. The client could then contact the further service directly without tying up resources at the initial service.
1.2.4	Querying for results
1.	It should be possible to request the value of any characteristic as long as it is available. The service should not be constrained to those characteristics defined now.
2.	Measurement results should be available encoding in the NM-WG NetworkMeasurement schema (or some other standardised form).
3.	It should be possible to specify that results are transferred in any form supported by both the service and the client. It is recognised that XML may not be the perfect medium for transferring extremely large volumes of data, and so other, more compact formats at least should be supported.
4.	It should be possible to request measurements which were made with particular parameters, including ranges of parameters or choices of parameters.
5.	It should be possible to request statistical summaries of data; which summaries are supported is more a matter for implementations, however.
6.	It should be possible to request any number of measurements within a particular time-range.
7.	It should be possible to receive notification of a change in the status of a network (that is, notification of new measurements).
1.2.5	Predictions
Some monitoring architectures are able to make predictions of the future state of networks.
1.	It should be possible to request predictions of the value of measurements that have not actually been made.
2.	It should be possible to request predictions for measurements made at particular times (interpolated values in the past may also count as “predictions”) or with particular parameters.
4.	Requests for predictions must be distinct from requests for new measurements and current values
1.2.6	Negotiation of new measurements
1.	It should be possible to specify that new measurements are to be made.
2.	It should be possible to make a schedule of one or more measurements, made at different times, with different parameters, between different hosts or any other setting.
3.	It should be understood that measurements may not be made exactly when or how requested (see 1.1.4). Rules governing acceptable deviation from a schedule of measurements may be required.
4.	It should be possible to negotiate the settings of measurements. It should be recognised, however, that negotiating the exact details of measurements a great time before they are made may be impossible (see 3).
5.	It should be possible to update or remove a particular schedule of measurements, given the proper authorisation.
6.	It should be possible to track the progress of measurements in a schedule. That is, it should be clear when a measurement:
a.	has not yet been made;
b.	has been delayed for some (any) reason;
c.	has been cancelled;
d.	has been made;
e.	or is in some other state.
Clearly, in a schedule, especially a repeating schedule, this reporting could be quite complicated.
7.	It should be possible to receive notification of the results whenever measurements in a schedule have been completed. However, this may well be taken care of by the Network Information Service.
1.2.7	Inter-service negotiation of new measurements
1.	Services must be able to negotiate the timing and parameters of a measurement such that it does not interfere with other measurements.
2.	Schedule negotiation need only happen on a last-minute basis. That is, the negotiation need only start at the time when the measurement is to be made.
3.	Services must be able to negotiate the capabilities of other services in order in order to choose the best tools and parameters for measurements; services must be able to evaluate when a measurement cannot be made.
4.	It should also be possible for two services to negotiate a schedule in advance of the actual measurement, if both services support this. This is, however, a difficult problem.
1.2.8	Querying of the monitoring system
1.	It should be possible to find out if any measurements are to be made at any particular time; or if any measurements were made at any particular time.
2.	It should be possible to examine an overall (or as close as possible) view of all measurements made or to be made.
3.	It should be possible to narrow queries to particular services, hosts, routes or some other criterion.