draft-ietf-rtfm-new-traffic-flow-05.txt   draft-ietf-rtfm-new-traffic-flow-06.txt 
skipping to change at page 1, line 18 skipping to change at page 2, line ?
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
September 29, 1998 October 3, 1998
expires expires
March 1, 1999 April 3, 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-05.txt> <draft-ietf-rtfm-new-traffic-flow-06.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 21 skipping to change at page 2, line ?
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. A companion document beyond simple measurement of traffic volumes. A companion document
to this draft will be written to define MIB structures for the new to this draft will be written to define MIB structures for the new
attributes. 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
organising 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 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 the University of Auckland, NZ, and Stephen Stibler and Sig Handelman
at IBM in Hawthorne, NY, USA. The RTFM WG has also defined the role at IBM in Hawthorne, NY, USA. The RTFM WG has also defined the role
of the Meter Reader whose role is to retrieve flow data from the of the Meter Reader whose role is to retrieve flow data from the
Meter. 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, Switches, and characteristics altered as it travels through Routers, Switches, and
other network units. It is important to note the spatial location of other network units. It is important to note the spatial location of
the Meter when referring to attributes of a flow. An example, a the Meter when referring to attributes of a flow. An example, a
server may send a sequence of packets with a definite order, and server may send a sequence of packets with a definite order, and
inter-packet timing with a leaky bucket algorithm. A meter reading inter packet timing with a leaky bucket algorithm. A meter reading
downstream of the leaky bucket would record a set with minimal inter 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 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 packets may arrive out of sequence, with the timings altered. A meter
at the client's location would record different attributes for the at the client's location would record different attributes for the
same flow. 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 behaviour 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 - '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 computed
e.g. FlowKind) to indicate direction. 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
and Kind). These are directly derived from the endpoint attribute and Kind). These are directly derived from the endpoint
values. attribute values.
c. A new flow is created when a packet is to be counted that does not c. A new flow is created when a packet is to be counted that does
match the attributes of an existing flow. The meter records the time not match the attributes of an existing flow. The meter records
when this new flow is created. the time when this new flow is created.
d. Attribute values in (a), (b) and (c) described above are set when d. Attribute values in (a), (b) and (c) are set when the meter sees
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
meter last saw a packet for the flow. the meter last saw a packet for the flow.
f. Each flow has two packet and two byte counters, one for each flow f. Each flow has two packet and two byte counters, one for each
direction (Forward and Backward). These are updated as packets for flow direction (Forward and Backward). These are updated as
the flow are observed by the meter. packets 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 as variety of protocols; IPX, AppleTalk, DECnet and CLNS as well
TCP/IP. as 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 (inferred 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
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 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
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. from flows.
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. An initial develop measures to work with these service metrics. An initial
implementation of IIS Monitoring has been developed at CEFRIEL in implementation of IIS Monitoring has been developd at CEFRIEL in
Italy [8]. 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
performance statistics at appropriate places in networks (server or
client locations). RTFM could give detailed analyses of IPPM test
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,
so that detailed IPPM work could be applied to these most used paths.
3.0 Flow Abstractions - An RTFM Meter could act as a passive device, gathering traffic
and performance statistics at appropriate places in networks
(server or client locations).
- RTFM could give detailed analyses of IPPM test 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, so that detailed IPPM work could be applied to these most
used paths.
3. 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:
- 'trace' attributes of individual packets in a flow or a segment of - 'trace,' attributes of individual packets in a flow or a segment
a flow (e.g. last packet size, last packet arrival time). of a flow (e.g. last packet size, last packet arrival time).
- 'aggregates' statistics derived from the flow taken as a whole - 'aggregate,' attributes derived from the flow taken as a whole
(e.g. mean rates, 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 within
the flow (e.g. 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 Note that attributes within each of these classes may have various
types of values - numbers, distributions, time series, and so on. 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.
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 very short response time Meter Reader that is tied to a meter with very short response 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 directly to the Meter Reader for further stamps and provide them directly to the Meter Reader for further
processing. 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. 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 30 skipping to change at page 6, line 36
observed. LastTime is updated as each packet in the flow is observed. 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
obtained 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.' This method is
a compact representation of the data, with the values being stored
as 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 single values. This saves all the information, - As a sequence of single values. This saves all the information,
but does not fit well with the RTFM goal of doing as much data but does not fit well with the RTFM goal of doing as much data
reduction as possible within the meter. reduction as possible within the meter.
- As a distribution, i.e. in an array of 'buckets.' This method is
a compact representation of the data, with the values being stored as
counters between a minimum and maximum, with defined steps in each
bucket. This fits the RTFM goal of compact data storage.
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 the distribution so that it can be easily read, is described in
section 4.2. section 4.2.
3.3 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." Data could be stored in a new attribute called, say, "PacketTrace." This could be a table,
a table, with a column for each property of interest. For example, with a column for each property of interest. For example, one could
one could trace: 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 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.
3.4 Aggregate Attributes 3.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
those packets which match the rule set for an individual flow. In packets which match the rule set for an individual flow. In addition
addition to these totals, RTFM could calculate Packet Size to these totals, for example, RTFM could calculate Packet Size
statistics. This data can be stored as distributions, though it may statistics. This data can be stored as distributions, though it may
sometimes be sufficient to simply keep a single e.g. maximum value. 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, as losing give an indication of the sensitivity to loss of a flow, for losing
large packets causes more data to be retransmitted. large packets causes more data to be retransmitted.
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 'packet size' distribution. The array of counters could hold a 'packet size' distribution. The
counters continue to increase, a meter reader will collect their counters continue to increase, a meter reader will collect their
values at regular intervals, an analysis application will compute and values at regular intervals, and an analysis application will compute
display distributions of the packet size for each collection and display distributions of the packet size for each collection
interval. interval.
3.5. Group Attributes
The notion of group attributes is to keep simple statistics for
measures that involve more than one packet. This section describes
some group attributes which it is feasible to implement in a traffic
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 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
rate distribution. data rate distribution.
- every 10 seconds, compute and save 10-second octet rate. - every 10 seconds, compute and save 10-second octet count, and
save 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 is needed to achieve this, but provided the meter is not 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 asked to do it for very large numbers of flows, it has been
successfully implemented. successfully implemented.
3.5 Group Attributes
The notion of group attributes is to keep simple statistics for
measures that involve more than one packet. This section describes
some group attributes which are feasible to implement in a traffic
meter, and which seem interesting and useful.
Short-term bit rate. (This 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.
Inter-arrival times. The Meter knows the time that it encounters each Inter-arrival times. The Meter knows the time that it encounters each
individual packet. Statistics can be kept to record the inter-arrival individual packet. Statistics can be kept to record the inter-arrival
times of the packets, which would give an indication of the jitter times of the packets, which would give an indication of the jitter
found in the Flow. found in the Flow.
Turn-around statistics. Sine the Meter knows the time that it Turn-around statistics. Sine the Meter knows the time that it
encounters each individual packet, it can produce statistics of the encounters each individual packet, it can produce statistics of the
time intervals between packets of a flow observed travelling in time intervals between packets in opposite directions are observed on
positive directions on the network. For protocols such as SNMP the network. For protocols such as SNMP (where every packet elicits
(where every packet request packet elicits an answering packet) this an answering packet) this gives a good indication of turn-around
gives a good indication of turn-around times. times.
Subflow analysis. Since the choice of flow endpoints is controlled Subflow analysis. Since the choice of flow endpoints is controlled
by the meter's rule set, it is easy to define an aggregate flow, e.g 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 "all the TCP streams between hosts A and B." Preliminary
implementation work suggests that - at least for this case - it implementation work suggests that - at least for this case - it
should be possible for the meter to maintain a table of information 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 about all the active streams. This could be used to produce at least
the following attributes: the following attributes:
- Number of streams, e.g. streams active for n-second intervals. - Number of streams, e.g. streams active for n-second intervals.
Determined for TCP and UDP using source-dest port number pairs. Determined for TCP and UDP using source-dest port number pairs.
- Number of TCP bytes, determined by taking difference of TCP - Number of TCP bytes, determined by taking difference of TCP
sequence numbers for each direction of the aggregate flow. sequence numbers for each direction of the aggreagate flow.
IIS attributes. Work at CEFRIEL [8] has produced a traffic meter IIS attributes. Work at CEFRIEL [8] has produced a traffic meter
with a rule set modified 'on the fly' so as to maintain a list of with a rule set modified 'on the fly' so as to maintain a list of
RSVP-reserved flows. For such flows the following attributes have RSVP-reserved flows. For such flows the following attributes have
been implemented: been implemented (these quantities are defined in [9]):
- QoSService: Service class for the flow - QoSService: Service class for the flow
(guaranteed, controlled load) (guaranteed, controlled load)
- QoSStyle: Reservation setup style (wildcard - QoSStyle: Reservation setup style
filter,fixed filter,shared explicit) (wildcard filter, fixed filter,
- QoSRate: [byte/s] rate for flows with guaranteed shared explicit)
service - QoSRate: [byte/s] rate for flows with
- QoSSlackTerm: [microseconds] Slack Term QoS parameter for guaranteed service
flows with guaranteed service - QoSSlackTerm: [microseconds] Slack Term QoS parameter
- QoSTokenBucketRate: [byte/s] Token Bucket Rate QoS parameter
for flows with guaranteed service for flows with guaranteed service
- QoSTokenBucketRate: [byte/s] Token Bucket Rate QoS parameter
for flows with guaranteed or
controlled load service
3.6 Actions on Exceptions The following are also being considered:
- QoSTokenBucketSize: [byte] Size of Token Bucket
- QoSPeakDataRate: [byte/s] Maximum rate for incoming data
- 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
3.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 High Watermarks. The existence of abnormal service conditions, such
as non-ending flow, a flow that exceeds a given limit in traffic as 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 (e.g. a flow that is exhausting the capacity of the line that carries
it) would cause an ALERT to be sent to the Meter Reader for it) would cause an ALERT to be sent to the Meter Reader for
forwarding to the Manager. Operations Support could define service forwarding to the Manager. Operations Support could define service
situations in many different environments. This is an area for situations in many different environments. This is an area for
further discussion on 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.
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 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 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 "To Bit Rate" for a particular flow, example, if a table entry has "To Bit Rate" for a particular flow,
the "ToBitRate" string would be found at the head of the row. (An the "ToBitRate" string would be found at the head of the row. (An
alternative method would be to code an identification value for each alternative method would be to code an identification value for each
extended attribute and push that value into the head of the row.) See extended attribute and push that value into the head of the row.) See
section 5.0 for an initial set of ten extended flow attributes. section 5. 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 necessary 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 necessarily 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 [7]. list already in the RTFM Meter MIB document [7].
Since distribution attributes are multi-valued it does not make sense Since distribution attributes are multi-valued it does not make sense
skipping to change at page 10, line 46 skipping to change at page 11, line 28
fields in the PushPkt rule are available to specify distribution fields in the PushPkt rule are available to specify distribution
parameters. 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 address. All we have to do is specify how these bytes should be
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, experiments with NeTraMet have used the following
rules:
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;
FromBitRate & 2.3.1!10000 = 60.5.0!0: PushPkttoAct, Next;
In these mask and value fields a dot indicates that the preceding In these mask and value fields a dot indicates that the preceding
number is a one-byte integer, the commas 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 The first rule specifies that a distribution of packet sizes is to be
to be built. It uses an array of 100 buckets, storing values built. It uses an array of 60 buckets, storing values from 1 to 1500
from 1 to 1500 bytes (i.e. linear steps of 15 bytes each). Any bytes (i.e. linear steps of 25 bytes each bucket). Any packets with
packets with size greater than 1500 will be counted in the 'overflow' size greater than 1500 will be counted in the 'overflow' bucket,
bucket, hence there are 101 counters for the distribution. hence there are 61 counters for the distribution.
The second rule specifies a bit-rate distribution, with the rate The second rule specifies an interarrival-time distribution, using a
being calculated every 5 seconds (parameter 1). A logarithmic logarithmic scale for an array of 60 counters (and an overflow
array of 7 counters (and an overflow bucket) are used for bucket) for rates from 1 ms to 1.8 s. Arrival times are measured in
rates from 16,000 bps to 2,048,000 bps. The scale factor of 3 indicates microseconds, hence the scale factor of 3 indicates that the limits
that the limits are given in thousands of bits per second. are given in milliseconds.
These distribution parameters will need to be stored in the meter The third rule specifies a bit-rate distribution, with the rate being
so that they are available for building the distribution. They calculated every 5 seconds (parameter 1). A logarithmic array of 60
will also need to be read from the meter and saved together with counters (and an overflow bucket) are used for rates from 1 kbps to
the other flow data. 10 Mbps. The scale factor of 3 indicates that the limits are given
in thousands of bits per second (rates are measured in bps).
4.3 Reading Distributions These distribution parameters will need to be stored in the meter so
that they are available for building the distribution. They will
also need to be read from the meter and saved together with the other
flow data.
Since RTFM flows are bi-directional, each distribution-valued quantity 4.3. Reading Distributions
(e.g. packet size, bit rate, etc.)
will actually need two sets of counters, one for packets travelling in each direction. Since RTFM flows are bi-directional, each distribution-valued
It is quantity (e.g. packet size, bit rate, etc.) will actually need two
tempting to regard these as components of a single 'distribution,' but sets of counters, one for packets travelling in each direction. It is
in many cases only one of the two directions will be of interest; it tempting to regard these as components of a single 'distribution,'
seems better to keep them in separate distributions. This is similar but in many cases only one of the two directions will be of interest;
to the old-style counter-valued attributes such as toOctets and fromOctets. it seems better to keep them in separate distributions. This is
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, 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 can be easily collected into a BER-encoded octet string,
and would be read and referred to as a 'distribution.' These can be easily collected into a BER-encoded octet string, and
would be read and referred to as a 'distribution.'
5. Extensions to the Rules Table, Attribute Numbers 5. 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 used to inform an RTFM "ToPacketSize", etc. will be developed and used to inform an RTFM
meter to collect a set of extended values for a particular flow (or set of flows). meter to collect a set of extended values for a particular flow (or
set of flows).
Note: An implementation suggestion. Value 65 is used for 'Distributions,' Note. An implementation suggestion. Value 65 is used for
which has one bit set for each distribution-valued attribute present 'Distributions,' which has one bit set for each distribution-valued
for the flow, using bit 0 for attribute 66, bit 1 for attribute 67, etc. attribute present for the flow, using bit 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 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
skipping to change at page 12, line 46 skipping to change at page 13, line 46
(76 .. 97) other distributions (76 .. 97) other distributions
It seems reasonable to allocate a further group of numbers It seems reasonable to allocate a further group of numbers
for the IIS attributes described above - for the IIS attributes described above -
QoSService(98) QoSService(98)
QoSStyle(99) QoSStyle(99)
QoSRate(100) QoSRate(100)
QoSSlackTerm(101) QoSSlackTerm(101)
QoSTokenBucketRate(102) QoSTokenBucketRate(102)
QoSTokenBucketSize(103)
QoSPeakDataRate(104)
QoSMinPolicedUnit(105)
QoSMaxPolicedUnit(106)
The following attributes have also been implemented in NetFlowMet, a The following attributes have also been implemented in NetFlowMet, a
version of the NeTraMet meter - version of the RTFM traffic meter -
MeterID(105) Integer identifying the router producing NetFlow MeterID(112) Integer identifying the router producing
data (needed when NetFlowMet takes data NetFlow data (needed when NetFlowMet takes
from several routers) data from several routers)
SourceASN(106) Autonomous System Number for flow's source SourceASN(113) Autonomous System Number for flow's source
SourcePrefix(107) CIDR width used by router for determining SourcePrefix(114) CIDR width used by router for determining
flow's source network flow's source network
DestASN(108) Autonomous System Number for flow's destination DestASN(115) Autonomous System Number for flow's destination
DestPrefix(109) CIDR width used by router for determining DestPrefix(116) CIDR width used by router for determining
flow's destination network 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, two more attributes will be useful: services, two more attributes will be useful:
SourceDSfield(118) DS field value for S->D packets SourceDSfield(118) DS field value for S->D packets
DestDSfield(119) DS field value for D->S packets DestDSfield(119) DS field value for D->S packets
6. Security Considerations 6. Security Considerations
The attributes considered in this document represent properties The attributes considered in this document represent properties of
of traffic flows; they do not present any security issues in traffic flows; they do not present any security issues in themselves.
themselves. The attributes may, however, be used in measuring the The attributes may, however, be used in measuring the behaviour of
behaviour of traffic flows, and the collected traffic flow data traffic flows, and the collected traffic flow data could be of
could be of considerable value. considerable value. Suitable precautions should be taken to keep such
Suitable precautions should be taken to keep such data safe. data safe.
7. Acknowledgements
8. Author's Address: 7. Author's Addresses:
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
Nevil Brownlee Nevil Brownlee
The University of Auckland The University of Auckland
New Zealand New Zealand
skipping to change at page 14, line 15 skipping to change at page 15, line 16
Waltham, MA Waltham, MA
Phone: 1 781 466 2448 Phone: 1 781 466 2448
E-mail: grr1@gte.com E-mail: grr1@gte.com
Stephen Stibler Stephen Stibler
IBM Research Division IBM Research Division
Hawthorne, NY Hawthorne, NY
Phone: 1-914-784-7191 Phone: 1-914-784-7191
E-mail: stibler@us.ibm.com E-mail: stibler@us.ibm.com
9. References: 8. References:
[1] Brownlee, N., Mills, C., Ruth, G.: "Traffic Flow Measurement: [1] Brownlee, N., Mills, C., Ruth, G.,
Architecture", RFC 2063, 1997 "Traffic Flow Measurement: Architecture,"
RFC 2063, The University of Auckland, January 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 RFC 2210, September 1997.
[4] Claffy, K., Braun, H-W, Polyzos, G.: "A Parameterizable
[3] Paxson, V., Almes, G., Mahdavi, J., Mathis, M., "Framework for
IP Performance Metrics," RFC 2330, May 1998.
[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.
[5] Mills, C., Ruth, G.: "Internet Accounting Background," RFC 1272, [5] Mills, C., Hirsch, G. and Ruth, G., "Internet Accounting
1992. Background," RFC 1272, Bolt Beranek and Newman Inc.,
Meridian Technology Corporation, November 1991.
[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",
1997 RFC 2064, The University of Auckland, January 1997.
[8] Maiocchi, S: "NeTraMet & NeMaC for IIS Accounting: User's Guide", [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 [9] Shenker, S., Partridge, C., Guerin, R.: "Specification of
Guaranteed Quality of Service," RFC 2212, 1997. Guaranteed Quality of Service," RFC 2212, 1997.
 End of changes. 86 change blocks. 
175 lines changed or deleted 221 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/