1. Participants

2. Introduction

QoS parameters will be IP-based when at least one network segment on the end-to-end path relies on IP-based QoS support mechanisms.
QoS parameters will be ATM-based when end systems rely on native ATM connections or when at least a segment of the end-to-end path is an ATM and QoS monitoring is  limited to that segment.

The definition of IP performance metrics is under development at the "IP Performance Metrics" (ippm) working group at IETF. The goal of this group is to provide a formal definition of parameters defining the IP traffic performance . The parameters which are currently under study are: one-way delay, round-trip delay, instantaneous packet delay variation, one-way packet loss, bulk transport capacity (BTC) and connectivity. When the first RFCs will be available, ippm compliant implementations and applications should be deployed to probe the network.

3. Proposal

1. protocols: monitoring of the protocols in use by a given QoS architecture is useful for the validation of the QoS architecture itself. Debugging tools available on the equipment fall into this category.

RSVP and RSVP to ATM SVC mapping testing will benefit of this type of monitoring, since both approaches rely on signalling protocols (RSVP and ATM signalling). For example, it may be useful to keep track of RSVP admission control failures in the routers and to verify that reservations are correctly set up according to the Rspec messages issued by destinations.
The applicability of this to the diffserv architecture depends on the feature set available on test equipment.
2. network: monitoring of the global status of a network in terms of resource availability and resource consumption is necessary for network engineering and management. Implementations of standards compliant tools offering the possibility to monitor network clouds fall into this category.

This may be particularly useful  in the diffserv architecture, which initially will not rely on dynamic signalling protocols. Since Service Level Agreements (SLAs)will be probably established at the boundaries through manual configuration, monitoring of resource availability from each ingress point to each egress point of the domain could be useful.
3. end-to-end QoS performance: monitoring of the real end-to-end performance experienced by traffic (for single or aggregated flows) is necessary to compare it to the initial service request.

This type of monitoring is also necessary to verify the impact of the combination of heterogeneous QoS mechanisms on end-to-end performance. For this reason it fits both the RSVP-to-ATM SVC mapping testbed and the diffserv-intserv scenario. Also in the diffserv architecture the end-to-end monitoring could be useful to verify the impact of  SLAs on the end-to-end performance when traffic goes through several diffserv domains.
Application monitoring tools provided or mechanisms based on external monitoring devices could be deployed.

1. PHASE 1: identification of relevant metrics to be measured in each QoS scenario, for example in the diffserv scenario:
   • throughput
   • one-way delay
   • delay variation
   • packet loss
   • resource utilization distribution
2. PHASE 2: identification of tools for protocol, network and end-to-end performance monitoring;
3. PHASE 3:
• specification of the hardware and software requirements of the tools,
• definition of a testbed (including the traffic meters location, when applicable),
• identification of a set of QoS capable applications to test the features of the tools.

3.1 QoS monitoring tools

3.1.1 Protocol monitoring

1. SMR  (Session Monitor and Reservation), a tool developed at CSELT (Centro Studi E Laboratori Telecomunicazioni) -Italy- for the monitoring of RSVP reservations and RSVP-ATM reservations. It runs on Solaris 2.5 and 2.6 platforms. To be applied to the RSVP test and RSVP-to-ATM mapping test.

1. RSVP monitoring tools: router supported tools, RSVP Diagnostics Tool developed at UCLA and/or other tools developed by the research community;

3.1.2 Network monitoring

1. SNMP-based monitoring applications could be useful to monitor the equipment.
   The availability of such applications will be investigated in PHASE 1.
   The integrated services MIB has already been standardised   in RFC 2213 and RFC 2214 and gives the possibility of testing RSVP equipment in terms of flows and resource management.
   The MIB stores plenty of information about:
   1. intserv sessions -Interface Flow Table - (type, QoS profile in terms of bit rate, message size, burst size, class of service in use etc.),
   2. interfaces -Interface Attribute Table - (amount of bandwidth already reserved, maximum amount of bandwidth which can be allocated, buffer information, number of current sessions, propagation delay,  etc.).
   
   QoS Monitoring using RSVP MIB: proposal

   The diffserv MIB has not been defined yet but it is part of the diffserv charter, the future developments in the diffserv working group should beconsidered.

2. measurement tools based on the Realtime Traffic Flow Measurement (RTFM )architecture. RTFM is based on the principle of passive traffic monitoring at a given measurement point. It is non invasive, in the sense that no additional traffic charge is generated to probe the network. At least two implementations of this architecture are available:  NeTraMet (the Network Traffic Meter) - free software - and an IBM Meter (implemented on AIX systems).

The RTFM architecture is made of four main components:
• meter: it's the data collector: It monitors traffic and stores measures in a RTFM MIB. An RTFM  rule set is used to define which flows need to be monitored. Meters can be implemented on PCs or workstations running a meter program or can be implemented as switch/router firmware. Meters can also make use of row data stored inrouters and switches.

Meters are SNMP agents collecting data.
• meter reader: it collects information from one or more meters.
• meter manager: it's responsible of the RTFM meter and meter reader configuration. Managers are SNMP clients which access row data through the RTFM MIB. Managers can provide the meters and the meter readers with flow specifications, and can define the meter and meter reader control parameters, as the sampling rate and the frequency at which data is collectedfrom the meter.
• analysis applications:  they process the data collected by the meter reader.

