draft-ietf-rtfm-architecture-03.txt   draft-ietf-rtfm-architecture-04.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 Sep 98
Expires January 1999 Expires Mar 99
Traffic Flow Measurement: Architecture Traffic Flow Measurement: Architecture
<draft-ietf-rtfm-architecture-03.txt> <draft-ietf-rtfm-architecture-04.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.
skipping to change at page 2, line ? skipping to change at page 2, line ?
ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim),
ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
Abstract Abstract
This document provides a general framework for describing network This document provides a general framework for describing network
traffic flows, presents an architecture for traffic flow measurement and traffic flows, presents an architecture for traffic flow measurement and
reporting, discusses how this relates to an overall network traffic flow reporting, discusses how this relates to an overall network traffic flow
architecture and indicates how it can be used within the Internet. architecture and indicates how it can be used within the Internet.
INTERNET-DRAFT Traffic Flow Measurement: Architecture Sep 98
Contents Contents
1 Statement of Purpose and Scope 3 1 Statement of Purpose and Scope 3
1.1 Brief Technical Specification (TS) . . . . . . . . . . . . . . 3 1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Applicability Statement (AS) . . . . . . . . . . . . . . . . . 3
1.3 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
INTERNET-DRAFT Traffic Flow Measurement: Architecture July 98
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.4 Interaction Between MANAGER and METER READER . . . . . . . . . 9
2.5 Multiple METERs or METER READERs . . . . . . . . . . . . . . . 9
2.6 Interaction Between MANAGERs (MANAGER - MANAGER) . . . . . . . 10
2.7 METER READERs and APPLICATIONs . . . . . . . . . . . . . . . . 11
3 Traffic Flows and Reporting Granularity 11
3.1 Flows and their Attributes . . . . . . . . . . . . . . . . . . 11
3.2 Granularity of Flow Measurements . . . . . . . . . . . . . . . 14
3.3 Rolling Counters, Timestamps, Report-in-One-Bucket-Only . . . 15
4 Meters 17 2 Traffic Flow Measurement Architecture 4
4.1 Meter Structure . . . . . . . . . . . . . . . . . . . . . . . 18 2.1 Meters and Traffic Flows . . . . . . . . . . . . . . . . . . . 5
4.2 Flow Table . . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.2 Interaction Between METER and METER READER . . . . . . . . . . 7
4.3 Packet Handling, Packet Matching . . . . . . . . . . . . . . . 20 2.3 Interaction Between MANAGER and METER . . . . . . . . . . . . 7
4.4 Rules and Rule Sets . . . . . . . . . . . . . . . . . . . . . 23 2.4 Interaction Between MANAGER and METER READER . . . . . . . . . 8
4.5 Maintaining the Flow Table . . . . . . . . . . . . . . . . . . 27 2.5 Multiple METERs or METER READERs . . . . . . . . . . . . . . . 8
4.6 Handling Increasing Traffic Levels . . . . . . . . . . . . . . 28 2.6 Interaction Between MANAGERs (MANAGER - MANAGER) . . . . . . . 9
2.7 METER READERs and APPLICATIONs . . . . . . . . . . . . . . . . 9
5 Meter Readers 29 3 Traffic Flows and Reporting Granularity 10
5.1 Identifying Flows in Flow Records . . . . . . . . . . . . . . 29 3.1 Flows and their Attributes . . . . . . . . . . . . . . . . . . 10
5.2 Usage Records, Flow Data Files . . . . . . . . . . . . . . . . 29 3.2 Granularity of Flow Measurements . . . . . . . . . . . . . . . 12
5.3 Meter to Meter Reader: Usage Record Transmission . . . . . . 30 3.3 Rolling Counters, Timestamps, Report-in-One-Bucket-Only . . . 14
6 Managers 31 4 Meters 16
6.1 Between Manager and Meter: Control Functions . . . . . . . . 31 4.1 Meter Structure . . . . . . . . . . . . . . . . . . . . . . . 16
6.2 Between Manager and Meter Reader: Control Functions . . . . . 32 4.2 Flow Table . . . . . . . . . . . . . . . . . . . . . . . . . . 18
6.3 Exception Conditions . . . . . . . . . . . . . . . . . . . . . 33 4.3 Packet Handling, Packet Matching . . . . . . . . . . . . . . . 18
6.4 Standard Rule Sets . . . . . . . . . . . . . . . . . . . . . . 34 4.4 Rules and Rule Sets . . . . . . . . . . . . . . . . . . . . . 22
4.5 Maintaining the Flow Table . . . . . . . . . . . . . . . . . . 26
4.6 Handling Increasing Traffic Levels . . . . . . . . . . . . . . 27
7 Security Considerations 35 5 Meter Readers 27
7.1 Threat Analysis . . . . . . . . . . . . . . . . . . . . . . . 35 5.1 Identifying Flows in Flow Records . . . . . . . . . . . . . . 27
7.2 Countermeasures . . . . . . . . . . . . . . . . . . . . . . . 36 5.2 Usage Records, Flow Data Files . . . . . . . . . . . . . . . . 28
5.3 Meter to Meter Reader: Usage Record Transmission . . . . . . . 29
8 APPENDICES 38 6 Managers 30
8.1 Appendix A: Network Characterisation . . . . . . . . . . . . . 38 6.1 Between Manager and Meter: Control Functions . . . . . . . . 30
8.2 Appendix B: Recommended Traffic Flow Measurement Capabilities 39 6.2 Between Manager and Meter Reader: Control Functions . . . . . 31
8.3 Appendix C: List of Defined Flow Attributes . . . . . . . . . 40 6.3 Exception Conditions . . . . . . . . . . . . . . . . . . . . . 32
8.4 Appendix D: List of Meter Control Variables . . . . . . . . . 41 6.4 Standard Rule Sets . . . . . . . . . . . . . . . . . . . . . . 33
8.5 Appendix E: Changes Introduced Since RFC 2063 . . . . . . . . 41
9 Acknowledgments 42 7 Security Considerations 34
7.1 Threat Analysis . . . . . . . . . . . . . . . . . . . . . . . 34
7.2 Countermeasures . . . . . . . . . . . . . . . . . . . . . . . 34
10 References 42 8 APPENDICES 36
8.1 Appendix A: Network Characterisation . . . . . . . . . . . . . 36
8.2 Appendix B: Recommended Traffic Flow Measurement Capabilities 37
8.3 Appendix C: List of Defined Flow Attributes . . . . . . . . . 38
8.4 Appendix D: List of Meter Control Variables . . . . . . . . . 39
8.5 Appendix E: Changes Introduced Since RFC 2063 . . . . . . . . 39
11 Author's Address 43 9 Acknowledgments 40
10 References 40
11 Author's Addresses 41
INTERNET-DRAFT Traffic Flow Measurement: Architecture July 98 INTERNET-DRAFT Traffic Flow Measurement: Architecture Sep 98
1 Statement of Purpose and Scope 1 Statement of Purpose and Scope
1.1 Brief Technical Specification (TS) 1.1 Introduction
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 This document describes an architecture for traffic flow measurement and
and reporting for data networks; it has the following characteristics: reporting for data networks which 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
skipping to change at page 5, line 4 skipping to change at page 3, line 31
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 5, line 28 skipping to change at page 4, line 4
- Quantification of network performance, - Quantification of network performance,
- Verifying the quality of network service, and - Verifying the quality of network service, and
- Attribution of network usage to users. - Attribution of network usage to users.
The traffic flow measurement architecture is deliberately structured so The traffic flow measurement architecture is deliberately structured so
that specific protocol implementations may extend coverage to that specific protocol implementations may extend coverage to
multi-protocol environments and to other protocol layers, such as usage multi-protocol environments and to other protocol layers, such as usage
INTERNET-DRAFT Traffic Flow Measurement: Architecture Sep 98
measurement for application-level services. Use of the same model for measurement for application-level services. Use of the same model for
both network- and application-level measurement may simplify the both network- and application-level measurement may simplify the
development of generic analysis applications which process and/or development of generic analysis applications which process and/or
correlate any or all levels of traffic and usage information. Within correlate any or all levels of traffic and usage information. Within
this docuemt the term 'usage data' is used as a generic term for the this docuemt the term 'usage data' is used as a generic term for the
data obtained using the traffic flow measurement architecture. data obtained using the traffic flow measurement architecture.
This document is not a protocol specification. It specifies and This document is not a protocol specification. It specifies and
structures the information that a traffic flow measurement system needs structures the information that a traffic flow measurement system needs
to collect, describes requirements that such a system must meet, and to collect, describes requirements that such a system must meet, and
skipping to change at page 6, line 5 skipping to change at page 4, line 35
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].
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
extensions are anticipated as the model is refined to address additional extensions are anticipated as the model is refined to address additional
protocol layers. protocol layers.
INTERNET-DRAFT Traffic Flow Measurement: Architecture Sep 98
2.1 Meters and Traffic Flows 2.1 Meters and Traffic Flows
At the heart of the traffic measurement model are network entities At the heart of the traffic measurement model are network entities
called traffic METERS. Meters observe packets as they pass by a single called traffic METERS. Meters observe packets as they pass by a single
point on their way through the network and classify them into certain point on their way through the network and classify them into certain
groups. For each such group a meter will accumulate certain attributes, groups. For each such group a meter will accumulate certain attributes,
for example the numbers of packets and bytes observed for the group. for example the numbers of packets and bytes observed for the group.
These METERED TRAFFIC GROUPS may correspond to a user, a host system, a These METERED TRAFFIC GROUPS may correspond to a user, a host system, a
network, a group of networks, a particular transport address (e.g. an network, a group of networks, a particular transport address (e.g. an
IP port number), any combination of the above, etc, depending on the IP port number), any combination of the above, etc, depending on the
skipping to change at page 7, line 4 skipping to change at page 5, line 37
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
of interest. For example, an application may wish to record accesses to of interest. For example, an application may wish to record accesses to
various different information resources or a host may wish to record the various different information resources or a host may wish to record the
username (subscriber id) for a particular network session. Provision is username (subscriber id) for a particular network session. Provision is
made in the traffic flow architecture to do this. In the future the made in the traffic flow architecture to do this. In the future the
measurement model may be extended to gather such information from measurement model may be extended to gather such information from
applications and hosts so as to provide values for higher-layer flow applications and hosts so as to provide values for higher-layer flow
attributes. attributes.
As well as FLOWS and METERS, the traffic flow measurement model includes As well as FLOWS and METERS, the traffic flow measurement model includes
MANAGERS, METER READERS and ANALYSIS APPLICAIONS, which are explained in MANAGERS, METER READERS and ANALYSIS APPLICAIONS, which are explained in
INTERNET-DRAFT Traffic Flow Measurement: Architecture Sep 98
following sections. The relationships between them are shown by the following sections. The relationships between them are shown by the
diagram below. Numbers on the diagram refer to sections in this diagram below. Numbers on the diagram refer to sections in this
document. document.
MANAGER MANAGER
/ \ / \
2.3 / \ 2.4 2.3 / \ 2.4
/ \ / \
/ \ ANALYSIS / \ ANALYSIS
METER <-----> METER READER <-----> APPLICATION METER <-----> METER READER <-----> APPLICATION
skipping to change at page 8, line 5 skipping to change at page 6, line 36
- 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.
- USAGE DATA showing the total traffic volumes sent and received - USAGE DATA showing the total traffic volumes sent and received
by particular hosts. by particular hosts.
The operation of the traffic measurement system as a whole is best The operation of the traffic measurement system as a whole is best
understood by considering the interactions between its components. understood by considering the interactions between its components.
These are described in the following sections. These are described in the following sections.
INTERNET-DRAFT Traffic Flow Measurement: Architecture Sep 98
2.2 Interaction Between METER and METER READER 2.2 Interaction Between METER and METER READER
The information which travels along this path is the usage data itself. The information which travels along this path is the usage data itself.
A meter holds usage data in an array of flow data records known as the A meter holds usage data in an array of flow data records known as the
FLOW TABLE. A meter reader may collect the data in any suitable manner. FLOW TABLE. A meter reader may collect the data in any suitable manner.
For example it might upload a copy of the whole flow table using a file For example it might upload a copy of the whole flow table using a file
transfer protocol, or read the records in the current flow set one at a transfer protocol, or read the records in the current flow set one at a
time using a suitable data transfer protocol. Note that the meter time using a suitable data transfer protocol. Note that the meter
reader need not read complete flow data records, a subset of their reader need not read complete flow data records, a subset of their
attribute values may well be sufficient. attribute values may well be sufficient.
skipping to change at page 9, line 5 skipping to change at page 7, line 35
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.
A meter may run several rule sets concurrently on behalf of one or more A meter may run several rule sets concurrently on behalf of one or more
managers, and any manager may download a set of flow specifications managers, and any manager may download a set of flow specifications
(i.e. a 'rule set') to a meter. Control parameters which apply to an (i.e. a 'rule set') to a meter. Control parameters which apply to an
individual rule set should be set by the manager after it downloads that individual rule set should be set by the manager after it downloads that
rule set. rule set.
INTERNET-DRAFT Traffic Flow Measurement: Architecture Sep 98
One manager should be designated as the 'master' for a meter. One manager should be designated as the 'master' for a meter.
Parameters such as sampling rate, which affect the overall operation of Parameters such as sampling rate, which affect the overall operation of
the meter, should only be set by the master manager. the meter, should only be set by the master manager.
2.4 Interaction Between MANAGER and METER READER 2.4 Interaction Between MANAGER and METER READER
A manager is responsible for configuring and controlling one or more A manager is responsible for configuring and controlling one or more
meter readers. A meter reader may only be controlled by a single meter readers. A meter reader may only be controlled by a single
manager. A meter reader needs to know at least the following for every manager. A meter reader needs to know at least the following for every
meter it is collecting usage data from: meter it is collecting usage data from:
skipping to change at page 10, line 5 skipping to change at page 8, line 33
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 --
Several uniquely identified meters may report to one or more meter Several uniquely identified meters may report to one or more meter
readers. The diagram above gives an example of how multiple meters and readers. The diagram above gives an example of how multiple meters and
meter readers could be used. meter readers could be used.
In the diagram above meter 1 is read by meter reader A, and meter 4 is In the diagram above meter 1 is read by meter reader A, and meter 4 is
read by meter reader B. Meters 1 and 4 have no redundancy; if either read by meter reader B. Meters 1 and 4 have no redundancy; if either
meter fails, usage data for their network segments will be lost. meter fails, usage data for their network segments will be lost.
INTERNET-DRAFT Traffic Flow Measurement: Architecture Sep 98
Meters 2 and 3, however, measure traffic on the same network segment. Meters 2 and 3, however, measure traffic on the same network segment.
One of them may fail leaving the other collecting the segment's usage One of them may fail leaving the other collecting the segment's usage
data. Meters 2 and 3 are read by meter reader A and by meter reader B. data. Meters 2 and 3 are read by meter reader A and by meter reader B.
If one meter reader fails, the other will continue collecting usage data If one meter reader fails, the other will continue collecting usage data
from both meters. from both meters.
The architecture does not require multiple meter readers to be The architecture does not require multiple meter readers to be
synchronized. In the situation above meter readers A and B could both synchronized. In the situation above meter readers A and B could both
collect usage data at the same intervals, but not neccesarily at the collect usage data at the same intervals, but not neccesarily at the
same times. Note that because collections are asynchronous it is same times. Note that because collections are asynchronous it is
skipping to change at page 11, line 5 skipping to change at page 9, line 33
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.
2.7 METER READERs and APPLICATIONs 2.7 METER READERs and APPLICATIONs
Once a collection of usage data has been assembled by a meter reader it Once a collection of usage data has been assembled by a meter reader it
can be processed by an analysis application. Details of analysis can be processed by an analysis application. Details of analysis
applications - such as the reports they produce and the data they applications - such as the reports they produce and the data they
require - are outside the scope of this architecture. require - are outside the scope of this architecture.
It should be noted, however, that analysis applications will often It should be noted, however, that analysis applications will often
require considerable amounts of input data. An important part of require considerable amounts of input data. An important part of
running a traffic flow measurement system is the storage and regular running a traffic flow measurement system is the storage and regular
INTERNET-DRAFT Traffic Flow Measurement: Architecture Sep 98
reduction of flow data so as to produce daily, weekly or monthly summary reduction of flow data so as to produce daily, weekly or monthly summary
files for further analysis. Again, details of such data handling are files for further analysis. Again, details of such data handling are
outside the scope of this architecture. outside the scope of this architecture.
3 Traffic Flows and Reporting Granularity 3 Traffic Flows and Reporting Granularity
A flow was defined in section 2.1 above in abstract terms as follows: A flow was defined in section 2.1 above in abstract terms as follows:
"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 32 skipping to change at page 11, line 5
(destination to source) components (e.g. packets and bytes) of the (destination to source) components (e.g. packets and bytes) of the
flow's traffic. The specifying of 'source' and 'destination' for flow's traffic. The specifying of 'source' and 'destination' for
flows is discussed in the section on packet matching below. flows is discussed in the section on packet matching below.
- OTHER attributes, e.g. the index of the flow's record in the flow - OTHER attributes, e.g. the index of the flow's record in the flow
table and the rule set id for the rules which the meter was running table and the rule set id for the rules which the meter was running
while the flow was observed. The values of these attributes while the flow was observed. The values of these attributes
provide a way of distinguishing flows observed by a meter at provide a way of distinguishing flows observed by a meter at
different times. different times.
INTERNET-DRAFT Traffic Flow Measurement: Architecture Sep 98
The attributes listed in this document (Appendix C) provide a basic The attributes listed in this document (Appendix C) provide a basic
(i.e. useful minimum) set; they are assigned attribute numbers in the (i.e. useful minimum) set; they are assigned attribute numbers in the
range 0 to 63. The RTFM working group is working on an extended set of range 0 to 63. The RTFM working group is working on an extended set of
attributes, which will have numbers in the range 64 to 127. attributes, which will have numbers in the range 64 to 127.
Implementors wishing to experiment with further new attributes should Implementors wishing to experiment with further new attributes should
use attribute numbers 128 and above. use attribute numbers 128 and above.
A flow's METERED TRAFFIC GROUP is specified by the values of its ADDRESS A flow's METERED TRAFFIC GROUP is specified by the values of its ADDRESS
attributes. For example, if a flow's address attributes specified only attributes. For example, if a flow's address attributes specified only
that "source address = IP address 10.1.0.1," then all IP packets from that "source address = IP address 10.1.0.1," then all IP packets from
skipping to change at page 13, line 5 skipping to change at page 11, line 29
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 35 skipping to change at page 12, line 5
address is a two-octet UDP or TCP port number. address is a two-octet UDP or TCP port number.
The four definitions above specify addresses for each of the four lowest The four definitions above specify addresses for each of the four lowest
layers of the OSI reference model, i.e. Physical layer, Link layer, layers of the OSI reference model, i.e. Physical layer, Link layer,
Network layer and Transport layer. A FLOW RECORD stores both the VALUE Network layer and Transport layer. A FLOW RECORD stores both the VALUE
for each of its addresses (as described above) and a MASK specifying for each of its addresses (as described above) and a MASK specifying
which bits of the address value are being used and which are ignored. which bits of the address value are being used and which are ignored.
Note that if address bits are being ignored the meter will set them to Note that if address bits are being ignored the meter will set them to
zero, however their actual values are undefined. zero, however their actual values are undefined.
INTERNET-DRAFT Traffic Flow Measurement: Architecture Sep 98
One of the key features of the traffic measurement architecture is that One of the key features of the traffic measurement architecture is that
attributes have essentially the same meaning for different protocols, so attributes have essentially the same meaning for different protocols, so
that analysis applications can use the same reporting formats for all that analysis applications can use the same reporting formats for all
protocols. This is straightforward for peer addresses; although the protocols. This is straightforward for peer addresses; although the
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
skipping to change at page 14, line 5 skipping to change at page 12, line 28
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 34 skipping to change at page 13, line 5
detail. Thus, the number of flows measured (and stored) at a meter can detail. Thus, the number of flows measured (and stored) at a meter can
be regulated by changing the granularity of their attributes. Flows are be regulated by changing the granularity of their attributes. Flows are
like an adjustable pipe - many fine-granularity streams can carry the like an adjustable pipe - many fine-granularity streams can carry the
data with each stream measured individually, or data can be bundled in data with each stream measured individually, or data can be bundled in
one coarse-granularity pipe. Time granularity may be controlled by one coarse-granularity pipe. Time granularity may be controlled by
varying the reporting interval, i.e. the time between meter readings. varying the reporting interval, i.e. the time between meter readings.
Flow granularity is controlled by adjusting the level of detail for the Flow granularity is controlled by adjusting the level of detail for the
following: following:
INTERNET-DRAFT Traffic Flow Measurement: Architecture Sep 98
- The metered traffic group (address attributes, discussed above). - The metered traffic group (address attributes, discussed above).
- The categorisation of packets (other attributes, discussed below). - The categorisation of packets (other attributes, discussed below).
- The lifetime/duration of flows (the reporting interval needs to be - The lifetime/duration of flows (the reporting interval needs to be
short enough to measure them with sufficient precision). short enough to measure them with sufficient precision).
The set of rules controlling the determination of each packet's metered The set of rules controlling the determination of each packet's metered
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 37 skipping to change at page 14, line 4
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. set.
The LIFETIME of a flow is the time interval which began when the meter The LIFETIME of a flow is the time interval which began when the meter
observed the first packet belonging to the flow and ended when it saw observed the first packet belonging to the flow and ended when it saw
the last packet. Flow lifetimes are very variable, but many - if not the last packet. Flow lifetimes are very variable, but many - if not
most - are rather short. A meter cannot measure lifetimes directly; most - are rather short. A meter cannot measure lifetimes directly;
instead a meter reader collects usage data for flows which have been instead a meter reader collects usage data for flows which have been
active since the last collection, and an analysis application may active since the last collection, and an analysis application may
INTERNET-DRAFT Traffic Flow Measurement: Architecture Sep 98
compare the data from each collection so as to determine when each flow compare the data from each collection so as to determine when each flow
actually stopped. actually stopped.
The meter does, however, need to reclaim memory (i.e. records in the The meter does, however, need to reclaim memory (i.e. records in the
flow table) being held by idle flows. The meter configuration includes flow table) being held by idle flows. The meter configuration includes
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 38 skipping to change at page 15, line 4
start time = 1 start time = 1 start time = 1 start time = 1
Usage record N: flow count = 2000 flow count = 2000 (done) Usage record N: flow count = 2000 flow count = 2000 (done)
start time = 1 start time = 5 start time = 1 start time = 5
Usage record N+1: flow count = 3000 new flow count = 1000 Usage record N+1: flow count = 3000 new flow count = 1000
Total count: 3000 3000 Total count: 3000 3000
In the continuing flow case, the same flow was reported when its count In the continuing flow case, the same flow was reported when its count
was 2000, and again at 3000: the total count to date is 3000. In the was 2000, and again at 3000: the total count to date is 3000. In the
INTERNET-DRAFT Traffic Flow Measurement: Architecture Sep 98
OLD/NEW case, the old flow had a count of 2000. Its record was then OLD/NEW case, the old flow had a count of 2000. Its record was then
stopped (perhaps because of temporary idleness), but then more traffic stopped (perhaps because of temporary idleness), but then more traffic
with the same characteristics arrived so a new flow record was started with the same characteristics arrived so a new flow record was started
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 38 skipping to change at page 16, line 4
Bucket 3: Packets which did NOT come in interface 1, Bucket 3: Packets which did NOT come in interface 1,
AND were sourced by IP address a.b.c.d AND were sourced by IP address a.b.c.d
(Bucket 4: Packets which did NOT come in interface 1, (Bucket 4: Packets which did NOT come in interface 1,
AND NOT sourced by IP address a.b.c.d) AND NOT sourced by IP address a.b.c.d)
The desired information can now be reconstructed by post-processing. The desired information can now be reconstructed by post-processing.
"Total packets coming in interface 1" can be found by adding buckets 1 & "Total packets coming in interface 1" can be found by adding buckets 1 &
2, and "Total packets sourced by IP address a.b.c.d" can be found by 2, and "Total packets sourced by IP address a.b.c.d" can be found by
adding buckets 1 & 3. Note that in this case bucket 4 is not explicitly adding buckets 1 & 3. Note that in this case bucket 4 is not explicitly
INTERNET-DRAFT Traffic Flow Measurement: Architecture Sep 98
required since its information is not of interest, but it is supplied required since its information is not of interest, but it is supplied
here in parentheses for completeness. here in parentheses for completeness.
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 18, line 38 skipping to change at page 17, line 5
4.1 Meter Structure 4.1 Meter Structure
An outline of the meter's structure is given in the following diagram: An outline of the meter's structure is given in the following diagram:
Briefly, the meter works as follows: Briefly, the meter works as follows:
- Incoming packet headers arrive at the top left of the diagram and - Incoming packet headers arrive at the top left of the diagram and
are passed to the PACKET PROCESSOR. are passed to the PACKET PROCESSOR.
INTERNET-DRAFT Traffic Flow Measurement: Architecture Sep 98
- The packet processor passes them to the Packet Matching Engine - The packet processor passes them to the Packet Matching Engine
(PME) where they are classified. (PME) where they are classified.
- 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 42 skipping to change at page 18, line 5
| | | |
+--------+--------+ +--------+--------+
| |
+--------*--------+ +--------*--------+
| 'Collect' index | | 'Collect' index |
+--------+--------+ +--------+--------+
| |
* *
Meter Reader Meter Reader
INTERNET-DRAFT Traffic Flow Measurement: Architecture Sep 98
The discussion above assumes that a meter will only be running a single The discussion above assumes that a meter will only be running a single
rule set. A meter may, however, run several rule sets concurrently. To rule set. A meter may, however, run several rule sets concurrently. To
do this the meter maintains a table of current rulesets. The packet do this the meter maintains a table of current rulesets. The packet
processor matches each packet against every current ruleset, producing a processor matches each packet against every current ruleset, producing a
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 20, line 37 skipping to change at page 19, line 5
- IDLE: The record is in use and the flow which it describes is part - IDLE: The record is in use and the flow which it describes is part
of the current flow set. In addition, no packets belonging to this of the current flow set. In addition, no packets belonging to this
flow have been seen for a period specified by the meter's flow have been seen for a period specified by the meter's
InactivityTime variable. InactivityTime variable.
4.3 Packet Handling, Packet Matching 4.3 Packet Handling, Packet Matching
Each packet header received by the traffic meter program is processed as Each packet header received by the traffic meter program is processed as
follows: follows:
INTERNET-DRAFT Traffic Flow Measurement: Architecture Sep 98
- 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 47 skipping to change at page 20, line 5
The diagram below describes the algorithm used by the traffic meter to The diagram below describes the algorithm used by the traffic meter to
process each packet. Flow through the diagram is from left to right and process each packet. Flow through the diagram is from left to right and
top to bottom, i.e. from the top left corner to the bottom right top to bottom, i.e. from the top left corner to the bottom right
corner. S indicates the flow's source address (i.e. its set of source corner. S indicates the flow's source address (i.e. its set of source
address attribute values) from the packet header, and D indicates its address attribute values) from the packet header, and D indicates its
destination address. destination address.
There are several cases to consider. These are: There are several cases to consider. These are:
INTERNET-DRAFT Traffic Flow Measurement: Architecture Sep 98
- The packet is recognised as one which is TO BE IGNORED. - The packet is recognised as one which is TO BE IGNORED.
- The packet would MATCH IN EITHER DIRECTION. One situation in which - The packet would MATCH IN EITHER DIRECTION. One situation in which
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 44 skipping to change at page 21, line 5
match(A->B) implements the PME. It uses the meter's current rule set match(A->B) implements the PME. It uses the meter's current rule set
to match the attribute values in the packet's match key. A->B means to match the attribute values in the packet's match key. A->B means
that the assumed source address is A and destination address B, i.e. that the assumed source address is A and destination address B, i.e.
that the packet was travelling from A to B. match() returns one of that the packet was travelling from A to B. match() returns one of
three results: three results:
'Ignore' means that the packet was matched but this flow is not 'Ignore' means that the packet was matched but this flow is not
to be counted. to be counted.
INTERNET-DRAFT Traffic Flow Measurement: Architecture Sep 98
'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 43 skipping to change at page 22, line 4
Normally, the best way to avoid these problems is to write rule sets Normally, the best way to avoid these problems is to write rule sets
which only classify flows in the forward direction, and rely on the which only classify flows in the forward direction, and rely on the
meter to handle reverse-travelling packets. meter to handle reverse-travelling packets.
Occasionally there can be situations when a rule set needs to know the Occasionally there can be situations when a rule set needs to know the
direction in which a packet is being matched. Consider, for example, a direction in which a packet is being matched. Consider, for example, a
rule set which wants to save some attribute values (source and rule set which wants to save some attribute values (source and
destination addresses perhaps) for any 'unusual' packets. The rule set destination addresses perhaps) for any 'unusual' packets. The rule set
will contain a sequence of tests for all the 'usual' source addresses; will contain a sequence of tests for all the 'usual' source addresses;
follwed by a rule which will execute a 'NoMatch' action. If the match follwed by a rule which will execute a 'NoMatch' action. If the match
INTERNET-DRAFT Traffic Flow Measurement: Architecture Sep 98
fails in the S->D direction, the NoMatch action will cause it to be fails in the S->D direction, the NoMatch action will cause it to be
retried. If it fails in the D->S direction, the packet can be counted retried. If it fails in the D->S direction, the packet can be counted
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 44 skipping to change at page 23, line 5
If the test indicator is true: If the test indicator is true:
Perform the test, i.e. AND the attribute value with the Perform the test, i.e. AND the attribute value with the
mask and compare it with the value. mask and compare it with the value.
If these are equal the test has succeeded; perform the If these are equal the test has succeeded; perform the
rule's action (below). rule's action (below).
If the test fails execute the next rule in the rule set. If the test fails execute the next rule in the rule set.
If there are no more rules in the rule set, return from the If there are no more rules in the rule set, return from the
match() function indicating NoMatch. match() function indicating NoMatch.
INTERNET-DRAFT Traffic Flow Measurement: Architecture Sep 98
If the test indicator is false, or the test (above) succeeded: If the test indicator is false, or the test (above) succeeded:
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 25, line 42 skipping to change at page 24, line 5
14 PushPktTo 1 1 14 PushPktTo 1 1
15 PushPktToAct 1 0 15 PushPktToAct 1 0
16 PopTo 1 1 16 PopTo 1 1
17 PopToAct 1 0 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.
INTERNET-DRAFT Traffic Flow Measurement: Architecture Sep 98
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,
mask and value in the PME's pattern queue, then mask and value in the PME's pattern queue, then
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 26, line 41 skipping to change at page 25, line 5
AssignAct: Same as Assign, except that the test indicator AssignAct: Same as Assign, except that the test indicator
is cleared before going to the specified rule. is cleared before going to the specified rule.
Goto: Set the test indicator then goto the Goto: Set the test indicator then goto the
specified rule. specified rule.
GotoAct: Clear the test indicator then goto the specified GotoAct: Clear the test indicator then goto the specified
rule. rule.
INTERNET-DRAFT Traffic Flow Measurement: Architecture Sep 98
PushRuleTo: Save this rule's attribute name, mask and value PushRuleTo: Save this rule's attribute name, mask and value
in the PME's pattern queue. Set the test in the PME's pattern queue. Set the test
indicator then goto the specified rule. indicator then goto the specified rule.
PushRuleToAct: Same as PushRuleTo, except that the test indicator PushRuleToAct: Same as PushRuleTo, except that the test indicator
is cleared before going to the specified rule. is cleared before going to the specified rule.
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 PopTo: Delete the most recent item from the pattern
queue, so as to remove the information saved by queue, so as to remove the information saved by
an earlier 'push' action. Set the test indicator an earlier 'push' action. Set the test indicator
skipping to change at page 27, line 39 skipping to change at page 26, line 4
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.
v1 .. v5: v1, v2, v3, v4 and v5 are 'meter variables.' They v1 .. v5: v1, v2, v3, v4 and v5 are 'meter variables.' They
provide a way to pass parameters into rule-matching provide a way to pass parameters into rule-matching
subroutines. Each may hold the number of a normal subroutines. Each may hold the number of a normal
attribute; its value is set by an Assign action. attribute; its value is set by an Assign action.
When a meter variable appears as the attribute of a When a meter variable appears as the attribute of a
rule, its value specifies the actual attribute to be rule, its value specifies the actual attribute to be
INTERNET-DRAFT Traffic Flow Measurement: Architecture Sep 98
tested. For example, if v1 had been assigned tested. For example, if v1 had been assigned
SourcePeerAddress as its value, a rule with v1 as its SourcePeerAddress as its value, a rule with v1 as its
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 28, line 42 skipping to change at page 27, line 4
flow is idle. flow is idle.
The meter must recover records used for idle flows, if only to prevent The meter must recover records used for idle flows, if only to prevent
it running out of flow records. Recovered flow records are returned to it running out of flow records. Recovered flow records are returned to
the 'inactive' state. A variety of recovery strategies are possible, the 'inactive' state. A variety of recovery strategies are possible,
including the following: including the following:
One possible recovery strategy is to recover idle flow records as soon One possible recovery strategy is to recover idle flow records as soon
as possible after their data has been collected by all readers which as possible after their data has been collected by all readers which
have registered to do so. To implement this the meter could run a have registered to do so. To implement this the meter could run a
INTERNET-DRAFT Traffic Flow Measurement: Architecture Sep 98
background process which scans the flow table looking for 'current' background process which scans the flow table looking for 'current'
flows whose 'last packet' time is earlier than the meter's flows whose 'last packet' time is earlier than the meter's
LastCollectTime. LastCollectTime.
Another recovery strategy is to leave idle flows alone as long as Another recovery strategy is to leave idle flows alone as long as
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
skipping to change at page 29, line 38 skipping to change at page 28, line 4
The following sections describe the contents of usage records and flow The following sections describe the contents of usage records and flow
data files. Note, however, that at this stage the details of such data files. Note, however, that at this stage the details of such
records and files is not specified in the architecture. Specifying a records and files is not specified in the architecture. Specifying a
common format for them would be a worthwhile future development. common format for them would be a worthwhile future development.
5.1 Identifying Flows in Flow Records 5.1 Identifying Flows in Flow Records
Once a packet has been classified and is ready to be counted, an Once a packet has been classified and is ready to be counted, an
appropriate flow data record must already exist in the flow table; appropriate flow data record must already exist in the flow table;
otherwise one must be created. The flow record has a flexible format otherwise one must be created. The flow record has a flexible format
INTERNET-DRAFT Traffic Flow Measurement: Architecture Sep 98
where unnecessary identification attributes may be omitted. The where unnecessary identification attributes may be omitted. The
determination of which attributes of the flow record to use, and of what determination of which attributes of the flow record to use, and of what
values to put in them, is specified by the current rule set. values to put in them, is specified by the current rule set.
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 30, line 41 skipping to change at page 29, line 5
| Meter Id (& digital signature if required) | | Meter Id (& digital signature if required) |
| Timestamp | | Timestamp |
| Collection Rules ID | | Collection Rules ID |
+-------------------------------------------------------------------+ +-------------------------------------------------------------------+
| FLOW IDENTIFIERS: | COUNTERS | | FLOW IDENTIFIERS: | COUNTERS |
| Address List | Packet Count | | Address List | Packet Count |
| Subscriber ID (Optional) | Byte Count | | Subscriber ID (Optional) | Byte Count |
| Attributes (Optional) | Flow Start/Stop Time | | Attributes (Optional) | Flow Start/Stop Time |
+-------------------------------------------------------------------+ +-------------------------------------------------------------------+
INTERNET-DRAFT Traffic Flow Measurement: Architecture Sep 98
5.3 Meter to Meter Reader: Usage Record Transmission 5.3 Meter to Meter Reader: Usage Record Transmission
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 31, line 38 skipping to change at page 30, line 5
Users of the Traffic Flow Measurement system should analyse their Users of the Traffic Flow Measurement system should analyse their
requirements carefully and assess for themselves whether it is more requirements carefully and assess for themselves whether it is more
important to attempt to collect flow data at normal granularity important to attempt to collect flow data at normal granularity
(increasing the collection frequency as needed to keep up with traffic (increasing the collection frequency as needed to keep up with traffic
volumes), or to accept flow data with a coarser granularity. Similarly, volumes), or to accept flow data with a coarser granularity. Similarly,
it may be acceptable to lose flow data for a short time in return for it may be acceptable to lose flow data for a short time in return for
being sure that the meter keeps running properly, i.e. is not being sure that the meter keeps running properly, i.e. is not
overwhelmed by rising traffic levels. overwhelmed by rising traffic levels.
INTERNET-DRAFT Traffic Flow Measurement: Architecture Sep 98
6 Managers 6 Managers
A manager configures meters and controls meter readers. It does this A manager configures meters and controls meter readers. It does this
via the interactions described below. via the interactions described below.
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 32, line 39 skipping to change at page 31, line 5
- Oldest flows, or - Oldest flows, or
- Flows with the smallest number of observed packets. - Flows with the smallest number of observed packets.
- SET INACTIVITY TIMEOUT: This is a time in seconds since the last - SET INACTIVITY TIMEOUT: This is a time in seconds since the last
packet was seen for a flow. Flow records may be reclaimed if they packet was seen for a flow. Flow records may be reclaimed if they
have been idle for at least this amount of time, and have been have been idle for at least this amount of time, and have been
collected in accordance with the current collection criteria. collected in accordance with the current collection criteria.
INTERNET-DRAFT Traffic Flow Measurement: Architecture Sep 98
6.2 Between Manager and Meter Reader: Control Functions 6.2 Between Manager and Meter Reader: Control Functions
Because there are a number of parameters that must be set for traffic Because there are a number of parameters that must be set for traffic
flow measurement to function properly, and viable settings may change as flow measurement to function properly, and viable settings may change as
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 33, line 43 skipping to change at page 32, line 5
condition), and for the manager to arbitrate (by decreasing the condition), and for the manager to arbitrate (by decreasing the
polling interval, letting nature take its course, or by telling the polling interval, letting nature take its course, or by telling the
meter to ask for help sooner next time). meter to ask for help sooner next time).
- GRANULARITY CONTROL: Granularity control is a catch-all for all the - GRANULARITY CONTROL: Granularity control is a catch-all for all the
parameters that can be tuned and traded to optimise the system's parameters that can be tuned and traded to optimise the system's
ability to reliably measure and store information on all the ability to reliably measure and store information on all the
traffic (or as close to all the traffic as an administration traffic (or as close to all the traffic as an administration
requires). Granularity requires). Granularity
INTERNET-DRAFT Traffic Flow Measurement: Architecture Sep 98
- Controls the amount of address information identifying each - Controls the amount of address information identifying each
flow, and flow, and
- 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 34, line 41 skipping to change at page 33, line 5
regular poll that a meter has failed and restarted. It could then regular poll that a meter has failed and restarted. It could then
advise the manager of this, instead of relying on a trap from the advise the manager of this, instead of relying on a trap from the
meter. meter.
- METER READER OUTAGES: If the collection system is down or isolated, - METER READER OUTAGES: If the collection system is down or isolated,
the meter should try to inform the manager of its failure to the meter should try to inform the manager of its failure to
communicate with the collection system. Usage data is maintained communicate with the collection system. Usage data is maintained
in the flows' rolling counters, and can be recovered when the meter in the flows' rolling counters, and can be recovered when the meter
reader is restarted. reader is restarted.
INTERNET-DRAFT Traffic Flow Measurement: Architecture Sep 98
- MANAGER OUTAGES: If the manager fails for any reason, the meter - MANAGER OUTAGES: If the manager fails for any reason, the meter
should continue measuring and the meter reader(s) should keep should continue measuring and the meter reader(s) should keep
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 35, line 43 skipping to change at page 34, line 5
- TRANSPORT TYPE: The meter records packets by transport address; for - TRANSPORT TYPE: The meter records packets by transport address; for
IP packets this provides usage information for the various IP IP packets this provides usage information for the various IP
services. services.
- HYBRID SYSTEMS: Combinations of the above, e.g. for one interface - HYBRID SYSTEMS: Combinations of the above, e.g. for one interface
report End Systems, for another interface report Adjacent Systems. report End Systems, for another interface report Adjacent Systems.
This strategy might be used by an enterprise network to learn This strategy might be used by an enterprise network to learn
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.
INTERNET-DRAFT Traffic Flow Measurement: Architecture Sep 98
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 40 skipping to change at page 35, line 5
- UNAUTHORIZED USE OF SYSTEM RESOURCES is countered through the use - UNAUTHORIZED USE OF SYSTEM RESOURCES is countered through the use
of authentication and access control services. of authentication and access control services.
- UNAUTHORIZED DISCLOSURE OF DATA is countered through the use of a - UNAUTHORIZED DISCLOSURE OF DATA is countered through the use of a
confidentiality (encryption) service. confidentiality (encryption) service.
- UNAUTHORIZED ALTERATION, REPLACEMENT OR DESTRUCTION OF DATA is - UNAUTHORIZED ALTERATION, REPLACEMENT OR DESTRUCTION OF DATA is
countered through the use of an integrity service. countered through the use of an integrity service.
INTERNET-DRAFT Traffic Flow Measurement: Architecture Sep 98
A Traffic Measurement system must address all of these concerns. Since A Traffic Measurement system must address all of these concerns. Since
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 45 skipping to change at page 36, line 5
element should check that the requested type of access is allowed; element should check that the requested type of access is allowed;
this is indicated on the table by 'acc ctrl.' this is indicated on the table by 'acc ctrl.'
- Whenever there is a transfer of information its integrity should be - Whenever there is a transfer of information its integrity should be
protected. protected.
- 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.
INTERNET-DRAFT Traffic Flow Measurement: Architecture Sep 98
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 47 skipping to change at page 37, line 5
REGIONAL networks are closely related to backbones, and differ only in REGIONAL networks are closely related to backbones, and differ only in
size, the number of networks connected via each port, and geographical size, the number of networks connected via each port, and geographical
coverage. Regionals may have directly connected hosts, acting as hybrid coverage. Regionals may have directly connected hosts, acting as hybrid
backbone/stub networks. A regional network is a SUBSCRIBER to the backbone/stub networks. A regional network is a SUBSCRIBER to the
backbone. backbone.
STUB/ENTERPRISE networks connect hosts and local area networks. STUB/ENTERPRISE networks connect hosts and local area networks.
STUB/ENTERPRISE networks are SUBSCRIBERS to regional and backbone STUB/ENTERPRISE networks are SUBSCRIBERS to regional and backbone
networks. networks.
INTERNET-DRAFT Traffic Flow Measurement: Architecture Sep 98
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 47 skipping to change at page 38, line 4
end-system network address or network address pair if detailed reporting end-system network address or network address pair if detailed reporting
is required in the local area network. If no local reporting is is required in the local area network. If no local reporting is
required, they may record usage information in the exit router to track required, they may record usage information in the exit router to track
external traffic only. (These are the only networks which routinely use external traffic only. (These are the only networks which routinely use
attributes to perform reporting at granularities finer than end-system attributes to perform reporting at granularities finer than end-system
or intermediate-system network address.) or intermediate-system network address.)
REGIONAL networks are intermediate networks. In some cases, subscribers REGIONAL networks are intermediate networks. In some cases, subscribers
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
INTERNET-DRAFT Traffic Flow Measurement: Architecture Sep 98
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 48 skipping to change at page 39, line 5
15 Destination Adjacent Type Integer 15 Destination Adjacent Type Integer
16 Destination Adjacent Address String 16 Destination Adjacent Address String
17 Destination AdjacentMask String 17 Destination AdjacentMask String
18 Destination PeerType Integer 18 Destination PeerType Integer
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
INTERNET-DRAFT Traffic Flow Measurement: Architecture Sep 98
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 41, line 48 skipping to change at page 40, line 5
'per reader' variables: 'per reader' variables:
Reader Last Time Timestamp Reader Last Time Timestamp
8.5 Appendix E: Changes Introduced Since RFC 2063 8.5 Appendix E: Changes Introduced Since RFC 2063
The first version of the Traffic Flow Measurement Architecture was The first version of the Traffic Flow Measurement Architecture was
published as RFC 2063 in January 1997. The most significant changes published as RFC 2063 in January 1997. The most significant changes
made since then are summarised below. made since then are summarised below.
INTERNET-DRAFT Traffic Flow Measurement: Architecture Sep 98
- A Traffic Meter can now run multiple rule sets concurrently. This - A Traffic Meter can now run multiple rule sets concurrently. This
makes a meter much more useful, and required only minimal changes makes a meter much more useful, and required only minimal changes
to the architecture. to the architecture.
INTERNET-DRAFT Traffic Flow Measurement: Architecture July 98
- 'NoMatch' replaces 'Fail' as an action. This name was agreed to at - 'NoMatch' replaces 'Fail' as an action. This name was agreed to at
the Working Group 1996 meeting in Montreal; it better indicates the Working Group 1996 meeting in Montreal; it better indicates
that although a particular match has failed, it may be tried again that although a particular match has failed, it may be tried again
with the packet's addresses reversed. with the packet's addresses reversed.
- The 'MatchingStoD' attribute has been added. This is a Packet - The 'MatchingStoD' attribute has been added. This is a Packet
Matching Engine (PME) attribute indicating that addresses are being Matching Engine (PME) attribute indicating that addresses are being
matched in StoD (i.e. 'wire') order. It can be used to perform matched in StoD (i.e. 'wire') order. It can be used to perform
different actions when the match is retried, thereby simplifying different actions when the match is retried, thereby simplifying
some kinds of rule sets. It was discussed and agreed to at the San some kinds of rule sets. It was discussed and agreed to at the San
skipping to change at page 42, line 47 skipping to change at page 41, line 5
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.
10 References 10 References
[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.
INTERNET-DRAFT Traffic Flow Measurement: Architecture Sep 98
[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. RFC 2064, The University of Auckland, January 1997.
11 Author's Addresses 11 Author's Addresses
Nevil Brownlee Nevil Brownlee
Information Technology Systems & Services Information Technology Systems & Services
The University of Auckland The University of Auckland
Phone: +64 9 373 7599 x8941 Phone: +64 9 373 7599 x8941
E-mail: n.brownlee@auckland.ac.nz E-mail: n.brownlee@auckland.ac.nz
skipping to change at page 43, line 36 skipping to change at page 41, line 41
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 Expires March 99
 End of changes. 96 change blocks. 
210 lines changed or deleted 141 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/