mome-wp3-0409-d31 standardisation plan › ... › mome-wp3-0409-d31_standardisation… · Document...

Monitoring and Measurement Cluster – 001990

Document Info Document Reference MOME-WP3-0409-D31_STANDARDISATION_PLAN

Document Type Deliverable

Deliverable Type Report

Deliverable Status Submitted

Delivery Date Contractual: 31/09/2004, Actual: 18/10/2004

Dissemination Level Public

Editing Author Jürgen Quittek, NEC

Contributing Author(s) Jürgen Quittek, NEC

Tanja Szeby, FHG

Elisa Boschi, FHG

Workpackage(s) WP3

D31 - MOME Standardisation Plan and Recommendations

Abstract

This document gives an overview of standardisation activities concerning IP monitoring and

measurement in various standardisation bodies. For each body, known contributions from IST projects

are described and opportunities for participation are listed. The opportunities are summarized in a

standardisation plan and recommendations for activities related to monitoring and measurement in the

IST programme.

Keywords MOME, standardisation, Internet Protocol, measurement, monitoring, traffic flow, IETF, 3GPP, ITU

MOME-WP3-0409-D31_STANDARDISATION_PLAN 001990

Deliverable D31 Monitoring and Measurement Cluster

18/10/2004 of 27

Table of Contents

1 Introduction ......................................................................................................................................6 2 Monitoring and Measurement Standardisation Overview................................................................8

2.1 Standardisation Bodies..............................................................................................................8 2.2 IETF ..........................................................................................................................................8

2.2.1 SNMP MIB Modules .........................................................................................................8 2.2.2 RMONMIB – Remote MONitoring MIB module ...........................................................10 2.2.3 RTFM – Real-Time Flow Measurement..........................................................................11 2.2.4 IPFIX – IP Flow Information eXport...............................................................................12 2.2.5 PSAMP – Packet SAMPling............................................................................................14 2.2.6 IPPM – IP Performance Metrics ......................................................................................16

2.3 IRTF ........................................................................................................................................17 2.3.1 IMRG ...............................................................................................................................17 2.3.2 NMRG..............................................................................................................................17

2.4 ITU ..........................................................................................................................................18 2.4.1 SG 3 – Study Group 3 ......................................................................................................18

2.5 3GPP .......................................................................................................................................19 2.5.1 SA5 – Service Architecture Working Group 5 ................................................................19

2.6 IPDR.org .................................................................................................................................21 2.7 GGF.........................................................................................................................................21

2.7.1 NM-WG – Network Measurements Working Group.......................................................21 2.7.2 GB-RG – Grid Benchmark Research Group....................................................................21 2.7.3 NMA-RG – Network Measurements for Applications Research Group .........................21

3 Opportunities for Contributions......................................................................................................23 3.1 Contributions from IST projects..............................................................................................23 3.2 Standardisation Opportunities .................................................................................................23 3.3 Recommendations ...................................................................................................................23 3.4 Standardisation Plan................................................................................................................24

3.4.1 IPFIX Standardisation Team............................................................................................24 3.4.2 Identifying potential contributions to the IRTF IMRG....................................................24

4 References ......................................................................................................................................26



18/10/2004 of 27

List of Figures

Figure 1: Generic Traffic Measurement Process .....................................................................................6 Figure 2: SNMP Application Scenario ....................................................................................................9 Figure 3: The RTFM Architecture.........................................................................................................11 Figure 4: The IPFIX Architecture..........................................................................................................12 Figure 5: IPFIX Devices ........................................................................................................................13 Figure 6: IPFIX Packet Format..............................................................................................................14 Figure 7: The PSAMP Architecture.......................................................................................................15 Figure 8: 3GPP IP Flow-Based Online Charging Architecture .............................................................20 Figure 9: 3GPP IP Flow-Based Online Charging Architecture .............................................................20

List of Tables

Table 1: Interaction Between Components of Traffic Measurement Applications .................................6 Table 2: Standardisation Bodies for IP Traffic Measurement .................................................................8



18/10/2004 of 27

List of Acronyms

3GPP The 3rd

Generation Partnership Project

CLI Command Line Interface

CRANE Common Reliable Accounting for Network Elements

DMTF Distributed Management Task Force, Inc.

GB-RG Grid-Benchmark Research Group

GMA Grid Monitoring Architecture

GGF Global Grid Forum

IESG Internet Engineering Steering Group

IETF Internet Engineering Task Force

IMRG Internet Measurement Research Group

IMS IP Multimedia Subsystem

IP Internet Protocol

IPDR IP Detailed Record

IPFIX Internet Protocol Flow Information eXport

IPPM Internet Protocol Performance Metric

IPv4 Internet Protocol version 4

IPv6 Internet Protocol version 6

IRTF Internet Research Task Force

IST Information Society Technologies

ITU International Telecommunication Union

MIB Management Information Base

MPLS Multiprotocol Label Switching

NMA-RG Network Measurements for Applications Research Group

NM-WG Network Measurement Working Group

NMRG Network Measurement Research Group

PSAMP Packet SAMPling

QoS Quality of Service

PR-SCTP Partially Reliable Stream Control Transmission Protocol

RFC Request For Comments

RTFM Realtime Traffic Flow Measurement

RTT Round Trip Time

SG Study Group

SIP Session Initiation Protocol

SLA/SLS Service Level Agreement / Service Level Specification

SNMP Simple Network Management Protocol

WG Working Group



18/10/2004 of 27

Executive Summary


measurement in several standardisation bodies. For each body, known contributions from IST projects

are described and opportunities for participation are listed in Section 2. Section 3 summarises the

opportunities in a standardisation plan and gives recommendations for active participation out of the

IST programme in the standardisation of monitoring and measurement.

Two main recommendations are given. The first one is continuing the strong and successful active

participation in standardizing traffic metering technology within the Internet Engineering Task Force

(IETF). This recommendation is particularly directed to projects and project partners that have already

built up expertise in IETF standardisation. The second recommendation is becoming active in the

Internet Measurement Research Group (IMRG) of the Internet Research Task Force (IRTF). This

group is very open and looking for interesting work items. This recommendation is particularly

directed towards new projects exploring new area in traffic measurement or in its application.

A minor recommendation concerns activities in the 3rd

Generation Partnership Project where IP traffic

measurement is under standardisation for accounting and charging purposes, but work on this issue

has already progressed far in 3GPP and the opportunity to participate is only given if actions start

immediately.



18/10/2004 of 27

1 Introduction Usually, monitoring and measurement of Internet traffic involves not just a single application, but a

combination of different tools that process measured information on different levels. In order to

exchange information between these tools, agreed common information models, data models, file

formats, and protocols are required.

The exchange of information can serve different purposes as listed in Table 1.

Purpose of Interaction Type of Interaction configuration and control of traffic measurement processes control

monitoring traffic measurement processes control

query request for transmission of specified measured data control

the transmission of measured data itself data

