draft-ietf-rtfm-new-traffic-flow-03.txt   draft-ietf-rtfm-new-traffic-flow-04.txt 
skipping to change at page 1, line 18 skipping to change at page 1, line 18
U of Auckland, NZ U of Auckland, NZ
Greg Ruth Greg Ruth
GTE Laboratories, Inc GTE Laboratories, Inc
Waltham, MA USA Waltham, MA USA
S. Stibler S. Stibler
IBM IBM
Hawthorne, NY USA Hawthorne, NY USA
March 13, 1998 August 7, 1998
expires expires
September 13, 1998 February 7, 1999
RTFM Working Group - New Attributes for Traffic Flow Measurement RTFM Working Group - New Attributes for Traffic Flow Measurement
<draft-ietf-rtfm-new-traffic-flow-03.txt> <draft-ietf-rtfm-new-traffic-flow-04.txt>
1. Status of this Memo 1. Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
skipping to change at page 2, line 13 skipping to change at page 2, line 13
Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
2. Introduction 2. Introduction
The Real-Time Flow Measurement (RTFM) Working Group (WG) has The Real-Time Flow Measurement (RTFM) Working Group (WG) has
developed a system for measuring and reporting information about developed a system for measuring and reporting information about
traffic flows in the Internet. This document explores the definition traffic flows in the Internet. This document explores the definition
of extensions to the flow measurements as currently defined in [1]. of extensions to the flow measurements as currently defined in [1].
The new attributes described in this document will be useful for The new attributes described in this document will be useful for
monitoring network performance and will expand the scope of RTFM monitoring network performance and will expand the scope of RTFM
beyond simple measurement of traffic volumes. Performance attributes beyond simple measurement of traffic volumes. A companion document
typically deal with throughput, packet loss, and delays. The WG will to this draft will be written to define MIB structures for the new
explore the methods by which RTFM can extract values from packets and attributes.
flows so as to measure these attributes. The WG will also look at
capturing information on jitter and congestion control. A companion
document to this draft will be written to define the MIB structures
of the new attributes.
This draft was started in 1996 to advance the work of the RTFM group. This draft 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, The goal of this work is to produce a simple set of abstractions,
which can be easily implemented and at the same time enhance the which can be easily implemented and at the same time enhance the
value of RTFM Meters. This document also defines a method for value of RTFM Meters. This document also defines a method for
organizing the flow abstractions to augment the existing RTFM flow organizing the flow abstractions to augment the existing RTFM flow
table. table.
Implementations of the RTFM Meter meter have been done by Nevil Implementations of the RTFM Meter have been done by Nevil Brownlee in
Brownlee in the University of Auckland, NZ, and Stephen Stibler and the University of Auckland, NZ, and Stephen Stibler and Sig Handelman
Sig Handelman at IBM in Hawthorne, NY, USA. The RTFM WG has also at IBM in Hawthorne, NY, USA. The RTFM WG has also defined the role
defined the role of the Meter Reader whose role is to retrieve flow of the Meter Reader whose role is to retrieve flow data from the
data from the Meter. Meter.
Note on flows and positioning of meters.
A flow as it traverses the Internet may have some of its
characteristics altered as it travels through Routers, Switches, and
other network units. It is important to note the spatial location of
the Meter when referring to attributes of a flow. An example, a
server may send a sequence of packets with a definite order, and
inter packet timing with a leaky bucket algorithm. A meter reading
downstream of the leaky bucket would record a set with minimal inter
packet timing due to the leaky bucket. At the client's location, the
packets may arrive out of sequence, with the timings altered. A meter
at the client's location would record different attributes for the
same flow.
2.1 RTFM's Definition of Flows 2.1 RTFM's Definition of Flows
The RTFM Meter architecture views a flow as a set of packets between The RTFM Meter architecture views a flow as a set of packets between
two endpoints (as defined by their source and destination attribute two endpoints (as defined by their source and destination attribute
values and start and end times), and as BI-DIRECTIONAL (i.e. the values and start and end times), and as BI-DIRECTIONAL (i.e. the
meter 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) are
the same for both directions; storing them in bi-directional flows the same for both directions; storing them in bi-directional flows
reduces the meter's memory demands. reduces the meter's memory demands.
- 'One-way' (uni-directional) flows are a degenerate case. Existing
RTFM meters can handle this by using one of the computed attributes
e.g. FlowKind) to indicate direction.
2.2 RTFM's Current Definition of Flows and their Attributes 2.2 RTFM's Current Definition of Flows and their Attributes
Flows, as described in the "Architecture" document [1] have the Flows, as described in the "Architecture" document [1] have the
following properties: 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
skipping to change at page 3, line 46 skipping to change at page 4, line 8
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 counters. They are NEVER reset. In this document they will be
referred 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 available sequence number fields for packets in each direction; only available
for protocols which have sequence numbers). 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 Label
from the IPv6 header. from the IPv6 header.
2.3 RTFM Flows, Integrated Services, IPPM and Research in Flows 2.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 For the purpose of extending RTFM, a starting point is the work of
the Integrated Services WG. We will measure quantities that are often the Integrated Services WG. We will measure quantities that are often
set by Integrated Services configuration programs. We will look at set by Integrated Services configuration programs. We will look at
skipping to change at page 4, line 25 skipping to change at page 4, line 33
An example of the use of capacity and performance information is An example of the use of capacity and performance information is
found in "The Use of RSVP with IETF Integrated Services" [2]. RSVP's found in "The Use of RSVP with IETF Integrated Services" [2]. RSVP's
use of Integrated Services revolves around Token Bucket Rate, Token use of Integrated Services revolves around Token Bucket Rate, Token
Bucket Size, Peak Data Rate, Minimum Policed Unit, Maximum Packet Bucket Size, Peak Data Rate, Minimum Policed Unit, Maximum Packet
Size, and the Slack term. These are set by TSpec, ADspec and FLowspec Size, and the Slack term. These are set by TSpec, ADspec and FLowspec
(Integrated Services Keywords), and are used in configuration and (Integrated Services Keywords), and are used in configuration and
operation of Integrated Services. RTFM could monitor explicitly Peak operation of Integrated Services. RTFM could monitor explicitly Peak
Data Rate, Minimum Policed Unit, Maximum Packet Size, and the Slack Data Rate, Minimum Policed Unit, Maximum Packet Size, and the Slack
term. RTFM could infer details of the Token Bucket. The WG will term. RTFM could infer details of the Token Bucket. The WG will
develop measures to work with these service metrics. develop measures to work with these service metrics. An initial
implementation of IIS Monitoring has been developd at CEFRIEL in
Italy [8].
RTFM will work with several traffic measurements identified by IPPM RTFM will work with several traffic measurements identified by IPPM
[3]. There are three broad areas in which RTFM is useful for IPPM. [3]. There are three broad areas in which RTFM is useful for IPPM.
An RTFM Meter could act as a passive device, gathering traffic and An RTFM Meter could act as a passive device, gathering traffic and
performance statistics at appropriate places in networks (server or performance statistics at appropriate places in networks (server or
client locations). RTFM could give detailed analyses of IPPM test client locations). RTFM could give detailed analyses of IPPM test
flows that pass through the Network segment that RTFM is monitoring. flows that pass through the Network segment that RTFM is monitoring.
RTFM could be used to identify the most-used paths in a network mesh, 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 used paths. so that detailed IPPM work could be applied to these most used paths.
3.0 Flow Abstractions 3.0 Flow Abstractions
Performance attributes include throughput, packet loss, delays, Performance attributes include throughput, packet loss, delays,
jitter, and congestion measures. RTFM will calculate these attributes jitter, and congestion measures. RTFM will calculate these attributes
in the form of extensions to the RTFM flow attributes according to in the form of extensions to the RTFM flow attributes according to
three general classes: three general classes:
o 'packet traces' - collections of attributes of individual packets o 'trace' - attributes of individual packets in a flow or a segment
in a flow or a segment of a flow. of a flow (e.g. last packet size, last packet arrival time).
o 'aggregates' - statistics derived from the flow taken as a whole o 'aggregates' - statistics derived from the flow taken as a whole
(e.g. mean rate, max packet size). (e.g. mean rate, max packet size, packet size distribution).
o 'series'- attributes that depend on more than one packet (e.g. o 'group'- attributes that depend on groups of packet values within
inter-arrival times, short-term traffic rates). the flow (e.g. inter-arrival times, short-term traffic rates).
Note that attributes within each of these classes may have various
types of values - numbers, distributions, time series, and so on.
3.1. Meter Readers and Meters 3.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.
As an introduction to flow abstractions one fact must be emphasized.
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 the meter with instantaneous response Meter Reader that is tied to the meter with very short response time
time and very high bandwidth. If the Meter Reader and Meter can be and very high bandwidth. If the Meter Reader and Meter can be
arranged in such a way, RTFM could collect Packet Traces with time arranged in such a way, RTFM could collect Packet Traces with time
stamps and provide them 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 statistics locally. This allows a looser coupling between the Meter
and Meter Reader. RTFM will monitor an 'extended attribute' depending and Meter Reader. RTFM will monitor an 'extended attribute' depending
upon settings in its Rule table. RTFM will not create any "extended upon settings in its Rule table. RTFM will not create any "extended
attribute" data without explicit instructions in the Rule table. attribute" data without explicit instructions in the Rule table.
3.2. Attribute Types 3.2. Attribute Types
Section 3.0 described three different classes of attributes; this Section 3.0 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 Packet Traces (as described below) are a special case in that they
are tables with each row containing a sequence of values, each of are tables with each row containing a sequence of values, each of
varying type. They are essentially 'compound objects' i.e. lists of varying type. They are essentially 'compound objects' i.e. lists of
attribute values for a string of packets. attribute values for a string of packets.
Aggregate attributes are like the 'old-style' attributes. The 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. They
do not change with time, and they are used as a key to find the do not change with time, and they are used as a key to find the
flow's 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
skipping to change at page 6, line 46 skipping to change at page 7, line 13
with a column for each property of interest. For example, one could with a column for each property of interest. For example, one could
trace trace
- Packet Arrival time (TimeTicks from sysUpTime, or microseconds from - Packet Arrival time (TimeTicks from sysUpTime, or microseconds from
FirstTime for the flow). 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 example is for the user who is familiar with the Note: The following implementation proposal is for the user who is
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 the To add a row to the table, we only need a rule which PushPkts the
PacketTrace attribute. To use this, one would write a rule set which PacketTrace attribute. To use this, one would write a rule set which
selected out a small number of flows of interest, with a 'PushPkt selected out a small number of flows of interest, with a 'PushPkt
PacketTrace' rule for each of them. A MaxTraceRows default value of PacketTrace' rule for each of them. A MaxTraceRows default value of
2000 would be enough to allow a Meter Reader to read one-second ping 2000 would be enough to allow a Meter Reader to read one-second ping
traces every 10 minutes or so. More realistically, a MaxTraceRows of traces every 10 minutes or so. More realistically, a MaxTraceRows of
500 would be enough for one-minute pings, read once each hour. Note 500 would be enough for one-minute pings, read once each hour. Note
that packet traces are already implemented in the RMON MIB [6], in that packet traces are already implemented in the RMON MIB [6], in
the Packet Capture Group. They are therefore a low priority for RTFM. the Packet Capture Group. They are therefore a low priority for RTFM.
skipping to change at page 7, line 48 skipping to change at page 8, line 16
might compute this for each flow of interest as follows: might compute this for each flow of interest as follows:
- maintain an array of counters to hold the flow's 10-second data - maintain an array of counters to hold the flow's 10-second data
rate distribution. rate distribution.
- every 10 seconds, compute and save 10-second octet count, and save - every 10 seconds, compute and save 10-second octet count, and save
a copy of the flow's forward octet counter. a copy of the flow's forward octet counter.
To achieve this, the meter will have to keep a list of aggregate To achieve this, the meter will have to keep a list of aggregate
flows and the intervals at which they require processing. Careful flows and the intervals at which they require processing. Careful
programming will be needed to achieve this, but provided the meter is programming is needed to achieve this, but provided the meter is not
not asked to do it for very large numbers of flows, it should not be asked to do it for very large numbers of flows, it has been
too difficult! successfully implemented.
Note that aggregate attributes are a simple extension of the 'old- Note that aggregate attributes are a simple extension of the 'old-
style' attributes; their values are never reset. For example, an style' attributes; their values are never reset. For example, an
array of counters could hold a '10-second bit rate' distribution. array of counters could hold a '10-second bit rate' distribution.
The counters continue to increase, a meter reader will collect their The counters continue to increase, a meter reader will collect their
values at regular intervals, and an analysis application will compute values at regular intervals, and an analysis application will compute
and display distributions of the 10-second bit rate for each and display distributions of the 10-second bit rate for each
collection interval. collection interval.
3.5 Series Attributes 3.5 Group Attributes
The notion of series attributes is to keep simple statistics for The notion of group attributes is to keep simple statistics for
measures that involve more than one packet. The attribute values measures that involve more than one packet. This section describes
would be stored in the meter as a distribution (see above). some group attributes which it is feasible to implement in a traffic
meter, and which seem interesting and useful.
TCP and UDP Inter-arrival times. The Meter knows the time that it encounters 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.
Performance aspects of flows are of interest between servers and Turn-around statistics. Sine the Meter knows the time that it
clients. We can observe common measurement attributes with TCP/IP encounters each individual packet, it can produce statistics of the
and UDP flows. TCP flows yield additional information due to the time intervals between packets in opposite directions are observed on
sequence numbers found in TCP. These performance data describe the the network. For protocols such as SNMP (where every packet elicits
performance of a flow as recorded in the locale of the RTFM Meter. an answering packet) this gives a good indication of turn-around
times.
Inter-arrival statistics - TCP and UDP. The Meter knows the time that Subflow analysis. Since the choice of flow endpoints is controlled
it encounters each individual packet. Statistics can be kept to by the meter's rule set, it is easy to define an aggregate flow, e.g
record the inter-arrival times of the packets, which would give an "all the TCP streams between hosts A and B." Preliminary
indication of the jitter found in the Flow. 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 streams, e.g. streams active for n-second intervals.
Determined for TCP and UDP using source-dest port number pairs.
- Number of TCP bytes, determined by taking difference of TCP
sequence numbers for each direction of the aggreagate flow.
Turn-around statistics - TCP and UDP. The Meter knows the time that IIS attributes. Work at CEFRIEL [8] has produced a traffic meter
it encounters each individual packet. Statistics can be kept to with a rule set modified 'on the fly' so as to maintain a list of
record the times when packets in opposite directions are found on the RSVP-reserved flows. For such flows the following attributes have
net. This would give an indication of turn around times which have been implemented (these quantities are defined in [9]):
use for protocols with simple packet flow, e.g. SNMP.
TCP Only - Packet loss - RTFM can calculate packet loss performance - QoSService: Service class for the flow
metrics. This is an area for further study. TCP packets have byte (guaranteed, controlled load)
sequence numbers and SYNS, FINS, and ACK's associated with them. RTFM - QoSStyle: Reservation setup style
could track the sequence numbers in the flows, and calculate the (wildcard filter, fixed filter,
packet loss occurring in a flow, and thus we can develop a metric of shared explicit)
lost packets and useful traffic. - 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
Delay analysis - TCP flows could be examined for the timing between The following are also being considered:
Transmissions and ACKS and thus we can get some measure of delay (of
IPPM performance metrics). This assumes the forward and reverse
packets are both visible to the meter. In the case of asymmetric
flows, RTFM can be run on multiple paths, and with precise timing
create packet traces, which can be compared at later times.
Subflow analysis - TCP flows, e.g. a Web server's httpd flows - QoSTokenBucketSize: [byte] Size of Token Bucket
actually contain many individual sub flows. Given, a well known Web
Server WW, and a client CC, RTFM would normally pick up an
aggregation of all the flows of text, graphics, Java programs, etc.
that are sent between WW and CC. RTFM could detect the TCP handshake
at the beginning of flows, and the Sequence numbers of the flow, and
thus maintain statistics about the subflows within a flow. (A
question for RTFM is whether we will examine fields beyond the
transport header to determine details of the application flow.)
Congestion Analysis - In a TCP/IP flow we have information on the - QoSPeakDataRate: [byte/s] Maximum rate for incoming data
negotiation of Window sizes which are used by TCP/IP to control
congestion. Well behaved flows honor these requests and in the vast - QoSMinPolicedUnit: [byte] IP datagrams less than this are
majority of cases the sender will slow down and thus decrease its counted as being this size
rate of injecting packets into the congested network. We will look - QoSMaxDatagramSize: [byte] Size of biggest datagram which
for cases where flows do not honor these congestion controls and are conforms to the traffic specification
not slowing down. We will also look for flows which have the
"precedence" fields turned on and thus are aggressively competing for
network resources.
3.6 Actions on Exceptions 3.6 Actions on Exceptions
The user of RTFM will have the ability to mark flows as having High Some users of RTFM have requested the ability to mark flows as having
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) (e.g. a flow that is exhausting the capacity of the line that carries
causes 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 may define service situations in many forwarding to the Manager. Operations Support could define service
different environments. This is an area for further discussion on situations in many different environments. This is an area for
Alert and Trap handling. further discussion on Alert and Trap handling.
4. Extensions to the 'Basic' RTFM Meter 4. Extensions to the 'Basic' RTFM Meter
The WG has agreed that the basic RTFM Meter will not be altered by The WG has agreed that the basic RTFM Meter will not be altered by
the addition of the new attributes of this document. This section the addition of the new attributes of this document. This section
describes the extensions needed to implement the new attributes. describes the extensions needed to implement the new attributes.
4.1 Flow table extensions 4.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 draft does not change that structure. The flow table could have
ancillary tables called "Distribution Tables" and "Trace Tables," ancillary tables called "Distribution Tables" and "Trace Tables,"
these would contain rows of values and or actions as defined above. these would contain rows of values and or actions as defined above.
skipping to change at page 10, line 51 skipping to change at page 11, line 18
used! As a starting point, the following is proposed (bytes are used! As a starting point, the following is proposed (bytes are
numbered 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 and Counts 2 Scale Factor Power of 10 multiplier for Limits 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-2 Buckets Number of buckets. Does not include 1 Buckets Number of buckets. Does not include
the 'overflow' bucket the 'overflow' bucket
3-4 Parameter-1 Parameter use depends on 2 Parameter-1 } Parameter use depends
5-6 Parameter-2 distribution attribute 3-4 Parameter-2 } on distribution-valued
5-6 Parameter-3 } attribute
For example: For example:
ToPacketSize & .1.0,15,1500 = ,100,0,0: PushPkt, Next FromPacketSize & 1.0.25!1500 = 60.0!0: PushPkttoAct, Next;
FromBitrate & .2.3,16,2048 = ,7,5,0: PushPkt, Next ToInterArrivalTime & 2.3.1!1800 = 60.0.0!0: PushPkttoAct, Next;
In these mask and value fields a dot indicates that the next FromBitRate & 2.3.1!10000 = 60.5.0!0: PushPkttoAct, Next;
number is a one-byte integer, and the commas indicate that the
next number is a two-byte integer. In these mask and value fields a dot indicates that the preceding
number is a one-byte integer, the exclamation marks indicate that
the preceding number is a two-byte integer, and the last number is
two bytes wide since this was the width of the preceding field.
(Note 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 The first rule specifies that a distribution of packet sizes is
to be built. It uses an array of 100 buckets, storing values to be built. It uses an array of 60 buckets, storing values from
from 1 to 1500 bytes (i.e. linear steps of 15 bytes each). Any 1 to 1500 bytes (i.e. linear steps of 25 bytes each bucket). Any
packets with size greater than 1500 will be counted in the 'overflow' packets with size greater than 1500 will be counted in the
bucket, hence there are 101 counters for the distribution.
The second rule specifies a bit-rate distribution, with the rate The second rule specifies an arrival-time distribution, using a
logarithmic scale for an array of 60 counters (and an overflow
bucket) for rates from 1 ms to 1.8 s. The scale factor of 3
indicates that the limits are given in milliseconds.
The third rule specifies a bit-rate distribution, with the rate
being calculated every 5 seconds (parameter 1). A logarithmic being calculated every 5 seconds (parameter 1). A logarithmic
array of 7 counters (and an overflow bucket) are used for array of 60 counters (and an overflow bucket) are used for
rates from 16,000 bps to 2,048,000 bps. The scale factor of 3 indicates rates from 1 kbps to 10 Mbps. The scale factor of 3 indicates
that the limits are given in thousands of bits per second. that the limits are given in thousands of bits per second.
These distribution parameters will need to be stored in the meter These distribution parameters will need to be stored in the meter
so that they are available for building the distribution. They so that they are available for building the distribution. They
will also need to be read from the meter and saved together with will also need to be read from the meter and saved together with
the other flow data. the other flow data.
4.3 Reading Distributions 4.3 Reading Distributions
Since RTFM flows are bi-directional, each distribution-valued quantity Since RTFM flows are bi-directional, each distribution-valued quantity
(e.g. packet size, bit rate, etc.) (e.g. packet size, bit rate, etc.)
will actually need two sets of counters, one for packets travelling in each direction. It is will actually need two sets of counters, one for packets travelling in each
direction. It is
tempting to regard these as components of a single 'distribution,' but tempting to regard these as components of a single 'distribution,' but
in many cases only one of the two directions will be of interest; it in many cases only one of the two directions will be of interest; it
seems better to keep them in separate distributions. This is similar seems better to keep them in separate distributions. This is similar
to the old-style counter-valued attributes such as toOctets and fromOctets. to the old-style counter-valued attributes such as toOctets and fromOctets.
A distribution should be read by a meter reader as a single, A distribution should be read by a meter reader as a single,
structured 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 distribution - 'mask' and 'value' fields from the rule which created the distribution
- sequence of counters ('buckets' + overflow) - sequence of counters ('buckets' + overflow)
These could be easily collected into a BER-encoded octet string, These can be easily collected into a BER-encoded octet string,
and would be read and referred to as a 'distribution.' and would be read and referred to as a 'distribution.'
5. Extensions to the Rules Table 5. Extensions to the Rules Table
Extensions to the Rules Table, Attribute Numbers
The Rules Table of "old-style" attributes will be extended for the The Rules Table of "old-style" attributes will be extended for the
new flow types. A list of actions, and keywords, such as "ToBitRate", new flow types. A list of actions, and keywords, such as "ToBitRate",
"ToPacketSize", etc. will be developed and "ToPacketSize", etc. will be developed and used to inform an RTFM
used to inform RTFM to collect a set of extended values for a meter to collect a set of extended values for a
particular flow (or set of flows). particular flow (or set of flows).
Note. An implementation suggestion. Value 65 is used for 'Distributions,' which Note. An implementation suggestion. Value 65 is used for 'Distributions,'
has one bit set for each distribution-valued attribute present for the flow, using which has one bit set for each distribution-valued attribute present
bit 0 for attribute 66, bit 1 for attribute 67, etc. for the flow, using bit 0 for attribute 66, bit 1 for attribute 67, etc.
Here are ten possible distribution-valued attributes numbered according to RTFM WG Here are ten possible distribution-valued attributes numbered according
consensus at the 1997 meeting in Munich: 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 ToInterarrivalTime(68) microseconds between successive packets
FromInterarrivalTime(69) travelling in the same direction FromInterarrivalTime(69) travelling in the same direction
ToTurnaroundTime(70) microseconds between successive packets ToTurnaroundTime(70) microseconds between successive packets
FromTurnaroundTime(71) travelling in opposite directions FromTurnaroundTime(71) travelling in opposite directions
ToBitRate(72) short-term flow rate in bits per second ToBitRate(72) short-term flow rate in bits per second
FromBitRate(73) Parameter 1 = rate interval in seconds FromBitRate(73) Parameter 1 = rate interval in seconds
ToPDURate(74) short-term flow rate in PDUs per second ToPDURate(74) short-term flow rate in PDUs per second
skipping to change at page 12, line 35 skipping to change at page 13, line 16
ToTurnaroundTime(70) microseconds between successive packets ToTurnaroundTime(70) microseconds between successive packets
FromTurnaroundTime(71) travelling in opposite directions FromTurnaroundTime(71) travelling in opposite directions
ToBitRate(72) short-term flow rate in bits per second ToBitRate(72) short-term flow rate in bits per second
FromBitRate(73) Parameter 1 = rate interval in seconds FromBitRate(73) Parameter 1 = rate interval in seconds
ToPDURate(74) short-term flow rate in PDUs per second ToPDURate(74) short-term flow rate in PDUs per second
FromPDURate(75) Parameter 1 = rate interval in seconds 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 -
QoSService(98)
QoSStyle(99)
QoSRate(100)
QoSSlackTerm(101)
QoSTokenBucketRate(102)
QoSTokenBucketSize(103)
QoSPeakDataRate(104)
QoSMinPolicedUnit(105)
QoSMaxPolicedUnit(106)
The following attributes have also been implemented in NetFlowMet, a
version of the NeTraMet meter -
MeterID(112) Integer identifying the router producing
NetFlow data (needed when NetFlowMet takes
data from several routers)
SourceASN(113) Autonomous System Number for flow's source
SourcePrefix(114) CIDR width used by router for determining
flow's source network
DestASN(115) Autonomous System Number for flow's destination
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
allocated attribute numbers below 64, making them part of the 'base'
RTFM meter attributes.
6. Security Considerations 6. Security Considerations
The attributes considered in this document represent properties The attributes considered in this document represent properties
of traffic flows; they do not present any security issues in of traffic flows; they do not present any security issues in
themselves. The attributes may, however, be used in measuring the themselves. The attributes may, however, be used in measuring the
behaviour of traffic flows, and the collected traffic flow data behaviour of traffic flows, and the collected traffic flow data
could be of considerable value. Suitable could be of considerable value. Suitable precautions should be taken to keep
precautions should be taken to keep such data safe. such data safe.
7. Acknowledgments 7. Acknowledgments
8. Author's Address: 8. Author's Address:
Sig Handelman Sig Handelman
IBM Research Division IBM Research Division
Hawthorne, NY Hawthorne, NY
Phone: 1-914-784-7626 Phone: 1-914-784-7626
E-mail: swhandel@us.ibm.com E-mail: swhandel@us.ibm.com
skipping to change at line 599 skipping to change at page 15, line 15
Selected Areas in Communications, Vol. 13, No. 8, October 1995. Selected Areas in Communications, Vol. 13, No. 8, October 1995.
[5] Mills, C., Ruth, G.: "Internet Accounting Background," RFC 1272, [5] Mills, C., Ruth, G.: "Internet Accounting Background," RFC 1272,
1992. 1992.
[6] Waldbusser, S.: "Remote Network Monitoring Management Information [6] Waldbusser, S.: "Remote Network Monitoring Management Information
Base," RFC 1757, 1995, and RFC 2021, 1997. Base," RFC 1757, 1995, and RFC 2021, 1997.
[7] Brownlee, N: "Traffic Flow Measurement: Meter MIB", RFC 2064, [7] Brownlee, N: "Traffic Flow Measurement: Meter MIB", RFC 2064,
1997 1997
[8] Maiocchi, S: "NeTraMet & NeMaC for IIS Accounting: User's Guide",
CEFRIEL, Milan, 5 May 1998, (See also, http://www.cefriel.it/ntw).
[9] Shenker, S., Partridge, C., Guerin, R.: "Specification of
Guaranteed Quality of Service," RFC 2212, 1997.
 End of changes. 49 change blocks. 
120 lines changed or deleted 183 lines changed or added

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