The RTFM architecture may be used for traffic flow measurement at any level of granularity. RTFM with appropriately located meters can also be used for the measurements of a few end-to-end performance parameters. This possibility requires further investigation.

In the QTP overlay network meters could be located as illustrated infigure 1.

Figure 1: application of an RTFM architecture in QTP

3.1.3 End-to-end performance monitoring

1. application supported monitoring tools, for example  MGEN  a Multicast traffic GENerator supporting logging and analysis tools;
2. application monitoring tools based on RTP  (Realtime Transfer Protocol) and IBM RTP testing;
3. one way delay measurement (IPPM metric) through GPS-based synchronization (e.g. Test Traffic Project at RIPE and Surveyor)

4. Summary

1. PROTOCOL MONITORING:
   • routers (router supported monitoring tools)
   • end-systems (Solaris 2.5 or 2.6 platform), and ATM NIC (Fore Runner ATM NIC) -SMR-
2. NETWORK MONITORING:
   • end systems running SNMP based monitoring applications
   • end-systems (Unix platforms or DOS platforms -NetTraMet- + routers (Cisco Routers -NetFlow-)
3. END-TO-END PERFORMANCE MONITORING:
   • end systems (running applications which are able to perform end-to-end measurements, performing explicit IPPM probes)

1. PROTOCOL MONITORING:
   • protocol debugging and monitoring tools
2. NETWORK MONITORING:
   • SNMP-based monitoring applications
     • RFC 2213, RFC 2214 (intserv MIB)
   • RTFM-based monitoring tools (meter+meter reader+meter manager+ analysis applications)
     • RFC 2063, RFC 2064, RFC 2123 and RTFM internet drafts
3. END-TO-END PERFORMANCE MONITORING:
   • applications capable of running IPPM probes (for the measurement of the packet related parameters as delay, delay variation, packet drop percentage, burst size etc)
   • end-system sinchronization through NTP
     • RFC 1305 (NTP)
   • RTP-based applications
     • RFC 1889 (RTP)

1. PROTOCOL MONITORING:
   • routers (router supported monitoring tools)
   • Solaris 2.5 or 2.6 platform and Fore Runner ATM NIC -SMR-
2. NETWORK MONITORING:
   • end systems running SNMP based monitoring applications
   • Unix platforms or DOS platforms -NetTraMet- + Cisco Routers with IOS supporting NetFlow, disk space
3. END-TO-END PERFORMANCE MONITORING:
   • end systems (running applications which are able to perform end-to-end measurements, performing explicit IPPM probes)

1. PROTOCOL MONITORING
   • in parallel with the RSVP test, possible from the beginning of the RSVP tests
2. NETWORK MONITORING
   • possible from the beginning (some network monitoring tools already available)
3. END-TO-END PERFORMANCE MONITORING
   • possible from the beginning, IPPM probing depends on the availability of IPPM capable applications, the same for RTP monitoring)

1. PROTOCOL MONITORING
   • routers: participants (generally speaking whenever a RSVP router is located, location in the backbone is not required), sharable
   • end-systems (SMR): participants, sharable
2. NETWORK MONITORING
   • end-systems and routers: backbone and/or participants, sharable
3. END-TO-END PERFORMANCE MONITORING:
   • end-systems: participants, sharable

5. Bibliography

1. RFC 2213: Integrated Services Management Information Base using SMIv2, F.Baker et alt.
2. RFC 2214: Integrated Services Management Information Base Guaranteed Service Extensions using SMIv2; F.Baker et alt.
3. SMR: Integrated Services over ATM Eperimentations;  http://carmen.cselt.it/isatm-exp/index.html
4. RSVP Diagnostics Tool (UCLA Internet Research Laboratory), http://irl.cs.ucla.edu/
5. IP Performance Metrics (ippm) Working Group, home page:  http://www.ietf.org/html.charters/ippm-charter.html
6. RFC 2330: Framework for IP Performance Metrics; V.Paxon et alt.
7. RFC 1889:RTP: A Transport Protocol for Real-Time Applications; H.Schulzrinne et alt.
8. Multicast traffic GENerator supporting logging and analysis tools,   http://tonnant.itd.nrl.navy.mil/ipresearch/mgen.html
9. Realtime Traffic Flow Measurement (rtfm) Working Group home page:  http://www.ietf.org/html.charters/rtfm-charter.html
10. RFC 2064: Traffic Flow Measurement: Meter MIB; N.Brownlee
11. RFC 2063: Traffic Flow Measurement: Architecture; N.Brownlee et alt.
12. RFC 2064: Traffic Flow Measurement: Experiences with NeTraMet; N.Brownlee
13. RTFM, Applicability Statement, N.Brownlee, draft-ietf-rtfm-applicability-statement-01
14. The Network Traffic Meter: NeTraMet,  http://www.auckland.ac.nz/net/NeTraMet/
15. RFC 1305:Network Time Protocol
16. Test Traffic project home page (RIPE).
17. Internet Delay Measurements using Test Traffic, H.Uijterwaal, O.Kolkman (Postscript).
18. Surveyor