Table 1: Interaction Between Components of Traffic Measurement Applications

The illustration of the general Internet traffic measurement process in Figure 1 shows that measured

traffic data primarily contains packet records with raw per-packet information or flow records with

aggregated per-flow information.

Classification &Flow Recording

Observation

PointPAYLOAD HEAD

PAYLOAD HEADPAYLOAD HEAD

PAYLOAD HEAD

Packet Capturing

Filtering

Sampling

packets

flow

records

sampling and

filtering steps

may be trivial (1:1 sampling,

no filtering)

Filtering

Sampling

flow records

packet records

packet records

packet records

flow records

flow records

packetrecords Further

Processing

Analysis,

Accounting,Traffic

Engineering,Intrusion

Detection,

…

Classification &Flow Recording

Observation

PointPAYLOAD HEAD

PAYLOAD HEADPAYLOAD HEAD

PAYLOAD HEAD

PAYLOAD HEADPAYLOAD HEADPAYLOAD HEADPAYLOAD HEAD

PAYLOAD HEADPAYLOAD HEADPAYLOAD HEADPAYLOAD HEAD

Packet Capturing

Filtering

Sampling

packets

flow

records

sampling and

filtering steps

may be trivial (1:1 sampling,

no filtering)

Filtering

Sampling

flow recordsflow records

packet recordspacket records





packetrecords Further

Processing

Analysis,

Accounting,Traffic

Engineering,Intrusion

Detection,

…

Figure 1: Generic Traffic Measurement Process

After observing and capturing individual IP packets at an observation point, (parts of) captured

packets are further processed as packet records. Optional processing steps are sampling and filtering.

The output of packet level processing are packet records. Tools for packet capturing and for further



18/10/2004 of 27

processing interact by using common formats for packet records. Records can be exchanged using

Application Programming Interfaces (APIs), packet record exchange protocols, packet record files

(e.g. tcpdump files) or packet record entries in a database. Analogous considerations apply to traffic

flow records that are created by packet record classification and flow recording.

To achieve interoperability between different tools or components of Internet monitoring and

measurement applications, standardisation of the interactions listed in Table 1 is required. The most

obvious standardisation body for Internet traffic measurement is the Internet Engineering Task Force

(IETF) that develops most of the Internet-specific standards. But also other generals

telecommunication standardisation bodies, such as the International Telecommunication Union (ITU),

and standardisation bodies dedicated to specific technologies or application areas, such as the 3rd

Generation Partnership Project (3GPP) or the Global Grid Forum (GGF).


measurement in several standardisation bodies. For each body, known contributions from IST projects

are described and opportunities for participation are listed in Section 2. Section 3 summarises the

opportunities in a standardisation plan and gives recommendations for active participation out of the

IST programme in the standardisation of monitoring and measurement.



18/10/2004 of 27

2 Monitoring and Measurement Standardisation Overview

This section gives and overview of standardisation bodies that are involved in standardising IP traffic

monitoring and measurement standards.

2.1 Standardisation Bodies

The following list of standardisation bodies is discussed. Most bodies are industry fora not producing

legal standards, but often standards that are de-facto standards. Only the ITU is a legal standardisation

body.

Acronym Name URL Status IETF Internet Engineering Task Force www.ietf.org industry

IRTF Internet Research Task Force www.irtf.org industry

ITU International Telecommunication Union www.itu.int legal

3GPP 3rd

Generation Partnership Project www.3gpp.org industry

IPDR IPDR.org www.ipdr.org industry

GGF Global Grid Forum www.ggf.org industry

Table 2: Standardisation Bodies for IP Traffic Measurement

2.2 IETF The Internet Engineering Task Force defines standards for the Internet, particularly protocols and

information models are standardised. IETF work is structured into areas and working groups. Traffic

measurement standards are developed by the IP Performance Metrics (IPPM) and Real-Time Flow

Measurement (RTFM) WGs in the Transport Area and by the Packet SAMPling (PSAMP), IP Flow

Information eXport (IPFIX), and Remote MONitoring Management Information Base (RMONMIB)

WGs in the Operations and Maintenance Area. In addition to traffic measurement specific WGs, also

other WGs defined standards providing traffic measurement features, particularly, definitions of

Management Information Base (MIB) modules for the Simple Network Management Protocol

(SNMP).

2.2.1 SNMP MIB Modules The Simple Network Management Protocol (SNMP, [16]) serves for communication between a

management application (SNMP manager) and SNMP agents at managed nodes, such as hosts,

routers, and other devices. The agent offers access to managed objects containing information about

the managed node, such as its type, configuration, state and current performance values.



18/10/2004 of 27

Manager

Management Station

Router

Agent

Router

Agent

Router

Agent

Host

Agent

Host

Agent

Host

Agent

Host

Agent

SNMP

Figure 2: SNMP Application Scenario

Managed objects are structured in a Management Information Base (MIB). Individual MIB modules

define portions of the MIB, for example, the Interface MIB module defines objects representing state

and configuration of all IP interfaces of a device. Via SNMP the manager can send read requests and

write requests for particular managed objects to the agent. This way, the manager can retrieve, for

example, the configuration and status of an IP interface by reading the corresponding managed

objects. By writing objects, a manager can, for example, manipulate the state of an interface.

In 1991 the IETF standardised a basic MIB module called MIB-II [1]. This module contained all

objects that were useful as default for a device with IP interfaces. The MIB-II module contained

- incoming and outgoing counters for bytes and packets per IP interface,

- incoming and outgoing counters for bytes and datagrams per UDP socket,

- incoming and outgoing counters for bytes and segments per TCP socket.

Today, most of the definitions in the MIB-II module have been updated and these definitions are split

over several documents. For example, the managed objects concerning IP interfaces are defined in the

IF-MIB module [5], the objects concerning UDP and TCP are defined in the UDP-MIB module [4]

and the TCP-MIB module [2].

With the counters in these MIB modules, basic traffic measurement can be performed at

communication endpoints that are usually located at the hosts. At routers only the coarse granular byte

and packet counters per interface were available, per connection information on UDP or TCP data

streams were only available if the router was a communication endpoint. For measuring individual

traffic flows passing a router further means are required. These are standardised by dedicated working

groups, such as the RMONMIB, RTFM, IPFIX and PSAMP WGs.

Open issues and Opportunities for Contributions The definition of default managed objects for devices with IP interfaces is very stable. If needed some

of the specific documents are updated, but usually the updates do not concern traffic measurement-

related issues.



18/10/2004 of 27

2.2.2 RMONMIB – Remote MONitoring MIB module The Remote MONitoring MIB module WG is the longest running of the WGs concerned with traffic

measurement. The RMONMIB WG develops a very complex, flexible and powerful MIB module for

detailed analysis of network traffic. The MIB module covers configuration of a measurement process

as well as retrieving measured data. The RMONMIB is suited for detailed and specific network

analysis tasks on different network layers.

RMONMIB probe implementations have high performance and typically have hardware support. They

