draft-ietf-rtfm-architecture-02.txt   draft-ietf-rtfm-architecture-03.txt 
Internet Engineering Task Force Brownlee, Mills, Ruth Internet Engineering Task Force Brownlee, Mills, Ruth
INTERNET-DRAFT The University of Auckland INTERNET-DRAFT The University of Auckland
July 98
Expires January 1999
Traffic Flow Measurement: Architecture Traffic Flow Measurement: Architecture
<draft-ietf-rtfm-architecture-02.txt> <draft-ietf-rtfm-architecture-03.txt>
Status of this Memo 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, and documents of the Internet Engineering Task Force (IETF), its Areas, and
its Working Groups. Note that other groups may also distribute working its Working Groups. Note that other groups may also distribute working
documents as Internet-Drafts. This Internet Draft is a product of the documents as Internet-Drafts. This Internet Draft is a product of the
Realtime Traffic Flow Measurement Working Group of the IETF. Realtime Traffic Flow Measurement Working Group of the IETF.
Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts are draft documents valid for a maximum of six months.
Internet Drafts may be updated, replaced, or obsoleted by other Internet Drafts may be updated, replaced, or obsoleted by other
documents at any time. It is not appropriate to use Internet Drafts as documents at any time. It is not appropriate to use Internet Drafts as
reference material or to cite them other than as a "working draft" or reference material or to cite them other than as a "working draft" or
"work in progress." "work in progress."
To view the entire list of current Internet-Drafts, please check the To view the entire list of current Internet-Drafts, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim),
ftp.isi.edu (US West Coast). ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
Abstract Abstract
This document describes an architecture for the measurement and This document provides a general framework for describing network
reporting of network traffic flows, discusses how this relates to an traffic flows, presents an architecture for traffic flow measurement and
overall network traffic flow architecture, and describes how it can be reporting, discusses how this relates to an overall network traffic flow
used within the Internet. It is intended to provide a starting point architecture and indicates how it can be used within the Internet.
for the Realtime Traffic Flow Measurement Working Group.
Contents Contents
1 Statement of Purpose and Scope 3 1 Statement of Purpose and Scope 3
1.1 Changes Introduced Since RFC 2063 . . . . . . . . . . . . . . 4 1.1 Brief Technical Specification (TS) . . . . . . . . . . . . . . 3
1.2 Applicability Statement (AS) . . . . . . . . . . . . . . . . . 3
1.3 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2 Traffic Flow Measurement Architecture 5 INTERNET-DRAFT Traffic Flow Measurement: Architecture July 98
2.1 Meters and Traffic Flows . . . . . . . . . . . . . . . . . . . 5
2.2 Interaction Between METER and METER READER . . . . . . . . . . 7 2 Traffic Flow Measurement Architecture 6
2.1 Meters and Traffic Flows . . . . . . . . . . . . . . . . . . . 6
2.2 Interaction Between METER and METER READER . . . . . . . . . . 8
2.3 Interaction Between MANAGER and METER . . . . . . . . . . . . 8 2.3 Interaction Between MANAGER and METER . . . . . . . . . . . . 8
2.4 Interaction Between MANAGER and METER READER . . . . . . . . . 8 2.4 Interaction Between MANAGER and METER READER . . . . . . . . . 9
2.5 Multiple METERs or METER READERs . . . . . . . . . . . . . . . 9 2.5 Multiple METERs or METER READERs . . . . . . . . . . . . . . . 9
2.6 Interaction Between MANAGERs (MANAGER - MANAGER) . . . . . . . 10 2.6 Interaction Between MANAGERs (MANAGER - MANAGER) . . . . . . . 10
2.7 METER READERs and APPLICATIONs . . . . . . . . . . . . . . . . 10 2.7 METER READERs and APPLICATIONs . . . . . . . . . . . . . . . . 11
3 Traffic Flows and Reporting Granularity 10 3 Traffic Flows and Reporting Granularity 11
3.1 Flows and their Attributes . . . . . . . . . . . . . . . . . . 11 3.1 Flows and their Attributes . . . . . . . . . . . . . . . . . . 11
3.2 Granularity of Flow Measurements . . . . . . . . . . . . . . . 13 3.2 Granularity of Flow Measurements . . . . . . . . . . . . . . . 14
3.3 Rolling Counters, Timestamps, Report-in-One-Bucket-Only. . . . 15 3.3 Rolling Counters, Timestamps, Report-in-One-Bucket-Only . . . 15
4 Meters 17 4 Meters 17
4.1 Meter Structure . . . . . . . . . . . . . . . . . . . . . . . 17 4.1 Meter Structure . . . . . . . . . . . . . . . . . . . . . . . 18
4.2 Flow Table . . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.2 Flow Table . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.3 Packet Handling, Packet Matching . . . . . . . . . . . . . . . 19 4.3 Packet Handling, Packet Matching . . . . . . . . . . . . . . . 20
4.4 Rules and Rule Sets . . . . . . . . . . . . . . . . . . . . . 23 4.4 Rules and Rule Sets . . . . . . . . . . . . . . . . . . . . . 23
4.5 Maintaining the Flow Table . . . . . . . . . . . . . . . . . . 26 4.5 Maintaining the Flow Table . . . . . . . . . . . . . . . . . . 27
4.6 Handling Increasing Traffic Levels . . . . . . . . . . . . . . 27 4.6 Handling Increasing Traffic Levels . . . . . . . . . . . . . . 28
5 Meter Readers 28 5 Meter Readers 29
5.1 Identifying Flows in Flow Records . . . . . . . . . . . . . . 28 5.1 Identifying Flows in Flow Records . . . . . . . . . . . . . . 29
5.2 Usage Records, Flow Data Files . . . . . . . . . . . . . . . . 29 5.2 Usage Records, Flow Data Files . . . . . . . . . . . . . . . . 29
5.3 Meter to Meter Reader: Usage Record Transmission . . . . . . 30 5.3 Meter to Meter Reader: Usage Record Transmission . . . . . . 30
6 Managers 30 6 Managers 31
6.1 Between Manager and Meter: Control Functions . . . . . . . . 30 6.1 Between Manager and Meter: Control Functions . . . . . . . . 31
6.2 Between Manager and Meter Reader: Control Functions . . . . . 31 6.2 Between Manager and Meter Reader: Control Functions . . . . . 32
6.3 Exception Conditions . . . . . . . . . . . . . . . . . . . . . 33 6.3 Exception Conditions . . . . . . . . . . . . . . . . . . . . . 33
6.4 Standard Rule Sets . . . . . . . . . . . . . . . . . . . . . . 34 6.4 Standard Rule Sets . . . . . . . . . . . . . . . . . . . . . . 34
7 Security Considerations 34 7 Security Considerations 35
7.1 Threat Analysis . . . . . . . . . . . . . . . . . . . . . . . 34 7.1 Threat Analysis . . . . . . . . . . . . . . . . . . . . . . . 35
7.2 Countermeasures . . . . . . . . . . . . . . . . . . . . . . . 35 7.2 Countermeasures . . . . . . . . . . . . . . . . . . . . . . . 36
8 APPENDICES 37 8 APPENDICES 38
8.1 Appendix A: Network Characterisation . . . . . . . . . . . . . 37 8.1 Appendix A: Network Characterisation . . . . . . . . . . . . . 38
8.2 Appendix B: Recommended Traffic Flow Measurement Capabilities 38 8.2 Appendix B: Recommended Traffic Flow Measurement Capabilities 39
8.3 Appendix C: List of Defined Flow Attributes . . . . . . . . . 39 8.3 Appendix C: List of Defined Flow Attributes . . . . . . . . . 40
8.4 Appendix D: List of Meter Control Variables . . . . . . . . . 40 8.4 Appendix D: List of Meter Control Variables . . . . . . . . . 41
8.5 Appendix E: Changes Introduced Since RFC 2063 . . . . . . . . 41
9 Acknowledgments 40 9 Acknowledgments 42
10 References 41 10 References 42
11 Author's Addresses 41 11 Author's Address 43
INTERNET-DRAFT Traffic Flow Measurement: Architecture July 98
1 Statement of Purpose and Scope 1 Statement of Purpose and Scope
This document describes an architecture for traffic flow measurement and 1.1 Brief Technical Specification (TS)
reporting for data networks which has the following characteristics:
RTFM provides for the measurement of network traffic FLOWS, i.e.
- a method of specifying traffic flows within
a network
- a hierarchy of devices (meters, meter readers, managers)
for measuring the specified flows
- a mechanism for configuring meters and meter readers,
and for collecting the flow data from remote meters
The RTFM Meter is designed so as to do as much data reduction work as
possible. This minimizes the amount of data to be read and the amount
of processing needed to produce useful reports from it.
RTFM flow data can be used for a wide range of purposes, such as usage
accounting, long-term recording of network usage (classified by IP
address attributes) and real-time analysis of traffic flows at remote
metering points.
1.2 Applicability Statement (AS)
To use RTFM for collecting network traffic information one must first
consider where in the network traffic flows are to be measured. Once
this is decided, an RTFM Meter must be installed at each chosen
measurement point.
At least one Meter Reader is needed to collect the measured data from
the meters, and a single Manager is needed to control the meters and
meter readers.
RTFM Meters may be single- or multi-user hosts running a meter program
(one such program is available as free software, a second is under
development at IBM Research). Alternatively, meters could be run as
firmware in switches or routers. A hybrid approach, where an RTFM meter
takes raw traffic data from a router, provides another useful
implementation path.
INTERNET-DRAFT Traffic Flow Measurement: Architecture July 98
RTFM Managers are programs running on a Unix host, communicating with
meters and meter readers via the network. In principle any protocol
could be used for this, but current implementations use the RTFM Meter
MIB [4] to store and access the flow data. This will require networks
using RTFM to implement the IP protocol so as to send and receive SNMP
requests carried in UDP datagrams.
As indicated above, a meter must handle SNMP over UDP. If it runs on a
dedicated host it must also respond to ARP requests. To aid in
troubleshooting, it should respond to ICMP echo (ping) requests. These
remarks also apply to RTFM Meter Readers and Managers.
(The paragraphs above describe the current implementations of RTFM.
Its architecture is not limited to having the meter be an SNMP agent -
other communication and storage methods could be used. For example,
configuration data could be downloaded via FTP, data could be stored in
an SQL database and meter readers could get it via SQL requests.)
Users of RTFM should note that installing meters, meter readers and
managers merely provides one with the capability to collect flow data.
Further installation work will be needed to develop configuration files
('RTFM rulesets') for each meter, data processing applications to
analyse the flow data, and various scripts, cron jobs, etc. so as to
create a useful production-quality measurement system which suits a
user's particular needs.
1.3 Introduction
This document describes an architecture for traffic flow measurement
and reporting for data networks; it has the following characteristics:
- The traffic flow model can be consistently applied to any - The traffic flow model can be consistently applied to any
protocol/application at any network layer (e.g. network, protocol/application at any network layer (e.g. network,
transport, application layers). transport, application layers).
- Traffic flow attributes are defined in such a way that they are - Traffic flow attributes are defined in such a way that they are
valid for multiple networking protocol stacks, and that traffic valid for multiple networking protocol stacks, and that traffic
flow measurement implementations are useful in MULTI-PROTOCOL flow measurement implementations are useful in MULTI-PROTOCOL
environments. environments.
- Users may specify their traffic flow measurement requirements by - Users may specify their traffic flow measurement requirements by
writing 'rule sets,' allowing them to collect the flow data they writing 'rule sets,' allowing them to collect the flow data they
need while ignoring other traffic. need while ignoring other traffic.
- The data reduction effort to produce requested traffic flow - The data reduction effort to produce requested traffic flow
information is placed as near as possible to the network information is placed as near as possible to the network
measurement point. This minimises the volume of data to be measurement point. This minimises the volume of data to be
INTERNET-DRAFT Traffic Flow Measurement: Architecture July 98
obtained (and transmitted across the network for storage), and obtained (and transmitted across the network for storage), and
reduces the amount of processing required in traffic flow analysis reduces the amount of processing required in traffic flow analysis
applications. applications.
The architecture specifies common metrics for measuring traffic flows. The architecture specifies common metrics for measuring traffic flows.
By using the same metrics, traffic flow data can be exchanged and By using the same metrics, traffic flow data can be exchanged and
compared across multiple platforms. Such data is useful for: compared across multiple platforms. Such data is useful for:
- Understanding the behaviour of existing networks, - Understanding the behaviour of existing networks,
skipping to change at page 4, line 30 skipping to change at page 6, line 5
A cost recovery structure decides "who pays for what." The major issue A cost recovery structure decides "who pays for what." The major issue
here is how to construct a tariff (who gets billed, how much, for which here is how to construct a tariff (who gets billed, how much, for which
things, based on what information, etc). Tariff issues include things, based on what information, etc). Tariff issues include
fairness, predictability (how well can subscribers forecast their fairness, predictability (how well can subscribers forecast their
network charges), practicality (of gathering the data and administering network charges), practicality (of gathering the data and administering
the tariff), incentives (e.g. encouraging off-peak use), and cost the tariff), incentives (e.g. encouraging off-peak use), and cost
recovery goals (100% recovery, subsidisation, profit making). Issues recovery goals (100% recovery, subsidisation, profit making). Issues
such as these are not covered here. such as these are not covered here.
INTERNET-DRAFT Traffic Flow Measurement: Architecture July 98
Background information explaining why this approach was selected is Background information explaining why this approach was selected is
provided by the 'Internet Accounting: Background' RFC [1]. provided by the 'Internet Accounting: Background' RFC [1].
1.1 Changes Introduced Since RFC 2063
The first version of the Traffic Flow Measurement Architecture was
published as RFC 2063 in January 1997. The most significant changes
made since then are summarised below.
- A Traffic Meter can now run multiple rule sets concurrently. This
makes a meter much more useful, and required only minimal changes
to the architecture.
- 'NoMatch' replaces 'Fail' as an action. This name was agreed to at
the Working Group 1996 meeting in Montreal; it better indicates
that although a particular match has failed, it may be tried again
with the packet's addresses reversed.
- The 'MatchingStoD' attribute has been added. This is a Packet
Matching Engine (PME) attribute indicating that addresses are being
matched in StoD (i.e. 'wire') order. It can be used to perform
different actions when the match is retried, thereby simplifying
some kinds of rule sets. It was discussed and agreed to at the San
Jose meeting in 1996.
- Computed attributes (Class and Kind) may now be tested within a
rule set. This lifts an unneccessary earlier restriction.
- The list of attribute numbers has been extended to define ranges
for 'basic' attributes (in this document) and 'extended' attributes
(currently being developed by the RTFM Working Group).
- The 'Security Considerations' section has been completely
rewritten. It provides an evaluation of traffic measurement
security risks and their countermeasures.
2 Traffic Flow Measurement Architecture 2 Traffic Flow Measurement Architecture
A traffic flow measurement system is used by Network Operations A traffic flow measurement system is used by Network Operations
personnel to aid in managing and developing a network. It provides a personnel to aid in managing and developing a network. It provides a
tool for measuring and understanding the network's traffic flows. This tool for measuring and understanding the network's traffic flows. This
information is useful for many purposes, as mentioned in section 1 information is useful for many purposes, as mentioned in section 1
(above). (above).
The following sections outline a model for traffic flow measurement, The following sections outline a model for traffic flow measurement,
which draws from working drafts of the OSI accounting model [2]. Future which draws from working drafts of the OSI accounting model [2]. Future
skipping to change at page 6, line 17 skipping to change at page 7, line 4
or connection. A flow is a portion of traffic, delimited by a start and or connection. A flow is a portion of traffic, delimited by a start and
stop time, that belongs to one of the metered traffic groups mentioned stop time, that belongs to one of the metered traffic groups mentioned
above. Attribute values (source/destination addresses, packet counts, above. Attribute values (source/destination addresses, packet counts,
byte counts, etc.) associated with a flow are aggregate quantities byte counts, etc.) associated with a flow are aggregate quantities
reflecting events which take place in the DURATION between the start and reflecting events which take place in the DURATION between the start and
stop times. The start time of a flow is fixed for a given flow; the stop times. The start time of a flow is fixed for a given flow; the
stop time may increase with the age of the flow. stop time may increase with the age of the flow.
For connectionless network protocols such as IP there is by definition For connectionless network protocols such as IP there is by definition
no way to tell whether a packet with a particular source/destination no way to tell whether a packet with a particular source/destination
INTERNET-DRAFT Traffic Flow Measurement: Architecture July 98
combination is part of a stream of packets or not - each packet is combination is part of a stream of packets or not - each packet is
completely independent. A traffic meter has, as part of its completely independent. A traffic meter has, as part of its
configuration, a set of 'rules' which specify the flows of interest, in configuration, a set of 'rules' which specify the flows of interest, in
terms of the values of their attributes. It derives attribute values terms of the values of their attributes. It derives attribute values
from each observed packet, and uses these to decide which flow they from each observed packet, and uses these to decide which flow they
belong to. Classifying packets into 'flows' in this way provides an belong to. Classifying packets into 'flows' in this way provides an
economical and practical way to measure network traffic and subdivide it economical and practical way to measure network traffic and subdivide it
into well-defined groups. into well-defined groups.
Usage information which is not derivable from traffic flows may also be Usage information which is not derivable from traffic flows may also be
skipping to change at page 7, line 14 skipping to change at page 8, line 4
- METER: Meters are placed at measurement points determined by - METER: Meters are placed at measurement points determined by
Network Operations personnel. Each meter selectively records Network Operations personnel. Each meter selectively records
network activity as directed by its configuration settings. It can network activity as directed by its configuration settings. It can
also aggregate, transform and further process the recorded activity also aggregate, transform and further process the recorded activity
before the data is stored. The processed and stored results are before the data is stored. The processed and stored results are
called the 'usage data.' called the 'usage data.'
- METER READER: A meter reader reliably transports usage data from - METER READER: A meter reader reliably transports usage data from
meters so that it is available to analysis applications. meters so that it is available to analysis applications.
INTERNET-DRAFT Traffic Flow Measurement: Architecture July 98
- ANALYSIS APPLICATION: An analysis application processes the usage - ANALYSIS APPLICATION: An analysis application processes the usage
data so as to provide information and reports which are useful for data so as to provide information and reports which are useful for
network engineering and management purposes. Examples include: network engineering and management purposes. Examples include:
- TRAFFIC FLOW MATRICES, showing the total flow rates for many of - TRAFFIC FLOW MATRICES, showing the total flow rates for many of
the possible paths within an internet. the possible paths within an internet.
- FLOW RATE FREQUENCY DISTRIBUTIONS, summarizing flow rates over - FLOW RATE FREQUENCY DISTRIBUTIONS, summarizing flow rates over
a period of time. a period of time.
skipping to change at page 8, line 18 skipping to change at page 9, line 5
meters. Each meter's configuration includes information such as: meters. Each meter's configuration includes information such as:
- Flow specifications, e.g. which traffic flows are to be measured, - Flow specifications, e.g. which traffic flows are to be measured,
how they are to be aggregated, and any data the meter is required how they are to be aggregated, and any data the meter is required
to compute for each flow being measured. to compute for each flow being measured.
- Meter control parameters, e.g. the 'inactivity' time for flows (if - Meter control parameters, e.g. the 'inactivity' time for flows (if
no packets belonging to a flow are seen for this time the flow is no packets belonging to a flow are seen for this time the flow is
considered to have ended, i.e. to have become idle). considered to have ended, i.e. to have become idle).
INTERNET-DRAFT Traffic Flow Measurement: Architecture July 98
- Sampling rate. Normally every packet will be observed. It may - Sampling rate. Normally every packet will be observed. It may
sometimes be necessary to use sampling techniques to observe only sometimes be necessary to use sampling techniques to observe only
some of the packets. (Sampling algorithms are not prescribed by some of the packets. (Sampling algorithms are not prescribed by
the architecture; it should be noted that before using sampling one the architecture; it should be noted that before using sampling one
should verify the statistical validity of the algorithm used). should verify the statistical validity of the algorithm used).
Current experience with the measurement architecture shows that a Current experience with the measurement architecture shows that a
carefully-designed and implemented meter compresses the data such carefully-designed and implemented meter compresses the data such
that in normal LANs and WANs of today sampling is really not that in normal LANs and WANs of today sampling is really not
needed. needed.
skipping to change at page 9, line 16 skipping to change at page 10, line 5
a particular rule set, flows which have been active since a given a particular rule set, flows which have been active since a given
time, etc.). time, etc.).
- Which attribute values are to be collected for the required flow - Which attribute values are to be collected for the required flow
records (e.g. all attributes, or a small subset of them) records (e.g. all attributes, or a small subset of them)
Since redundant reporting may be used in order to increase the Since redundant reporting may be used in order to increase the
reliability of usage data, exchanges among multiple entities must be reliability of usage data, exchanges among multiple entities must be
considered as well. These are discussed below. considered as well. These are discussed below.
INTERNET-DRAFT Traffic Flow Measurement: Architecture July 98
2.5 Multiple METERs or METER READERs 2.5 Multiple METERs or METER READERs
-- METER READER A -- -- METER READER A --
/ | \ / | \
/ | \ / | \
=====METER 1 METER 2=====METER 3 METER 4===== =====METER 1 METER 2=====METER 3 METER 4=====
\ | / \ | /
\ | / \ | /
-- METER READER B -- -- METER READER B --
skipping to change at page 10, line 13 skipping to change at page 11, line 5
usage data from the flows recorded by the old rule sets. usage data from the flows recorded by the old rule sets.
If there is only one meter reader and it fails, the meters continue to If there is only one meter reader and it fails, the meters continue to
run. When the meter reader is restarted it can collect all of the run. When the meter reader is restarted it can collect all of the
accumulated flow data. Should this happen, time resolution will be lost accumulated flow data. Should this happen, time resolution will be lost
(because of the missed collections) but overall traffic flow information (because of the missed collections) but overall traffic flow information
will not. The only exception to this would occur if the traffic volume will not. The only exception to this would occur if the traffic volume
was sufficient to 'roll over' counters for some flows during the was sufficient to 'roll over' counters for some flows during the
failure; this is addressed in the section on 'Rolling Counters.' failure; this is addressed in the section on 'Rolling Counters.'
INTERNET-DRAFT Traffic Flow Measurement: Architecture July 98
2.6 Interaction Between MANAGERs (MANAGER - MANAGER) 2.6 Interaction Between MANAGERs (MANAGER - MANAGER)
Synchronization between multiple management systems is the province of Synchronization between multiple management systems is the province of
network management protocols. This traffic flow measurement network management protocols. This traffic flow measurement
architecture specifies only the network management controls necessary to architecture specifies only the network management controls necessary to
perform the traffic flow measurement function and does not address the perform the traffic flow measurement function and does not address the
more global issues of simultaneous or interleaved (possibly conflicting) more global issues of simultaneous or interleaved (possibly conflicting)
commands from multiple network management stations or the process of commands from multiple network management stations or the process of
transferring control from one network management station to another. transferring control from one network management station to another.
skipping to change at page 11, line 10 skipping to change at page 12, line 5
"A TRAFFIC FLOW is an artifical logical equivalent to a call or "A TRAFFIC FLOW is an artifical logical equivalent to a call or
connection, belonging to a (user-specieied) METERED TRAFFIC connection, belonging to a (user-specieied) METERED TRAFFIC
GROUP." GROUP."
In practical terms, a flow is a stream of packets observed by the meter In practical terms, a flow is a stream of packets observed by the meter
as they pass across a network between two end points (or from a single as they pass across a network between two end points (or from a single
end point), which have been summarized by a traffic meter for analysis end point), which have been summarized by a traffic meter for analysis
purposes. purposes.
INTERNET-DRAFT Traffic Flow Measurement: Architecture July 98
3.1 Flows and their Attributes 3.1 Flows and their Attributes
Every traffic meter maintains a table of 'flow records' for flows seen Every traffic meter maintains a table of 'flow records' for flows seen
by the meter. A flow record holds the values of the ATTRIBUTES of by the meter. A flow record holds the values of the ATTRIBUTES of
interest for its flow. These attributes might include: interest for its flow. These attributes might include:
- ADDRESSES for the flow's source and destination. These comprise - ADDRESSES for the flow's source and destination. These comprise
the protocol type, the source and destination addresses at various the protocol type, the source and destination addresses at various
network layers (extracted from the packet header), and the number network layers (extracted from the packet header), and the number
of the interface on which the packet was observed. of the interface on which the packet was observed.
skipping to change at page 12, line 12 skipping to change at page 13, line 5
destination address = IP address 26.1.0.1" then only IP packets between destination address = IP address 26.1.0.1" then only IP packets between
10.1.0.1 and 26.1.0.1 would be counted in that flow. 10.1.0.1 and 26.1.0.1 would be counted in that flow.
The addresses specifying a flow's address attributes may include one or The addresses specifying a flow's address attributes may include one or
more of the following types: more of the following types:
- The INTERFACE NUMBER for the flow, i.e. the interface on which the - The INTERFACE NUMBER for the flow, i.e. the interface on which the
meter measured the traffic. Together with a unique address for the meter measured the traffic. Together with a unique address for the
meter this uniquely identifies a particular physical-level port. meter this uniquely identifies a particular physical-level port.
INTERNET-DRAFT Traffic Flow Measurement: Architecture July 98
- The ADJACENT ADDRESS, i.e. the [n-1] layer address of the - The ADJACENT ADDRESS, i.e. the [n-1] layer address of the
immediate source or destination on the path of the packet. For immediate source or destination on the path of the packet. For
example, if flow measurement is being performed at the IP layer on example, if flow measurement is being performed at the IP layer on
an Ethernet LAN [3], an adjacent address will normally be a an Ethernet LAN [3], an adjacent address will normally be a
six-octet Media Access Control (MAC) address. For a host connected six-octet Media Access Control (MAC) address. For a host connected
to the same LAN segment as the meter the adjacent address will be to the same LAN segment as the meter the adjacent address will be
the MAC address of that host. For hosts on other LAN segments it the MAC address of that host. For hosts on other LAN segments it
will be the MAC address of the adjacent (upstream or downstream) will be the MAC address of the adjacent (upstream or downstream)
router carrying the traffic flow. router carrying the traffic flow.
skipping to change at page 13, line 4 skipping to change at page 13, line 49
form of addresses differs for the various protocols, the meaning of a form of addresses differs for the various protocols, the meaning of a
'peer address' remains the same. It becomes harder to maintain this 'peer address' remains the same. It becomes harder to maintain this
correspondence at higher layers - for example, at the Network layer IP, correspondence at higher layers - for example, at the Network layer IP,
Novell IPX and AppleTalk all use port numbers as a 'transport address,' Novell IPX and AppleTalk all use port numbers as a 'transport address,'
but CLNP and DECnet have no notion of ports. Further work is needed but CLNP and DECnet have no notion of ports. Further work is needed
here, particularly in selecting attributes which will be suitable for here, particularly in selecting attributes which will be suitable for
the higher layers of the OSI reference model. the higher layers of the OSI reference model.
Reporting by adjacent intermediate sources and destinations or simply by Reporting by adjacent intermediate sources and destinations or simply by
meter interface (most useful when the meter is embedded in a router) meter interface (most useful when the meter is embedded in a router)
supports hierarchical Internet reporting schemes as described in the supports hierarchical Internet reporting schemes as described in the
'Internet Accounting: Background' RFC [1]. That is, it allows backbone 'Internet Accounting: Background' RFC [1]. That is, it allows backbone
and regional networks to measure usage to just the next lower level of and regional networks to measure usage to just the next lower level of
granularity (i.e. to the regional and stub/enterprise levels, granularity (i.e. to the regional and stub/enterprise levels,
respectively), with the final breakdown according to end user (e.g. to respectively), with the final breakdown according to end user (e.g. to
source IP address) performed by the stub/enterprise networks. source IP address) performed by the stub/enterprise networks.
INTERNET-DRAFT Traffic Flow Measurement: Architecture July 98
In cases where network addresses are dynamically allocated (e.g. mobile In cases where network addresses are dynamically allocated (e.g. mobile
subscribers), further subscriber identification will be necessary if subscribers), further subscriber identification will be necessary if
flows are to ascribed to individual users. Provision is made to further flows are to ascribed to individual users. Provision is made to further
specify the metered traffic group through the use of an optional specify the metered traffic group through the use of an optional
SUBSCRIBER ID as part of the flow id. A subscriber ID may be associated SUBSCRIBER ID as part of the flow id. A subscriber ID may be associated
with a particular flow either through the current rule set or by with a particular flow either through the current rule set or by
proprietary means within a meter, for example via protocol exchanges proprietary means within a meter, for example via protocol exchanges
with one or more (multi-user) hosts. At this time a subscriber ID is an with one or more (multi-user) hosts. At this time a subscriber ID is an
arbitrary text string; later versions of the architecture may specify arbitrary text string; later versions of the architecture may specify
its contents in more detail. its contents in more detail.
skipping to change at page 14, line 9 skipping to change at page 15, line 4
traffic group is known as the meter's CURRENT RULE SET. As will be traffic group is known as the meter's CURRENT RULE SET. As will be
shown, the meter's current rule set forms an integral part of the shown, the meter's current rule set forms an integral part of the
reported information, i.e. the recorded usage information cannot be reported information, i.e. the recorded usage information cannot be
properly interpreted without a definition of the rules used to collect properly interpreted without a definition of the rules used to collect
that information. that information.
Settings for these granularity factors may vary from meter to meter. Settings for these granularity factors may vary from meter to meter.
They are determined by the meter's current rule set, so they will change They are determined by the meter's current rule set, so they will change
if network Operations personnel reconfigure the meter to use a new rule if network Operations personnel reconfigure the meter to use a new rule
set. It is expected that the collection rules will change rather set. It is expected that the collection rules will change rather
INTERNET-DRAFT Traffic Flow Measurement: Architecture July 98
infrequently; nonetheless, the rule set in effect at any time must be infrequently; nonetheless, the rule set in effect at any time must be
identifiable via a RULE SET ID. Granularity of metered traffic groups is identifiable via a RULE SET ID. Granularity of metered traffic groups is
further specified by additional ATTRIBUTES. These attributes include: further specified by additional ATTRIBUTES. These attributes include:
- Attributes which record information derived from other attribute - Attributes which record information derived from other attribute
values. Six of these are defined (SourceClass, DestClass, values. Six of these are defined (SourceClass, DestClass,
FlowClass, SourceKind, DestKind, FlowKind), and their meaning is FlowClass, SourceKind, DestKind, FlowKind), and their meaning is
determined by the meter's rule set. For example, one could have a determined by the meter's rule set. For example, one could have a
subroutine in the rule set which determined whether a source or subroutine in the rule set which determined whether a source or
destination peer address was a member of an arbitrary list of destination peer address was a member of an arbitrary list of
skipping to change at page 15, line 5 skipping to change at page 16, line 5
a variable called InactivityTimeout, which specifies the minimum time a a variable called InactivityTimeout, which specifies the minimum time a
meter must wait before recovering the flow's record. In addition, meter must wait before recovering the flow's record. In addition,
before recovering a flow record the meter must be sure that the flow's before recovering a flow record the meter must be sure that the flow's
data has been collected by all meter readers which registered to collect data has been collected by all meter readers which registered to collect
it. it.
These 'lifetime' issues are considered further in the section on meter These 'lifetime' issues are considered further in the section on meter
readers (below). A complete list of the attributes currently defined is readers (below). A complete list of the attributes currently defined is
given in Appendix C later in this document. given in Appendix C later in this document.
INTERNET-DRAFT Traffic Flow Measurement: Architecture July 98
3.3 Rolling Counters, Timestamps, Report-in-One-Bucket-Only 3.3 Rolling Counters, Timestamps, Report-in-One-Bucket-Only
Once a usage record is sent, the decision needs to be made whether to Once a usage record is sent, the decision needs to be made whether to
clear any existing flow records or to maintain them and add to their clear any existing flow records or to maintain them and add to their
counts when recording subsequent traffic on the same flow. The second counts when recording subsequent traffic on the same flow. The second
method, called rolling counters, is recommended and has several method, called rolling counters, is recommended and has several
advantages. Its primary advantage is that it provides greater advantages. Its primary advantage is that it provides greater
reliability - the system can now often survive the loss of some usage reliability - the system can now often survive the loss of some usage
records, such as might occur if a meter reader failed and later records, such as might occur if a meter reader failed and later
restarted. The next usage record will very often contain yet another restarted. The next usage record will very often contain yet another
skipping to change at page 16, line 4 skipping to change at page 16, line 51
and it quickly reached a count of 1000. The total flow count from both and it quickly reached a count of 1000. The total flow count from both
the old and new records is 3000. the old and new records is 3000.
The flow START TIMESTAMP attribute is sufficient to resolve this. In The flow START TIMESTAMP attribute is sufficient to resolve this. In
the example above, the CONTINUING FLOW flow record in the second usage the example above, the CONTINUING FLOW flow record in the second usage
record has an old FLOW START timestamp, while the NEW FLOW contains a record has an old FLOW START timestamp, while the NEW FLOW contains a
recent FLOW START timestamp. recent FLOW START timestamp.
Each packet is counted in at most one flow for each running ruleset, so Each packet is counted in at most one flow for each running ruleset, so
as to avoid multiple counting of a single packet. The record of a as to avoid multiple counting of a single packet. The record of a
single flow is informally called a "bucket." If multiple, sometimes single flow is informally called a "bucket." If multiple, sometimes
overlapping, records of usage information are required (aggregate, overlapping, records of usage information are required (aggregate,
individual, etc), the network manager should collect the counts in individual, etc), the network manager should collect the counts in
sufficiently detailed granularity so that aggregate and combination sufficiently detailed granularity so that aggregate and combination
INTERNET-DRAFT Traffic Flow Measurement: Architecture July 98
counts can be reconstructed in post-processing of the raw usage data. counts can be reconstructed in post-processing of the raw usage data.
Alternatively, multiple rulesets could be used to collect data at Alternatively, multiple rulesets could be used to collect data at
different granularities. different granularities.
For example, consider a meter from which it is required to record both For example, consider a meter from which it is required to record both
'total packets coming in interface #1' and 'total packets arriving from 'total packets coming in interface #1' and 'total packets arriving from
any interface sourced by IP address = a.b.c.d,' using a single rule set. any interface sourced by IP address = a.b.c.d,' using a single rule set.
Although a bucket can be declared for each case, it is not clear how to Although a bucket can be declared for each case, it is not clear how to
handle a packet which satisfies both criteria. It must only be counted handle a packet which satisfies both criteria. It must only be counted
once. By default it will be counted in the first bucket for which it once. By default it will be counted in the first bucket for which it
skipping to change at page 17, line 5 skipping to change at page 18, line 5
Alternatively, the above could be achieved by running two rule sets (A Alternatively, the above could be achieved by running two rule sets (A
and B), as follows: and B), as follows:
Bucket 1: Packets which came in interface 1; Bucket 1: Packets which came in interface 1;
counted by rule set A. counted by rule set A.
Bucket 2: Packets which were sourcede by IP address a.b.c.d; Bucket 2: Packets which were sourcede by IP address a.b.c.d;
counted by rule set B. counted by rule set B.
INTERNET-DRAFT Traffic Flow Measurement: Architecture July 98
4 Meters 4 Meters
A traffic flow meter is a device for collecting data about traffic flows A traffic flow meter is a device for collecting data about traffic flows
at a given point within a network; we will call this the METERING POINT. at a given point within a network; we will call this the METERING POINT.
The header of every packet passing the network metering point is offered The header of every packet passing the network metering point is offered
to the traffic meter program. to the traffic meter program.
A meter could be implemented in various ways, including: A meter could be implemented in various ways, including:
- A dedicated small host, connected to a LAN (so that it can see all - A dedicated small host, connected to a LAN (so that it can see all
skipping to change at page 17, line 49 skipping to change at page 19, line 5
- The PME is a Virtual Machine running a pattern matching program - The PME is a Virtual Machine running a pattern matching program
contained in the CURRENT RULE SET. It is invoked by the Packet contained in the CURRENT RULE SET. It is invoked by the Packet
Processor, and returns instructions on what to do with the packet. Processor, and returns instructions on what to do with the packet.
- Some packets are classified as 'to be ignored.' They are discarded - Some packets are classified as 'to be ignored.' They are discarded
by the Packet Processor. by the Packet Processor.
- Other packets are matched by the PME, which returns a FLOW KEY - Other packets are matched by the PME, which returns a FLOW KEY
describing the flow to which the packet belongs. describing the flow to which the packet belongs.
INTERNET-DRAFT Traffic Flow Measurement: Architecture July 98
- The flow key is used to locate the flow's entry in the FLOW TABLE; - The flow key is used to locate the flow's entry in the FLOW TABLE;
a new entry is created when a flow is first seen. The entry's data a new entry is created when a flow is first seen. The entry's data
fields (e.g. packet and byte counters) are updated. fields (e.g. packet and byte counters) are updated.
- A meter reader may collect data from the flow table at any time. - A meter reader may collect data from the flow table at any time.
It may use the 'collect' index to locate the flows to be collected It may use the 'collect' index to locate the flows to be collected
within the flow table. within the flow table.
packet +------------------+ packet +------------------+
header | Current Rule Set | header | Current Rule Set |
skipping to change at page 19, line 5 skipping to change at page 20, line 5
single flow table with flows from all the rule sets. The overall effect single flow table with flows from all the rule sets. The overall effect
of doing this is somewhat similar to running several independent meters, of doing this is somewhat similar to running several independent meters,
one for each rule set. one for each rule set.
4.2 Flow Table 4.2 Flow Table
Every traffic meter maintains a table of TRAFFIC FLOW RECORDS for flows Every traffic meter maintains a table of TRAFFIC FLOW RECORDS for flows
seen by the meter. A flow record contains attribute values for its seen by the meter. A flow record contains attribute values for its
flow, including: flow, including:
INTERNET-DRAFT Traffic Flow Measurement: Architecture July 98
- Addresses for the flow's source and destination. These include - Addresses for the flow's source and destination. These include
addresses and masks for various network layers (extracted from the addresses and masks for various network layers (extracted from the
packet), and the identity of the interface on which the packet was packet), and the identity of the interface on which the packet was
observed. observed.
- First and last times when packets were seen for this flow. - First and last times when packets were seen for this flow.
- Counts for 'forward' (source to destination) and 'backward' - Counts for 'forward' (source to destination) and 'backward'
(destination to source) components of the flow's traffic. (destination to source) components of the flow's traffic.
skipping to change at page 19, line 44 skipping to change at page 21, line 4
- Extract attribute values from the packet header and use them to - Extract attribute values from the packet header and use them to
create a MATCH KEY for the packet. create a MATCH KEY for the packet.
- Match the packet's key against the current rule set, as explained - Match the packet's key against the current rule set, as explained
in detail below. in detail below.
The rule set specifies whether the packet is to be counted or ignored. The rule set specifies whether the packet is to be counted or ignored.
If it is to be counted the matching process produces a FLOW KEY for the If it is to be counted the matching process produces a FLOW KEY for the
flow to which the packet belongs. This flow key is used to find the flow to which the packet belongs. This flow key is used to find the
INTERNET-DRAFT Traffic Flow Measurement: Architecture July 98
flow's record in the flow table; if a record does not yet exist for this flow's record in the flow table; if a record does not yet exist for this
flow, a new flow record may be created. The data for the matching flow flow, a new flow record may be created. The data for the matching flow
record can then be updated. record can then be updated.
For example, the rule set could specify that packets to or from any host For example, the rule set could specify that packets to or from any host
in IP network 130.216 are to be counted. It could also specify that in IP network 130.216 are to be counted. It could also specify that
flow records are to be created for every pair of 24-bit (Class C) flow records are to be created for every pair of 24-bit (Class C)
subnets within network 130.216. subnets within network 130.216.
Each packet's match key is passed to the meter's PATTERN MATCHING ENGINE Each packet's match key is passed to the meter's PATTERN MATCHING ENGINE
skipping to change at page 21, line 5 skipping to change at page 22, line 5
this could happen would be a rule set which matches flows within this could happen would be a rule set which matches flows within
network X (Source = X, Dest = X) but specifies that flows are to be network X (Source = X, Dest = X) but specifies that flows are to be
created for each subnet within network X, say subnets y and z. If, created for each subnet within network X, say subnets y and z. If,
for example a packet is seen for y->z, the meter must check that for example a packet is seen for y->z, the meter must check that
flow z->y is not already current before creating y->z. flow z->y is not already current before creating y->z.
- The packet MATCHES IN ONE DIRECTION ONLY. If its flow is already - The packet MATCHES IN ONE DIRECTION ONLY. If its flow is already
current, its forward or reverse counters are incremented. current, its forward or reverse counters are incremented.
Otherwise it is added to the flow table and then counted. Otherwise it is added to the flow table and then counted.
INTERNET-DRAFT Traffic Flow Measurement: Architecture July 98
Ignore Ignore
--- match(S->D) -------------------------------------------------+ --- match(S->D) -------------------------------------------------+
| Suc | NoMatch | | Suc | NoMatch |
| | Ignore | | | Ignore |
| match(D->S) -----------------------------------------+ | match(D->S) -----------------------------------------+
| | Suc | NoMatch | | | Suc | NoMatch |
| | | | | | | |
| | +-------------------------------------------+ | | +-------------------------------------------+
| | | | | |
| | Suc | | | Suc |
skipping to change at page 22, line 5 skipping to change at page 23, line 5
'NoMatch' means that the packet did not match. It might, however 'NoMatch' means that the packet did not match. It might, however
match with its direction reversed, i.e. from B to A. match with its direction reversed, i.e. from B to A.
'Suc' means that the packet did match, i.e. it belongs to a flow 'Suc' means that the packet did match, i.e. it belongs to a flow
which is to be counted. which is to be counted.
current(A->B) succeeds if the flow A-to-B is current - i.e. has current(A->B) succeeds if the flow A-to-B is current - i.e. has
a record in the flow table whose state is Current - and fails a record in the flow table whose state is Current - and fails
otherwise. otherwise.
INTERNET-DRAFT Traffic Flow Measurement: Architecture July 98
create(A->B) adds the flow A-to-B to the flow table, setting the create(A->B) adds the flow A-to-B to the flow table, setting the
value for attributes - such as addresses - which remain constant, value for attributes - such as addresses - which remain constant,
and zeroing the flow's counters. and zeroing the flow's counters.
count(A->B,f) increments the 'forward' counters for flow A-to-B. count(A->B,f) increments the 'forward' counters for flow A-to-B.
count(A->B,r) increments the 'reverse' counters for flow A-to-B. count(A->B,r) increments the 'reverse' counters for flow A-to-B.
'Forward' here means the counters for packets travelling from 'Forward' here means the counters for packets travelling from
A to B. Note that count(A->B,f) is identical to count(B->A,r). A to B. Note that count(A->B,f) is identical to count(B->A,r).
When writing rule sets one must remember that the meter will normally When writing rule sets one must remember that the meter will normally
skipping to change at page 23, line 5 skipping to change at page 24, line 5
as an 'unusual' packet. as an 'unusual' packet.
To count such an 'unusual' packet we need to know the matching To count such an 'unusual' packet we need to know the matching
direction: the MatchingStoD attribute provides this. To use it, one direction: the MatchingStoD attribute provides this. To use it, one
follows the source address tests with a rule which tests whether the follows the source address tests with a rule which tests whether the
matching direction is S->D (MatchingStoD value is 1). If so, a matching direction is S->D (MatchingStoD value is 1). If so, a
'NoMatch' action is executed. Otherwise, the packet has failed to match 'NoMatch' action is executed. Otherwise, the packet has failed to match
in both directions; we can Push whatever attribute values are of in both directions; we can Push whatever attribute values are of
interest and count the 'unusual' packet. interest and count the 'unusual' packet.
INTERNET-DRAFT Traffic Flow Measurement: Architecture July 98
4.4 Rules and Rule Sets 4.4 Rules and Rule Sets
A rule set is an array of rules. Rule sets are held within a meter as A rule set is an array of rules. Rule sets are held within a meter as
entries in an array of rule sets. entries in an array of rule sets.
Rule set 1 (the first entry in the rule set table) is built-in to the Rule set 1 (the first entry in the rule set table) is built-in to the
meter and cannot be changed. It is run when the meter is started up, meter and cannot be changed. It is run when the meter is started up,
and provides a very coarse reporting granularity; it is mainly useful and provides a very coarse reporting granularity; it is mainly useful
for verifying that the meter is running, before a 'useful' rule set is for verifying that the meter is running, before a 'useful' rule set is
downloaded to it. downloaded to it.
skipping to change at page 24, line 5 skipping to change at page 25, line 5
Set the test indicator to this opcode's test flag value. Set the test indicator to this opcode's test flag value.
Determine the next rule to execute. Determine the next rule to execute.
If the opcode has its goto flag set, its parameter value If the opcode has its goto flag set, its parameter value
specifies the number of the next rule. specifies the number of the next rule.
Opcodes which don't have their goto flags set either Opcodes which don't have their goto flags set either
determine the next rule in special ways (Return), determine the next rule in special ways (Return),
or they terminate execution (Ignore, NoMatch, Count, or they terminate execution (Ignore, NoMatch, Count,
CountPkt). CountPkt).
Perform the action. Perform the action.
INTERNET-DRAFT Traffic Flow Measurement: Architecture July 98
The PME maintains two 'history' data structures. The first, the The PME maintains two 'history' data structures. The first, the
'return' stack, simply records the index (i.e. 1-origin rule number) of 'return' stack, simply records the index (i.e. 1-origin rule number) of
each Gosub rule as it is executed; Return rules pop their Gosub rule each Gosub rule as it is executed; Return rules pop their Gosub rule
index. The second, the 'pattern' queue, is used to save information for index. The second, the 'pattern' queue, is used to save information for
later use in building a flow key. A flow key is built by zeroing all later use in building a flow key. A flow key is built by zeroing all
its attribute values, then copying attribute and mask information from its attribute values, then copying attribute and mask information from
the pattern queue in the order it was enqueued. the pattern queue in the order it was enqueued.
The opcodes are: The opcodes are:
skipping to change at page 24, line 32 skipping to change at page 25, line 34
6 Gosub 1 1 6 Gosub 1 1
7 GosubAct 1 0 7 GosubAct 1 0
8 Assign 1 1 8 Assign 1 1
9 AssignAct 1 0 9 AssignAct 1 0
10 Goto 1 1 10 Goto 1 1
11 GotoAct 1 0 11 GotoAct 1 0
12 PushRuleTo 1 1 12 PushRuleTo 1 1
13 PushRuleToAct 1 0 13 PushRuleToAct 1 0
14 PushPktTo 1 1 14 PushPktTo 1 1
15 PushPktToAct 1 0 15 PushPktToAct 1 0
16 PopTo 1 1
17 PopToAct 1 0
The actions they perform are: The actions they perform are:
Ignore: Stop matching, return from the match() function Ignore: Stop matching, return from the match() function
indicating that the packet is to be ignored. indicating that the packet is to be ignored.
NoMatch: Stop matching, return from the match() function NoMatch: Stop matching, return from the match() function
indicating failure. indicating failure.
Count: Stop matching. Save this rule's attribute name, Count: Stop matching. Save this rule's attribute name,
skipping to change at page 25, line 5 skipping to change at page 26, line 5
construct a flow key for the flow to which this construct a flow key for the flow to which this
packet belongs. Return from the match() function packet belongs. Return from the match() function
indicating success. The meter will use the flow indicating success. The meter will use the flow
key to search for the flow record for this key to search for the flow record for this
packet's flow. packet's flow.
CountPkt: As for Count, except that the masked value from CountPkt: As for Count, except that the masked value from
the packet is saved in the PME's pattern queue the packet is saved in the PME's pattern queue
instead of the rule's value. instead of the rule's value.
INTERNET-DRAFT Traffic Flow Measurement: Architecture July 98
Gosub: Call a rule-matching subroutine. Push the current Gosub: Call a rule-matching subroutine. Push the current
rule number on the PME's return stack, set the rule number on the PME's return stack, set the
test indicator then goto the specified rule. test indicator then goto the specified rule.
GosubAct: Same as Gosub, except that the test indicator is GosubAct: Same as Gosub, except that the test indicator is
cleared before going to the specified rule. cleared before going to the specified rule.
Return: Return from a rule-matching subroutine. Pop the Return: Return from a rule-matching subroutine. Pop the
number of the calling gosub rule from the PME's number of the calling gosub rule from the PME's
'return' stack and add this rule's parameter value 'return' stack and add this rule's parameter value
skipping to change at page 25, line 55 skipping to change at page 27, line 5
PushRuleTo actions may be used to save the value PushRuleTo actions may be used to save the value
and mask used in a test, or (if the test is not and mask used in a test, or (if the test is not
performed) to save an arbitrary value and mask. performed) to save an arbitrary value and mask.
PushPktTo: Save this rule's attribute name, mask, and the PushPktTo: Save this rule's attribute name, mask, and the
masked value from the packet header, in the PME's masked value from the packet header, in the PME's
pattern queue. Set the test indicator then goto pattern queue. Set the test indicator then goto
the specified rule. the specified rule.
INTERNET-DRAFT Traffic Flow Measurement: Architecture July 98
PushPktToAct: Same as PushPktTo, except that the test indicator PushPktToAct: Same as PushPktTo, except that the test indicator
is cleared before going to the specified rule. is cleared before going to the specified rule.
PushPktTo actions may be used to save a value from PushPktTo actions may be used to save a value from
the packet using a specified mask. The test in the packet using a specified mask. The test in
PushPktTo rules will almost never be executed. PushPktTo rules will almost never be executed.
PopTo: Delete the most recent item from the pattern
queue, so as to remove the information saved by
an earlier 'push' action. Set the test indicator
then goto the specified rule.
PopToAct: Same as PopTo, except that the test indicator
is cleared before going to the specified rule.
As well as the attributes applying directly to packets (such as As well as the attributes applying directly to packets (such as
SourcePeerAddress, DestTransAddress, etc.) the PME implements several SourcePeerAddress, DestTransAddress, etc.) the PME implements several
further attribtes. These are: further attribtes. These are:
Null: Tests performed on the Null attribute always succeed. Null: Tests performed on the Null attribute always succeed.
MatchingStoD: Indicates whether the PME is matching the packet MatchingStoD: Indicates whether the PME is matching the packet
with its addresses in 'wire order' or with its with its addresses in 'wire order' or with its
addresses reversed. MatchingStoD's value is 1 if the addresses reversed. MatchingStoD's value is 1 if the
addresses are in wire order (StoD), and != 1 otherwise. addresses are in wire order (StoD), and != 1 otherwise.
skipping to change at page 26, line 38 skipping to change at page 28, line 5
attribute would actually test SourcePeerAddress. attribute would actually test SourcePeerAddress.
SourceClass, DestClass, FlowClass, SourceClass, DestClass, FlowClass,
SourceKind, DestKind, FlowKind: SourceKind, DestKind, FlowKind:
These six attributes may be set by executing PushRuleto These six attributes may be set by executing PushRuleto
actions. They allow the PME to save (in flow records) actions. They allow the PME to save (in flow records)
information which has been built up during matching. information which has been built up during matching.
Their values may be tested in rules; this allows one Their values may be tested in rules; this allows one
to set them early in a rule set, and test them later. to set them early in a rule set, and test them later.
INTERNET-DRAFT Traffic Flow Measurement: Architecture July 98
4.5 Maintaining the Flow Table 4.5 Maintaining the Flow Table
The flow table may be thought of as a 1-origin array of flow records. The flow table may be thought of as a 1-origin array of flow records.
(A particular implementation may, of course, use whatever data structure (A particular implementation may, of course, use whatever data structure
is most suitable). When the meter starts up there are no known flows; is most suitable). When the meter starts up there are no known flows;
all the flow records are in the 'inactive' state. all the flow records are in the 'inactive' state.
Each time a packet is matched for a flow which is not in a current flow Each time a packet is matched for a flow which is not in a current flow
set a flow record is created for it; the state of such a record is set a flow record is created for it; the state of such a record is
'current.' When selecting a record for the new flow the meter searches 'current.' When selecting a record for the new flow the meter searches
skipping to change at page 27, line 41 skipping to change at page 29, line 5
possible, which would be suitable if one was only interested in possible, which would be suitable if one was only interested in
measuring total traffic volumes. It could be implemented by having the measuring total traffic volumes. It could be implemented by having the
meter search for collected idle flows only when it ran low on 'inactive' meter search for collected idle flows only when it ran low on 'inactive'
flow records. flow records.
One further factor a meter should consider before recovering a flow is One further factor a meter should consider before recovering a flow is
the number of meter readers which have collected the flow's data. If the number of meter readers which have collected the flow's data. If
there are multiple meter readers operating, each reader should collect a there are multiple meter readers operating, each reader should collect a
flow's data before its memory is recovered. flow's data before its memory is recovered.
INTERNET-DRAFT Traffic Flow Measurement: Architecture July 98
4.6 Handling Increasing Traffic Levels 4.6 Handling Increasing Traffic Levels
Under normal conditions the meter reader specifies which set of usage Under normal conditions the meter reader specifies which set of usage
records it wants to collect, and the meter provides them. records it wants to collect, and the meter provides them.
If memory usage rises above the high-water mark the meter should switch If memory usage rises above the high-water mark the meter should switch
to a STANDBY RULE SET so as to decrease the rate at which new flows are to a STANDBY RULE SET so as to decrease the rate at which new flows are
created. When the manager, usually as part of a regular poll, becomes created. When the manager, usually as part of a regular poll, becomes
aware that the meter is using its standby rule set, it could decrease aware that the meter is using its standby rule set, it could decrease
the interval between collections. The meter should also increase its the interval between collections. The meter should also increase its
efforts to recover flow memory so as to reduce the number of idle flows efforts to recover flow memory so as to reduce the number of idle flows
in memory. When the situation returns to normal, the manager may in memory. When the situation returns to normal, the manager may
request the meter to switch back to its normal rule set. request the meter to switch back to its normal rule set.
5 Meter Readers 5 Meter Readers
Usage data is accumulated by a meter (e.g. in a router) as memory Usage data is accumulated by a meter (e.g. in a router) as memory
permits. It is collected at regular reporting intervals by meter permits. It is collected at regular reporting intervals by meter
readers, as specified by a manager. The collected data is recorded in a readers, as specified by a manager. The collected data is recorded in a
skipping to change at page 28, line 41 skipping to change at page 30, line 4
Note that the combination of start time, rule set id and subscript (row Note that the combination of start time, rule set id and subscript (row
number in the flow table) provide a unique flow identifier, regardless number in the flow table) provide a unique flow identifier, regardless
of the values of its other attributes. of the values of its other attributes.
The current rule set may specify additional information, e.g. a The current rule set may specify additional information, e.g. a
computed attribute value such as FlowKind, which is to be placed in the computed attribute value such as FlowKind, which is to be placed in the
attribute section of the usage record. That is, if a particular flow is attribute section of the usage record. That is, if a particular flow is
matched by the rule set, then the corresponding flow record should be matched by the rule set, then the corresponding flow record should be
marked not only with the qualifying identification attributes, but also marked not only with the qualifying identification attributes, but also
with the additional information. Using this feature, several flows may with the additional information. Using this feature, several flows may
INTERNET-DRAFT Traffic Flow Measurement: Architecture July 98
each carry the same FlowKind value, so that the resulting usage records each carry the same FlowKind value, so that the resulting usage records
can be used in post-processing or between meter reader and meter as a can be used in post-processing or between meter reader and meter as a
criterion for collection. criterion for collection.
5.2 Usage Records, Flow Data Files 5.2 Usage Records, Flow Data Files
The collected usage data will be stored in flow data files on the meter The collected usage data will be stored in flow data files on the meter
reader, one file for each meter. As well as containing the measured reader, one file for each meter. As well as containing the measured
usage data, flow data files must contain information uniquely usage data, flow data files must contain information uniquely
identifiying the meter from which it was collected. identifiying the meter from which it was collected.
skipping to change at page 29, line 46 skipping to change at page 31, line 4
The usage record contents are the raison d'etre of the system. The The usage record contents are the raison d'etre of the system. The
accuracy, reliability, and security of transmission are the primary accuracy, reliability, and security of transmission are the primary
concerns of the meter/meter reader exchange. Since errors may occur on concerns of the meter/meter reader exchange. Since errors may occur on
networks, and Internet packets may be dropped, some mechanism for networks, and Internet packets may be dropped, some mechanism for
ensuring that the usage information is transmitted intact is needed. ensuring that the usage information is transmitted intact is needed.
Flow data is moved from meter to meter reader via a series of protocol Flow data is moved from meter to meter reader via a series of protocol
exchanges between them. This may be carried out in various ways, moving exchanges between them. This may be carried out in various ways, moving
individual attribute values, complete flows, or the entire flow table individual attribute values, complete flows, or the entire flow table
INTERNET-DRAFT Traffic Flow Measurement: Architecture July 98
(i.e. all the active and idle flows). One possible method of achieving (i.e. all the active and idle flows). One possible method of achieving
this transfer is to use SNMP; the 'Traffic Flow Measurement: Meter MIB' this transfer is to use SNMP; the 'Traffic Flow Measurement: Meter MIB'
document [4] gives details. Note that this is simply one example; the document [4] gives details. Note that this is simply one example; the
transfer of flow data from meter to meter reader is not specified in transfer of flow data from meter to meter reader is not specified in
this document. this document.
The reliability of the data transfer method under light, normal, and The reliability of the data transfer method under light, normal, and
extreme network loads should be understood before selecting among extreme network loads should be understood before selecting among
collection methods. collection methods.
skipping to change at page 30, line 44 skipping to change at page 32, line 5
6.1 Between Manager and Meter: Control Functions 6.1 Between Manager and Meter: Control Functions
- DOWNLOAD RULE SET: A meter may hold an array of rule sets. One of - DOWNLOAD RULE SET: A meter may hold an array of rule sets. One of
these, the 'default' rule set, is built in to the meter and cannot these, the 'default' rule set, is built in to the meter and cannot
be changed; the others must be downloaded by the manager. A be changed; the others must be downloaded by the manager. A
manager may use any suitable protocol exchange to achieve this, for manager may use any suitable protocol exchange to achieve this, for
example an FTP file transfer or a series of SNMP SETs, one for each example an FTP file transfer or a series of SNMP SETs, one for each
row of the rule set. row of the rule set.
INTERNET-DRAFT Traffic Flow Measurement: Architecture July 98
- SPECIFY METER TASK: Once the rule sets have been downloaded, the - SPECIFY METER TASK: Once the rule sets have been downloaded, the
manager must instruct the meter which rule sets will be the manager must instruct the meter which rule sets will be the
'current' and 'standby' ones for each task the meter is to perform. 'current' and 'standby' ones for each task the meter is to perform.
- SET HIGH WATER MARK: A percentage of the flow table capacity, used - SET HIGH WATER MARK: A percentage of the flow table capacity, used
by the meter to determine when to switch to its standby rule set by the meter to determine when to switch to its standby rule set
(so as to increase the granularity of the flows and conserve the (so as to increase the granularity of the flows and conserve the
meter's flow memory). Once this has happened, the manager may also meter's flow memory). Once this has happened, the manager may also
change the polling frequency or the meter's control parameters (so change the polling frequency or the meter's control parameters (so
as to increase the rate at which the meter can recover memory from as to increase the rate at which the meter can recover memory from
skipping to change at page 31, line 43 skipping to change at page 33, line 4
a result of network traffic characteristics, it is desirable to have a result of network traffic characteristics, it is desirable to have
dynamic network management as opposed to static meter configurations. dynamic network management as opposed to static meter configurations.
Many of these operations have to do with space tradeoffs - if memory at Many of these operations have to do with space tradeoffs - if memory at
the meter is exhausted, either the collection interval must be decreased the meter is exhausted, either the collection interval must be decreased
or a coarser granularity of aggregation must be used to reduce the or a coarser granularity of aggregation must be used to reduce the
number of active flows. number of active flows.
Increasing the collection interval effectively stores data in the meter; Increasing the collection interval effectively stores data in the meter;
usage data in transit is limited by the effective bandwidth of the usage data in transit is limited by the effective bandwidth of the
virtual link between the meter and the meter reader, and since these virtual link between the meter and the meter reader, and since these
INTERNET-DRAFT Traffic Flow Measurement: Architecture July 98
limited network resources are usually also used to carry user data (the limited network resources are usually also used to carry user data (the
purpose of the network), the level of traffic flow measurement traffic purpose of the network), the level of traffic flow measurement traffic
should be kept to an affordable fraction of the bandwidth. should be kept to an affordable fraction of the bandwidth.
("Affordable" is a policy decision made by the Network Operations ("Affordable" is a policy decision made by the Network Operations
personnel). At any rate, it must be understood that the operations personnel). At any rate, it must be understood that the operations
below do not represent the setting of independent variables; on the below do not represent the setting of independent variables; on the
contrary, each of the values set has a direct and measurable effect on contrary, each of the values set has a direct and measurable effect on
the behaviour of the other variables. the behaviour of the other variables.
Network management operations follow: Network management operations follow:
skipping to change at page 32, line 44 skipping to change at page 34, line 5
- Determines the number of buckets into which user traffic will - Determines the number of buckets into which user traffic will
be lumped together. be lumped together.
Since granularity is controlled by the meter's current rule set, Since granularity is controlled by the meter's current rule set,
the manager can only change it by requesting the meter to switch to the manager can only change it by requesting the meter to switch to
a different rule set. The new rule set could be downloaded when a different rule set. The new rule set could be downloaded when
required, or it could have been downloaded as part of the meter's required, or it could have been downloaded as part of the meter's
initial configuration. initial configuration.
INTERNET-DRAFT Traffic Flow Measurement: Architecture July 98
- FLOW LIFETIME CONTROL: Flow termination parameters include timeout - FLOW LIFETIME CONTROL: Flow termination parameters include timeout
parameters for obsoleting inactive flows and removing them from parameters for obsoleting inactive flows and removing them from
tables, and maximum flow lifetimes. This is intertwined with tables, and maximum flow lifetimes. This is intertwined with
reporting interval and granularity, and must be set in accordance reporting interval and granularity, and must be set in accordance
with the other parameters. with the other parameters.
6.3 Exception Conditions 6.3 Exception Conditions
Exception conditions must be handled, particularly occasions when the Exception conditions must be handled, particularly occasions when the
meter runs out of space for flow data. Since - to prevent an active meter runs out of space for flow data. Since - to prevent an active
skipping to change at page 33, line 45 skipping to change at page 35, line 5
gathering usage records. gathering usage records.
- BUFFER PROBLEMS: The network manager may realise that there is a - BUFFER PROBLEMS: The network manager may realise that there is a
'low memory' condition in the meter. This can usually be 'low memory' condition in the meter. This can usually be
attributed to the interaction between the following controls: attributed to the interaction between the following controls:
- The reporting interval is too infrequent, or - The reporting interval is too infrequent, or
- The reporting granularity is too fine. - The reporting granularity is too fine.
INTERNET-DRAFT Traffic Flow Measurement: Architecture July 98
Either of these may be exacerbated by low throughput or bandwidth Either of these may be exacerbated by low throughput or bandwidth
of circuits carrying the usage data. The manager may change any of of circuits carrying the usage data. The manager may change any of
these parameters in response to the meter (or meter reader's) plea these parameters in response to the meter (or meter reader's) plea
for help. for help.
6.4 Standard Rule Sets 6.4 Standard Rule Sets
Although the rule table is a flexible tool, it can also become very Although the rule table is a flexible tool, it can also become very
complex. It may be helpful to develop some rule sets for common complex. It may be helpful to develop some rule sets for common
applications: applications:
skipping to change at page 34, line 43 skipping to change at page 36, line 5
detail about local usage and use an aggregate count for the shared detail about local usage and use an aggregate count for the shared
regional network. regional network.
7 Security Considerations 7 Security Considerations
7.1 Threat Analysis 7.1 Threat Analysis
A traffic flow measurement system may be subject to the following kinds A traffic flow measurement system may be subject to the following kinds
of attacks: of attacks:
INTERNET-DRAFT Traffic Flow Measurement: Architecture July 98
- UNAUTHORIZED USE OF SYSTEM RESOURCES: An attacker may wish to gain - UNAUTHORIZED USE OF SYSTEM RESOURCES: An attacker may wish to gain
advantage or cause mischief (e.g. denial of service) by subverting advantage or cause mischief (e.g. denial of service) by subverting
any of the system elements - meters, meter readers or managers. any of the system elements - meters, meter readers or managers.
- UNAUTHORIZED DISCLOSURE OF DATA: Any data that is sensitive to - UNAUTHORIZED DISCLOSURE OF DATA: Any data that is sensitive to
disclosure can be read through active or passive attacks unless it disclosure can be read through active or passive attacks unless it
is suitably protected. Usage data may or may not be of this type. is suitably protected. Usage data may or may not be of this type.
Control messages, traps, etc. are not likely to be considered Control messages, traps, etc. are not likely to be considered
sensitive to disclosure. sensitive to disclosure.
skipping to change at page 36, line 5 skipping to change at page 37, line 5
a high degree of protection is required, the use of strong cryptographic a high degree of protection is required, the use of strong cryptographic
methodologies is recommended. The security requirements for methodologies is recommended. The security requirements for
communication between pairs of traffic measurmement system elements are communication between pairs of traffic measurmement system elements are
summarized in the table below. It is assumed that meters do not summarized in the table below. It is assumed that meters do not
communicate with other meters, and that meter readers do not communicate communicate with other meters, and that meter readers do not communicate
directly with other meter readers (if synchronization is required, it is directly with other meter readers (if synchronization is required, it is
handled by the manager, see Section 2.5). Each entry in the table handled by the manager, see Section 2.5). Each entry in the table
indicates which kinds of security services are required. Basically, the indicates which kinds of security services are required. Basically, the
requirements are as follows: requirements are as follows:
INTERNET-DRAFT Traffic Flow Measurement: Architecture July 98
Security Service Requirements for RTFM elements Security Service Requirements for RTFM elements
+------------------------------------------------------------------+ +------------------------------------------------------------------+
| from\to | meter | meter reader | application | manager | | from\to | meter | meter reader | application | manager |
|---------+--------------+--------------+-------------+------------| |---------+--------------+--------------+-------------+------------|
| meter | N/A | authent | N/A | authent | | meter | N/A | authent | N/A | authent |
| | | acc ctrl | | acc ctrl | | | | acc ctrl | | acc ctrl |
| | | integrity | | | | | | integrity | | |
| | | confid ** | | | | | | confid ** | | |
|---------+--------------+--------------+-------------+------------| |---------+--------------+--------------+-------------+------------|
skipping to change at page 37, line 5 skipping to change at page 38, line 5
- Whenever there is a transfer of usage data it should be possible to - Whenever there is a transfer of usage data it should be possible to
ensure its confidentiality if it is deemed sensitive to disclosure. ensure its confidentiality if it is deemed sensitive to disclosure.
This is indicated by 'confid' in the table. This is indicated by 'confid' in the table.
Security protocols are not specified in this document. The system Security protocols are not specified in this document. The system
elements' management and collection protocols are responsible for elements' management and collection protocols are responsible for
providing sufficient data integrity, confidentiality, authentication and providing sufficient data integrity, confidentiality, authentication and
access control services. access control services.
INTERNET-DRAFT Traffic Flow Measurement: Architecture July 98
8 APPENDICES 8 APPENDICES
8.1 Appendix A: Network Characterisation 8.1 Appendix A: Network Characterisation
Internet users have extraordinarily diverse requirements. Networks Internet users have extraordinarily diverse requirements. Networks
differ in size, speed, throughput, and processing power, among other differ in size, speed, throughput, and processing power, among other
factors. There is a range of traffic flow measurement capabilities and factors. There is a range of traffic flow measurement capabilities and
requirements. For traffic flow measurement purposes, the Internet may requirements. For traffic flow measurement purposes, the Internet may
be viewed as a continuum which changes in character as traffic passes be viewed as a continuum which changes in character as traffic passes
through the following representative levels: through the following representative levels:
skipping to change at page 38, line 5 skipping to change at page 39, line 5
STUB/ENTERPRISE networks are SUBSCRIBERS to regional and backbone STUB/ENTERPRISE networks are SUBSCRIBERS to regional and backbone
networks. networks.
END SYSTEMS, colloquially HOSTS, are SUBSCRIBERS to any of the above END SYSTEMS, colloquially HOSTS, are SUBSCRIBERS to any of the above
networks. networks.
Providing a uniform identification of the SUBSCRIBER in finer Providing a uniform identification of the SUBSCRIBER in finer
granularity than that of end-system, (e.g. user/account), is beyond the granularity than that of end-system, (e.g. user/account), is beyond the
scope of the current architecture, although an optional attribute in the scope of the current architecture, although an optional attribute in the
INTERNET-DRAFT Traffic Flow Measurement: Architecture July 98
traffic flow measurement record may carry system-specific 'user traffic flow measurement record may carry system-specific 'user
identification' labels so that meters can implement proprietary or identification' labels so that meters can implement proprietary or
non-standard schemes for the attribution of network traffic to non-standard schemes for the attribution of network traffic to
responsible parties. responsible parties.
8.2 Appendix B: Recommended Traffic Flow Measurement Capabilities 8.2 Appendix B: Recommended Traffic Flow Measurement Capabilities
Initial recommended traffic flow measurement conventions are outlined Initial recommended traffic flow measurement conventions are outlined
here according to the following Internet building blocks. It is here according to the following Internet building blocks. It is
important to understand what complexity reporting introduces at each important to understand what complexity reporting introduces at each
skipping to change at page 39, line 5 skipping to change at page 40, line 5
will be enterprise networks, in which case the intermediate system will be enterprise networks, in which case the intermediate system
network address is sufficient to identify the regional's immediate network address is sufficient to identify the regional's immediate
subscriber. In other cases, individual hosts or a disjoint group of subscriber. In other cases, individual hosts or a disjoint group of
hosts may constitute a subscriber. Then end-system network address hosts may constitute a subscriber. Then end-system network address
pairs need to be tracked for those subscribers. When the source may be pairs need to be tracked for those subscribers. When the source may be
an aggregate entity (such as a network, or adjacent router representing an aggregate entity (such as a network, or adjacent router representing
traffic from a world of hosts beyond) and the destination is a singular traffic from a world of hosts beyond) and the destination is a singular
entity (or vice versa), the meter is said to be operating as a HYBRID entity (or vice versa), the meter is said to be operating as a HYBRID
system. system.
INTERNET-DRAFT Traffic Flow Measurement: Architecture July 98
At the regional level, if the overhead is tolerable it may be At the regional level, if the overhead is tolerable it may be
advantageous to report usage both by intermediate system network address advantageous to report usage both by intermediate system network address
(e.g. adjacent router address) and by end-system network address or (e.g. adjacent router address) and by end-system network address or
end-system network address pair. end-system network address pair.
BACKBONE networks are the highest level networks operating at higher BACKBONE networks are the highest level networks operating at higher
link speeds and traffic levels. The high volume of traffic will in most link speeds and traffic levels. The high volume of traffic will in most
cases preclude detailed traffic flow measurement. Backbone networks cases preclude detailed traffic flow measurement. Backbone networks
will usually account for traffic by adjacent routers' network addresses. will usually account for traffic by adjacent routers' network addresses.
skipping to change at page 40, line 4 skipping to change at page 41, line 4
19 Destination PeerAddress String 19 Destination PeerAddress String
20 Destination PeerMask String 20 Destination PeerMask String
21 Destination TransType Integer 21 Destination TransType Integer
22 Destination TransAddress String 22 Destination TransAddress String
23 Destination TransMask String 23 Destination TransMask String
26 Rule Set Number Integer Meter attribute 26 Rule Set Number Integer Meter attribute
27 Forward Bytes Integer Source-to-Dest counters 27 Forward Bytes Integer Source-to-Dest counters
28 Forward Packets Integer 28 Forward Packets Integer
INTERNET-DRAFT Traffic Flow Measurement: Architecture July 98
29 Reverse Bytes Integer Dest-to-Source counters 29 Reverse Bytes Integer Dest-to-Source counters
30 Reverse Packets Integer 30 Reverse Packets Integer
31 First Time Timestamp Activity times 31 First Time Timestamp Activity times
32 Last Active Time Timestamp 32 Last Active Time Timestamp
33 Source Subscriber ID String Session attributes 33 Source Subscriber ID String Session attributes
34 Destination Subscriber ID String 34 Destination Subscriber ID String
35 Session ID String 35 Session ID String
36 Source Class Integer 'Computed' attributes 36 Source Class Integer 'Computed' attributes
37 Destination Class Integer 37 Destination Class Integer
skipping to change at page 40, line 39 skipping to change at page 41, line 42
Inactivity Timeout (seconds) Integer Inactivity Timeout (seconds) Integer
'per task' variables: 'per task' variables:
Current Rule Set Number Integer Current Rule Set Number Integer
Standby Rule Set Number Integer Standby Rule Set Number Integer
High Water Mark Percentage High Water Mark Percentage
'per reader' variables: 'per reader' variables:
Reader Last Time Timestamp Reader Last Time Timestamp
8.5 Appendix E: Changes Introduced Since RFC 2063
The first version of the Traffic Flow Measurement Architecture was
published as RFC 2063 in January 1997. The most significant changes
made since then are summarised below.
- A Traffic Meter can now run multiple rule sets concurrently. This
makes a meter much more useful, and required only minimal changes
to the architecture.
INTERNET-DRAFT Traffic Flow Measurement: Architecture July 98
- 'NoMatch' replaces 'Fail' as an action. This name was agreed to at
the Working Group 1996 meeting in Montreal; it better indicates
that although a particular match has failed, it may be tried again
with the packet's addresses reversed.
- The 'MatchingStoD' attribute has been added. This is a Packet
Matching Engine (PME) attribute indicating that addresses are being
matched in StoD (i.e. 'wire') order. It can be used to perform
different actions when the match is retried, thereby simplifying
some kinds of rule sets. It was discussed and agreed to at the San
Jose meeting in 1996.
- Computed attributes (Class and Kind) may now be tested within a
rule set. This lifts an unneccessary earlier restriction.
- The list of attribute numbers has been extended to define ranges
for 'basic' attributes (in this document) and 'extended' attributes
(currently being developed by the RTFM Working Group).
- The 'Security Considerations' section has been completely
rewritten. It provides an evaluation of traffic measurement
security risks and their countermeasures.
9 Acknowledgments 9 Acknowledgments
An initial draft of this document was produced under the auspices of the An initial draft of this document was produced under the auspices of the
IETF's Internet Accounting Working Group with assistance from SNMP, RMON IETF's Internet Accounting Working Group with assistance from SNMP, RMON
and SAAG working groups. This version documents the implementation work and SAAG working groups. This version documents the implementation work
done by the Internet Accounting Working Group, and is intended to done by the Internet Accounting Working Group, and is intended to
provide a starting point for the Realtime Traffic Flow Measurement provide a starting point for the Realtime Traffic Flow Measurement
Working Group. Particular thanks are due to Stephen Stibler (IBM Working Group. Particular thanks are due to Stephen Stibler (IBM
Research) for his patient and careful comments during the preparation of Research) for his patient and careful comments during the preparation of
this draft. this draft.
skipping to change at page 41, line 16 skipping to change at page 43, line 5
[1] Mills, C., Hirsch, G. and Ruth, G., "Internet Accounting [1] Mills, C., Hirsch, G. and Ruth, G., "Internet Accounting
Background", RFC 1272, Bolt Beranek and Newman Inc., Meridian Background", RFC 1272, Bolt Beranek and Newman Inc., Meridian
Technology Corporation, November 1991. Technology Corporation, November 1991.
[2] International Standards Organisation (ISO), "Management [2] International Standards Organisation (ISO), "Management
Framework," Part 4 of Information Processing Systems Open Framework," Part 4 of Information Processing Systems Open
Systems Interconnection Basic Reference Model, ISO 7498-4, Systems Interconnection Basic Reference Model, ISO 7498-4,
1994. 1994.
INTERNET-DRAFT Traffic Flow Measurement: Architecture July 98
[3] IEEE 802.3/ISO 8802-3 Information Processing Systems - [3] IEEE 802.3/ISO 8802-3 Information Processing Systems -
Local Area Networks - Part 3: Carrier sense multiple access Local Area Networks - Part 3: Carrier sense multiple access
with collision detection (CSMA/CD) access method and physical with collision detection (CSMA/CD) access method and physical
layer specifications, 2nd edition, September 21, 1990. layer specifications, 2nd edition, September 21, 1990.
[4] Brownlee, N., "Traffic Flow Measurement: Meter MIB," [4] Brownlee, N., "Traffic Flow Measurement: Meter MIB,"
Internet Draft, 'Working draft' to become an experimental RFC. Internet Draft, 'Working draft' to become an experimental RFC.
11 Author's Addresses 11 Author's Addresses
skipping to change at line 1879 skipping to change at page 43, line 35
GTE Laboratories, Inc GTE Laboratories, Inc
Phone: +1 617 466 4278 Phone: +1 617 466 4278
E-mail: cmills@gte.com E-mail: cmills@gte.com
Greg Ruth Greg Ruth
GTE Laboratories, Inc GTE Laboratories, Inc
Phone: +1 617 466 2448 Phone: +1 617 466 2448
E-mail: gruth@gte.com E-mail: gruth@gte.com
Expires January 1999
 End of changes. 67 change blocks. 
78 lines changed or deleted 249 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/