draft-ietf-rtfm-new-traffic-flow-02.txt   draft-ietf-rtfm-new-traffic-flow-03.txt 
skipping to change at page 1, line 14 skipping to change at page 1, line 14
Internet-draft IBM Internet-draft IBM
Hawthorne, NY USA Hawthorne, NY USA
Nevil Brownlee Nevil Brownlee
U of Auckland, NZ U of Auckland, NZ
Greg Ruth Greg Ruth
GTE Laboratories, Inc GTE Laboratories, Inc
Waltham, MA USA Waltham, MA USA
July 20, 1997 S. Stibler
IBM
Hawthorne, NY USA
March 13, 1998
expires expires
January 20, 1998 September 13, 1998
RTFM Working Group - New Attributes for Traffic Flow Measurement RTFM Working Group - New Attributes for Traffic Flow Measurement
<draft-ietf-rtfm-new-traffic-flow-02.txt> <draft-ietf-rtfm-new-traffic-flow-03.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, 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".
To learn the current status of any Internet Draft, please check the Internet-Drafts are draft documents valid for a maximum of six months
"1id-abstracts.txt" listing contained in the Internet Drafts shadow and may be updated, replaced, or obsoleted by other documents at any
directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), time. It is inappropriate to use Internet- Drafts as reference
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or material or to cite them other than as "work in progress."
ftp.isi.edu (US West Coast).
This memo provides information for the Internet community. This memo To view the entire list of current Internet-Drafts, please check the
does not specify an Internet standard of any kind. Distribution of "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
this memo is unlimited. Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
2. Introduction 2. Introduction
The Real-time Traffic Flow Measurement (RTFM) Working Group 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].
and [5]. The new attributes described in this document will be The new attributes described in this document will be useful for
useful for monitoring network performance and expand the scope of monitoring network performance and will expand the scope of RTFM
RTFM beyond simple measurement of traffic rates. Performance beyond simple measurement of traffic volumes. Performance attributes
attributes typically deal with throughput, packet loss, and delays. typically deal with throughput, packet loss, and delays. The WG will
We will explore the methods by which RTFM can extract values from explore the methods by which RTFM can extract values from packets and
flows so as to measure these attributes. We will also look at flows so as to measure these attributes. The WG will also look at
capturing information on jitter and congestion control. 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.
The RTFM Working Group has defined the concept of a standardized This draft was started in 1996 to advance the work of the RTFM group.
meter which records flows from a traffic stream according to Rule The goal of this work is to produce a simple set of abstractions,
Sets which are active in the meter[1]. which can be easily implemented and at the same time enhance the
value of RTFM Meters. This document also defines a method for
organizing the flow abstractions to augment the existing RTFM flow
table.
Implementations of this meter have been done by Nevil Brownlee in the Implementations of the RTFM Meter meter have been done by Nevil
University of Auckland, NZ, and Stephen Stibler and Sig Handelman at Brownlee in the University of Auckland, NZ, and Stephen Stibler and
IBM in Hawthorne, NY, USA. The RTFM WG has also defined the Meter Sig Handelman at IBM in Hawthorne, NY, USA. The RTFM WG has also
Reader Program whose job is to fetch flow data from the Meter. defined the role of the Meter Reader whose role is to retrieve flow
data from the Meter.
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 end-points (as defined by their source and destination attribute two endpoints (as defined by their source and destination attribute
values), and as BI-DIRECTIONAL (i.e. the meter effectively monitors values and start and end times), and as BI-DIRECTIONAL (i.e. the
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:
- We are interested in understanding the behavior of sessions between - The WG is interested in understanding the behavior of sessions
end-points. between endpoints.
- We want to perform as much data reduction as possible, so as to
reduce the amount of data to be retrieved from a remote meter.
- 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.
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
and Kind). These are directly derived from the endpoint attribute and Kind). These are directly derived from the endpoint attribute
values. values.
c. A new flow is created when a packet is to be counted which is not c. A new flow is created when a packet is to be counted that does not
classified by the Rule Set into an existing flow. The meter records match the attributes of an existing flow. The meter records the time
the time when this new flow is created. 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 the e. Each flow has a "LastTime" attribute, which indicates the time the
meter last saw a packet for the flow. meter last saw a packet for the flow.
f. Each flow has two packet and byte counters, one for each flow f. Each flow has two packet and two byte counters, one for each flow
direction (Forward and Backward). These are updated as packets are direction (Forward and Backward). These are updated as packets for
observed by the meter. 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 as variety of protocols; IPX, AppleTalk, DECnet and CLNS as well 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 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 sequence numbers).
- In the future, RTFM could coordinate directly with the Flow number - In the future, RTFM could coordinate directly with the Flow Label
from the IPv6 header. from the IPv6 header.
At the June, 1996 meeting of the RTFM WG in Montreal, Canada, a
proposal was made to extend the work of the group to produce an
Internet Draft "New Attributes for Traffic Flow Measurement". That
proposal has brought forth this document. 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 value of RTFM meters. This document
also defines a method for organizing the flow abstractions to
preserve the existing RTFM flow table.
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
the work of the Benchmarking / IP Performance Metrics Working Group, the work of the Benchmarking / IP Performance Metrics Working Group,
and also look at the work of Claffy, Braun and Polyzos [4]. We will and also look at the work of Claffy, Braun and Polyzos [4]. We will
demonstrate how RTFM can compute throughput, packet loss, and delays demonstrate how RTFM can compute throughput, packet loss, and delays
from flows. An example of the use of capacity and performance from flows.
information is found in "The Use of RSVP with IETF Integrated
Services" [2]. RSVP's use of Integrated Services revolves around An example of the use of capacity and performance information is
Token Bucket Rate, Token Bucket Size, Peak Data Rate, Minimum Policed found in "The Use of RSVP with IETF Integrated Services" [2]. RSVP's
Unit, Maximum Packet Size, and the Slack term. These are set by use of Integrated Services revolves around Token Bucket Rate, Token
TSpec, ADspec and FLowspec (Integrated Services Keywords), and are Bucket Size, Peak Data Rate, Minimum Policed Unit, Maximum Packet
used in configuration and operation of Integrated Services. RTFM Size, and the Slack term. These are set by TSpec, ADspec and FLowspec
could monitor explicitly Peak Data Rate, Minimum Policed Unit, (Integrated Services Keywords), and are used in configuration and
Maximum Packet Size, and the Slack term. RTFM could infer details of operation of Integrated Services. RTFM could monitor explicitly Peak
the Token Bucket. We will develop measures to work with these service Data Rate, Minimum Policed Unit, Maximum Packet Size, and the Slack
metrics. term. RTFM could infer details of the Token Bucket. The WG will
develop measures to work with these service metrics.
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 that, gathering traffic An RTFM Meter could act as a passive device, gathering traffic and
and performance statistics at appropriate places in TCP/IP networks performance statistics at appropriate places in networks (server or
(server or client locations). RTFM could give detailed analyses of client locations). RTFM could give detailed analyses of IPPM test
IPPM test flows that pass through the Network segment that RTFM is flows that pass through the Network segment that RTFM is monitoring.
monitoring. RTFM could be used to identify the most-used paths in a RTFM could be used to identify the most-used paths in a network mesh,
network mesh, so that detailed IPPM work could be applied to the most so that detailed IPPM work could be applied to these most used paths.
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 individual packets in a flow or a
segment of a flow o 'packet traces' - collections of attributes of individual packets
in a flow or a segment of a flow.
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).
o 'series'- attributes that depend on more than one packet (e.g. o 'series'- attributes that depend on more than one packet (e.g.
inter-arrival times, short-term traffic rates). inter-arrival times, short-term traffic rates).
The following sections suggest implementations for each of these 3.1. Meter Readers and Meters
classes of extensions.
A note on the relation between Meter Readers and Meters.
As an introduction to flow abstractions one fact must be emphasized. 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 instantaneous response
and very high bandwidth. If the Meter Reader and Meter can be time 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 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 create 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.1. Attrubute Types 3.2. Attribute Types
The previous section described three different classes of attribute; Section 3.0 described three different classes of attributes; this
this section considers what the types of these attributes could be. 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,' and will not varying type. They are essentially 'compound objects' i.e. lists of
be considered further here. attribute values for a string of packets.
Aggregate attributes are like the 'old-style' ones. Their types are Aggregate attributes are like the 'old-style' attributes. The 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 set 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
counters, so as to determine rates for these attributes. For counters, so as to determine rates for these attributes. For
example, if we read flow data at five-minute intervals, we can example, if we read flow data at five-minute intervals, we can
calculate five-minute packet and byte rates for the flow's two calculate five-minute packet and byte rates for the flow's two
directions. directions.
Times - the FirstTime for a flow is set when its first packet is Times - the FirstTime for a flow is set when its first packet is
observed. LastTime is updated for every packet of the flow. observed. LastTime is updated as each packet in the flow is observed.
All the above types have the common feature that they are expressed All the above types have the common feature that they are expressed
as 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 time intervals, we can compute an interval for every packet after
the first. If we are interested in packet sizes, a new value is the first. If we are interested in packet sizes, a new value is
produced as each packet arrives. When it comes to storing this data obtained as each packet arrives. When it comes to storing this data
we have two options: we have two options:
- As a distribution, i.e. in an array of 'buckets.' On the other hand - As a distribution, i.e. in an array of 'buckets.' This method is
meter storage requirements are well-defined, as is the amount of data a compact representation of the data, with the values being stored as
to be read from the meter. counters between a minimum and maximum, with defined steps in each
bucket. This fits the RTFM goal of compact data storage.
- As a sequence of integers. This saves all the information, but - As a sequence of single values. This saves all the information,
does not fit well with the RTFM goal of doing as much data reduction but does not fit well with the RTFM goal of doing as much data
as possible within the meter. 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.
For most of RTFM's attributes, a 'distribution' (as described above) A method for specifying the distribution parameters, and for
appears to be the most effective attribute type. A method of encoding the distribution so that it can be easily read, is described
specifying the distribution parameters, and for encoding the in section 4.2.
distribution so that it can be easily read, are described in section
4.2.
3.2. Packet Traces 3.3 Packet Traces
The simplest way of collecting a trace in the meter would be to have The simplest way of collecting a trace in the meter would be to have
a new attribute called, say, "PacketTrace." This could be a table, a new attribute called, say, "PacketTrace." This could be a table,
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
- 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).
- Direction (Forward or Backward) - Packet Direction (Forward or Backward)
- Sequence number (for protocols with sequence numbers) - Packet Sequence number (for protocols with sequence numbers)
- Flags (for TCP at least). - Packet Flags (for TCP at least).
Note: The following example is for the user who is 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 1-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.
3.3 Aggregate Attributes
Performance aspects of flows are of interest in the case of a flow 3.4 Aggregate Attributes
between a server and client. TCP/IP and UDP flows contain equivalent
performance, with additional data from TCP flows. The performance
data found by this method define the flow capacity used by the
individual flow, as experienced in the locale of the RTFM meter.
For both TCP/IP and UDP, RTFM's "old-style" flow attributes count the RTFM's "old-style" flow attributes count the bytes and packets for
bytes and packets for packets which match the rule set for an packets which match the rule set for an individual flow. In addition
individual flow. In addition to these totals, RTFM could calculate to these totals, RTFM could calculate Packet Size and Bit Rate
Packet size and Bit rate statistics. Bit rate statistics point to the statistics. Bit Rate statistics point to the throughput-related
throughput-related performance metrics. performance metrics. This data can be stored as distributions, though
it may sometimes be sufficient to simply keep a maximum value.
Packet size - RTFM's packet flows can be examined to determine the Packet Size - RTFM's packet flows can be examined to determine the
maximum packet size found in a flow. This will give the Network maximum packet size found in a flow. This will give the Network
Operator an indication of the MTU being used in a flow. It will also Operator an indication of the MTU being used in a flow. It will also
give an indication of the sensitivity to loss of a flow, for losing give an indication of the sensitivity to loss of a flow, for losing
large packets causes more data to be repeated. large packets causes more data to be retransmitted.
Short-term bit rate - The data could also be recorded as the maximum 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 and minimum data rate of the flow, found over specific time periods
during the lifetime of a flow; this is a special kind of during the lifetime of a flow; this is a special kind of
'distribution.' Bit rate could be used to define the throughput of a '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 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. a network, one can find the throughput of the network.
If we are interested in '10-second' forward data rates, the meter If we are interested in '10-second' forward data rates, the meter
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 the 10-second octet count, and save a - every 10 seconds, compute and save 10-second octet count, and save
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 will be needed to achieve this, but provided the meter is
not asked to do it for very large numbers of flows, it should not be not asked to do it for very large numbers of flows, it should not be
too difficult! too difficult!
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.4 Series Attributes 3.5 Series Attributes
The notion of series attributes is to keep simple statistics for The notion of series attributes is to keep simple statistics for
measures that involve more than one packet. The attribute values measures that involve more than one packet. The attribute values
would be stored in the meter as a distribution (see above). would be stored in the meter as a distribution (see above).
TCP and UDP TCP and UDP
Performance aspects of flows are of interest between servers and
clients. We can observe common measurement attributes with TCP/IP
and UDP flows. TCP flows yield additional information due to the
sequence numbers found in TCP. These performance data describe the
performance of a flow as recorded in the locale of the RTFM Meter.
Inter-arrival statistics - TCP and UDP. The Meter knows the time that Inter-arrival statistics - TCP and UDP. The Meter knows the time that
it encounters each individual packet. Statistics can be kept to it encounters each individual packet. Statistics can be kept to
record the inter-arrival times of the packets, which would give an record the inter-arrival times of the packets, which would give an
indication of the jitter found in the Flow. indication of the jitter found in the Flow.
Turn-around statistics - TCP and UDP. The Meter knows the time that
it encounters each individual packet. Statistics can be kept to
record the times when packets in opposite directions are found on the
net. This would give an indication of turn around times which have
use for protocols with simple packet flow, e.g. SNMP.
TCP Only - Packet loss - RTFM can calculate packet loss performance TCP Only - Packet loss - RTFM can calculate packet loss performance
metrics. This is an area for further study. TCP packets have byte metrics. This is an area for further study. TCP packets have byte
sequence numbers and SYNS, FINS, and ACK's associated with them. RTFM sequence numbers and SYNS, FINS, and ACK's associated with them. RTFM
could track the sequence numbers in the flows, and calculate the could track the sequence numbers in the flows, and calculate the
packet loss occurring in a flow, and thus we can develop a metric of packet loss occurring in a flow, and thus we can develop a metric of
lost packets and useful traffic. lost packets and useful traffic.
Delay analysis - TCP flows could be examined for the timing between Delay analysis - TCP flows could be examined for the timing between
Transmissions and ACKS and thus we can get some measure of delay (of Transmissions and ACKS and thus we can get some measure of delay (of
IPPM performance metrics). This assumes the forward and reverse IPPM performance metrics). This assumes the forward and reverse
packets are both visible to the meter. In the case of asymmetric packets are both visible to the meter. In the case of asymmetric
flows, RTFM can be run on multiple paths, and with precise timing flows, RTFM can be run on multiple paths, and with precise timing
create packet traces, which can be compared at later times. create packet traces, which can be compared at later times.
Subflow analysis - TCP flows, e.g. a Web server's httpd flows Subflow analysis - TCP flows, e.g. a Web server's httpd flows
actually contain many individual sub flows. Given, a well known Web actually contain many individual sub flows. Given, a well known Web
Server WW, and a client CC, RTFM would normally pick up an Server WW, and a client CC, RTFM would normally pick up an
aggregation of all the flows of text, graphics, Java programs, etc. aggregation of all the flows of text, graphics, Java programs, etc.
that are sent between WW and CC. By analyzing the Sequence numbers, that are sent between WW and CC. RTFM could detect the TCP handshake
RTFM could estimate when each subflow occurs, and thus maintain at the beginning of flows, and the Sequence numbers of the flow, and
statistics about the subflows on a network. 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 Congestion Analysis - In a TCP/IP flow we have information on the
negotiation of Window sizes which are used by TCP/IP to control negotiation of Window sizes which are used by TCP/IP to control
congestion. Well behaved flows honor these requests and in the vast congestion. Well behaved flows honor these requests and in the vast
majority of cases the sender will slow down and thus decrease its majority of cases the sender will slow down and thus decrease its
rate of injecting packets into the congested network. We will look rate of injecting packets into the congested network. We will look
for cases where flows do not honor these congestion control and are for cases where flows do not honor these congestion controls and are
not slowing down. We will also look for flows which have the not slowing down. We will also look for flows which have the
"precedence" fields turned on and thus are aggressively competing for "precedence" fields turned on and thus are aggressively competing for
network resources. network resources.
3.5 Actions on Exceptions 3.6 Actions on Exceptions
The user of RTFM will have the ability to mark flows as having High The user of RTFM will have the ability to mark flows as having High
Watermarks. The existence of abnormal service conditions, such as Watermarks. The existence of abnormal service conditions, such as
non-ending flow, a flow that exceeds a given limit in traffic (e.g. a non-ending flow, a flow that exceeds a given limit in traffic (e.g. a
flow that is exhausting the capacity of the line that carries it) flow that is exhausting the capacity of the line that carries it)
causes an ALERT to be sent to the Meter Reader for forwarding to the causes an ALERT to be sent to the Meter Reader for forwarding to the
Manager. Operations Support may define service situations in many Manager. Operations Support may define service situations in many
different environments. This is an area for further discussion on different environments. This is an area for further discussion on
Alert and Trap handling. 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 addition of the new attributes of this document. This section
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.
Each 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
writing of rule sets for the RTFM Meter.
In order to identify the data in a Packet Flow Table, the attribute In order to identify the data in a Packet Flow Table, the attribute
name could be pushed into a string at the head of each row. For name could be pushed into a string at the head of each row. For
example, if a table entry has Bit Rates for a particular flow, the example, if a table entry has "To Bit Rate" for a particular flow,
"BitRate" string would be found at the head of the row. the "ToBitRate" string would be found at the head of the row. (An
alternative method would be to code an identification value for each
extended attribute and push that value into the head of the row.) See
section 5.0 for an inital set of ten extended flow attributes.
4.2. Specifying Distributions in RuleSets 4.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 RTFM Meter architecture to support distributions. This, however, is
not 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
skipping to change at page 10, line 25 skipping to change at page 10, line 52
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-2 Buckets Number of buckets. Does not include
the 'overflows' bucket the 'overflow' bucket
3-4 Parameter-1 Parameter use depends on 3-4 Parameter-1 Parameter use depends on
5-6 Parameter-2 distribution attribute 5-6 Parameter-2 distribution attribute
For example: For example:
ToPacketSize & 1.0,1,1500 = 100,0,0: PushPkt, Next ToPacketSize & .1.0,15,1500 = ,100,0,0: PushPkt, Next
FromBitrate & 2.3,16,2048 = 7,5,0: PushPkt, Next FromBitrate & .2.3,16,2048 = ,7,5,0: PushPkt, Next
In these mask and value fields a dot indicates that the next In these mask and value fields a dot indicates that the next
number is a one-byte integer, and the commas indicate that the number is a one-byte integer, and the commas indicate that the
next number is a two-byte integer. next number is a two-byte integer.
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 100 buckets, storing values
from 1 to 1500 bytes (i.e. linear steps of 15 bytes each). Any from 1 to 1500 bytes (i.e. linear steps of 15 bytes each). Any
packets with size greater than 1500 will be counted in the 'overflow' packets with size greater than 1500 will be counted in the 'overflow'
bucket, hence there are 101 counters for the distribution. bucket, hence there are 101 counters for the distribution.
The second rule specifies a bit-rate distribution, with the rate The second 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 7 counters (and an overflow bucket) are used for
rates from 16 kbps to 2048 kbps. The scale factor of 10 indicates rates from 16,000 bps to 2,048,000 bps. The scale factor of 3 indicates
that the limits are given in kilobits 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, Since RTFM flows are bi-directional, each distribution-valued quantity
each distribution-valued quantity (e.g. packet size, bit rate, etc.) (e.g. packet size, bit rate, etc.)
will actually need two sets of will actually need two sets of counters, one for packets travelling in each direction. It is
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 sensible; 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' field from 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 could be easily collected into a BER-encoded octet string,
and 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
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 "BitRate"- new flow types. A list of actions, and keywords, such as "ToBitRate",
for Bit Rate, "MaxPackSize", for Max Packet size will be developed and "ToPacketSize", etc. will be developed and
used to inform RTFM to collect a set of extended values for a used to inform RTFM to collect a set of extended values for a
particular flow (or set of flows). particular flow (or set of flows).
To begin with, here are ten possible distribution-valued attributes: Note. An implementation suggestion. Value 65 is used for 'Distributions,' which
has one bit set for each distribution-valued attribute present for the flow, using
bit 0 for attribute 66, bit 1 for attribute 67, etc.
ToPacketSize(61) size of PDUs in bytes (i.e. number Here are ten possible distribution-valued attributes numbered according to RTFM WG
FromPacketSize(62) of bytes actually transmitted) consensus at the 1997 meeting in Munich:
ToInterarrivalTime(63) microseconds between successive packets ToPacketSize(66) size of PDUs in bytes (i.e. number
FromInterarrivalTime(64) travelling in the same direction FromPacketSize(67) of bytes actually transmitted)
ToTurnaroundTime(65) microseconds between successive packets ToInterarrivalTime(68) microseconds between successive packets
FromTurnaroundTime(66) travelling in opposite directions FromInterarrivalTime(69) travelling in the same direction
ToBitRate(67) short-term flow rate in bits per second ToTurnaroundTime(70) microseconds between successive packets
FromBitRate(68) Parameter 1 = rate interval in seconds FromTurnaroundTime(71) travelling in opposite directions
ToPDURate(69) short-term flow rate in PDUs per second ToBitRate(72) short-term flow rate in bits per second
FromPDURate(70) Parameter 1 = rate interval in seconds FromBitRate(73) Parameter 1 = rate interval in seconds
ToPDURate(74) short-term flow rate in PDUs per second
FromPDURate(75) Parameter 1 = rate interval in seconds
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. could be of considerable value. Suitable
Anyone making such measurments should have a clearly-defined precautions should be taken to keep such data safe.
purpose in doing so. They should also take great care to ensure
that the data is properly stored, and is used solely for its
intended purpose.
7. Acknowledgments 7. Acknowledgments
We thank Stephen Stibler of IBM for his input to, and comments on this draft.
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: handel@watson.ibm.com E-mail: swhandel@us.ibm.com
Nevil Brownlee Nevil Brownlee
The University of Auckland The University of Auckland
New Zealand New Zealand
Phone: +64 9 373 7599 x8941 Phone: +64 9 373 7599 x8941
E-mail: n.brownlee@auckland.ac.nz E-mail: n.brownlee@auckland.ac.nz
Greg Ruth Greg Ruth
GTE Laboratories GTE Laboratories
Waltham, MA Waltham, MA
Phone: 1 617 466 2448 Phone: 1 781 466 2448
E-mail: grr1@gte.com E-mail: grr1@gte.com
Stephen Stibler
IBM Research Division
Hawthorne, NY
Phone: 1-914-784-7191
E-mail: stibler@us.ibm.com
9. References: 9. References:
[1] Brownlee, N., Mills, C., Ruth, G.: "Traffic Flow Measurement: [1] Brownlee, N., Mills, C., Ruth, G.: "Traffic Flow Measurement:
Architecture", RFC 2063, 1997 Architecture", RFC 2063, 1997
[2] Wroclawski, J.: "The Use of RSVP with IETF Integrated Services" [2] Wroclawski, J.: "The Use of RSVP with IETF Integrated Services"
[3] Almes, G. et al: "Framework for IP Performance Metrics" Internet [3] Almes, G. et al: "Framework for IP Performance Metrics" Internet
[4] Claffy, K., Braun, H-W, Polyzos, G.: "A Parameterizable [4] Claffy, K., Braun, H-W, Polyzos, G.: "A Parameterizable
Methodology for Internet Traffic Flow Profiling," IEEE Journal on Methodology for Internet Traffic Flow Profiling," IEEE Journal on
Selected Areas in Communications, Vol. 13, No. 8, October 1995. Selected Areas in Communications, Vol. 13, No. 8, October 1995.
 End of changes. 77 change blocks. 
171 lines changed or deleted 194 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/