are too complex and expensive for massive deployment, for example in every router. RMONMIB

implementations can operate offline when a management station will not be in constant contact with

its remote monitoring devices. This is sometimes by design in an attempt to lower communications

costs (especially when communicating over a WAN or dialup link), or by accident as network failures

affect the communications between the management station and the probe.

For this reason, the RMONMIB allows a probe to be configured to perform diagnostics and to collect

statistics continuously, even when communication with the management station may not be possible or

efficient. The probe may then attempt to notify the management station when an exceptional

condition occurs. Thus, even in circumstances where communication between management station

and probe is not continuous, fault, performance, and configuration information may be continuously

accumulated and communicated to the management station conveniently and efficiently. Given the

resources available on the monitor, it is potentially helpful for it continuously to run diagnostics and to

log network performance. The monitor is always available at the onset of any failure. It can notify the

management station of the failure and can store historical statistical information about the failure.

This historical information can be played back by the management station in an attempt to perform

further diagnosis into the cause of the problem.

The monitor can be configured to recognize conditions, most notably error conditions, and

continuously check for them. When one of these conditions occurs, the event may be logged, and

management stations can be notified in a number of ways.

Because a remote monitoring device represents a network resource dedicated exclusively to network

management functions, and because it is located directly on the monitored portion of the network, the

remote network monitoring device has the opportunity to add significant value to the data it collects.

For instance, by highlighting those hosts on the network that generate the most traffic or errors, the

probe can give the management station precisely the information it needs to solve a class of problems.

An organization may have multiple management systems for different units of the organization, for

different functions (e.g. engineering and operations), and in an attempt to provide disaster recovery.

Because environments with multiple management stations are common, the RMONMIB can deal with

more than one management station, potentially using its resources concurrently.

The basic RMONMIB specification [14] is accompanied by several functional or technology-specific

extensions, such as the Token Ring RMON MIB [2]. It provides objects specific to managing Token

Ring networks. The RMON-2 MIB [5] extends RMON by providing RMON analysis up to the

application layer. The SMON MIB [6]extends RMON by providing RMON analysis for switched

networks. An overview of all extensions is given in [25].

The WG planned to shutdown several times already and always another small issue came up that was

worth continuing the work. The most recent issue is real-time application quality of service

monitoring. This work is already progressed quite far and only few more small contributions are

expected.

Contributions from IST Projects The only known contribution was an Internet draft and a presentation with contributions from the

ACTS IthACI project.



18/10/2004 of 27

Open issues and Opportunities for Contributions In general, this WG is always open for further extensions. But experiences showed that very few

proposals have been accepted and that most of them came from the same core team that is

participating in this group for many years already. Therefore, in a realistic view, the chances to join

this WG with new contributions are rather small.

2.2.3 RTFM – Real-Time Flow Measurement The Real-Time Flow Measurement (RTFM) WG was established in 1995. It developed an architecture

for traffic measurement [12] containing a Manager that controls the measurement process, a Meter that

measures traffic flows and a Reader that receives traffic flow measurement results from a Meter, see

Figure 3.

Application

Manager

Reader

Meter

Figure 3: The RTFM Architecture

The manager communicates with an application that requires traffic measurement results. The

application tells the Manager which kind of measurement is required. The Manager configures one or

more meters according to the application’s requirements and instructs a reader to regularly collect

measurement information from the Meter. The Reader makes these results available to the application.

The main standard developed by the RTFM WG is the Meter MIB. This is an SNMP MIB module that

specifies communication between Manager and Meter as well as between Reader and Meter via

SNMP. The Meter MIB, particularly the interface between Manager and Meter is very powerful

concerning functionality, but at the same time it is highly complex and difficult to use. The rules for

traffic measurement, that are transmitted from Manager to Meter are coded as machine code for a

packet-processing engine defined in [12]. There are only two implementations of the Meter MIB

known, one by IBM used for internal purposes and one called NeTraMet by Nevil Brownlee, the chair

of the RTFM WG. Since the source of NeTraMet is open and can be used free of charges, this

powerful tool has been used by many universities in various research projects.

Contributions from IST Projects Contribution to the RTFM working group were made by the ACTS IthACI project. In this project IP

over ATM technologies were studied as a contribution to the development of Multiprotocol Label

Switching (MPLS). Results of IP over MPLS traffic measurement in IthACI served as input for RFC

2724 [13].



18/10/2004 of 27

Open issues and Opportunities for Contributions This working group is closed.

2.2.4 IPFIX – IP Flow Information eXport The IP Flow Information eXport (IPFIX) WG standardises a protocol for exporting information on

observed packets. An initiative of the IST MobiVAS project contributed to establishing this WG. In

December 2000 a first BoF session was organized at an IETF meeting based on experiences with the

RTFM architecture. The BoF was titled RTFM2, because the intention was to improve RTFM in order

to increase its usability and acceptance. A request for establishing a new WG was rejected by the

Internet Engineering Steering Group (IESG), because the IESG members did not like the idea to

improve a failed approach. Instead, they recommended to develop a new standard independent of

RTFM. In summer 2001 another BoF session was held titled IP Flow eXport (IPFX), which basically

suggested standardising a protocol similar to the proprietary Cisco NetFlow protocol. This attempt was

successful and in autumn 2001 a new WG called IP Flow Information eXport (IPFIX) was

established..

The WG defined requirements for IPFIX [29] that were based on five kinds of applications requiring

traffic flow measurements: IP-based charging, traffic analysis, traffic engineering, QoS monitoring

and intrusion/attack detection. The group developed an IPFIX architecture shown in Figure 4.

Application

FlowRecord

Observation Point

Flow InformationExport

PAYLOAD H EAD

PAYLOAD H EAD

PAYLOAD H EAD

PAYLOAD H EAD

PAYLOAD H EAD

PAYLOAD H EAD

PAYLOAD H EAD

PAYLOAD H EAD

MeteringProcess

ExportingProcess

Collecting

Process

FlowRecord

Figure 4: The IPFIX Architecture

At an observation point IP packets are observed and their headers (including transport headers and

potentially also some application layer headers) are captured and forwarded to a metering process. The

metering process samples and filters packet headers and maps the remaining headers to IP flows.

Properties of flows are stored in flow records. An exporting process exports flow records over an IP

network using the IPFIX protocol to a collecting process. There flow records are received and

available for processing by an application. There can be multiple instances of all components of the

architecture. The IPFIX architecture can be applied to various kinds of measurement devices and

scenarios. Figure 5 gives an overview of potential IPFIX devices.



18/10/2004 of 27

O

M

E

Probe

O

M

E

Simple Router

O OO O

M

E

Complex Router

O OO O

M

O OO O

M

E

Multiple Exporters

O OO O

M

E

O OO

O

M

E

Protocol Converter

(Meter MIB)

O

M

E

O

M

E

O

M

E

M E

Concentrator

C E

Proxy

C É

Figure 5: IPFIX Devices

