draft-ietf-rtfm-architecture-00.txt   draft-ietf-rtfm-architecture-01.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
September 1997
Traffic Flow Measurement: Architecture Traffic Flow Measurement: Architecture
<draft-ietf-rtfm-architecture-00.txt> <draft-ietf-rtfm-architecture-01.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
Internet Accounting Working Group of the IETF. Realtime Traffic Flow Measurement Working Group of the IETF.
Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts are draft documents valid for a maximum of six months.
Internet Drafts may be updated, replaced, or obsoleted by other Internet Drafts may be updated, replaced, or obsoleted by other
documents at any time. It is not appropriate to use Internet Drafts as documents at any time. It is not appropriate to use Internet Drafts as
reference material or to cite them other than as a "working draft" or reference material or to cite them other than as a "working draft" or
"work in progress." "work in progress."
Please check the I-D abstract listing contained in the Internet-drafts To view the entire list of current Internet-Drafts, please check the
Shadow Directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
ftp.nisc.sri.com or munnari.oz.au to learn the current status of this or Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe),
any other Internet Draft. munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Abstract Abstract
This document describes an architecture for the measurement and This document describes an architecture for the measurement and
reporting of network traffic flows, discusses how this relates to an reporting of network traffic flows, discusses how this relates to an
overall network traffic flow architecture, and describes how it can be overall network traffic flow architecture, and describes how it can be
used within the Internet. It is intended to provide a starting point used within the Internet. It is intended to provide a starting point
for the Realtime Traffic Flow Measurement Working Group. for the Realtime Traffic Flow Measurement Working Group.
Contents Contents
skipping to change at page 2, line ? skipping to change at page 2, line ?
2.2 Interaction Between METER and METER READER . . . . . . . . . . 7 2.2 Interaction Between METER and METER READER . . . . . . . . . . 7
2.3 Interaction Between MANAGER and METER . . . . . . . . . . . . 8 2.3 Interaction Between MANAGER and METER . . . . . . . . . . . . 8
2.4 Interaction Between MANAGER and METER READER . . . . . . . . . 8 2.4 Interaction Between MANAGER and METER READER . . . . . . . . . 8
2.5 Multiple METERs or METER READERs . . . . . . . . . . . . . . . 9 2.5 Multiple METERs or METER READERs . . . . . . . . . . . . . . . 9
2.6 Interaction Between MANAGERs (MANAGER - MANAGER) . . . . . . . 10 2.6 Interaction Between MANAGERs (MANAGER - MANAGER) . . . . . . . 10
2.7 METER READERs and APPLICATIONs . . . . . . . . . . . . . . . . 10 2.7 METER READERs and APPLICATIONs . . . . . . . . . . . . . . . . 10
3 Traffic Flows and Reporting Granularity 10 3 Traffic Flows and Reporting Granularity 10
3.1 Flows and their Attributes . . . . . . . . . . . . . . . . . . 11 3.1 Flows and their Attributes . . . . . . . . . . . . . . . . . . 11
3.2 Granularity of Flow Measurements . . . . . . . . . . . . . . . 13 3.2 Granularity of Flow Measurements . . . . . . . . . . . . . . . 13
3.3 Rolling Counters, Timestamps, Report-in-One-Bucket-Only . . . 15 3.3 Rolling Counters, Timestamps, Report-in-One-Bucket-Only. . . . 15
4 Meters 16 4 Meters 17
4.1 Meter Structure . . . . . . . . . . . . . . . . . . . . . . . 17 4.1 Meter Structure . . . . . . . . . . . . . . . . . . . . . . . 17
4.2 Flow Table . . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.2 Flow Table . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.3 Packet Handling, Packet Matching . . . . . . . . . . . . . . . 19 4.3 Packet Handling, Packet Matching . . . . . . . . . . . . . . . 19
4.4 Rules and Rule Sets . . . . . . . . . . . . . . . . . . . . . 22 4.4 Rules and Rule Sets . . . . . . . . . . . . . . . . . . . . . 23
4.5 Maintaining the Flow Table . . . . . . . . . . . . . . . . . . 26 4.5 Maintaining the Flow Table . . . . . . . . . . . . . . . . . . 27
4.6 Handling Increasing Traffic Levels . . . . . . . . . . . . . . 27 4.6 Handling Increasing Traffic Levels . . . . . . . . . . . . . . 28
5 Meter Readers 27 5 Meter Readers 28
5.1 Identifying Flows in Flow Records . . . . . . . . . . . . . . 27 5.1 Identifying Flows in Flow Records . . . . . . . . . . . . . . 28
5.2 Usage Records, Flow Data Files . . . . . . . . . . . . . . . . 28 5.2 Usage Records, Flow Data Files . . . . . . . . . . . . . . . . 29
5.3 Meter to Meter Reader: Usage Record Transmission . . . . . . . 28 5.3 Meter to Meter Reader: Usage Record Transmission . . . . . . 30
6 Managers 29 6 Managers 30
6.1 Between Manager and Meter: Control Functions . . . . . . . . . 29 6.1 Between Manager and Meter: Control Functions . . . . . . . . 31
6.2 Between Manager and Meter Reader: Control Functions . . . . . 30 6.2 Between Manager and Meter Reader: Control Functions . . . . . 31
6.3 Exception Conditions . . . . . . . . . . . . . . . . . . . . . 32 6.3 Exception Conditions . . . . . . . . . . . . . . . . . . . . . 33
6.4 Standard Rule Sets . . . . . . . . . . . . . . . . . . . . . . 33 6.4 Standard Rule Sets . . . . . . . . . . . . . . . . . . . . . . 34
7 APPENDICES 34 7 Security Considerations 35
7.1 Appendix A: Network Characterisation . . . . . . . . . . . . . 34 7.1 Threat Analysis . . . . . . . . . . . . . . . . . . . . . . . 35
7.2 Appendix B: Recommended Traffic Flow Measurement Capabilities 35 7.2 Countermeasures . . . . . . . . . . . . . . . . . . . . . . . 35
7.3 Appendix C: List of Defined Flow Attributes . . . . . . . . . 36
7.4 Appendix D: List of Meter Control Variables . . . . . . . . . 37
8 Security Considerations 38 8 APPENDICES 37
8.1 Threat Analysis . . . . . . . . . . . . . . . . . . . . . . . 38 8.1 Appendix A: Network Characterisation . . . . . . . . . . . . . 37
8.2 Countermeasures . . . . . . . . . . . . . . . . . . . . . . . 38 8.2 Appendix B: Recommended Traffic Flow Measurement Capabilities .38
8.3 Appendix C: List of Defined Flow Attributes . . . . . . . . . 39
8.4 Appendix D: List of Meter Control Variables . . . . . . . . . 40
9 Acknowledgments 40 9 Acknowledgments 41
10 References 40 10 References 41
11 Author's Addresses 41 11 Author's Addresses 42
1 Statement of Purpose and Scope 1 Statement of Purpose and Scope
This document describes an architecture for traffic flow measurement and This document describes an architecture for traffic flow measurement and
reporting for data networks which 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 in a - Users may specify their traffic flow measurement requirements by
simple manner, allowing them to collect the flow data they need writing 'rule sets,' allowing them to collect the flow data they
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 reduces the volume of data to be obtained measurement point. This minimises the volume of data to be
(and transmitted across the network for storage), and minimises the obtained (and transmitted across the network for storage), and
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,
- Planning for network development and expansion, - Planning for network development and expansion,
skipping to change at page 4, line 31 skipping to change at page 4, line 31
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.
Background information explaining why this approach was selected is Background information explaining why this approach was selected is
provided by the 'Traffic Flow Measurement: Background' RFC [1]. provided by the 'Internet Accounting: Background' RFC [1].
1.1 Changes Introduced Since RFC 2063 1.1 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.
- A Traffic Meter is now expected to run multiple rule sets - A Traffic Meter should be able to run multiple rule sets
concurrently. This makes a meter much more useful, and concurrently. This makes a meter much more useful, and required
required only minimal changes to the architecture. only minimal changes to the architecture.
- '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
skipping to change at page 5, line 20 skipping to change at page 5, line 20
- The list of attribute numbers has been extended to define ranges - The list of attribute numbers has been extended to define ranges
for 'basic' attributes (in this document) and 'extended' attributes for 'basic' attributes (in this document) and 'extended' attributes
(currently being developed by the RTFM Working Group). (currently being developed by the RTFM Working Group).
- The 'Security Considerations' section has been completely - The 'Security Considerations' section has been completely
rewritten. It provides an evaluation of traffic measurement rewritten. It provides an evaluation of traffic measurement
security risks and their countermeasures. security risks and their countermeasures.
2 Traffic Flow Measurement Architecture 2 Traffic Flow Measurement Architecture
A traffic flow measurement system is used by network Operations A traffic flow measurement system is used by Network Operations
personnel for managing and developing a network. It provides a tool for personnel to aid in managing and developing a network. It provides a
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.
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 count certain attributes (such as numbers called traffic METERS. Meters observe packets as they pass by a single
of packets and bytes) and classify them as belonging to ACCOUNTABLE point on their way through the network and classify them into certain
ENTITIES using other attributes (such as source and destination groups. For each such group a meter will accumulate certain attributes,
addresses). An accountable entity is someone who (or something which) for example the numbers of packets and bytes observed for the group.
is responsible for some activity on the network. It may be a user, a These METERED TRAFFIC GROUPS may correspond to a user, a host system,
host system, a network, a group of networks, etc, depending on the a network, a group of networks, a particular transport address (e.g. an
granularity specified by the meter's configuration. IP port number), any combination of the above, etc, depending on the
meter's configuration.
We assume that routers or traffic monitors throughout a network are We assume that routers or traffic monitors throughout a network are
instrumented with meters to measure traffic. Issues surrounding the instrumented with meters to measure traffic. Issues surrounding the
choice of meter placement are discussed in the 'Traffic Flow choice of meter placement are discussed in the 'Traffic Flow
Measurement: Background' RFC [1]. An important aspect of meters is Measurement: Background' RFC [1]. An important aspect of meters is
that they provide a way of succinctly aggregating entity usage that they provide a way of succinctly aggregating traffic information.
information.
For the purpose of traffic flow measurement we define the concept of a For the purpose of traffic flow measurement we define the concept of a
TRAFFIC FLOW, which is an artificial logical equivalent to a call or TRAFFIC FLOW, which is like an artificial logical equivalent to a call
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 was generated by a particular accountable entity. stop time, that belongs to one of the metered traffic groups mentioned
Attribute values (source/destination addresses, packet counts, byte above. Attribute values (source/destination addresses, packet counts,
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
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 ascribe it economical and practical way to measure network traffic and subdivide it
to accountable entities. 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 will 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
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
2.2 2.7 2.2 2.7
- MANAGER: A traffic measurement manager is an application which - MANAGER: A traffic measurement manager is an application which
configures 'meter' entities and controls 'meter reader' entities. configures 'meter' entities and controls 'meter reader' entities.
It uses the data requirements of analysis applications to determine It sends configuration commands to the meters, and supervises the
the appropriate configurations for each meter, and the proper proper operation of each meter and meter reader. It may well be
operation of each meter reader. It may well be convenient to convenient to combine the functions of meter reader and manager
combine the functions of meter reader and manager within a single within a single network entity.
network entity.
- 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.
- 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
skipping to change at page 8, line 14 skipping to change at page 8, line 14
2.3 Interaction Between MANAGER and METER 2.3 Interaction Between MANAGER and METER
A manager is responsible for configuring and controlling one or more A manager is responsible for configuring and controlling one or more
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 maximum size of its flow table, - Meter control parameters, e.g. the 'inactivity' time for flows (if
the 'inactivity' time for flows (if no packets belonging to a flow no packets belonging to a flow are seen for this time the flow is
are seen for this time the flow is considered to have ended, i.e. considered to have ended, i.e. to have become idle).
to have become idle).
- 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 when it downloads that individual rule set should be set by the manager after it downloads that
rule set. rule set.
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:
- The meter's unique identity, i.e. its network name or address. - The meter's unique identity, i.e. its network name or address.
- How often usage data is to be collected from the meter. - How often usage data is to be collected from the meter.
- Which flow records are to be collected (e.g. all active flows, the - Which flow records are to be collected (e.g. flows for a particular
whole flow table, flows seen since a given time, etc.). rule set, whole flow table, flows seen since a given 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.
2.5 Multiple METERs or METER READERs 2.5 Multiple METERs or METER READERs
skipping to change at page 9, line 31 skipping to change at page 9, line 31
\ | / \ | /
\ | / \ | /
-- 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
fails, usage data for their network segments will be lost. meter fails, usage data for their network segments will be lost.
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 If one meter reader fails, the other will continue collecting usage data
data. 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
unlikely that usage records from two different meter readers will agree unlikely that usage records from two different meter readers will agree
exactly. exactly.
If precisely synchronized collections are required this can be achieved If precisely synchronized collections are required this can be achieved
by having one manager request each meter to begin collecting a new set by having one manager request each meter to begin running a new set of
of flows, then allowing all meter readers to collect the usage data from rules at the same time, then allowing all meter readers to collect the
the old sets of flows. 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.'
2.6 Interaction Between MANAGERs (MANAGER - MANAGER) 2.6 Interaction Between MANAGERs (MANAGER - MANAGER)
skipping to change at page 10, line 42 skipping to change at page 10, line 42
running a traffic flow measurement system is the storage and regular running a traffic flow measurement system is the storage and regular
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 an ACCOUNTABLE ENTITY." connection, belonging to a (user-specieied) METERED TRAFFIC
GROUP."
In practical terms, a flow is a stream of packets passing across a In practical terms, a flow is a stream of packets passing across a
network between two end points (or being sent from a single end point), network between two end points (or being sent from a single end point),
which have been summarized by a traffic meter for analysis purposes. which have been summarized by a traffic meter for analysis purposes.
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), and the number of the network layers (extracted from the packet header), and the number
interface on which the packet was observed. of the interface on which the packet was observed.
- First and last TIMES when packets were seen for this flow, i.e. - First and last TIMES when packets were seen for this flow, i.e.
the 'creation' and 'last activity' times for the flow. the 'creation' and 'last activity' times for the flow.
- COUNTS for 'forward' (source to destination) and 'backward' - COUNTS for 'forward' (source to destination) and 'backward'
(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. information computed by the meter. - 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
while the flow was observed. The values of these attributes
provide a way of distinguishing flows observed by a meter at
different times.
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 65 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 above 128. use attribute numbers 128 and above.
A flow's ACCOUNTABLE ENTITY 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
and to that address would be counted in that flow. If a flow's address and to that address would be counted in that flow. If a flow's address
list were specified as "source address = IP address 10.1.0.1, list were specified as "source address = IP address 10.1.0.1,
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.
- 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 is a six-octet Media an Ethernet LAN [3], an adjacent address will normally be a
Access Control (MAC) address. For a host connected to the same LAN six-octet Media Access Control (MAC) address. For a host connected
segment as the meter the adjacent address will be the MAC address to the same LAN segment as the meter the adjacent address will be
of that host. For hosts on other LAN segments it will be the MAC the MAC address of that host. For hosts on other LAN segments it
address of the adjacent (upstream or downstream) router carrying will be the MAC address of the adjacent (upstream or downstream)
the traffic flow. router carrying the traffic flow.
- The PEER ADDRESS, which identifies the source or destination of the - The PEER ADDRESS, which identifies the source or destination of the
PEER-LEVEL packet. The form of a peer address will depend on the PEER-LEVEL packet. The form of a peer address will depend on the
network-layer protocol in use, and the network layer [n] at which network-layer protocol in use, and the network layer [n] at which
traffic measurement is being performed. traffic measurement is being performed.
- The TRANSPORT ADDRESS, which identifies the source or destination - The TRANSPORT ADDRESS, which identifies the source or destination
port for the packet, i.e. its [n+1] layer address. For example, port for the packet, i.e. its [n+1] layer address. For example,
if flow measurement is being performed at the IP layer a transport if flow measurement is being performed at the IP layer a transport
address is a two-octet UDP or TCP port number. address is a two-octet UDP or TCP port number.
skipping to change at page 12, line 48 skipping to change at page 12, line 52
'peer address' remains the same. It becomes harder to maintain this 'peer address' remains the same. It becomes harder to maintain this
correspondence at higher layers - for example, at the Network layer IP, correspondence at higher layers - for example, at the Network layer IP,
Novell IPX and AppleTalk all use port numbers as a 'transport address,' Novell IPX and AppleTalk all use port numbers as a 'transport address,'
but CLNP and DECnet have no notion of ports. Further work is needed but CLNP and DECnet have no notion of ports. Further work is needed
here, particularly in selecting attributes which will be suitable for here, particularly in selecting attributes which will be suitable for
the higher layers of the OSI reference model. the higher layers of the OSI reference model.
Reporting by adjacent intermediate sources and destinations or simply by Reporting by adjacent intermediate sources and destinations or simply by
meter interface (most useful when the meter is embedded in a router) meter interface (most useful when the meter is embedded in a router)
supports hierarchical Internet reporting schemes as described in the supports hierarchical Internet reporting schemes as described in the
'Traffic Flow Measurement: Background' RFC [1]. That is, it allows 'Internet Accounting: Background' RFC [1]. That is, it allows backbone
backbone and regional networks to measure usage to just the next lower and regional networks to measure usage to just the next lower level of
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.
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 accountable entity through the use of an optional SUBSCRIBER specify the metered traffic group through the use of an optional
ID as part of the flow id. A subscriber ID may be associated with a SUBSCRIBER ID as part of the flow id. A subscriber ID may be associated
particular flow either through the current rule set or by proprietary with a particular flow either through the current rule set or by
means within a meter, for example via protocol exchanges with one or proprietary means within a meter, for example via protocol exchanges
more (multi-user) hosts. At this time a subscriber ID is an arbitrary with one or more (multi-user) hosts. At this time a subscriber ID is an
text string; later versions of the architecture may specify its contents arbitrary text string; later versions of the architecture may specify
in more detail. its contents in more detail.
3.2 Granularity of Flow Measurements 3.2 Granularity of Flow Measurements
GRANULARITY is the 'control knob' by which an application and/or the GRANULARITY is the 'control knob' by which an application and/or the
meter can trade off the overhead associated with performing usage meter can trade off the overhead associated with performing usage
reporting against the level of detail supplied. A coarser granularity reporting against the level of detail supplied. A coarser granularity
means a greater level of aggregation; finer granularity means a greater means a greater level of aggregation; finer granularity means a greater
level of detail. Thus, the number of flows measured (and stored) at a level of detail. Thus, the number of flows measured (and stored) at a
meter can be regulated by changing the granularity of the accountable meter can be regulated by changing the granularity of the metered
entity, the attributes, or the time intervals. Flows are like an traffic group, the attributes, or the inactivity time interval. Flows
adjustable pipe - many fine-granularity streams can carry the data with are like an adjustable pipe - many fine-granularity streams can carry
each stream measured individually, or data can be bundled in one the data with each stream measured individually, or data can be bundled
coarse-granularity pipe. in one coarse-granularity pipe.
Flow granularity is controlled by adjusting the level of detail at which Flow granularity is controlled by adjusting the level of detail at which
the following are reported: the following are determined:
- The accountable entity (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 The set of rules controlling the determination of each packet's metered
accountable entity 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
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 accountable entities is
further specified by additional ATTRIBUTES. These attributes include: further specified by additional ATTRIBUTES. These attributes include:
- Meter variables such as the index of the flow's record in the flow
table and the rule set id for the rules which the meter was running
while the flow was observed. The values of these attributes
provide a way of distinguishing flows observed by a meter at
different times.
- 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
networks, and set SourceClass/DestClass to one if the source/dest networks, and set SourceClass/DestClass to one if the source/dest
peer address was in the list or to zero otherwise. peer address was in the list or to zero otherwise.
- Administratively specified attributes such as Quality Of Service - Administratively specified attributes such as Quality Of Service
and Priority, etc. These are not defined at this time. and Priority, etc. These are not defined at this time.
- Higher-layer (especially application-level) attributes. These are - Higher-layer (especially application-level) attributes. These are
not defined at this time. not defined at this time.
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. 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
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 at least one meter reader. data has been collected by all meter readers which registered to collect
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.
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
skipping to change at page 15, line 37 skipping to change at page 15, line 37
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
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, or MAX LIFETIME policy), stopped (perhaps because of temporary idleness), but then more traffic
but then more traffic with the same characteristics arrived so a new with the same characteristics arrived so a new flow record was started
flow record was started and it quickly reached a count of 1000. The and it quickly reached a count of 1000. The total flow count from both
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 one and only one flow, so as to avoid multiple Each packet is counted in at most one flow for each running ruleset, so
counting of a single packet. The record of a single flow is informally as to avoid multiple counting of a single packet. The record of a
called a "bucket." If multiple, sometimes overlapping, records of usage single flow is informally called a "bucket." If multiple, sometimes
information are required (aggregate, individual, etc), the network overlapping, records of usage information are required (aggregate,
manager should collect the counts in sufficiently detailed granularity individual, etc), the network manager should collect the counts in
so that aggregate and combination counts can be reconstructed in sufficiently detailed granularity so that aggregate and combination
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
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.' Although a bucket can any interface sourced by IP address = a.b.c.d,' using a single rule set.
be declared for each case, it is not clear how to handle a packet which Although a bucket can be declared for each case, it is not clear how to
satisfies both criteria. It must only be counted once. By default it handle a packet which satisfies both criteria. It must only be counted
will be counted in the first bucket for which it qualifies, and not in once. By default it will be counted in the first bucket for which it
the other bucket. Further, it is not possible to reconstruct this qualifies, and not in the other bucket. Further, it is not possible to
information by post-processing. The solution in this case is to define reconstruct this information by post-processing. The solution in this
not two, but THREE buckets, each one collecting a unique combination of case is to define not two, but THREE buckets, each one collecting a
the two criteria: unique combination of the two criteria:
Bucket 1: Packets which came in interface 1, Bucket 1: Packets which came in interface 1,
AND were sourced by IP address a.b.c.d AND were sourced by IP address a.b.c.d
Bucket 2: Packets which came in interface 1, Bucket 2: Packets which came in interface 1,
AND were NOT sourced by IP address a.b.c.d AND were NOT sourced by IP address a.b.c.d
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
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
and B), as follows:
Bucket 1: Packets which came in interface 1;
counted by rule set A.
Bucket 2: Packets which were sourcede by IP address a.b.c.d;
counted by rule set B.
4 Meters 4 Meters
A traffic flow meter is a device for collecting data about traffic flows A traffic flow meter is a device for collecting data about traffic flows
at a given point within a network; we will call this the METERING POINT. at a given point within a network; we will call this the METERING POINT.
The header of every packet passing the network metering point is offered The header of every packet passing the network metering point is offered
to the traffic meter program. to the traffic meter program.
A meter could be implemented in various ways, including: A meter could be implemented in various ways, including:
- A dedicated small host, connected to a LAN (so that it can see all - A dedicated small host, connected to a LAN (so that it can see all
skipping to change at page 17, line 18 skipping to change at page 17, line 32
on any subset of its network interfaces can be measured. on any subset of its network interfaces can be measured.
- A packet-forwarding device such as a router or switch. This is - A packet-forwarding device such as a router or switch. This is
similar to (b) except that every received packet should also be similar to (b) except that every received packet should also be
forwarded, usually on a different interface. forwarded, usually on a different interface.
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:
- Incoming packet headers arrive at the top left of the diagram and
are passed to the PACKET PROCESSOR.
- The packet processor passes them to the Packet Matching Engine
(PME) where they are classified.
- The PME is a Virtual Machine running a pattern matching program
contained in the CURRENT RULE SET. It is invoked by the Packet
Processor, and returns instructions on what to do with the packet.
- Some packets are classified as 'to be ignored.' They are discarded
by the Packet Processor.
- Other packets are matched by the PME, which returns a FLOW KEY
describing the flow to which the packet belongs.
- 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
fields (e.g. packet and byte counters) are updated.
- 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
within the flow table.
packet +------------------+ packet +------------------+
header | Current Rule Set | header | Current Rule Set |
| +--------+---------+ | +--------+---------+
| | | |
+--------*---------+ +----------*-------------+ +--------*---------+ +----------*-------------+
| Packet Processor |<----->| Packet Matching Engine | | Packet Processor |<----->| Packet Matching Engine |
+--+------------+--+ +------------------------+ +--+------------+--+ +------------------------+
| | | |
Ignore * | Count via flow key Ignore * | Count via flow key
| |
skipping to change at page 17, line 45 skipping to change at page 18, line 40
| | | |
+--------+--------+ +--------+--------+
| |
+--------*--------+ +--------*--------+
| 'Collect' index | | 'Collect' index |
+--------+--------+ +--------+--------+
| |
* *
Meter Reader Meter Reader
Briefly, the meter works as follows:
- Incoming packet headers arrive at the top left of the diagram and
are passed to the PACKET PROCESSOR.
- The packet processor passes them to the Packet Matching Engine
(PME) where they are classified.
- The PME is a Virtual Machine running a pattern matching program
contained in the CURRENT RULE SET. It is invoked by the Packet
Processor, and returns instructions on what to do with the packet.
- Some packets are classified as 'to be ignored.' They are discarded
by the Packet Processor.
- Other packets are matched by the PME, which returns a FLOW KEY
describing the flow to which the packet belongs.
- 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
packet and byte counters are updated.
- 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
within the flow table.
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
skipping to change at page 19, line 33 skipping to change at page 20, line 9
- 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
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 counts for the matching flow, a new flow record may be created. The data for the matching flow
flow record can then be incremented. 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
(PME) for matching. The PME is a Virtual Machine which uses a set of (PME) for matching. The PME is a Virtual Machine which uses a set of
instructions called RULES, i.e. a RULE SET is a program for the PME. A instructions called RULES, i.e. a RULE SET is a program for the PME. A
packet's match key contains an interface number, source address (S) and packet's match key contains an interface number, source address (S) and
skipping to change at page 20, line 23 skipping to change at page 20, line 44
together the 'forward' and 'reverse' components of sessions. together the 'forward' and 'reverse' components of sessions.
Implementing bi-directional flows is, of course, more difficult for the Implementing bi-directional flows is, of course, more difficult for the
meter, since it must decide whether a packet is a 'forward' packet or a meter, since it must decide whether a packet is a 'forward' packet or a
'reverse' one. To make this decision the meter will often need to 'reverse' one. To make this decision the meter will often need to
invoke the PME twice, once for each possible packet direction. invoke the PME twice, once for each possible packet direction.
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, 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:
- The packet is recognised as one which is TO BE IGNORED. - The packet is recognised as one which is TO BE IGNORED.
- The packet MATCHES IN BOTH DIRECTIONS. One situation in which this - The packet would MATCH IN EITHER DIRECTION. One situation in which
could happen would be a rule set which matches flows within network this could happen would be a rule set which matches flows within
X (Source = X, Dest = X) but specifies that flows are to be created network X (Source = X, Dest = X) but specifies that flows are to be
for each subnet within network X, say subnets y and z. If, for created for each subnet within network X, say subnets y and z. If,
example a packet is seen for y->z, the meter must check that flow for example a packet is seen for y->z, the meter must check that
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.
Ignore
--- match(S->D) -------------------------------------------------+
| Suc | NoMatch |
| | Ignore |
| match(D->S) -----------------------------------------+
| | Suc | NoMatch |
| | | |
| | +-------------------------------------------+
| | |
| | Suc |
| current(D->S) ---------- count(D->S,r) --------------+
| | Fail |
| | |
| create(D->S) ----------- count(D->S,r) --------------+
| |
| Suc |
current(S->D) ------------------ count(S->D,f) --------------+
| Fail |
| Suc |
current(D->S) ------------------ count(D->S,r) --------------+
| Fail |
| |
create(S->D) ------------------- count(S->D,f) --------------+
|
*
The algorithm uses four functions, as follows: The algorithm uses four functions, as follows:
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.
'Fail' 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.
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).
Ignore
--- match(S->D) -------------------------------------------------+
| Suc | Fail |
| | Ignore |
| match(D->S) -----------------------------------------+
| | Suc | Fail |
| | | |
| | +-------------------------------------------+
| | |
| | Suc |
| current(D->S) ---------- count(D->S,r) --------------+
| | Fail |
| | |
| create(D->S) ----------- count(D->S,r) --------------+
| |
| Suc |
current(S->D) ------------------ count(S->D,f) --------------+
| Fail |
| Suc |
current(D->S) ------------------ count(D->S,r) --------------+
| Fail |
| |
create(S->D) ------------------- count(S->D,f) --------------+
|
*
When writing rule sets one must remember that the meter will normally When writing rule sets one must remember that the meter will normally
try to match each packet in both directions. It is particularly try to match each packet in the reverse direction if the forward match
important that the rule set does not contain inconsistencies which will does not succeed. It is particularly important that the rule set does
upset this process. not contain inconsistencies which will upset this process.
Consider, for example, a rule set which counts packets from source Consider, for example, a rule set which counts packets from source
network A to destination network B, but which ignores packets from network A to destination network B, but which ignores packets from
source network B. This is an obvious example of an inconsistent rule source network B. This is an obvious example of an inconsistent rule
set, since packets from network B should be counted as reverse packets set, since packets from network B should be counted as reverse packets
for the A-to-B flow. for the A-to-B flow.
This problem could be avoided by devising a language for specifying rule This problem could be avoided by devising a language for specifying rule
files and writing a compiler for it, thus making it much easier to files and writing a compiler for it, thus making it much easier to
produce correct rule sets. Another approach would be to write a 'rule produce correct rule sets. Another approach would be to write a 'rule
set consistency checker' program, which could detect problems in set consistency checker' program, which could detect problems in
hand-written rule sets. hand-written rule sets.
In the short term the best way to avoid these problems is to write rule Normally, the best way to avoid these problems is to write rule sets
sets which only clasify 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
direction in which a packet is being matched. Consider, for example, a
rule set which wants to save some attribute values (source and
destination addresses perhaps) for any 'unusual' packets. The rule set
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
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
as an 'unusual' packet.
To count such an 'unusual' packet we need to know the matching
direction: the MatchingStoD attribute provides this. To use it, one
follows the source address tests with a rule which tests whether the
matching direction is S->D (MatchingStoD value is 1). If so, a
'NoMatch' action is executed. Otherwise, the packet has failed to match
in both directions; we can Push whatever attribute values are of
interest and count the 'unusual' packet.
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. One member of this array is the entries in an array of rule sets.
CURRENT RULE SET, in that it is the one which is currently being used by
the meter to classify incoming packets.
Rule set 1 is built in to the meter and cannot be changed. It is run Rule set 1 (the first entry in the rule set table) is built in to the
when the meter is started up, and provides a very coarse reporting meter and cannot be changed. It is run when the meter is started up,
granularity; it is mainly useful for verifying that the meter is and provides a very coarse reporting granularity; it is mainly useful
running, before a 'useful' rule set is downloaded to it. for verifying that the meter is running, before a 'useful' rule set is
downloaded to it.
If the meter is instructed to use rule set 0, it will cease measuring; A meter also maintains an array of 'tasks,' which specify what rule sets
all packets will be ignored until another (non-zero) rule set is made the meter is running. Each task has a 'current' rule set (the one which
current. it normally uses), and a 'standby' rule set (which will be used when the
overall traffic level is unusually high). If a task is instructed to
use rule set 0, it will cease measuring; all packets will be ignored
until another (non-zero) rule set is made current.
Each rule in a rule set is structured as follows: Each rule in a rule set is structured as follows:
+-------- test ---------+ +---- action -----+ +-------- test ---------+ +---- action -----+
attribute & mask = value: opcode, parameter; attribute & mask = value: opcode, parameter;
Opcodes contain two flags: 'goto' and 'test.' The PME maintains a Opcodes contain two flags: 'goto' and 'test.' The PME maintains a
Boolean indicator called the 'test indicator,' which is initially set Boolean indicator called the 'test indicator,' which is initially set
(true). Execution begins with rule 1, the first in the rule set. It (true). Execution begins with rule 1, the first in the rule set. It
proceeds as follows: proceeds as follows:
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 failure. match() function indicating NoMatch.
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 rule'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.
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 stack in the order it was enqueued. the pattern queue in the order it was enqueued.
The opcodes are: The opcodes are:
opcode goto test opcode goto test
1 Ignore 0 - 1 Ignore 0 -
2 NoMatch 0 - 2 NoMatch 0 -
3 Count 0 - 3 Count 0 -
4 CountPkt 0 - 4 CountPkt 0 -
5 Return 0 0 5 Return 0 0
skipping to change at page 24, line 16 skipping to change at page 25, line 16
Ignore: Stop matching, return from the match() function Ignore: Stop matching, return from the match() function
indicating that the packet is to be ignored. indicating that the packet is to be ignored.
NoMatch: Stop matching, return from the match() function NoMatch: Stop matching, return from the match() function
indicating failure. indicating failure.
Count: Stop matching. Save this rule's attribute name, Count: Stop matching. Save this rule's attribute name,
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
this packet belongs. Return from the match() packet belongs. Return from the match() function
function indicating success. The meter will use indicating success. The meter will use the flow
the flow key to locate 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.
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.
skipping to change at page 25, line 20 skipping to change at page 26, line 20
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, in the PME's pattern masked value from the packet header, in the PME's
SET the test indicator then goto the specified pattern queue. Set the test indicator then goto
rule. the specified rule.
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.
As well as the attributes applying directly to packets (such as As well as the attributes applying directly to packets (such as
SourcePeerAddress, DestTransAddress, etc.) the PME implements several SourcePeerAddress, DestTransAddress, etc.) the PME implements several
skipping to change at page 25, line 44 skipping to change at page 26, line 44
Null: Tests performed on the Null attribute always succeed. Null: Tests performed on the Null attribute always succeed.
MatchingStoD: Indicates whether the PME is matching the packet MatchingStoD: Indicates whether the PME is matching the packet
with its addresses in 'wire order' or with its with its addresses in 'wire order' or with its
addresses reversed. MatchingStoD's value is 1 if the addresses reversed. MatchingStoD's value is 1 if the
addresses are in wire order (StoD), and != 1 otherwise. addresses are in wire order (StoD), and != 1 otherwise.
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 name 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
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
skipping to change at page 26, line 20 skipping to change at page 27, line 18
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.
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 seen for a flow which is not in the current flow Each time a packet is matched for a flow which is not in a current flow
set a flow record is set up 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
the flow table for a 'inactive' record - there is no particular the flow table for an 'inactive' record. If no inactive records are
significance in the ordering of records within the table. available it will search for an 'idle' one instead. Note that there is
no particular significance in the ordering of records within the table.
Flow data may be collected by a 'meter reader' at any time. There is no Flow data may be collected by a 'meter reader' at any time. There is no
requirement for collections to be synchronized. The reader may collect requirement for collections to be synchronized. The reader may collect
the data in any suitable manner, for example it could upload a copy of the data in any suitable manner, for example it could upload a copy of
the whole flow table using a file transfer protocol, or it could read the whole flow table using a file transfer protocol, or it could read
the records in the current flow set row by row using a suitable data the records in the current flow set row by row using a suitable data
transfer protocol. transfer protocol.
The meter keeps information about collections, in particular it The meter keeps information about collections, in particular it
maintains a LastCollectTime variable which remembers the time the last maintains ReaderLastTime variables which remember the time the last
collection was made. A second variable, InactivityTime, specifies the collection was made by each reader. A second variable, InactivityTime,
minimum time the meter will wait before considering that a flow is idle. specifies the minimum time the meter will wait before considering that a
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. To implement this the as possible after their data has been collected by all readers which
meter could run a background process which scans the flow table looking have registered to do so. To implement this the meter could run a
for 'current' flows whose 'last packet' time is earlier than the meter's background process which scans the flow table looking for 'current'
LastCollectTime. This would be suitable for use when one was interested flows whose 'last packet' time is earlier than the meter's
in measuring flow lifetimes. 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 out of '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.
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 increase the granularity of flow to a STANDBY RULE SET so as to decrease the rate at which new flows are
collection and decrease the rate at which new flows are created. When created. When the manager, usually as part of a regular poll, becomes
the manager, usually as part of a regular poll, becomes aware that the aware that the meter is using its standby rule set, it could decrease
meter is using its standby rule set, it could decrease the interval the interval between collections. The meter should also increase its
between collections. The meter should also increase its efforts to efforts to recover flow memory so as to reduce the number of idle flows
recover flow memory so as to reduce the number of idle flows in memory. in memory. When the situation returns to normal, the manager may
When the situation returns to normal, the manager may request the meter request the meter to switch back to its normal rule set.
to switch back to its normal rule set.
5 Meter Readers 5 Meter Readers
Usage data is accumulated by a meter (e.g. in a router) as memory Usage data is accumulated by a meter (e.g. in a router) as memory
permits. It is collected at regular reporting intervals by meter permits. It is collected at regular reporting intervals by meter
readers, as specified by a manager. The collected data is recorded in a readers, as specified by a manager. The collected data is recorded in a
disk file called a FLOW DATA FILE, as a sequence of USAGE RECORDS. disk file called a FLOW DATA FILE, as a sequence of USAGE RECORDS.
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
skipping to change at page 28, line 28 skipping to change at page 29, line 28
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.
A USAGE RECORD contains the descriptions of and values for one or more A USAGE RECORD contains the descriptions of and values for one or more
flows. Quantities are counted in terms of number of packets and number flows. Quantities are counted in terms of number of packets and number
of bytes per flow. Each usage record contains the entity identifier of of bytes per flow. Each usage record contains the metered traffic group
the meter (a network address), a time stamp and a list of reported flows identifier of the meter (a set of network addresses), a time stamp and a
(FLOW DATA RECORDS). A meter reader will build up a file of usage list of reported flows (FLOW DATA RECORDS). A meter reader will build up
records by regularly collecting flow data from a meter, using this data a file of usage records by regularly collecting flow data from a meter,
to build usage records and concatenating them to the tail of a file. using this data to build usage records and concatenating them to the
Such a file is called a FLOW DATA FILE. tail of a file. Such a file is called a FLOW DATA FILE.
A usage record contains the following information in some form: A usage record contains the following information in some form:
+-------------------------------------------------------------------+ +-------------------------------------------------------------------+
| RECORD IDENTIFIERS: | | RECORD IDENTIFIERS: |
| 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 |
skipping to change at page 29, line 16 skipping to change at page 30, line 16
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
(i.e. all the active flows). One possible method of achieving this (i.e. all the active and idle flows). One possible method of achieving
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.
In normal operation the meter will be running a rule file which provides In normal operation the meter will be running a rule file which provides
the required degree of flow reporting granularity, and the meter the required degree of flow reporting granularity, and the meter
skipping to change at page 30, line 14 skipping to change at page 31, line 14
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.
- SWITCH TO SPECIFIED RULE SET: Once the rule sets have been - SPECIFY METER TASK: Once the rule sets have been downloaded, the
downloaded, the manager must instruct the meter which rule set it manager must instruct the meter which rule sets will be the
is to actually run (i.e. which is to be the current rule set), and 'current' and 'standby' ones for each task the meter is to perform.
which is to be the standby rule set.
- SET HIGH WATER MARK: A percentage value interpreted by the meter - SET HIGH WATER MARK: A percentage value interpreted by the meter
which tells the meter when to switch to its standby rule set, so as which tells the meter when to switch to its standby rule set, so as
to increase the granularity of the flows and conserve the meter's to increase the granularity of the flows and conserve the meter's
flow memory. Once this has happened, the manager may also change flow memory. Once this has happened, the manager may also change
the polling frequency or the meter's control parameters (so as to the polling frequency or the meter's control parameters (so as to
increase the rate at which the meter can recover memory from idle increase the rate at which the meter can recover memory from idle
flows). flows).
If the high traffic levels persist, the meter's normal rule set may If the high traffic levels persist, the meter's normal rule set may
have to be rewritten to permanently reduce the reporting have to be rewritten to permanently reduce the reporting
granularity. granularity.
- SET FLOW TERMINATION PARAMETERS: The meter should have the good - SET FLOW TERMINATION PARAMETERS: The meter should have the good
sense in situations where lack of resources may cause data loss to sense in situations where lack of resources may cause data loss to
purge flow records from its tables. Such records may include: purge flow records from its tables. Such records may include:
- Flows that have already been reported to at least one meter - Flows that have already been reported to all registered meter
reader, and show no activity since the last report, readers, and show no activity since the last report,
- Oldest flows, or - Oldest flows, or
- Flows with the smallest number of unreported 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.
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
skipping to change at page 31, line 9 skipping to change at page 32, line 4
- 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.
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 reporting interval must be decreased the meter is exhausted, either the collection interval must be decreased
or a coarser granularity of aggregation must be used so that more data or a coarser granularity of aggregation must be used so that the flow
fits into less space. data fits into less space.
Increasing the reporting 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
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:
- MANAGER and METER READER IDENTIFICATION: The manager should ensure - MANAGER and METER READER IDENTIFICATION: The manager should ensure
that meters report to the correct set of meter readers, and take that meters are read by the correct set of meter readers, and take
steps to prevent unauthorised access to usage information. The steps to prevent unauthorised access to usage information. The
meter readers so identified should be prepared to poll if necessary meter readers so identified should be prepared to poll if necessary
and accept data from the appropriate meters. Alternate meter and accept data from the appropriate meters. Alternate meter
readers may be identified in case both the primary manager and the readers may be identified in case both the primary manager and the
primary meter reader are unavailable. Similarly, alternate primary meter reader are unavailable. Similarly, alternate
managers may be identified. managers may be identified.
- REPORTING INTERVAL CONTROL: The usual reporting interval should be - REPORTING INTERVAL CONTROL: The usual reporting interval should be
selected to cope with normal traffic patterns. However, it may be selected to cope with normal traffic patterns. However, it may be
possible for a meter to exhaust its memory during traffic spikes possible for a meter to exhaust its memory during traffic spikes
even with a correctly set reporting interval. Some mechanism must even with a correctly set reporting interval. Some mechanism
be available for the meter to tell the manager that it is in danger should be available for the meter to tell the manager that it is in
of exhausting its memory (by declaring a 'high water' condition), danger of exhausting its memory (by declaring a 'high water'
and for the manager to arbitrate (by decreasing the polling condition), and for the manager to arbitrate (by decreasing the
interval, letting nature take its course, or by telling the meter polling interval, letting nature take its course, or by telling the
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
- Controls flow-id granularities for each interface, and - Controls flow-id granularities for each interface, 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.
skipping to change at page 32, line 24 skipping to change at page 33, line 20
- 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 buffer space. Since, to prevent counting any packet meter runs out of space for flow data. Since, to prevent counting any
twice, packets can only be counted in a single flow at any given time, packet twice, packets can only be counted in a single flow at any given
discarding records will result in the loss of information. The time, discarding records will result in the loss of information. The
mechanisms to deal with this are as follows: mechanisms to deal with this are as follows:
- METER OUTAGES: In case of impending meter outages (controlled - METER OUTAGES: In case of impending meter outages (controlled
restarts, etc.) the meter could send a trap to the manager. The restarts, etc.) the meter could send a trap to the manager. The
manager could then request one or more meter readers to pick up the manager could then request one or more meter readers to pick up the
usage record from the meter. data from the meter.
Following an uncontrolled meter outage such as a power failure, the Following an uncontrolled meter outage such as a power failure, the
meter could send a trap to the manager indicating that it has meter could send a trap to the manager indicating that it has
restarted. The manager could then download the meter's correct restarted. The manager could then download the meter's correct
rule set and advise the meter reader(s) that the meter is running rule set and advise the meter reader(s) that the meter is running
again. Alternatively, the meter reader may discover from its again. Alternatively, the meter reader may discover from its
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.
skipping to change at page 34, line 4 skipping to change at page 34, line 46
contained in the packet. (Variants on this table are "report contained in the packet. (Variants on this table are "report
source" or "report sink" only.) This strategy might be used by an source" or "report sink" only.) This strategy might be used by an
End System network to get detailed host traffic matrix usage data. End System network to get detailed host traffic matrix usage data.
- 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.
7 APPENDICES 7 Security Considerations
7.1 Appendix A: Network Characterisation 7.1 Threat Analysis
A traffic flow measurement system may be subject to the following kinds
of attacks:
- UNAUTHORIZED USE OF SYSTEM RESOURCES: An attacker may wish to gain
advantage or cause mischief (e.g. denial of service) by subverting
any of the system elements - meters, meter readers or managers.
- UNAUTHORIZED DISCLOSURE OF DATA: Any data that is sensitive to
disclosure can be read through active or passive attacks unless it
is suitably protected. Usage data may or may not be of this type.
Control messages, traps, etc. are not likely to be considered
sensitive to disclosure.
- UNAUTHORIZED ALTERATION, REPLACEMENT OR DESTRUCTION OF DATA:
Similarly, any data whose integrity is sensitive can be altered,
replaced/injected or deleted through active or passive attacks
unless it is suitably protected. Attackers may modify message
streams to falsify usage data or interfere with the proper
operation of the traffic flow measurement system. Therefore, all
messages, both those containing usage data and those containing
control data, should be considered vulnerable to such attacks.
7.2 Countermeasures
The following countermeasures are recommended to address the possible
threats enumerated above:
- UNAUTHORIZED USE OF SYSTEM RESOURCES is countered through the use
of authentication and access control services.
- UNAUTHORIZED DISCLOSURE OF DATA is countered through the use of a
confidentiality (encryption) service.
- UNAUTHORIZED ALTERATION, REPLACEMENT OR DESTRUCTION OF DATA is
countered through the use of an integrity service.
An Internet Accounting system must address all of these concerns. Since
a high degree of protection is required, the use of strong cryptographic
methodologies is recommended. The security requirements for
communication between pairs of accounting system elements are summarized
in the table below. It is assumed that meters do not communicate with
other meters, and that meter readers do not communicate directly with
other meter readers (if synchronization is required, it is handled by
the manager, see Section 2.5). Each entry in the table indicates which
kinds of security services are required. Basically, the requirements
are as follows:
Security Service Requirements for RTFM elements
+------------------------------------------------------------------+
| from\to | meter | meter reader | application | manager |
|---------+--------------+--------------+-------------+------------|
| meter | N/A | authent | N/A | authent |
| | | acc ctrl | | acc ctrl |
| | | integrity | | |
| | | confid ** | | |
|---------+--------------+--------------+-------------+------------|
| meter | authent | N/A | authent | authent |
| reader | acc ctrl | | acc ctrl | acc ctrl |
| | | | integrity | |
| | | | confid ** | |
|---------+--------------+--------------+-------------+------------|
| appl | N/A | authent | | |
| | | acc ctrl | ## | ## |
|---------+--------------+--------------+-------------+------------|
| manager | authent | authent | N/A | authent |
| | acc ctrl | acc ctrl | | acc ctrl |
| | integrity | integrity | | integrity |
+------------------------------------------------------------------+
N/A = Not Applicable ** = optional ## = outside RTFM scope
- When any two elements intercommunicate they should mutually
authenticate themselves to one another. This is indicated by
'authent' in the table. Once authentication is complete, an
element should check that the requested type of access is allowed;
this is indicated on the table by 'acc ctrl.'
- Whenever there is a transfer of information its integrity should be
protected.
- Whenever there is a transfer of usage data it should be possible to
ensure its confidentiality if it is deemed sensitive to disclosure.
This is indicated by 'confid' in the table.
Security protocols are not specified in this document. The system
elements' management and collection protocols are responsible for
providing sufficient data integrity, confidentiality, authentication and
access control services.
8 APPENDICES
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:
International | International |
Backbones/National ---------------- Backbones/National ---------------
/ \ / \
Regional/MidLevel ---------- ----------- Regional/MidLevel ---------- ----------
/ \ \ / / \ / \ \ / / \
Stub/Enterprise --- --- --- ---- ---- Stub/Enterprise --- --- --- ---- ----
||| ||| ||| |||| |||| ||| ||| ||| |||| ||||
End-Systems/Hosts xxx xxx xxx xxxx xxxx End-Systems/Hosts xxx xxx xxx xxxx xxxx
Note that mesh architectures can also be built out of these components, Note that mesh architectures can also be built out of these components,
and that these are merely descriptive terms. The nature of a single and that these are merely descriptive terms. The nature of a single
network may encompass any or all of the descriptions below, although network may encompass any or all of the descriptions below, although
some networks can be clearly identified as a single type. some networks can be clearly identified as a single type.
skipping to change at page 35, line 16 skipping to change at page 38, line 16
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
traffic flow measurement record may carry system-specific "accountable traffic flow measurement record may carry system-specific "accountable
(billable) party" labels so that meters can implement proprietary or (billable) party" 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.
7.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
network level. Whereas the hierarchy is described top-down in the network level. Whereas the hierarchy is described top-down in the
previous section, reporting requirements are more easily addressed previous section, reporting requirements are more easily addressed
bottom-up. bottom-up.
End-Systems End-Systems
Stub Networks Stub Networks
skipping to change at page 35, line 41 skipping to change at page 38, line 41
END-SYSTEMS are currently responsible for allocating network usage to END-SYSTEMS are currently responsible for allocating network usage to
end-users, if this capability is desired. From the Internet Protocol end-users, if this capability is desired. From the Internet Protocol
perspective, end-systems are the finest granularity that can be perspective, end-systems are the finest granularity that can be
identified without protocol modifications. Even if a meter violated identified without protocol modifications. Even if a meter violated
protocol boundaries and tracked higher-level protocols, not all packets protocol boundaries and tracked higher-level protocols, not all packets
could be correctly allocated by user, and the definition of user itself could be correctly allocated by user, and the definition of user itself
varies widely from operating system to operating system (e.g. how to varies widely from operating system to operating system (e.g. how to
trace network usage back to users from shared processes). trace network usage back to users from shared processes).
STUB and ENTERPRISE networks will usually collect traffic data either by STUB and ENTERPRISE networks will usually collect traffic data either by
end- system network address or network address pair if detailed end-system network address or network address pair if detailed reporting
reporting is required in the local area network. If no local reporting is required in the local area network. If no local reporting is
is required, they may record usage information in the exit router to required, they may record usage information in the exit router to track
track external traffic only. (These are the only networks which external traffic only. (These are the only networks which routinely use
routinely use attributes to perform reporting at granularities finer attributes to perform reporting at granularities finer than end-system
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
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
skipping to change at page 36, line 23 skipping to change at page 39, line 23
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.
7.3 Appendix C: List of Defined Flow Attributes 8.3 Appendix C: List of Defined Flow Attributes
This Appendix provides a checklist of the attributes defined to date; This Appendix provides a checklist of the attributes defined to date;
others will be added later as the Traffic Measurement Architecture is others will be added later as the Traffic Measurement Architecture is
further developed. further developed.
0 Null 0 Null
1 Flow Subscript Integer Flow table info 1 Flow Subscript Integer Flow table info
2 Flow Status Integer
4 Source Interface Integer Source Address 4 Source Interface Integer Source Address
5 Source Adjacent Type Integer 5 Source Adjacent Type Integer
6 Source Adjacent Address String 6 Source Adjacent Address String
7 Source Adjacent Mask String 7 Source Adjacent Mask String
8 Source Peer Type Integer 8 Source Peer Type Integer
9 Source Peer Address String 9 Source Peer Address String
10 Source Peer Mask String 10 Source Peer Mask String
11 Source Trans Type Integer 11 Source Trans Type Integer
12 Source Trans Address String 12 Source Trans Address String
skipping to change at page 37, line 6 skipping to change at page 40, line 4
14 Destination Interface Integer Destination Address 14 Destination Interface Integer Destination Address
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
26 Rule Set Number Integer Meter attribute
24 Packet Scale Factor Integer 'Other' attributes
25 Byte Scale Factor Integer
26 Rule Set Number Integer
27 Forward Bytes Counter Source-to-Dest counters 27 Forward Bytes Counter Source-to-Dest counters
28 Forward Packets Counter 28 Forward Packets Counter
29 Reverse Bytes Counter Dest-to-Source counters 29 Reverse Bytes Counter Dest-to-Source counters
30 Reverse Packets Counter 30 Reverse Packets Counter
31 First Time TimeTicks Activity times 31 First Time TimeTicks Activity times
32 Last Active Time TimeTicks 32 Last Active Time TimeTicks
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
38 Flow Class Integer 38 Flow Class Integer
39 Source Kind Integer 39 Source Kind Integer
40 Destination Kind Integer 40 Destination Kind Integer
41 Flow Kind Integer 41 Flow Kind Integer
50 MatchingStoD Integer PME variable 50 MatchingStoD Integer PME variable
51 V1 Integer Meter variables
52 V2 Integer
53 V3 Integer
54 V4 Integer
55 V5 Integer
65 65
.. 'Extended' attributes (to be defined by the RTFM working group) .. 'Extended' attributes (to be defined by the RTFM working group)
127 127
7.4 Appendix D: List of Meter Control Variables 8.4 Appendix D: List of Meter Control Variables
Current Rule Set Number Integer Meter variables:
Standby Rule Set Number Integer
High Water Mark Percentage
Flood Mark Percentage Flood Mark Percentage
Inactivity Timeout (seconds) Integer Inactivity Timeout (seconds) Integer
Last Collect Time TimeTicks
8 Security Considerations
8.1 Threat Analysis
A traffic flow measurement system may be subject to the following kinds
of attacks:
- UNAUTHORIZED USE OF SYSTEM RESOURCES: An attacker may wish to gain 'per task' variables:
advantage or cause mischief (e.g. denial of service) by subverting Current Rule Set Number Integer
any of the system elements - meters, meter readers or managers. Standby Rule Set Number Integer
High Water Mark Percentage
- UNAUTHORIZED DISCLOSURE OF DATA: Any data that is sensitive to
disclosure can be read through active or passive attacks unless it
is suitably protected. Usage data may or may not be of this type.
Control messages, traps, etc. are not likely to be considered
sensitive to disclosure.
- UNAUTHORIZED ALTERATION, REPLACEMENT OR DESTRUCTION OF DATA:
Similarly, any data whose integrity is sensitive can be altered,
replaced/injected or deleted through active or passive attacks
unless it is suitably protected. Attackers may modify message
streams to falsify usage data or interfere with the proper
operation of the traffic flow measurement system. Therefore, all
messages, both those containing usage data and those containing
control data, should be considered vulnerable to such attacks.
8.2 Countermeasures
The following countermeasures are recommended to address the possible
threats enumerated above:
- UNAUTHORIZED USE OF SYSTEM RESOURCES is countered through the use
of authentication and access control services.
- UNAUTHORIZED DISCLOSURE OF DATA is countered through the use of a
confidentiality (encryption) service.
- UNAUTHORIZED ALTERATION, REPLACEMENT OR DESTRUCTION OF DATA is
countered through the use of an integrity service.
An Internet Accounting system must address all of these concerns. Since
a high degree of protection is required, the use of strong cryptographic
methodologies is recommended. The security requirements for
communication between pairs of accounting system elements are summarized
in the table below. It is assumed that meters do not communicate with
other meters, and that meter readers do not communicate directly with
other meter readers (if synchronization is required, it is handled by
the manager, see Section 2.5). Each entry in the table indicates which
kinds of security services are required. Basically, the requirements
are as follows:
Security Service Requirements for RTFM elements
+------------------------------------------------------------------+
| from\to | meter | meter reader | application | manager |
|---------+--------------+--------------+-------------+------------|
| meter | N/A | authent | N/A | authent |
| | | acc ctrl | | acc ctrl |
| | | integrity | | |
| | | confid ** | | |
|---------+--------------+--------------+-------------+------------|
| meter | authent | N/A | authent | authent |
| reader | acc ctrl | | acc ctrl | acc ctrl |
| | | | integrity | |
| | | | confid ** | |
|---------+--------------+--------------+-------------+------------|
| appl | N/A | authent | | |
| | | acc ctrl | ## | N/A |
|---------+--------------+--------------+-------------+------------|
| manager | authent | authent | N/A | authent |
| | acc ctrl | acc ctrl | | acc ctrl |
| | integrity | integrity | | integrity |
+------------------------------------------------------------------+
N/A = Not Applicable ** = optional ## = outside RTFM scope
- When any two elements intercommunicate they should mutually
authenticate themselves to one another.
- Whenever there is a transfer of information its integrity should be
protected.
- Whenever there is a transfer of usage data it should be possible to
ensure its confidentiality if it is deemed sensitive to disclosure.
Security protocols are not specified in this document. The system 'per reader' variables:
elements' management and collection protocols are responsible for Reader Last Time TimeTicks
providing sufficient data integrity, confidentiality, authentication and
access control services.
9 Acknowledgments 9 Acknowledgments
An initial draft of this document was produced under the auspices of the An initial draft of this document was produced under the auspices of the
IETF's Internet Accounting Working Group with assistance from SNMP, RMON IETF's Internet Accounting Working Group with assistance from SNMP, RMON
and SAAG working groups. This version documents the implementation work and SAAG working groups. This version documents the implementation work
done by the Internet Accounting Working Group, and is intended to done by the Internet Accounting Working Group, and is intended to
provide a starting point for the Realtime Traffic Flow Measurement provide a starting point for the Realtime Traffic Flow Measurement
Working Group. Particular thanks are due to Stephen Stibler (IBM Working Group. Particular thanks are due to Stephen Stibler (IBM
Research) for his patient and careful comments during the preparation of Research) for his patient and careful comments during the preparation of
skipping to change at page 41, line 15 skipping to change at page 42, line 15
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
Cyndi Mills Cyndi Mills
BBN Systems and Technologies GTE Laboratories, Inc
Phone: +1 617 873 4143 Phone: +1 617 466 4278
E-mail: cmills@bbn.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
 End of changes. 115 change blocks. 
406 lines changed or deleted 438 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/