draft-ietf-rtfm-new-traffic-flow-10.txt   rfc2724.txt 
Internet Engineering Task Force S.W. Handelman
INTERNET-DRAFT IBM
Hawthorne, NY USA
Nevil Brownlee Network Working Group S. Handelman
Request for Comments: 2724 S. Stibler
Category: Experimental IBM
N. Brownlee
The University of Auckland The University of Auckland
New Zealand G. Ruth
Greg Ruth
GTE Internetworking GTE Internetworking
Waltham, MA USA October 1999
S. Stibler
IBM
Hawthorne, NY USA
September 2000
Expires March 2000
RTFM: New Attributes for Traffic Flow Measurement RTFM: New Attributes for Traffic Flow Measurement
<draft-ietf-rtfm-new-traffic-flow-10.txt>
Abstract
The RTFM Traffic Measurement Architecture provides a general framework
for describing and measuring network traffic flows. Flows are defined
in terms of their Address Attribute values and measured by a 'Traffic
Meter.' This document discusses RTFM flows and the attributes which
they can have, so as to provide a logical framework for extending the
architecture by adding new attributes.
Extensions described include Address Attributes such as DSCodePoint,
SourceASN and DestASN, and Group Attributes such as short-term bit rates
and turnaround times. Quality of Service parameters for Integrated
Services are also discussed.
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with all This memo defines an Experimental Protocol for the Internet
provisions of Section 10 of RFC 2026. community. It does not specify an Internet standard of any kind.
Discussion and suggestions for improvement are requested.
Internet-Drafts are working documents of the Internet Engineering Task Distribution of this memo is unlimited.
Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet Draft is a product of the Realtime Traffic Flow
Measurement Working Group of the IETF.
Contents Copyright Notice
1 Introduction 3 Copyright (C) The Internet Society (1999). All Rights Reserved.
1.1 RTFM's Definition of Flows . . . . . . . . . . . . . . . . . 3
1.2 RTFM's Current Definition of Flows and their Attributes . . . 4
1.3 RTFM Flows, Integrated Services, IPPM and Research in Flows . 5
2 Flow Abstractions 6 Abstract
2.1 Meter Readers and Meters .. . . . . . . . . . . . . . . . . 6
2.2 Attribute Types . . . . . .. . . . . . . . . . . . . . . . . 6
2.3 Packet Traces . . . . . . .. . . . . . . . . . . . . . . . . 8
2.4 Aggregate Attributes . . . .. . . . . . . . . . . . . . . . . 8
2.5 Group Attributes . . . .. . . . . . . . . . . . . . . . . . . 9
2.6 Actions on Exceptions . . .. . . . . . . . . . . . . . . . . 10
3 Extensions to the 'Basic' RTFM Meter 11 The RTFM Traffic Measurement Architecture provides a general
3.1 Flow table extensions . . .. . . . . . . . . . . . . . . . . 11 framework for describing and measuring network traffic flows. Flows
3.2 Specifying Distributions in RuleSets . . . . . . . . . . . . 11 are defined in terms of their Address Attribute values and measured
3.3 Reading Distributions . . .. . . . . . . . . . . . . . . . . 13 by a 'Traffic Meter'. This document discusses RTFM flows and the
attributes which they can have, so as to provide a logical framework
for extending the architecture by adding new attributes.
4 Extensions to the Rules Table, Attribute Numbers 13 Extensions described include Address Attributes such as DSCodePoint,
SourceASN and DestASN, and Group Attributes such as short-term bit
rates and turnaround times. Quality of Service parameters for
Integrated Services are also discussed.
5 Security Considerations 15 Table of Contents
6 References 15 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1 RTFM's Definition of Flows . . . . . . . . . . . . . . . . 3
1.2 RTFM's Current Definition of Flows and their Attributes . . 3
1.3 RTFM Flows, Integrated Services, IPPM and Research in Flows 4
2 Flow Abstractions . . . . . . . . . . . . . . . . . . . . . . . 5
2.1 Meter Readers and Meters . . . . . . . . . . . . . . . . . 5
2.2 Attribute Types . . . . . . . . . . . . . . . . . . . . . . 6
2.3 Packet Traces . . . . . . . . . . . . . . . . . . . . . . . 7
2.4 Aggregate Attributes . . . . . . . . . . . . . . . . . . . 8
2.5 Group Attributes . . . . . . . . . . . . . . . . . . . . . 8
2.6 Actions on Exceptions . . . . . . . . . . . . . . . . . . .10
3 Extensions to the 'Basic' RTFM Meter . . . . . . . . . . . . .10
3.1 Flow table extensions . . . . . . . . . . . . . . . . . . .10
3.2 Specifying Distributions in RuleSets . . . . . . . . . . .11
3.3 Reading Distributions . . . . . . . . . . . . . . . . . . .13
4 Extensions to the Rules Table, Attribute Numbers . . . . . . .13
5 Security Considerations . . . . . . . . . . . . . . . . . . . .15
6 References . . . . . . . . . . . . . . . . . . . . . . . . . .16
7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . .17
8 Full Copyright Statement . . . . . . . . . . . . . . . . . . .18
7 Author's Addresses 16
1 Introduction 1 Introduction
The Real-Time Flow Measurement (RTFM) Working Group (WG) has developed a The Real-Time Flow Measurement (RTFM) Working Group (WG) has
system for measuring and reporting information about traffic flows in developed a system for measuring and reporting information about
the Internet. This document explores the definition of extensions to traffic flows in the Internet. This document explores the definition
the flow measurements as currently defined in [RTFM-ARC]. The new of extensions to the flow measurements as currently defined in
attributes described in this document will be useful for monitoring [RTFM-ARC]. The new attributes described in this document will be
network performance and will expand the scope of RTFM beyond simple useful for monitoring network performance and will expand the scope
measurement of traffic volumes. A companion document to this draft will of RTFM beyond simple measurement of traffic volumes. A companion
be written to define MIB structures for the new attributes. document to this memo will be written to define MIB structures for
the new attributes.
This draft was started in 1996 to advance the work of the RTFM group. This memo was started in 1996 to advance the work of the RTFM group.
The goal of this work is to produce a simple set of abstractions, which The goal of this work is to produce a simple set of abstractions,
can be easily implemented and at the same time enhance the value of RTFM which can be easily implemented and at the same time enhance the
Meters. This document also defines a method for organizing the flow value of RTFM Meters. This document also defines a method for
abstractions to augment the existing RTFM flow table. organizing the flow abstractions to augment the existing RTFM flow
table.
Implementations of the RTFM Meter have been done by Nevil Brownlee in Implementations of the RTFM Meter have been done by Nevil Brownlee in
the University of Auckland, NZ, and Stephen Stibler and Sig Handelman at the University of Auckland, NZ, and Stephen Stibler and Sig Handelman
IBM in Hawthorne, NY, USA. The RTFM WG has also defined the role of the at IBM in Hawthorne, NY, USA. The RTFM WG has also defined the role
Meter Reader whose role is to retrieve flow data from the Meter. of the Meter Reader whose role is to retrieve flow data from the
Meter.
Note on flows and positioning of meters: Note on flows and positioning of meters:
A flow as it traverses the Internet may have some of its A flow as it traverses the Internet may have some of its
characteristics altered as it travels through Routers, characteristics altered as it travels through Routers, Switches,
Switches, and other network units. It is important to note the and other network units. It is important to note the spatial
spatial location of the Meter when referring to attributes of a location of the Meter when referring to attributes of a flow. An
flow. An example, a server may send a sequence of packets with example, a server may send a sequence of packets with a definite
a definite order, and inter packet timing with a leaky bucket order, and inter packet timing with a leaky bucket algorithm. A
algorithm. A meter reading downstream of the leaky bucket meter reading downstream of the leaky bucket would record a set
would record a set with minimal inter packet timing due to the with minimal inter packet timing due to the leaky bucket. At the
leaky bucket. At the client's location, the packets may arrive client's location, the packets may arrive out of sequence, with
out of sequence, with the timings altered. A meter at the the timings altered. A meter at the client's location would
client's location would record different attributes for the record different attributes for the same flow.
same flow.
1.1 RTFM's Definition of Flows 1.1 RTFM's Definition of Flows
The RTFM Meter architecture views a flow as a set of packets between two The RTFM Meter architecture views a flow as a set of packets between
endpoints (as defined by their source and destination attribute values two endpoints (as defined by their source and destination attribute
and start and end times), and as BI-DIRECTIONAL (i.e. the meter values and start and end times), and as BI-DIRECTIONAL (i.e. the
effectively monitors two sub-flows, one in each direction). meter effectively monitors two sub-flows, one in each direction).
Reasons why RTFM flows are bi-directional: Reasons why RTFM flows are bi-directional:
- The WG is interested in understanding the behavior of sessions - The WG is interested in understanding the behavior of sessions
between endpoints. between endpoints.
- The endpoint attribute values (the "Address" and "Type" ones) are - The endpoint attribute values (the "Address" and "Type" ones)
the same for both directions; storing them in bi-directional flows are the same for both directions; storing them in bi-
reduces the meter's memory demands. directional flows reduces the meter's memory demands.
- 'One-way' (uni-directional) flows are a degenerate case. Existing - 'One-way' (uni-directional) flows are a degenerate case.
RTFM meters can handle this by using one of the computed attributes Existing RTFM meters can handle this by using one of the
(e.g. FlowKind) to indicate direction. computed attributes (e.g. FlowKind) to indicate direction.
1.2 RTFM's Current Definition of Flows and their Attributes 1.2 RTFM's Current Definition of Flows and their Attributes
Flows, as described in the "Architecture" document [RTFM-ARC] have the Flows, as described in the "Architecture" document [RTFM-ARC] have
following properties: the following properties:
a. They occur between two endpoints, specified as sets of attribute a. They occur between two endpoints, specified as sets of attribute
values in the meter's current rule set. A flow is completely values in the meter's current rule set. A flow is completely
identified by its set of endpoint attribute values. identified by its set of endpoint attribute values.
b. Each flow may also have values for "computed" attributes (Class b. Each flow may also have values for "computed" attributes (Class
and Kind). These are directly derived from the endpoint and Kind). These are directly derived from the endpoint attribute
attribute values. values.
c. A new flow is created when a packet is to be counted that does c. A new flow is created when a packet is to be counted that does not
not match the attributes of an existing flow. The meter records match the attributes of an existing flow. The meter records the
the time when this new flow is created. time when this new flow is created.
d. Attribute values in (a), (b) and (c) are set when the meter sees d. Attribute values in (a), (b) and (c) are set when the meter sees
the first packet for the flow, and are never changed. the first packet for the flow, and are never changed.
e. Each flow has a "LastTime" attribute, which indicates the time e. Each flow has a "LastTime" attribute, which indicates the time the
the meter last saw a packet for the flow. meter last saw a packet for the flow.
f. Each flow has two packet and two byte counters, one for each f. Each flow has two packet and two byte counters, one for each flow
flow direction (Forward and Backward). These are updated as direction (Forward and Backward). These are updated as packets
packets for the flow are observed by the meter. for the flow are observed by the meter.
g. ALL the attributes have (more or less) the same meaning for a g. ALL the attributes have (more or less) the same meaning for a
variety of protocols; IPX, AppleTalk, DECnet and CLNS as well variety of protocols; IPX, AppleTalk, DECnet and CLNS as well as
as TCP/IP. TCP/IP.
Current flow attributes - as described above - fit very well into the Current flow attributes - as described above - fit very well into the
SNMP data model. They are either static, or are continuously updated SNMP data model. They are either static, or are continuously updated
counters. They are NEVER reset. In this document they will be referred counters. They are NEVER reset. In this document they will be
to as "old-style" attributes. referred to as "old-style" attributes.
It is easy to add further "old-style" attributes, since they don't It is easy to add further "old-style" attributes, since they don't
require any new features in the architecture. For example: require any new features in the architecture. For example:
- Count of the number of "lost" packets (determined by watching - Count of the number of "lost" packets (determined by watching
sequence number fields for packets in each direction; only sequence number fields for packets in each direction; only
available for protocols which have such sequence numbers). available for protocols which have such sequence numbers).
- In the future, RTFM could coordinate directly with the Flow Label - In the future, RTFM could coordinate directly with the Flow
from the IPv6 header. Label from the IPv6 header.
1.3 RTFM Flows, Integrated Services, IPPM and Research in Flows 1.3 RTFM Flows, Integrated Services, IPPM and Research in Flows
The concept of flows has been studied in various different contexts. The concept of flows has been studied in various different contexts.
For the purpose of extending RTFM, a starting point is the work of the For the purpose of extending RTFM, a starting point is the work of
Integrated Services WG. We will measure quantities that are often set by the Integrated Services WG. We will measure quantities that are often
Integrated Services configuration programs. We will look at the work of set by Integrated Services configuration programs. We will look at
the Benchmarking / IP Performance Metrics Working Group, and also look the work of the Benchmarking/IP Performance Metrics Working Group,
at the work of Claffy, Braun and Polyzos [C-B-P]. We will demonstrate and also look at the work of Claffy, Braun and Polyzos [C-B-P]. We
how RTFM can compute throughput, packet loss, and delays from flows. will demonstrate how RTFM can compute throughput, packet loss, and
delays from flows.
An example of the use of capacity and performance information is found An example of the use of capacity and performance information is
in "The Use of RSVP with IETF Integrated Services" [IIS-RSVP]. RSVP's found in "The Use of RSVP with IETF Integrated Services" [IIS-RSVP].
use of Integrated Services revolves around Token Bucket Rate, Token RSVP's use of Integrated Services revolves around Token Bucket Rate,
Bucket Size, Peak Data Rate, Minimum Policed Unit, Maximum Packet Size, Token Bucket Size, Peak Data Rate, Minimum Policed Unit, Maximum
and the Slack term. These are set by TSpec, ADspec and FLowspec Packet Size, and the Slack term. These are set by TSpec, ADspec and
(Integrated Services Keywords), and are used in configuration and FLowspec (Integrated Services Keywords), and are used in
operation of Integrated Services. RTFM could monitor explicitly Peak configuration and operation of Integrated Services. RTFM could
Data Rate, Minimum Policed Unit, Maximum Packet Size, and the Slack monitor explicitly Peak Data Rate, Minimum Policed Unit, Maximum
term. RTFM could infer details of the Token Bucket. The WG will Packet Size, and the Slack term. RTFM could infer details of the
develop measures to work with these service metrics. An initial Token Bucket. The WG will develop measures to work with these
implementation of IIS Monitoring has been developd at CEFRIEL in Italy service metrics. An initial implementation of IIS Monitoring has
[IIS-ACCT]. been developd at CEFRIEL in Italy [IIS-ACCT].
RTFM will work with several traffic measurements identified by IPPM RTFM will work with several traffic measurements identified by IPPM
[IPPM-FRM]. There are three broad areas in which RTFM is useful for [IPPM-FRM]. There are three broad areas in which RTFM is useful for
IPPM. IPPM.
- An RTFM Meter could act as a passive device, gathering traffic and - An RTFM Meter could act as a passive device, gathering traffic
performance statistics at appropriate places in networks (server or and performance statistics at appropriate places in networks
client locations). (server or client locations).
- RTFM could give detailed analyses of IPPM test flows that pass - RTFM could give detailed analyses of IPPM test flows that pass
through the Network segment that RTFM is monitoring. through the Network segment that RTFM is monitoring.
- RTFM could be used to identify the most-used paths in a network - RTFM could be used to identify the most-used paths in a network
mesh, so that detailed IPPM work could be applied to these most mesh, so that detailed IPPM work could be applied to these most
used paths. used paths.
2 Flow Abstractions 2 Flow Abstractions
Performance attributes include throughput, packet loss, delays, jitter, Performance attributes include throughput, packet loss, delays,
and congestion measures. RTFM will calculate these attributes in the jitter, and congestion measures. RTFM will calculate these
form of extensions to the RTFM flow attributes according to three attributes in the form of extensions to the RTFM flow attributes
general classes: according to three general classes:
- 'Trace,' attributes of individual packets in a flow or a segment - 'Trace', attributes of individual packets in a flow or a
of a flow (\eg last packet size, last packet arrival time). segment of a flow (e.g. last packet size, last packet arrival
time).
- 'Aggregate,' attributes derived from the flow taken as a whole - 'Aggregate', attributes derived from the flow taken as a whole
(e.g. mean rate, max packet size, packet size distribution). (e.g. mean rate, max packet size, packet size distribution).
- 'Group,' attributes that depend on groups of packet values within - 'Group', attributes that depend on groups of packet values
the flow (\eg inter-arrival times, short-term traffic rates). within the flow (e.g. inter-arrival times, short-term traffic
rates).
Note that attributes within each of these classes may have various types Note that attributes within each of these classes may have various
of values - numbers, distributions, time series, and so on. types of values - numbers, distributions, time series, and so on.
2.1 Meter Readers and Meters 2.1 Meter Readers and Meters
A note on the relation between Meter Readers and Meters .. A note on the relation between Meter Readers and Meters.
Several of the measurements enumerated below can be implemented by a Several of the measurements enumerated below can be implemented by a
Meter Reader that is tied to a meter with very short response time and Meter Reader that is tied to a meter with very short response time
very high bandwidth. If the Meter Reader and Meter can be arranged in and very high bandwidth. If the Meter Reader and Meter can be
such a way, RTFM could collect Packet Traces with time stamps and arranged in such a way, RTFM could collect Packet Traces with time
provide them directly to the Meter Reader for further processing. stamps and provide them directly to the Meter Reader for further
processing.
A more useful alternative is to have the Meter calculate some flow A more useful alternative is to have the Meter calculate some flow
statistics locally. This allows a looser coupling between the Meter and statistics locally. This allows a looser coupling between the Meter
Meter Reader. RTFM will monitor an 'extended attribute' depending upon and Meter Reader. RTFM will monitor an 'extended attribute'
settings in its Rule table. RTFM will not create any "extended depending upon settings in its Rule table. RTFM will not create any
attribute" data without explicit instructions in the Rule table. "extended attribute" data without explicit instructions in the Rule
table.
2.2 Attribute Types 2.2 Attribute Types
Section 2. described three different classes of attributes; this Section 2 described three different classes of attributes; this
section considers the "data types" of these attributes. section considers the "data types" of these attributes.
Packet Traces (as described below) are a special case in that they are Packet Traces (as described below) are a special case in that they
tables with each row containing a sequence of values, each of varying are tables with each row containing a sequence of values, each of
type. They are essentially 'compound objects' i.e. lists of attribute varying type. They are essentially 'compound objects' i.e. lists of
values for a string of packets. attribute values for a string of packets.
Aggregate attributes are like the 'old-style' attributes. Their types Aggregate attributes are like the 'old-style' attributes. Their
are types are:
- Addresses, represented as byte strings (1 to 20 bytes long) - Addresses, represented as byte strings (1 to 20 bytes long)
- Counters, represented as 64-bit unsigned integers - Counters, represented as 64-bit unsigned integers
- Times, represented as 32-bit unsigned integers - Times, represented as 32-bit unsigned integers
Addresses are saved when the first packet of a flow is observed. They Addresses are saved when the first packet of a flow is observed.
do not change with time, and they are used as a key to find the flow's They do not change with time, and they are used as a key to find the
entry in the meter's flow table. flow's entry in the meter's flow table.
Counters are incremented for each packet, and are never reset. An Counters are incremented for each packet, and are never reset. An
analysis application can compute differences between readings of the analysis application can compute differences between readings of the
counters, so as to determine rates for these attributes. For example, counters, so as to determine rates for these attributes. For
if we read flow data at five-minute intervals, we can calculate example, if we read flow data at five-minute intervals, we can
five-minute packet and byte rates for the flow's two directions. calculate five-minute packet and byte rates for the flow's two
directions.
Times are derived from the FirstTime for a flow, which is set when its Times are derived from the FirstTime for a flow, which is set when
first packet is observed. LastTime is updated as each packet in the its first packet is observed. LastTime is updated as each packet in
flow is observed. the flow is observed.
All the above types have the common feature that they are expressed as All the above types have the common feature that they are expressed
single values. At least some of the new attributes will require as single values. At least some of the new attributes will require
multiple values. If, for example, we are interested in inter-packet multiple values. If, for example, we are interested in inter-packet
time intervals, we can compute an interval for every packet after the time intervals, we can compute an interval for every packet after the
first. If we are interested in packet sizes, a new value is obtained as first. If we are interested in packet sizes, a new value is obtained
each packet arrives. When it comes to storing this data we have two as each packet arrives. When it comes to storing this data we have
options: two options:
- As a distribution, i.e. in an array of 'buckets.' This method is a - As a distribution, i.e. in an array of 'buckets'. This method
compact representation of the data, with the values being stored as is a compact representation of the data, with the values being
counters between a minimum and maximum, with defined steps in each stored as counters between a minimum and maximum, with defined
bucket. This fits the RTFM goal of compact data storage. steps in each bucket. This fits the RTFM goal of compact data
storage.
- As a sequence of single values. This saves all the information, - As a sequence of single values. This saves all the
but does not fit well with the RTFM goal of doing as much data information, but does not fit well with the RTFM goal of doing
reduction as possible within the meter. as much data reduction as possible within the meter.
Studies which would be limited by the use of distributions might well Studies which would be limited by the use of distributions might well
use packet traces instead. use packet traces instead.
A method for specifying the distribution parameters, and for encoding A method for specifying the distribution parameters, and for encoding
the distribution so that it can be easily read, is described in section the distribution so that it can be easily read, is described in
3.2. section 3.2.
2.3 Packet Traces 2.3 Packet Traces
The simplest way of collecting a trace in the meter would be to have a The simplest way of collecting a trace in the meter would be to have
new attribute called, say, "PacketTrace." This could be a table, with a a new attribute called, say, "PacketTrace". This could be a table,
column for each property of interest. For example, one could trace with a column for each property of interest. For example, one could
trace:
- Packet Arrival time (TimeTicks from sysUpTime, or microseconds from - Packet Arrival time (TimeTicks from sysUpTime, or microseconds
FirstTime for the flow). from FirstTime for the flow).
- Packet Direction (Forward or Backward) - Packet Direction (Forward or Backward)
- Packet Sequence number (for protocols with sequence numbers) - Packet Sequence number (for protocols with sequence numbers)
- Packet Flags (for TCP at least) - Packet Flags (for TCP at least)
Note: The following implementation proposal is for the user who is Note: The following implementation proposal is for the user who is
familiar with the writing of rule sets for the RTFM Meter. familiar with the writing of rule sets for the RTFM Meter.
To add a row to the table, we only need a rule which PushPkts To add a row to the table, we only need a rule which PushPkts the
the PacketTrace attribute. To use this, one would write a rule PacketTrace attribute. To use this, one would write a rule set
set which selected out a small number of flows of interest, which selected out a small number of flows of interest, with a
with a 'PushPkt PacketTrace' rule for each of them. A 'PushPkt PacketTrace' rule for each of them. A MaxTraceRows
MaxTraceRows default value of 2000 would be enough to allow a default value of 2000 would be enough to allow a Meter Reader to
Meter Reader to read one-second ping traces every 10 minutes or read one-second ping traces every 10 minutes or so. More
so. More realistically, a MaxTraceRows of 500 would be enough realistically, a MaxTraceRows of 500 would be enough for one-
for one-minute pings, read once each hour. minute pings, read once each hour.
Packet traces are already implemented by the RMON MIB [RMON-MIB, Packet traces are already implemented by the RMON MIB [RMON-MIB,
RMON2-MIB], in the Packet Capture Group. They are therefore a low RMON2-MIB], in the Packet Capture Group. They are therefore a low
priority for RTFM. priority for RTFM.
2.4 Aggregate Attributes 2.4 Aggregate Attributes
RTFM's "old-style" flow attributes count the bytes and packets for RTFM's "old-style" flow attributes count the bytes and packets for
packets which match the rule set for an individual flow. In addition to packets which match the rule set for an individual flow. In addition
these totals, for example, RTFM could calculate Packet Size statistics. to these totals, for example, RTFM could calculate Packet Size
This data can be stored as distributions, though it may sometimes be statistics. This data can be stored as distributions, though it may
sufficient to simply keep a maximum value. sometimes be sufficient to simply keep a maximum value.
As an example, consider Packet Size. RTFM's packet flows can be As an example, consider Packet Size. RTFM's packet flows can be
examined to determine the maximum packet size found in a flow. This examined to determine the maximum packet size found in a flow. This
will give the Network Operator an indication of the MTU being used in a will give the Network Operator an indication of the MTU being used in
flow. It will also give an indication of the sensitivity to loss of a a flow. It will also give an indication of the sensitivity to loss
flow, for losing large packets causes more data to be retransmitted. of a flow, for losing large packets causes more data to be
retransmitted.
Note that aggregate attributes are a simple extension of the 'old-style' Note that aggregate attributes are a simple extension of the 'old-
attributes; their values are never reset. For example, an array of style' attributes; their values are never reset. For example, an
counters could hold a 'packet size' distribution. The counters continue array of counters could hold a 'packet size' distribution. The
to increase, a meter reader will collect their values at regular counters continue to increase, a meter reader will collect their
intervals, and an analysis application will compute and display values at regular intervals, and an analysis application will compute
distributions of the packet size for each collection interval. and display distributions of the packet size for each collection
interval.
2.5 Group Attributes 2.5 Group Attributes
The notion of group attributes is to keep simple statistics for measures The notion of group attributes is to keep simple statistics for
that involve more than one packet. This section describes some group measures that involve more than one packet. This section describes
attributes which it is feasible to implement in a traffic meter, and some group attributes which it is feasible to implement in a traffic
which seem interesting and useful. meter, and which seem interesting and useful.
Short-term bit rate - The data could also be recorded as the maximum and
minimum data rate of the flow, found over specific time periods during
the lifetime of a flow; this is a special kind of 'distribution.' Bit
rate could be used to define the throughput of a flow, and if the RTFM
flow is defined to be the sum of all traffic in a network, one can find
the throughput of the network.
If we are interested in '10-second' forward data rates, the meter might
compute this for each flow of interest as follows:
- maintain an array of counters to hold the flow's 10-second data Short-term bit rate - The data could also be recorded as the maximum
rate distribution. and minimum data rate of the flow, found over specific time periods
during the lifetime of a flow; this is a special kind of
'distribution'. Bit rate could be used to define the throughput of a
flow, and if the RTFM flow is defined to be the sum of all traffic in
a network, one can find the throughput of the network.
- every 10 seconds, compute and save 10-second octet count, and save If we are interested in '10-second' forward data rates, the meter
a copy of the flow's forward octet counter. might compute this for each flow of interest as follows:
To achieve this, the meter will have to keep a list of aggregate flows - maintain an array of counters to hold the flow's 10-second data
and the intervals at which they require processing. Careful programming rate distribution.
is needed to achieve this, but provided the meter is not asked to do it
for very large numbers of flows, it has been successfully implemented.
Inter-arrival times. The Meter knows the time that it encounters each - every 10 seconds, compute and save 10-second octet count, and
individual packet. Statistics can be kept to record the inter-arrival save a copy of the flow's forward octet counter.
times of the packets, which would give an indication of the jitter found
in the Flow.
Turn-around statistics. Sine the Meter knows the time that it To achieve this, the meter will have to keep a list of aggregate
encounters each individual packet, it can produce statistics of the time flows and the intervals at which they require processing. Careful
intervals between packets in opposite directions are observed on the programming is needed to achieve this, but provided the meter is not
asked to do it for very large numbers of flows, it has been
successfully implemented.
network. For protocols such as SNMP (where every packet elicits an Inter-arrival times. The Meter knows the time that it encounters
answering packet) this gives a good indication of turn-around times. each individual packet. Statistics can be kept to record the inter-
arrival times of the packets, which would give an indication of the
jitter found in the Flow.
Subflow analysis. Since the choice of flow endpoints is controlled by Turn-around statistics. Sine the Meter knows the time that it
the meter's rule set, it is easy to define an aggregate flow, e.g "all encounters each individual packet, it can produce statistics of the
the TCP streams between hosts A and B." Preliminary implementation work time intervals between packets in opposite directions are observed on
suggests that - at least for this case - it should be possible for the the network. For protocols such as SNMP (where every packet elicits
meter to maintain a table of information about all the active streams. an answering packet) this gives a good indication of turn-around
This could be used to produce at least the following attributes: times.
- Number of streams, e.g. streams active for n-second intervals. Subflow analysis. Since the choice of flow endpoints is controlled
Determined for TCP and UDP using source-dest port number pairs. by the meter's rule set, it is easy to define an aggregate flow, e.g.
"all the TCP streams between hosts A and B." Preliminary
implementation work suggests that - at least for this case - it
should be possible for the meter to maintain a table of information
about all the active streams. This could be used to produce at least
the following attributes:
- Number of TCP bytes, determined by taking difference of TCP - Number of streams, e.g. streams active for n-second intervals.
sequence numbers for each direction of the aggreagate flow. Determined for TCP and UDP using source-dest port number pairs.
IIS attributes. Work at CEFRIEL [IIS-ACCT] has produced a traffic meter - Number of TCP bytes, determined by taking difference of TCP
with a rule set modified 'on the fly' so as to maintain a list of sequence numbers for each direction of the aggreagate flow.
RSVP-reserved flows. For such flows the following attributes have been
implemented (these quantities are defined in [GUAR-QOS]):
- QoSService: Service class for the flow IIS attributes. Work at CEFRIEL [IIS-ACCT] has produced a traffic
(guaranteed, controlled load) meter with a rule set modified 'on the fly' so as to maintain a list
- QoSStyle: Reservation setup style of RSVP-reserved flows. For such flows the following attributes have
(wildcard filter, fixed filter, been implemented (these quantities are defined in [GUAR-QOS]):
shared explicit)
- QoSRate: [byte/s] rate for flows with
guaranteed service
- QoSSlackTerm: [microseconds] Slack Term QoS parameter
for flows with guaranteed service
- QoSTokenBucketRate: [byte/s] Token Bucket Rate QoS parameter
for flows with guaranteed or
controlled load service
The following are also being considered: - QoSService: Service class for the flow
(guaranteed, controlled load)
- QoSStyle: Reservation setup style
(wildcard filter, fixed filter,
shared explicit)
- QoSRate: [byte/s] rate for flows with
guaranteed service
- QoSSlackTerm: [microseconds] Slack Term QoS parameter
for flows with guaranteed service
- QoSTokenBucketRate: [byte/s] Token Bucket Rate QoS parameter
for flows with guaranteed or
controlled load service
- QoSTokenBucketSize: [byte] Size of Token Bucket The following are also being considered:
- QoSPeakDataRate: [byte/s] Maximum rate for incoming data - QoSTokenBucketSize: [byte] Size of Token Bucket
- QoSMinPolicedUnit: [byte] IP datagrams less than this are - QoSPeakDataRate: [byte/s] Maximum rate for incoming data
counted as being this size
- QoSMaxDatagramSize: [byte] Size of biggest datagram which
conforms to the traffic specification
- QoSMinPolicedUnit: [byte] IP datagrams less than this are
counted as being this size
- QoSMaxDatagramSize: [byte] Size of biggest datagram which
conforms to the traffic specification
2.6 Actions on Exceptions 2.6 Actions on Exceptions
Some users of RTFM have requested the ability to mark flows as having Some users of RTFM have requested the ability to mark flows as having
High Watermarks. The existence of abnormal service conditions, such as High Watermarks. The existence of abnormal service conditions, such
non-ending flow, a flow that exceeds a given limit in traffic (e.g. a as non-ending flow, a flow that exceeds a given limit in traffic
flow that is exhausting the capacity of the line that carries it) would (e.g. a flow that is exhausting the capacity of the line that carries
cause an ALERT to be sent to the Meter Reader for forwarding to the it) would cause an ALERT to be sent to the Meter Reader for
Manager. Operations Support could define service situations in many forwarding to the Manager. Operations Support could define service
different environments. This is an area for further discussion on Alert situations in many different environments. This is an area for
and Trap handling. further discussion on Alert and Trap handling.
3 Extensions to the 'Basic' RTFM Meter 3 Extensions to the 'Basic' RTFM Meter
The Working Group has agreed that the basic RTFM Meter will not be The Working Group has agreed that the basic RTFM Meter will not be
altered by the addition of the new attributes of this document. This altered by the addition of the new attributes of this document. This
section describes the extensions needed to implement the new attributes. section describes the extensions needed to implement the new
attributes.
3.1 Flow table extensions 3.1 Flow table extensions
The architecture of RTFM has defined the structure of flows, and this The architecture of RTFM has defined the structure of flows, and this
draft does not change that structure. The flow table could have memo does not change that structure. The flow table could have
ancillary tables called "Distribution Tables" and "Trace Tables," these ancillary tables called "Distribution Tables" and "Trace Tables,"
would contain rows of values and or actions as defined above. Each these would contain rows of values and or actions as defined above.
entry in these tables would be marked with the number of its Each entry in these tables would be marked with the number of its
corresponding flow in the RTFM flow table. corresponding flow in the RTFM flow table.
Note: The following section is for the user who is familiar with the Note: The following section is for the user who is familiar with the
writing of rule sets for the RTFM Meter. writing of rule sets for the RTFM Meter.
In order to identify the data in a Packet Flow Table, the In order to identify the data in a Packet Flow Table, the
attribute name could be pushed into a string at the head of attribute name could be pushed into a string at the head of each
each row. For example, if a table entry has "To Bit Rate" for row. For example, if a table entry has "To Bit Rate" for a
a particular flow, the "ToBitRate" string would be found at the particular flow, the "ToBitRate" string would be found at the head
head of the row. (An alternative method would be to code an of the row. (An alternative method would be to code an
identification value for each extended attribute and push that identification value for each extended attribute and push that
value into the head of the row.) See section 4. for an inital value into the head of the row.) See section 4. for an inital
set of ten extended flow attributes. set of ten extended flow attributes.
3.2 Specifying Distributions in RuleSets 3.2 Specifying Distributions in RuleSets
At first sight it would seem neccessary to add extra features to the At first sight it would seem neccessary to add extra features to the
RTFM Meter architecture to support distributions. This, however, is not RTFM Meter architecture to support distributions. This, however, is
neccessarily the case. not neccessarily the case.
What is actually needed is a way to specify, in a ruleset, the What is actually needed is a way to specify, in a ruleset, the
distribution parameters. These include the number of counters, the distribution parameters. These include the number of counters, the
lower and upper bounds of the distribution, whether it is linear or lower and upper bounds of the distribution, whether it is linear or
logarithmic, and any other details (e.g. the time interval for logarithmic, and any other details (e.g. the time interval for
short-term rate attributes). short-term rate attributes).
Any attribute which is distribution-valued needs to be allocated a Any attribute which is distribution-valued needs to be allocated a
RuleAttributeNumber value. These will be chosen so as to extend the RuleAttributeNumber value. These will be chosen so as to extend the
list already in the RTFM Meter MIB document [RTFM-MIB]. list already in the RTFM Meter MIB document [RTFM-MIB].
Since distribution attributes are multi-valued it does not make sense to Since distribution attributes are multi-valued it does not make sense
test them. This means that a PushPkt (or PushPkttoAct) action must be to test them. This means that a PushPkt (or PushPkttoAct) action
executed to add a new value to the distribution. The old-style must be executed to add a new value to the distribution. The old-
attributes use the 'mask' field to specify which bits of the value are style attributes use the 'mask' field to specify which bits of the
required, but again, this is not the case for distributions. Lastly, value are required, but again, this is not the case for
the MatchedValue ('value') field of a PushPkt rule is never used. distributions. Lastly, the MatchedValue ('value') field of a PushPkt
Overall, therefore, the 'mask' and 'value' fields in the PushPkt rule rule is never used. Overall, therefore, the 'mask' and 'value'
are available to specify distribution parameters. fields in the PushPkt rule are available to specify distribution
parameters.
Both these fields are at least six bytes long, the size of a MAC Both these fields are at least six bytes long, the size of a MAC
address. All we have to do is specify how these bytes should be used! address. All we have to do is specify how these bytes should be
As a starting point, the following is proposed (bytes are numbered used! As a starting point, the following is proposed (bytes are
left-to-right. numbered left-to-right.
Mask bytes: Mask bytes:
1 Transform 1 = linear, 2 = logarithmic 1 Transform 1 = linear, 2 = logarithmic
2 Scale Factor Power of 10 multiplier for Limits 2 Scale Factor Power of 10 multiplier for Limits
and Counts and Counts
3-4 Lower Limit Highest value for first bucket 3-4 Lower Limit Highest value for first bucket
5-6 Upper Limit Highest value for last bucket 5-6 Upper Limit Highest value for last bucket
Value bytes: Value bytes:
1 Buckets Number of buckets. Does not include 1 Buckets Number of buckets. Does not include
the 'overflow' bucket the 'overflow' bucket
2 Parameter-1 } Parameter use depends 2 Parameter-1 } Parameter use depends
3-4 Parameter-2 } on distribution-valued 3-4 Parameter-2 } on distribution-valued
5-6 Parameter-3 } attribute 5-6 Parameter-3 } attribute
For example, experiments with NeTraMet have used the following For example, experiments with NeTraMet have used the following rules:
rules:
FromPacketSize & 1.0.25!1500 = 60.0!0: PushPkttoAct, Next; FromPacketSize & 1.0.25!1500 = 60.0!0: PushPkttoAct, Next;
ToInterArrivalTime & 2.3.1!1800 = 60.0.0!0: PushPkttoAct, Next; ToInterArrivalTime & 2.3.1!1800 = 60.0.0!0: PushPkttoAct, Next;
FromBitRate & 2.3.1!10000 = 60.5.0!0: PushPkttoAct, Next; FromBitRate & 2.3.1!10000 = 60.5.0!0: PushPkttoAct, Next;
In these mask and value fields a dot indicates that the preceding number In these mask and value fields a dot indicates that the preceding
is a one-byte integer, the exclamation marks indicate that the preceding number is a one-byte integer, the exclamation marks indicate that the
number is a two-byte integer, and the last number is two bytes wide preceding number is a two-byte integer, and the last number is two
since this was the width of the preceding field. (Note that this bytes wide since this was the width of the preceding field. (Note
convention follows that for IP addresses - 130.216 means 130.216.0.0). that this convention follows that for IP addresses - 130.216 means
130.216.0.0).
The first rule specifies that a distribution of packet sizes is to be The first rule specifies that a distribution of packet sizes is to be
built. It uses an array of 60 buckets, storing values from 1 to 1500 built. It uses an array of 60 buckets, storing values from 1 to 1500
bytes (i.e. linear steps of 25 bytes each bucket). Any packets with bytes (i.e. linear steps of 25 bytes each bucket). Any packets with
size greater than 1500 will be counted in the 'overflow' bucket, hence size greater than 1500 will be counted in the 'overflow' bucket,
there are 61 counters for the distribution. hence there are 61 counters for the distribution.
The second rule specifies an interarrival-time distribution, using a The second rule specifies an interarrival-time distribution, using a
logarithmic scale for an array of 60 counters (and an overflow bucket) logarithmic scale for an array of 60 counters (and an overflow
for rates from 1 ms to 1.8 s. Arrival times are measured in bucket) for rates from 1 ms to 1.8 s. Arrival times are measured in
microseconds, hence the scale factor of 3 indicates that the limits are microseconds, hence the scale factor of 3 indicates that the limits
given in milliseconds. are given in milliseconds.
The third rule specifies a bit-rate distribution, with the rate being The third rule specifies a bit-rate distribution, with the rate being
calculated every 5 seconds (parameter 1). A logarithmic array of 60 calculated every 5 seconds (parameter 1). A logarithmic array of 60
counters (and an overflow bucket) are used for rates from 1 kbps to 10 counters (and an overflow bucket) are used for rates from 1 kbps to
Mbps. The scale factor of 3 indicates that the limits are given in 10 Mbps. The scale factor of 3 indicates that the limits are given
thousands of bits per second (rates are measured in bps). in thousands of bits per second (rates are measured in bps).
These distribution parameters will need to be stored in the meter so These distribution parameters will need to be stored in the meter so
that they are available for building the distribution. They will also that they are available for building the distribution. They will
need to be read from the meter and saved together with the other flow also need to be read from the meter and saved together with the other
data. flow data.
3.3 Reading Distributions 3.3 Reading Distributions
Since RTFM flows are bi-directional, each distribution-valued quantity Since RTFM flows are bi-directional, each distribution-valued
(e.g. packet size, bit rate, etc.) will actually need two sets of quantity (e.g. packet size, bit rate, etc.) will actually need two
counters, one for packets travelling in each direction. It is tempting sets of counters, one for packets travelling in each direction. It
to regard these as components of a single 'distribution,' but in many is tempting to regard these as components of a single 'distribution',
cases only one of the two directions will be of interest; it seems but in many cases only one of the two directions will be of interest;
better to keep them in separate distributions. This is similar to the it seems better to keep them in separate distributions. This is
old-style counter-valued attributes such as toOctets and fromOctets. similar to the old-style counter-valued attributes such as toOctets
and fromOctets.
A distribution should be read by a meter reader as a single, structured A distribution should be read by a meter reader as a single,
object. The components of a distribution object are structured object. The components of a distribution object are:
- 'mask' and 'value' fields from the rule which created the - 'mask' and 'value' fields from the rule which created the
distribution distribution
- sequence of counters ('buckets' + overflow) - sequence of counters ('buckets' + overflow)
These can be easily collected into a BER-encoded octet string, and would These can be easily collected into a BER-encoded octet string, and
be read and referred to as a 'distribution.' would be read and referred to as a 'distribution'.
4 Extensions to the Rules Table, Attribute Numbers 4 Extensions to the Rules Table, Attribute Numbers
The Rules Table of "old-style" attributes will be extended for the new The Rules Table of "old-style" attributes will be extended for the
flow types. A list of actions, and keywords, such as "ToBitRate", new flow types. A list of actions, and keywords, such as
"ToPacketSize", etc. will be developed and used to inform an RTFM meter "ToBitRate", "ToPacketSize", etc. will be developed and used to
to collect a set of extended values for a particular flow (or set of inform an RTFM meter to collect a set of extended values for a
flows). particular flow (or set of flows).
Note. An implementation suggestion. Note: An implementation suggestion.
Value 65 is used for 'Distributions,' which has one bit set for Value 65 is used for 'Distributions', which has one bit set for
each distribution-valued attribute present for the flow, using each distribution-valued attribute present for the flow, using bit
bit 0 for attribute 66, bit 1 for attribute 67, etc. 0 for attribute 66, bit 1 for attribute 67, etc.
Here are ten possible distribution-valued attributes numbered according Here are ten possible distribution-valued attributes numbered
to RTFM WG consensus at the 1997 meeting in Munich: according to RTFM WG consensus at the 1997 meeting in Munich:
ToPacketSize(66) size of PDUs in bytes (i.e. number ToPacketSize(66) size of PDUs in bytes (i.e. number
FromPacketSize(67) of bytes actually transmitted) FromPacketSize(67) of bytes actually transmitted)
ToInterarrivalTime(68) microseconds between successive packets
FromInterarrivalTime(69) travelling in the same direction
ToInterarrivalTime(68) microseconds between successive packets ToTurnaroundTime(70) microseconds between successive packets
FromInterarrivalTime(69) travelling in the same direction FromTurnaroundTime(71) travelling in opposite directions
ToTurnaroundTime(70) microseconds between successive packets ToBitRate(72) short-term flow rate in bits per second
FromTurnaroundTime(71) travelling in opposite directions FromBitRate(73) Parameter 1 = rate interval in seconds
ToBitRate(72) short-term flow rate in bits per second ToPDURate(74) short-term flow rate in PDUs per second
FromBitRate(73) Parameter 1 = rate interval in seconds FromPDURate(75) Parameter 1 = rate interval in seconds
ToPDURate(74) short-term flow rate in PDUs per second (76 .. 97) other distributions
FromPDURate(75) Parameter 1 = rate interval in seconds
(76 .. 97) other distributions It seems reasonable to allocate a further group of numbers for the
IIS attributes described above:
It seems reasonable to allocate a further group of numbers QoSService(98)
for the IIS attributes described above - QoSStyle(99)
QoSRate(100)
QoSSlackTerm(101)
QoSTokenBucketRate(102)
QoSTokenBucketSize(103)
QoSPeakDataRate(104)
QoSMinPolicedUnit(105)
QoSMaxPolicedUnit(106)
QoSService(98) The following attributes have also been implemented in NetFlowMet, a
QoSStyle(99) version of the RTFM traffic meter:
QoSRate(100)
QoSSlackTerm(101)
QoSTokenBucketRate(102)
QoSTokenBucketSize(103)
QoSPeakDataRate(104)
QoSMinPolicedUnit(105)
QoSMaxPolicedUnit(106)
The following attributes have also been implemented in NetFlowMet, a MeterID(112) Integer identifying the router producing
version of the RTFM traffic meter - NetFlow data (needed when NetFlowMet takes
MeterID(112) Integer identifying the router producing data from several routers)
NetFlow data (needed when NetFlowMet takes SourceASN(113) Autonomous System Number for flow's source
data from several routers) SourcePrefix(114) CIDR width used by router for determining
SourceASN(113) Autonomous System Number for flow's source flow's source network
SourcePrefix(114) CIDR width used by router for determining DestASN(115) Autonomous System Number for flow's destination
flow's source network DestPrefix(116) CIDR width used by router for determining
DestASN(115) Autonomous System Number for flow's destination flow's destination network
DestPrefix(116) CIDR width used by router for determining
flow's destination network
Some of the above, e.g. SourceASN and DestASN, might sensibly be Some of the above, e.g. SourceASN and DestASN, might sensibly be
allocated attribute numbers below 64, making them part of the 'base' allocated attribute numbers below 64, making them part of the 'base'
RTFM meter attributes. RTFM meter attributes.
To support use of the RTFM meter as an 'Edge Device' for implementing To support use of the RTFM meter as an 'Edge Device' for implementing
Differentiated Services, and/or for metering traffic carried via such Differentiated Services, and/or for metering traffic carried via such
services, one more attribute will be useful: services, one more attribute will be useful:
DSCodePoint(118) DS Code Point (6 bits) for packets in this flow DSCodePoint(118) DS Code Point (6 bits) for packets in this flow
Since the DS Code Point is a single field within a packet's IP header, Since the DS Code Point is a single field within a packet's IP
it is not possible to have both Source- and Dest- CodePoint attributes. header, it is not possible to have both Source- and Dest-CodePoint
Possible uses of DSCodePoint include aggregating flows using the same attributes. Possible uses of DSCodePoint include aggregating flows
Code Points, and separating flows having the same end-point addresses using the same Code Points, and separating flows having the same
but using different Code Points. end-point addresses but using different Code Points.
5 Security Considerations 5 Security Considerations
The attributes considered in this document represent properties of The attributes considered in this document represent properties of
traffic flows; they do not present any security issues in themselves. traffic flows; they do not present any security issues in themselves.
The attributes may, however, be used in measuring the behaviour of The attributes may, however, be used in measuring the behaviour of
traffic flows, and the collected traffic flow data could be of traffic flows, and the collected traffic flow data could be of
considerable value. Suitable precautions should be taken to keep such considerable value. Suitable precautions should be taken to keep
data safe. such data safe.
6 References 6 References
[C-B-P] Claffy, K., Braun, H-W, Polyzos, G., "A Parameterizable [C-B-P] Claffy, K., Braun, H-W, Polyzos, G., "A Parameterizable
Methodology for Internet Traffic Flow Profiling," Methodology for Internet Traffic Flow Profiling," IEEE
IEEE Journal on Selected Areas in Communications, Journal on Selected Areas in Communications, Vol. 13, No.
Vol. 13, No. 8, October 1995. 8, October 1995.
[GUAR-QOS] Shenker, S., Partridge, C., Guerin, R.: "Specification of [GUAR-QOS] Shenker, S., Partridge, C. and R. Guerin, "Specification
Guaranteed Quality of Service," RFC 2212, 1997. of Guaranteed Quality of Service", RFC 2212, September
1997.
[IIS-ACCT] Maiocchi, S: "NeTraMet & NeMaC for IIS Accounting: [IIS-ACCT] Maiocchi, S: "NeTraMet & NeMaC for IIS Accounting:
Users' Guide", CEFRIEL, Milan, 5 May 1998. Users' Guide", CEFRIEL, Milan, 5 May 1998. (See also
(See also http://www.cefriel.it/ntw) http://www.cefriel.it/ntw)
[IIS-RSVP] Wroclawski, J., "The Use of RSVP with IETF Integrated [IIS-RSVP] Wroclawski, J., "The Use of RSVP with IETF Integrated
Services," RFC 2210, September 1997. Services", RFC 2210, September 1997.
[IPPM-FRM] Paxson, V., Almes, G., Mahdavi, J. and Mathis, M., [IPPM-FRM] Paxson, V., Almes, G., Mahdavi, J. and Mathis, M.,
"Framework for IP Performance Metrics," RFC 2330, May 1998. "Framework for IP Performance Metrics", RFC 2330, May
1998.
[RMON-MIB] Waldbusser, S., "Remote Network Monitoring Management [RMON-MIB] Waldbusser, S., "Remote Network Monitoring Management
Information Base," RFC 1757, February 1995. Information Base", RFC 1757, February 1995.
[RMON2-MIB] Waldbusser, S., "Remote Network Monitoring Management [RMON2-MIB] Waldbusser, S., "Remote Network Monitoring Management
Information Base Version 2 using SMIv2," Information Base Version 2 using SMIv2", RFC 2021,
RFC 2021, January 1997. January 1997.
[RTFM-ARC] Brownlee, N., Mills, C. and G. Ruth, "Traffic Flow [RTFM-ARC] Brownlee, N., Mills, C. and G. Ruth, "Traffic Flow
Measurement: Architecture", RFC 2063, January 1997. Measurement: Architecture", RFC 2722, October 1999.
[RTFM-MIB] Brownlee, N., "Traffic Flow Measurement: Meter MIB", [RTFM-MIB] Brownlee, N., "Traffic Flow Measurement: Meter MIB", RFC
RFC 2064, January 1997. 2720, October 1999.
7 Author's Addresses 7 Authors' Addresses
Sig Handelman Sig Handelman
IBM Research Division IBM Research Division
T.J. Watson Research Center T.J. Watson Research Center
P.O. Box 704 P.O. Box 704
Yorktown Heights, NY 10598 Yorktown Heights, NY 10598
Phone: +1 914 784 7626 Phone: +1 914 784 7626
E-mail: swhandel@us.ibm.com EMail: swhandel@us.ibm.com
Nevil Brownlee Stephen Stibler
Information Technology Systems & Services IBM Research Division
The University of Auckland T.J. Watson Research Center
Private Bag 92-019 P.O. Box 704
Auckland, New Zealand Yorktown Heights, NY 10598
Phone: +64 9 373 7599 x8941 Phone: +1 914 784 7191
E-mail: n.brownlee@auckland.ac.nz EMail: stibler@us.ibm.com
Greg Ruth
GTE Internteworking
3 Van de Graaff Drive
P.O. Box 3073
Burlington, MA 01803, U.S.A.
Phone: +1 781 262 4831 Nevil Brownlee
E-mail: grr1@gte.com Information Technology Systems & Services
The University of Auckland
Private Bag 92-019
Auckland, New Zealand
Stephen Stibler Phone: +64 9 373 7599 x8941
IBM Research Division EMail: n.brownlee@auckland.ac.nz
T.J. Watson Research Center
P.O. Box 704
Yorktown Heights, NY 10598
Phone: +1 914 784 7191 Greg Ruth
E-mail: stibler@us.ibm.com GTE Internteworking
3 Van de Graaff Drive
P.O. Box 3073
Burlington, MA 01803, U.S.A.
Expires March 2000 Phone: +1 781 262 4831
EMail: gruth@bbn.com
8. Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 154 change blocks. 
559 lines changed or deleted 548 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/