The examples in Figure 5 are composed of one or more of the following elements: observation point

(O), metering process (M), exporting process (E), and collecting process (C). The observation points

shown in the figure are always the most fine-granular ones supported by the respective device.

A typical probe contains a single observation point, a single metering process, and a single exporting

process. A basic router extends this structure by multiple observation points. Here, the observation

point of a particular flow may be one of the displayed most fine-granular observation points, but also it

may be a set of them.

A more complex router may host more than one metering process, for example one per line card.

Alternatively, a complex router may host different exporting processes for flow records generated by

different metering processes. A protocol converter makes use of a metering process that can be

accessed only by protocol(s) other than the IPFIX protocol, for example SNMP and the Meter MIB

module [5]. Then the exporting process receives flow record from a remote metering process and

exports these records using the IPFIX protocol.

A concentrator receives flow records via the IPFIX protocol, merges them into more aggregated flow

records, and exports them again using the IPFIX protocol. Finally, a very simple IPFIX-related device

is a proxy. It just receives flow records using the IPFIX protocol and sends them further using the

same protocol. A proxy can be useful for traversing firewalls or other gateways.

Different to many previous non-standard protocols for exporting flow records, the IPFIX protocol uses

dynamic flow record structures. So-called flow record templates are sent initially from an exporting to

a collecting process. They define the structure of flow records by specifying the set of elements

contained in a record. The exporter may change the flow record structure over time if it announces the

change by an according flow record template. Also more than one template can be in use at a time.

Each flow record contains a template identifier indicating the template that describes the record’s

structure. Figure 6 shows the format of a typical IPFIX packet.



18/10/2004 of 27

PacketHeader

Flow RecordTemplate

FlowRecord

FlowRecord

Flow RecordTemplate

FlowRecord

. . .

Figure 6: IPFIX Packet Format

After a packet header indicating protocol version, packet length and some information about the

exporting process, a template flow record describes the format of the following flow records. After

some flow records, another flow record template specifies a new format for further flow records.

As basic transport protocol for IPFIX, UDP, TCP and PR-SCTP (Partially Reliable Stream Control

Transmission Protocol, [16][29]) were discussed. The working group decided having the use of PR-

SCTP mandatory for all compliant implementations and TCP and UDP as optional protocols. PR-

SCTP was preferred because different to UDP it is congestion-aware and reduces bandwidth in case of

a congestion. Compared to TCP, PR-SCTP was preferred because of its much simpler state machine

on the sender side. This saves resources on lightweight probes and router line cards.

After defining requirements, the IPFIX working group worked on an architecture document, a protocol

specification and a specification of an information model. All three documents are in a rather mature

state and their completion is expected soon – with end of editing in spring 2005 and publication in

autumn 2005. Furthermore, the WG works on a document containing applicability statements.

Explicitly not covered yet is the subject of IPFIX device configuration. Any discussion on this issue

was excluded by the WG charter.

Contributions from IST Projects The IST MobiVAS project contributed to establishing this WG. Three initial Internet drafts were

written and two Bird-of-Feather sessions were organized at IETF meetings. After the WG was

established, substantial contributions were made by the IST InterMon project including contributions

as author or editor to five working group documents in 29 versions and 2 individual Internet drafts.

The InterMon project was – together with Cisco – the technical driver of this WG. After termination of

the InterMon project, some of the contributors from InterMon continued their contributions to IPFIX

standardisation as part of their activities in the IST EuroLabs Specific Support Action.

The IST SCAMPI project gave input to the IPFIX working group by an Internet draft on IPFIX

implementation experiences and resulting recommendations.

Open issues and Opportunities for Contributions All work items of the WG charter are covered by a sufficient number of contributors. A re-chartering

of the IPFIX WG might happen in spring 2005. Potential issues for a new charter include

- Configuration and Monitoring of IPFIX Devices

The obvious issue at the IETF would be developing an IPFIX MIB module. This could be derived

from the PSAMP MIB (see below).

- Implementation Guidelines

Some implementation issues, for example the implementation on network address translators has

already been discussed in the WG.

- Integration of Flow sampling

So far, only packet sampling was considered by the WG documents, although also flow sampling

has already been discussed by the WG.

2.2.5 PSAMP – Packet SAMPling The Packet SAMPling (PSAMP) WG standardises a protocol for exporting information on observed

packets. This WG was founded after two BoF sessions in March and July 2002, when the IPFIX WG

was already working. While flow records containing information on sets of observed packets with

common properties are in the focus of the IPFIX WG, PSAMP focuses on more basic reports of single



18/10/2004 of 27

IP packets. Most of the function blocks, however, that are used by the PSAMP architecture are also

contained in the IPFIX architecture as shown by Figure 7.

Application

FlowRecord

Observation Point

InformationExport

PAYLOAD H EAD

PAYLOAD H EAD

PAYLOAD H EAD

PAYLOAD H EAD

PAYLOAD H EAD

PAYLOAD H EAD

PAYLOAD H EAD

PAYLOAD H EAD

MeteringProcess

ExportingProcess

Collecting

Process

PacketRecordSampling

& Filtering

Packet

Figure 7: The PSAMP Architecture

The most significant difference between both architectures is the aggregation of packets into flow

records, which is only contained in the IPFIX architecture.

The PSAMP WG decided to re-use the IPFIX protocol for packet information export. At the time of

this decision, the IPFIX protocol met all requirements for this purpose except the export of captured

parts of packets with variable length. On request of the PSAMP WG, the IPFIX WG added such a

feature to the IPFIX protocol. With this extension, the IPFIX protocol can be used also for packet

information export by just extending the IPFIX information model.

The PSAMP WG is working on five documents describing:

- the PSAMP framework and architecture,

- packet sampling and filtering methods,

- the use of the IPFIX protocol for PSAMP,

- the PSAMP information model (as extension of the IPFIX information model),

- a MIB module for reading and writing the PSAMP device configuration.

All documents are progressing well, but several issues are on hold, because they depend on output of

the IPFIX WG. Only a few items have been discussed by the WG that are not yet covered by these

documents. One is the better support of IPv6 packets by sampling methods, another one is a document

on PSAMP applicability.

Contributions from IST Projects Similar to the IPFIX WG, substantial contributions to the PSAMP WG were made by the IST

InterMon project including contributions as authors or editor to four out of five working group

documents in 14 versions and 2 individual Internet drafts. The InterMon project was – together with

Cisco – chairing the WG and – together with AT&T and Cisco – the technical driver of this WG. After

termination of the InterMon project, some of the contributors from InterMon continued their

contributions to IPFIX standardisation as part of their activities in the IST EuroLabs Specific Support

Action.



18/10/2004 of 27

Open issues and Opportunities for Contributions All work items of the working group charter are covered by a sufficient number of contributors. A re-

chartering of the PSAMP WG might happen in summer 2005 but it is expected that the WG will rather

be closed than continues at this point in time. Still, potential issues for a new charter include better

support for IPv6 packets (if this issue is not solved until then) and a document on PSAMP

applicability.

2.2.6 IPPM – IP Performance Metrics The IP Performance Metrics (IPPM) WG standardises a set of metrics to evaluate the quality,

performance and reliability of Internet data delivery services. The metrics defined by the WG provide

a quantitative measure of performance and characterize different features and service classes. Together

with the metric definition, a measurement procedure is also provided. Up to now the following metrics

have been defined:

- Connectivity. RFC 2678, “IPPM Metrics for measuring connectivity” [5], defines several metrics

determining whether pairs of hosts (IP addresses) can reach each other. The document proposes

analytical metrics to define one-way and two-way connectivity at one point in time and over an

interval of time. Methodologies to evaluate those metrics are then contributed too.

- One-way delay. RFC 2679, “A one-way delay metric for IPPM” [8], defines analytical metrics

called singleton, sample, and statistics to measure one single observation of one-way delay, a

sequence of singleton delays measured at times taken from a Poisson process and define and

discuss statistics of this sample

- One-way loss. RFC 2680, “A one-way packet loss metric for IPPM”[9] is the companion

document of RFC 2679, and has pretty much the same structure. It also uses singletons, samples

and statistics to define a metric for one-way packet loss across Internet paths.

- Round-trip delay is defined in RFC 2681 (“A round-trip delay metric for IPPM”) [10]. The

document uses the same schema as for the previous two RFCs.

- Delay variation is described in “IP packet delay variation for IPPM” (RFC 3393)” [22]. This

document refers to a metric based on the difference in the one-way delays of selected packets.

Both the case of pairs of hosts with synchronized clocks and without synchronized clocks are

addressed in the document.

- Loss patterns. The RFC 3357, “One-way loss pattern sample metrics” [19], proposes two derived

metrics, based on the base metrics defined in the other IPPM RFCs, called “loss distance” and

“loss period”. The former captures the frequency and length (burstiness) of loss once it starts,

while the latter captures the spacing between the loss periods. Their definition has been motivated

by the fact that for certain applications the loss pattern or loss distribution strongly influences the

perception of performance.

- Bulk transport capacity has been defined in “A Framework for Defining Empirical Bulk Transfer

Capacity Metrics” (RFC 3148) [16]. Bulk Transport Capacity (BTC) measures the ability of a

network to transfer certain amounts of data with a single congestion-aware transport connection

(e.g. TCP).

- Packet reordering is still at a draft stage [33]. The existing draft defines metrics to evaluate if a

network has maintained packet order on a packet-by-packet basis. As in other IPPM documents, it

starts by defining a reordered singleton using it as a basis for the definition of sample metrics for

several dimensions.

- Link bandwidth capacity is in its initial stage. The editor of the draft has been appointed in August

2004 during the 60th IETF meeting.

Another aspect currently covered within the Working Group is the definition of a reporting

Management Information Base (MIB) for managing network measurements based upon the IPPM

metrics [34]. The MIB definition specifies how the measurement results should be managed and

reported and how/when alarms should be pushed.

Re-chartering of the group is expected to happen in Spring 2005.

Contributions from IST Projects



18/10/2004 of 27

The IST 6QM project is contributing several drafts to this WG. The drafts all address mainly the

design of a reporting MIB. While the group is discussing the eventuality to define another IPPM MIB,

this document, currently in its sixth version and fully implemented could make it to informational

RFC.

Open issues and Opportunities for Contributions There is currently a discussion going on on the appropriateness of the proposed reporting MIB. There

seems to be no consensus with the actual MIB, defined too complex, while there is interest in defining

a lightweight MIB. It is still an open point whether the design of a simpler MIB should be part of the

charter.

Another opportunity to contribute would be in the area of multi-to-multi measurements or traceroutes.

The chairs encourage submitting individual drafts and the WG seems to agree on these as valid topics.

No contributions have been submitted up to now.

2.3 IRTF The Internet Research Task Force (IRTF) is a pre-standardisation organisation closely related to the

IETF. It aims at promoting research in areas important to the evolution of the Internet that are not yet

explored sufficiently for standardisation. The work is done in small, long-term working groups

focused on specific topics related to internet protocols, architecture, applications and technology.

Among the IRTF research groups related to monitoring and measurement are

- the Internet Measurement Research Group (IMRG) focusing on Internet measurements and

- the Network Management Research Group (NMRG).

2.3.1 IMRG The Internet Measurement Research Group (IMRG) provides an open forum for discussion of Internet

measurement research issues. The scope includes all kinds of network measurement (active

techniques, passive monitoring, end-point probing, in-network methods, network layer, transport layer,

application layer, etc.) and both designing new measurement techniques and analyzing measurements

of the network are of interest for the Working Group (WG). Besides this, IMRG is also trying to

increase interactions between operators, developers of measurement tools and techniques, and

researchers who analyze and model Internet dynamics.

Recent work done in the IMRG is related to the evaluation, and discussion on the motivation for a

protocol for Internet measurement. The protocol proposed, the IP Measurement Protocol (IPMP) [25],

has not been approved by the review team within IMRG, but the need for some sort of measurement

protocol seems still to be a point of interest for the group. While a discussion on the suitability of

IPMP is still going on, its rejection from the group makes the topic a good target for future

contributions.

Also, the problem of deploying SLAs that cross ISP boundaries has been raised. Inter-domain

measurement and monitoring is another area to contribute to. In 2003, during the 57th IETF meeting, a

BoF called ISPMON was proposed. Its aim was to address inter-domain measurements. While the BoF

at the time didn’t succeed to become an IETF WG, we feel that the interest for the topic is there (an

ISP, SPRINT, was proposing the BoF) and it might be an interesting area to contribute to in the future.

Beyond these two issues, the IMRG is not a very active research group and support for this group by

the research community is limited.

2.3.2 NMRG The Network Management Research Group (NMRG) investigates new technologies for Internet

management. Different to the IMRG, the NMRG did not start as an open group but as an exclusive

group of top researchers in the area with membership by invitation only. The membership rules have

been loosened since then, but still the NMRG is an important group for the discussion of upcoming

trends and recent results and experiences in network management.



18/10/2004 of 27

Several IETF working groups in the operations and management area have been discussed first in the

NMRG before BoF sessions for them were held and the groups were established.

Monitoring and measurement are only side issues at the NMRG, but often upcoming issues are

discussed at the NMRG before the IMRG takes care of the issue.

Contributions from IST Projects So far, there have been very few concrete contributions from IST projects to the IMRG. The IST

NGN-Labs project contributed several presentations at NMRG meetings but did not participate in

further NMRG activities.

Open issues and Opportunities for Contributions Certainly, the NMRG is very open for interesting new contributions. But since monitoring and

measurement is not the core subject of the NMRG, contributions should be preferred that are related to

network management, for example measurement of network management processes or management of

monitoring and measurement processes. Other issues should rather be contributed to the IMRG.

2.4 ITU The International Telecommunication Union (ITU) is a legal standardisation body that decides on

standards by votes from participating countries. It develops standards in its telecommunication section

(ITU-T) with focus rather on connection-oriented telecommunication. But with the Internet protocol

entering the backbone of telephony networks and with Internet connectivity becoming an issue of

basic connectivity supply to the world’s population, the ITU-T more an more covers Internet

standardisation.

The ITU developed a lot of standards on monitoring and measurement of traffic in non-IP networks,

such as SDH, ATM, etc. These standards are not covered by this document.

2.4.1 SG 3 – Study Group 3 The ITU-T Study Group 3 (SG 3) is responsible for studies relating to tariff and accounting principles

for international telecommunication services and study of related telecommunication economic and

policy issues. To this end, Study Group 3 shall in particular foster collaboration among its members

with a view to the establishment of rates at levels as low as possible consistent with an efficient

service and taking into account the necessity for maintaining independent financial administration of

telecommunication on a sound basis.

Relevant to IP monitoring and measurement are the tariff principles for International Internet

Connectivity (IIC). This covers the way in which Internet traffic at exchange points between different

Internet connectivity providers is measured and accounted. A first very basic document for this

purpose was agreed on in 2000 [17]. However, this recommendation consisting in its core of just 5

lines of text was considered to rudimentary. Particularly small operators and small or developing

countries felt that the needed more regulation in this area in order to have a more fair market.

Therefore, SG 3 currently works on a revision of [17] that covers more details. Besides political and

economical constraints, the issue is also related to technical constrains in the area of IP traffic

measurements.

Open issues and Opportunities for Contributions SG 3 is plans to complete the revision of D.50 in Autumn 2004. Anyway, participation from EU

projects is difficult, because only legal participants, such as national representatives are considered at

ITU. Still technical recommendations and text contributions by any source with the appropriate

expertise are welcome.



18/10/2004 of 27

2.5 3GPP The 3

rd Generation Partnership Project (3GPP) is an industry forum for standardizing technology for

3rd

generation mobile phone systems with the tendency to extend the terminals far beyond the phone

capabilities known from 2nd

generation mobile phone systems, such a GSM phones. 3GPP follows a

clear trend towards applying IP in more and more components. The core network is already defined as

an IP-based network, the access network, that so far is based on ATM transport, is expected to use IP

transport in future releases of 3GPP standards. For 3GPP terminals, the support of IP is obligatory

already.

3GPP is dealing with traffic measurement on three levels and on three stages. For all specification

stage one is the definition of requirements. For IP monitoring and measurement, this is done in the

Service Architecture Working Group 1 (SA1). On stage two, architectures are defined in SA2. On

stage three, functions and protocols for monitoring and measurement are defined in SA5.

The first level of usage-based IP packet accounting is the radio access network. Here, IP packets are

encapsulated into frames, and there is no instance capable of reading IP information. Therefore, only

packet count and byte count information is available for accounting. Standardisation of monitoring and

measurement at this level is already completed.

The second level is at the gateway between the access network and the IP-based core network. Here all

IP packets are fully visible and still can easily be mapped to the sending terminal or receiving

terminal, respectively. At the 3GPP, traffic accounting and charging at this level is called IP flow-

based bearer-level charging. For this issue, 3GPP standardisation has already reached stage 3. SA5 is

starting to define functions and protocols.

The third level is monitoring and measurement based on application-level signalling. 3GPP has

defined the IP Multimedia Subsystem (IMS) to which IP applications signal their communication

requests using the Session Initiation Protocol (SIP). At this level IP data streams are accounted based

on the information extracted from SIP signalling. No real packets are measured, but signalling

messages indicating (by their encoder type) which kind of packets are sent from where to where. IMS

accounting and charging is at the same stage as IP flow-based bearer-level charging. SA5 just started

defining functions and protocols.

For online charging, charging rules, traffic accounting and credit control are involved and need to

interact with each other via reference points. For offline charging, charging rules, traffic accounting,

charging collection functions and charging gateway functions are involved.

2.5.1 SA5 – Service Architecture Working Group 5 IP flow-based bearer-level charging [27] and IMS charging are current issues of 3GPP SA5 [20].

Work on IP flow-based bearer-level charging started in early 2004 and work on IMS charging in

summer 2004.

The main goal of IP flow-based bearer-level charging is increasing charging capability and charging

flexibility compared to packet accounting on the radio access level. The work is targeted at variable

charging schemes applicable to existing and new IP services. Flexibility of charging should include

volume-based charging, time-based charging, offline-charging (post-paid), credit-based online

charging (pre-paid), charging per service, and individual charging schemes for value-added services.

SA2 has developed a charging architecture for online and offline charging. For offline charging,

shown in Figure 8, the main components are an Application function (AF) that generates flow-based

charging rules and transmits them via the Rx reference point to a rule function that configures the

traffic measurement functions on traffic plane. From here, IP traffic flow records are transmitted via

the Gz reference point to a charging collection function that accumulates user’s charging records or to

a charging gateway function that forwards flow records to other external charging functions, for

example to a value-added service provider.



18/10/2004 of 27

Traffic PlaneFunction

ChargingGatewayFunction

Gx

ChargingCollectionFunction

Service Data FlowBased ChargingRules Function

Gz

Rx

AF

I

Figure 8: 3GPP IP Flow-Based Online Charging Architecture

Initially, SA5 discussed using IPIFX as protocol for reference point Gz, but finally the DIAMETER

protocol was selected. For online charging, reference point Gz is replaced by Gy and the traffic

measurement functions on the traffic plane do interact with online credit control functions (Figure 9).

Traffic PlaneFunction

Gx

Online Charging System*

Service DataFlow Based

Credit Control

Service Data FlowBased ChargingRules Function

Function

CAMELSCP

Gy

Rx

AF

Figure 9: 3GPP IP Flow-Based Online Charging Architecture

For credit control now the traffic plane functions must provide more than just traffic measurement

functionality, because in the case that credit is exhausted, also functionality for blocking traffic needs

to be included.

Contributions from IST Projects There are no known contributions from IST projects.



18/10/2004 of 27

Open issues and Opportunities for Contributions At the time of this writing, there is still a chance for joining SA5 and contributing to charging issues.

However, this time window will close soon, probably already in 2004.

2.6 IPDR.org IPDR.org is an industry forum developing technology for IP traffic-based accounting and charging.

The main goal of the members of this forum is defining a common information model for IP detailed

records containing accounting information on the usage of IP services. IPDR.org developed the IP

Detailed Record (IPDR) specification [29] that defines an information model for IP accounting

records. The model uses XML as specification languages and re-uses standardized XML data types.

Recently, IPDR.org adopted the Common Reliable Accounting for Network Elements (CRANE) [23]

as transport protocol for IPDR records.

The IPDR work is completed and acceptance of their standard is limited to a small group of IP

accounting systems and applications

Contributions from IST Projects There are no known contributions from IST projects.

Open issues and Opportunities for Contributions Since the work in IPDR.org on traffic measurement appears to be completed, there are no

opportunities for future contributions.

2.7 GGF The GGF is structured in 9 areas. Each area consists of multiple working groups and research groups.

Measurement related topics are discussed in the area Information Systems and Performance (ISP). The

group developed a Grid Monitoring Architecture (GMA, [19]) for fault detection, performance

analysis and tuning, performance prediction and task scheduling in grid networks.

2.7.1 NM-WG – Network Measurements Working Group The area consists of further working groups that work on measurement related topics. The Network

Measurements Working Group (NM-WG) defines which metrics are of relevance to supervise and

support the operation for applications and middleware in grid environments. It develops methods to

describe theses metrics in a standardized way. The working group cooperates closely with the IETF

IPPM working group and with the Internet2 End-to-end initiative. The group has issued a document on

“A Hierarchy of Network Performance Characteristics for Grid Applications and Services” which

describes metrics useful for grid applications. Terminology and metrics are strongly related to those

defined in the IETF IPPM working group. Furthermore the group works on an XML schema for the

description and representation of the measurement results. The working group maintains a tools

classification web page with a list of measurement tools that can be used to measure the relevant

metrics for grid environment.

2.7.2 GB-RG – Grid Benchmark Research Group In addition to this there are two research groups in the area. The Grid Benchmark Research Group

(GB-RG) will define metrics to rate the functionality, performance and efficiency of grid architectures.

With this different architectures and implementations can be compared. Furthermore the metrics are

used to inform users about the capabilities of a system (which can be used as a basis for adapting

applications to the grid capabilities). The group also plans to provide reference implementations.

2.7.3 NMA-RG – Network Measurements for Applications Research Group The Network Measurements for Applications Research Group (NMA-RG) investigates what network

performance parameters are most relevant for the grid middleware. The information on the relation

between network performance and middleware can be used as basis for developing a network-aware

middleware.



18/10/2004 of 27

Contributions from IST Projects The GGF attempts to use metrics and methods standardized within the IETF (mainly IPPM group). If

a project has not specifically Grid-oriented measurement tools or data, it is much better for this group

to submit their ideas directly to the IETF or IRTF instead to the GGF. Nevertheless, it may be of value

to make the GGF aware of new metrics and methods submitted as drafts to the IETF/IRTF.

Furthermore if metrics or methods are specifically developed with grid applications in mind or are of

special value for grid environment it would be advantageous to discuss requirements and methods with

the GGF groups (especially the NM-WG).

Open issues and Opportunities for Contributions The GGF is highly oriented towards the IETF measurement activities. Therefore measurement

standardization should be rather done in IETF/IRTF and then adopted by GGF. So instead of using

this forum to standardize measurement methods and metrics and instead of advising IST projects to

contribute to the GGF one could rather see the GGF as a user of the MOME results.

The NM-WG group maintains a list of measurement tools for measuring network parameters that are

needed in grid scenarios. So it seems that a tool database would be of value for the GGF. The MOME

project should contact the NM-WG when the MOME tool database is available. The GGF could in

general profit from MOME results, so that MOME might take a chance to present results to some GGF

groups.

Maybe special support with regard to grid applications could be added to the MOME databases in

order to support grid people who seek for tools or data with certain attributes.



18/10/2004 of 27

3 Opportunities for Contributions This section summarizes the open standardisation issues, opportunities and contributions from IST

projects reported in the previous section. Based on this overview, it gives a recommendation for future

involvement of IST projects in monitoring and measurement standardisation.

3.1 Contributions from IST projects Standardisation of traffic measurement at the IETF is already significantly influenced by IST projects,

particularly by the already completed InterMon project, but also by ACTS MobiVAS, IST SCAMPI,

IST 6QM, IST NGN-Lab and IST EuroLabs. It is highly recommended to maintain this high level of

contribution in order to consolidate the a clear recognition of contributions from Europe.

3.2 Standardisation Opportunities There are several minor standardisation opportunities in different bodies, but there is only one that is

permanently open: the Internet Measurement Research Group (IMRG) of the IRTF. All other research

opportunities have certain windows of time where participants can easily join the standardisation

process and can influence it.

The time window of IP traffic measurement in 3GPP will very soon be closed, definitely at the end of

2004.

At the IETF two new time windows are expected in spring 2005. The IPPM WG and the IPFIX WG

will be re-chartered at that time and new work items can be added to the WG charters. In IPPM,

chances of acceptance are high for work on defining a traceroute metric and defining a multi-to-multi

measurement metric. At IPFIX re-chartering may open an opportunity for contributing to the

standardisation of a network management interface to IPFIX devices by defining an IPFIX MIB

module and to specifying implementation recommendations for IPFIX devices.

3.3 Recommendations Based on past experiences and the identified opportunities for participation in standardisation

activities, two main recommendations are given.

The strong and successful active participation in standardizing traffic metering technology within the

IETF should be continued. A lot of expertise has been accumulated by European IST project and they

have become a driving force in standardising traffic monitoring and measurement in the IETF.

Particularly, the projects and project partners that already built up expertise in IETF standardisation

should continue their activities and encourage other projects to join them for building up a strong

European participation that brings European aspects and European points of view into the

standardisation process, for example the higher need for privacy of data.

The Internet Measurement Research Group (IMRG) is a very good platform for new ideas,

technologies or application of them in the area of IP traffic measurement. This platform can easily be

used by IST projects with new ideas, because it is very open and looking for more participation.

Particularly for new projects and for projects investigating basic issues in long term research activities,

it is recommended to join the IMRG as active members.

A minor recommendation concerns activities in the 3rd Generation Partnership Project where IP traffic

measurement is under standardisation for accounting and charging purposes, but work on this issue

has already progressed far in 3GPP and the opportunity to participate is only give if actions start

immediately



18/10/2004 of 27

3.4 Standardisation Plan According to the recommendations in the previous section, there are two actions to be performed by

the MOME WP3:

- Establishing a team for continuing the successful contribution to the IETF IPFIX and IPPM

standardisation.

- Identifying research areas in participating IST projects that are suited as work items for the IMRG

and encouraging the corresponding projects to bring their contributions to the IMRG.

Both actions are explained in more detail below.

3.4.1 IPFIX Standardisation Team A team should be established that continues the successful contributions to standardisation work in the

IETF IPFIX and IPPM WGs. Suitable candidates can be project partners in the 6QM, Lobster,

EuroLabs and other project participating in the MOME cluster. This team should include partners

experienced in IETF standardisation as well as “interested newcomers” in order to spread gained

knowledge and experience among the projects.

The team should be established by the end of 2004 in order to be prepared for the potential re-

chartering of both WGs. For the IETF meeting in March 2005 the team should prepare four Internet

drafts before the deadline for this meeting and in order to be presented at this meeting:

- a draft submitted to the IPPM WG proposing a metric for traceroute measurements,

- a draft submitted to the IPPM WG proposing a metric for multi-to-multi measurements,

- a draft submitted to the IPFIX WG proposing an MIB module for monitoring and optionally also

for configuring IPFIX devices,

- a draft submitted to the IPFIX WG proposing implementation guidelines for IPIFX

implementations

All four drafts have a reasonable chance to be accepted as work item of the respective WG. Still, there

might be competing drafts and the WG may reject these work items, but currently, no such competing

drafts or initiative to write them are known and the WG chairs show interest in adding these work

items to their charter.

The MOME WP3 will take care of shaping this team. The detailed actions include:

- Contacting related IST projects and suited partners within these projects,

- Organizing a phone conference with interested parties in order to explain the plan,

- Organizing a kick-off meeting with committed partners,

- Monitoring progress of the Internet drafts to be written,

- Coordinating discussions with IPFIX and IPPM WG chairs and the corresponding IETF area

directors

Results and experiences with this process will be reported and discussed at the MOME standardisation

event in summer 2005.

3.4.2 Identifying potential contributions to the IRTF IMRG MOME WP3 will identify research areas of IST projects participating in the MOME cluster which are

suited for a new activity in the Internet Measurement Research Group (IMRG) of the IRTF. For each

identified area, the potential of a contribution to the IMRG will be evaluated and the corresponding

projects, and partners within these projects will be encouraged to start respective initiatives in the

IMRG, and they will be consulted while doing so.



18/10/2004 of 27

A list of areas together with the names of the corresponding projects and candidate partners to perform

the initiative in the IMRG will be prepared for the MOME audit in February 2005. Initiatives are

expected to start in spring 2005.



18/10/2004 of 27

4 References

[1] McCloghrie, K. and M. Rose, "Management Information Base for Network Management of

TCP/IP-based internets: MIB-II", STD 17, RFC 1213, March 1991.

[2] Waldbusser, S., “Token Ring Extensions to the Remote Network Monitoring MIB", RFC 1513,

September 1993.

[3] McCloghrie, K., "SNMPv2 Management Information Base for the Transmission Control

Protocol using SMIv2", RFC 2012, November 1996.

[4] McCloghrie, K., "SNMPv2 Management Information Base for the User Datagram Protocol using

SMIv2", RFC 2013, November 1996.

[5] Waldbusser, S., “Remote Network Monitoring Management Information Base Version 2 using

SMIv2”, RFC 2021, January 1997.

[6] Waterman, R., Lahaye, B., Romascanu, D. and S. Waldbusser, “Remote Network Monitoring

MIB Extensions for Switched Networks Version 1.0”, RFC 2613, June 1999.

[7] Mahdavi, J. and V. Paxson “IPPM Metrics for Measuring Connectivity”, RFC 2678, September

1999.

[8] Almes, G., Kalidindi, S. and M. Zekauskas, „A One-way Delay Metric for IPPM”, RFC 2679,

September 1999.

[9] Almes, G., Kalidindi, S. and M. Zekauskas, „A One-way Packet Loss Metric for IPPM”, RFC

2680, September 1999.

[10] Almes, G., Kalidindi, S. and M. Zekauskas, „A Round-trip Delay Metric for IPPM”, RFC 2681,

September 1999.

[11] Brownlee, N., "Traffic Flow Measurement: Meter MIB", RFC 2720, October 1999.

[12] Brownlee, N., Mills, C. and G. Ruth, "Traffic Flow Measurement: Architecture", RFC 2722,

October 1999.

[13] Handelman, S., Brownlee, N., Ruth, G. and S. Stibler, "New Attributes for Traffic Flow

Measurement", RFC 2724, October 1999.

[14] Waldbusser, S., “Remote Network Monitoring Management Information Base”, RFC 1757, May

2000.

[15] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000.

[16] Stewart, R. (ed.) “Stream Control Transmission Protocol”, RFC 2960, October 2000.

[17] International Telecommunication Union, “General Tariff Principles – International Internet

Connection”, ITU-T Recommendation D.50, October 2000.

[18] Mathis, M. and M. Allman, “A Framework for Defining Empirical Bulk Transfer Capacity

Metrics”, RFC 3148, July 2001.

[19] Tierney, B., Aydt, R., Gunter, D., Smith, W., Swany, M., Taylor, V. and R. Wolski, “A Grid

Monitoring Architecture”, Informational GGF Document GFC.7, January 2002.

[20] 3rd

Generation Partnership Project, “Charging Implications of IMS Architecture”, TR 23.815,

April 2002.

[21] Koodli, R. and R. Ravikanth, "One-way Loss Pattern Sample Metrics”, RFC 3357, August 2002.

[22] Demichelis, C. and P.Chimento “IP Packet Delay Variation Metric for IP Performance Metrics

(IPPM)”, RFC 3393, November 2002

[23] Zhang, K. and E. Elkin, “XACCT's Common Reliable Accounting for Network Element

(CRANE) Protocol Specification Version 1.0”, RFC 3423, November 2002.

[24] Case, J., Mundy, R., Partain, D. and B. Stewart, “Introduction and Applicability Statements for

Internet-Standard Management Framework”, RFC 3410, December 2002.

[25] Waldbusser, S., Cole, R., Kalbfleisch, C., and D. Romascanu “Introduction to the Remote

Monitoring (RMON) Family of MIB Modules”, RFC 3577, August 2003.

[26] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. Arkko, “Diameter Base Protocol”, RFC

3588, September 2003.

[27] 3rd

Generation Partnership Project, “IP Flow-Based Bearer Level Charging Architecture”, TR

23.825, January 2004.

[28] McGregor A. and M. Luckie IP measurement protocol, Internet Draft, (work in progress) , draft-

mcgregor-ipmp-04.txt, February 2004.



18/10/2004 of 27

[29] Cotton, S. (Ed.), “IPDR/Streaming Protocol Specification, Version 2.0”, May 2004.

[30] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. Conrad, “Stream Control Transmission

Protocol (SCTP) Partial Reliability Extension”, RFC 3758, May 2004.

[31] Quittek, J., Zseby, T., Claise, B. and S. Zander, “Requirements for IP Flow Information Export

(IPFIX)”, RFC 3917, October 2004.

[32] Claise, B, et al “Cisco Systems NetFlow Services Export Version 9", RFC to be published soon,

Autumn/Winter 2004.

[33] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, s., and J. Perser “Packet Reordering

Metric for IPPM”, draft-ietf-ippm-reordering-07.txt, (work in progress).

[34] Stephan, E. and J. Hewitt, “IP Performance Metrics (IPPM) reporting Information Base (MIB)”,

draft-ietf-ippm-reporting-mib-06.txt (work in progress).

mome-wp3-0409-d31 standardisation plan › ... › mome-wp3-0409-d31_standardisation… · Document...

Documents

Transcript of mome-wp3-0409-d31 standardisation plan › ... › mome-wp3-0409-d31_standardisation… · Document...