draft-ietf-rtfm-architecture-01.txt   draft-ietf-rtfm-architecture-02.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
Traffic Flow Measurement: Architecture Traffic Flow Measurement: Architecture
<draft-ietf-rtfm-architecture-01.txt> <draft-ietf-rtfm-architecture-02.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas, and documents of the Internet Engineering Task Force (IETF), its Areas, and
its Working Groups. Note that other groups may also distribute working its Working Groups. Note that other groups may also distribute working
documents as Internet-Drafts. This Internet Draft is a product of the documents as Internet-Drafts. This Internet Draft is a product of the
Realtime Traffic Flow Measurement Working Group of the IETF. Realtime Traffic Flow Measurement Working Group of the IETF.
Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts are draft documents valid for a maximum of six months.
skipping to change at page 2, line ? skipping to change at page 2, line ?
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 17 4 Meters 17
4.1 Meter Structure . . . . . . . . . . . . . . . . . . . . . . . 17 4.1 Meter Structure . . . . . . . . . . . . . . . . . . . . . . . 17
4.2 Flow Table . . . . . . . . . . . . . . . . . . . . . . . . . . 19 4.2 Flow Table . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.3 Packet Handling, Packet Matching . . . . . . . . . . . . . . . 19 4.3 Packet Handling, Packet Matching . . . . . . . . . . . . . . . 19
4.4 Rules and Rule Sets . . . . . . . . . . . . . . . . . . . . . 23 4.4 Rules and Rule Sets . . . . . . . . . . . . . . . . . . . . . 23
4.5 Maintaining the Flow Table . . . . . . . . . . . . . . . . . . 27 4.5 Maintaining the Flow Table . . . . . . . . . . . . . . . . . . 26
4.6 Handling Increasing Traffic Levels . . . . . . . . . . . . . . 28 4.6 Handling Increasing Traffic Levels . . . . . . . . . . . . . . 27
5 Meter Readers 28 5 Meter Readers 28
5.1 Identifying Flows in Flow Records . . . . . . . . . . . . . . 28 5.1 Identifying Flows in Flow Records . . . . . . . . . . . . . . 28
5.2 Usage Records, Flow Data Files . . . . . . . . . . . . . . . . 29 5.2 Usage Records, Flow Data Files . . . . . . . . . . . . . . . . 29
5.3 Meter to Meter Reader: Usage Record Transmission . . . . . . 30 5.3 Meter to Meter Reader: Usage Record Transmission . . . . . . 30
6 Managers 30 6 Managers 30
6.1 Between Manager and Meter: Control Functions . . . . . . . . 31 6.1 Between Manager and Meter: Control Functions . . . . . . . . 30
6.2 Between Manager and Meter Reader: Control Functions . . . . . 31 6.2 Between Manager and Meter Reader: Control Functions . . . . . 31
6.3 Exception Conditions . . . . . . . . . . . . . . . . . . . . . 33 6.3 Exception Conditions . . . . . . . . . . . . . . . . . . . . . 33
6.4 Standard Rule Sets . . . . . . . . . . . . . . . . . . . . . . 34 6.4 Standard Rule Sets . . . . . . . . . . . . . . . . . . . . . . 34
7 Security Considerations 35 7 Security Considerations 34
7.1 Threat Analysis . . . . . . . . . . . . . . . . . . . . . . . 35 7.1 Threat Analysis . . . . . . . . . . . . . . . . . . . . . . . 34
7.2 Countermeasures . . . . . . . . . . . . . . . . . . . . . . . 35 7.2 Countermeasures . . . . . . . . . . . . . . . . . . . . . . . 35
8 APPENDICES 37 8 APPENDICES 37
8.1 Appendix A: Network Characterisation . . . . . . . . . . . . . 37 8.1 Appendix A: Network Characterisation . . . . . . . . . . . . . 37
8.2 Appendix B: Recommended Traffic Flow Measurement Capabilities .38 8.2 Appendix B: Recommended Traffic Flow Measurement Capabilities 38
8.3 Appendix C: List of Defined Flow Attributes . . . . . . . . . 39 8.3 Appendix C: List of Defined Flow Attributes . . . . . . . . . 39
8.4 Appendix D: List of Meter Control Variables . . . . . . . . . 40 8.4 Appendix D: List of Meter Control Variables . . . . . . . . . 40
9 Acknowledgments 41 9 Acknowledgments 40
10 References 41 10 References 41
11 Author's Addresses 42 11 Author's Addresses 41
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).
skipping to change at page 4, line 39 skipping to change at page 4, line 39
Background information explaining why this approach was selected is Background information explaining why this approach was selected is
provided by the 'Internet Accounting: Background' RFC [1]. provided by the 'Internet Accounting: Background' RFC [1].
1.1 Changes Introduced Since RFC 2063 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 should be able to run multiple rule sets - A Traffic Meter can now run multiple rule sets concurrently. This
concurrently. This makes a meter much more useful, and required makes a meter much more useful, and required only minimal changes
only minimal changes to the architecture. 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 38 skipping to change at page 5, line 38
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 observe packets as they pass by a single called traffic METERS. Meters observe packets as they pass by a single
point on their way through the network and classify them into certain point on their way through the network and classify them into certain
groups. For each such group a meter will accumulate certain attributes, groups. For each such group a meter will accumulate certain attributes,
for example the numbers of packets and bytes observed for the group. for example the numbers of packets and bytes observed for the group.
These METERED TRAFFIC GROUPS may correspond to a user, a host system, These METERED TRAFFIC GROUPS may correspond to a user, a host system, a
a network, a group of networks, a particular transport address (e.g. an network, a group of networks, a particular transport address (e.g. an
IP port number), any combination of the above, etc, depending on the IP port number), any combination of the above, etc, depending on the
meter's configuration. 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 traffic information. that they provide a way of succinctly aggregating traffic 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
skipping to change at page 6, line 49 skipping to change at page 6, line 49
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: MANAGER: A traffic measurement manager is an application
configures 'meter' entities and controls 'meter reader' entities. which configures 'meter' entities and controls 'meter reader'
It sends configuration commands to the meters, and supervises the entities. It sends configuration commands to the meters, and
proper operation of each meter and meter reader. It may well be supervises the proper operation of each meter and meter reader. It
convenient to combine the functions of meter reader and manager may well be convenient to combine the functions of meter reader and
within a single network entity. manager within a single 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.
skipping to change at page 7, line 14 skipping to change at page 7, line 14
- 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
network engineering and management purposes. Examples include: network engineering and management purposes. Examples include:
- TRAFFIC FLOW MATRICES, showing the total flow rates for many of - TRAFFIC FLOW MATRICES, showing the total flow rates for many of
the possible paths within an internet. the possible paths within an internet.
- FLOW RATE FREQUENCY DISTRIBUTIONS, indicating how flow rates - FLOW RATE FREQUENCY DISTRIBUTIONS, summarizing flow rates over
vary with time. a period of time.
- USAGE DATA showing the total traffic volumes sent and received - USAGE DATA showing the total traffic volumes sent and received
by particular hosts. by particular hosts.
The operation of the traffic measurement system as a whole is best The operation of the traffic measurement system as a whole is best
understood by considering the interactions between its components. understood by considering the interactions between its components.
These are described in the following sections. These are described in the following sections.
2.2 Interaction Between METER and METER READER 2.2 Interaction Between METER and METER READER
skipping to change at page 9, line 5 skipping to change at page 9, line 5
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. flows for a particular - Which flow records are to be collected (e.g. all flows, flows for
rule set, whole flow table, flows seen since a given time, etc.). a particular rule set, flows which have been active 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 11, line 5 skipping to change at page 11, line 5
outside the scope of this architecture. outside the scope of this architecture.
3 Traffic Flows and Reporting Granularity 3 Traffic Flows and Reporting Granularity
A flow was defined in section 2.1 above in abstract terms as follows: A flow was defined in section 2.1 above in abstract terms as follows:
"A TRAFFIC FLOW is an artifical logical equivalent to a call or "A TRAFFIC FLOW is an artifical logical equivalent to a call or
connection, belonging to a (user-specieied) METERED TRAFFIC connection, belonging to a (user-specieied) METERED TRAFFIC
GROUP." GROUP."
In practical terms, a flow is a stream of packets passing across a In practical terms, a flow is a stream of packets observed by the meter
network between two end points (or being sent from a single end point), as they pass across a network between two end points (or from a single
which have been summarized by a traffic meter for analysis purposes. end point), 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 header), and the number network layers (extracted from the packet header), and the number
skipping to change at page 13, line 23 skipping to change at page 13, line 27
with a particular flow either through the current rule set or by with a particular flow either through the current rule set or by
proprietary means within a meter, for example via protocol exchanges proprietary means within a meter, for example via protocol exchanges
with one or more (multi-user) hosts. At this time a subscriber ID is an with one or more (multi-user) hosts. At this time a subscriber ID is an
arbitrary text string; later versions of the architecture may specify arbitrary text string; later versions of the architecture may specify
its contents in more detail. its contents in more detail.
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 its level of detail. A coarser granularity means a
means a greater level of aggregation; finer granularity means a greater greater level of aggregation; finer granularity means a greater level of
level of detail. Thus, the number of flows measured (and stored) at a detail. Thus, the number of flows measured (and stored) at a meter can
meter can be regulated by changing the granularity of the metered be regulated by changing the granularity of their attributes. Flows are
traffic group, the attributes, or the inactivity time interval. Flows like an adjustable pipe - many fine-granularity streams can carry the
are like an adjustable pipe - many fine-granularity streams can carry data with each stream measured individually, or data can be bundled in
the data with each stream measured individually, or data can be bundled one coarse-granularity pipe. Time granularity may be controlled by
in one coarse-granularity pipe. varying the reporting interval, i.e. the time between meter readings.
Flow granularity is controlled by adjusting the level of detail at which Flow granularity is controlled by adjusting the level of detail for the
the following are determined: following:
- The metered traffic group (address attributes, discussed above). - The metered traffic group (address attributes, discussed above).
- The categorisation of packets (other attributes, discussed below). - The categorisation of packets (other attributes, discussed below).
- The lifetime/duration of flows (the reporting interval needs to be - The lifetime/duration of flows (the reporting interval needs to be
short enough to measure them with sufficient precision). short enough to measure them with sufficient precision).
The set of rules controlling the determination of each packet's metered The set of rules controlling the determination of each packet's metered
traffic group is known as the meter's CURRENT RULE SET. As will be traffic group is known as the meter's CURRENT RULE SET. As will be
skipping to change at page 17, line 15 skipping to change at page 17, line 15
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
packets as they pass by) and running a 'traffic meter' program. packets as they pass by) and running a traffic meter program. The
The metering point is the LAN segment to which the meter is metering point is the LAN segment to which the meter is attached.
attached.
- A multiprocessing system with one or more network interfaces, with - A multiprocessing system with one or more network interfaces, with
drivers enabling a traffic meter program to see packets. In this drivers enabling a traffic meter program to see packets. In this
case the system provides multiple metering points - traffic flows case the system provides multiple metering points - traffic flows
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.
skipping to change at page 19, line 13 skipping to change at page 19, line 7
one for each rule set. one for each rule set.
4.2 Flow Table 4.2 Flow Table
Every traffic meter maintains a table of TRAFFIC FLOW RECORDS for flows Every traffic meter maintains a table of TRAFFIC FLOW RECORDS for flows
seen by the meter. A flow record contains attribute values for its seen by the meter. A flow record contains attribute values for its
flow, including: flow, including:
- Addresses for the flow's source and destination. These include - Addresses for the flow's source and destination. These include
addresses and masks for various network layers (extracted from the addresses and masks for various network layers (extracted from the
packet), and the number of the interface on which the packet was packet), and the identity of the interface on which the packet was
observed. observed.
- First and last times when packets were seen for this flow. - First and last times when packets were seen for this flow.
- Counts for 'forward' (source to destination) and 'backward' - Counts for 'forward' (source to destination) and 'backward'
(destination to source) components of the flow's traffic. (destination to source) components of the flow's traffic.
- Other attributes, e.g. state of the flow record (discussed below). - Other attributes, e.g. state of the flow record (discussed below).
The state of a flow record may be: The state of a flow record may be:
skipping to change at page 20, line 20 skipping to change at page 20, line 13
record can then be updated. record can then be updated.
For example, the rule set could specify that packets to or from any host For example, the rule set could specify that packets to or from any host
in IP network 130.216 are to be counted. It could also specify that in IP network 130.216 are to be counted. It could also specify that
flow records are to be created for every pair of 24-bit (Class C) flow records are to be created for every pair of 24-bit (Class C)
subnets within network 130.216. subnets within network 130.216.
Each packet's match key is passed to the meter's PATTERN MATCHING ENGINE Each packet's match key is passed to the meter's PATTERN MATCHING ENGINE
(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 source (S) and destination (D) interface
destination address (D) values. It does not, however, contain any identities, address values and masks.
attribute masks for its attributes, only their values.
If measured flows were unidirectional, i.e. only counted packets If measured flows were unidirectional, i.e. only counted packets
travelling in one direction, the matching process would be simple. The travelling in one direction, the matching process would be simple. The
PME would be called once to match the packet. Any flow key produced by PME would be called once to match the packet. Any flow key produced by
a successful match would be used to find the flow's record in the flow a successful match would be used to find the flow's record in the flow
table, and that flow's counters would be updated. table, and that flow's counters would be updated.
Flows are, however, bidirectional, reflecting the forward and reverse Flows are, however, bidirectional, reflecting the forward and reverse
packets of a protocol interchange or 'session.' Maintaining two sets of packets of a protocol interchange or 'session.' Maintaining two sets of
counters in the meter's flow record makes the resulting flow data much counters in the meter's flow record makes the resulting flow data much
skipping to change at page 23, line 4 skipping to change at page 22, line 49
will contain a sequence of tests for all the 'usual' source addresses; will contain a sequence of tests for all the 'usual' source addresses;
follwed by a rule which will execute a 'NoMatch' action. If the match follwed by a rule which will execute a 'NoMatch' action. If the match
fails in the S->D direction, the NoMatch action will cause it to be fails in the S->D direction, the NoMatch action will cause it to be
retried. If it fails in the D->S direction, the packet can be counted retried. If it fails in the D->S direction, the packet can be counted
as an 'unusual' packet. as an 'unusual' packet.
To count such an 'unusual' packet we need to know the matching To count such an 'unusual' packet we need to know the matching
direction: the MatchingStoD attribute provides this. To use it, one direction: the MatchingStoD attribute provides this. To use it, one
follows the source address tests with a rule which tests whether the follows the source address tests with a rule which tests whether the
matching direction is S->D (MatchingStoD value is 1). If so, a matching direction is S->D (MatchingStoD value is 1). If so, a
'NoMatch' action is executed. Otherwise, the packet has failed to match 'NoMatch' action is executed. Otherwise, the packet has failed to match
in both directions; we can Push whatever attribute values are of in both directions; we can Push whatever attribute values are of
interest and count the 'unusual' packet. interest and count the 'unusual' packet.
4.4 Rules and Rule Sets 4.4 Rules and Rule Sets
A rule set is an array of rules. Rule sets are held within a meter as A rule set is an array of rules. Rule sets are held within a meter as
entries in an array of rule sets. entries in an array of rule sets.
Rule set 1 (the first entry in the rule set table) is built in to the Rule set 1 (the first entry in the rule set table) is built-in to the
meter and cannot be changed. It is run when the meter is started up, meter and cannot be changed. It is run when the meter is started up,
and provides a very coarse reporting granularity; it is mainly useful and provides a very coarse reporting granularity; it is mainly useful
for verifying that the meter is running, before a 'useful' rule set is for verifying that the meter is running, before a 'useful' rule set is
downloaded to it. downloaded to it.
A meter also maintains an array of 'tasks,' which specify what rule sets A meter also maintains an array of 'tasks,' which specify what rule sets
the meter is running. Each task has a 'current' rule set (the one which the meter is running. Each task has a 'current' rule set (the one which
it normally uses), and a 'standby' rule set (which will be used when the 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 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 use rule set 0, it will cease measuring; all packets will be ignored
skipping to change at page 31, line 18 skipping to change at page 30, line 48
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.
- SPECIFY METER TASK: Once the rule sets have been downloaded, the - SPECIFY METER TASK: Once the rule sets have been downloaded, the
manager must instruct the meter which rule sets will be the manager must instruct the meter which rule sets will be the
'current' and 'standby' ones for each task the meter is to perform. 'current' and 'standby' ones for each task the meter is to perform.
- SET HIGH WATER MARK: A percentage value interpreted by the meter - SET HIGH WATER MARK: A percentage of the flow table capacity, used
which tells the meter when to switch to its standby rule set, so as by the meter to determine when to switch to its standby rule set
to increase the granularity of the flows and conserve the meter's (so as to increase the granularity of the flows and conserve the
flow memory. Once this has happened, the manager may also change meter's flow memory). Once this has happened, the manager may also
the polling frequency or the meter's control parameters (so as to change the polling frequency or the meter's control parameters (so
increase the rate at which the meter can recover memory from idle as to increase the rate at which the meter can recover memory from
flows). idle 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 all registered meter - Flows that have already been reported to all registered meter
skipping to change at page 32, line 4 skipping to change at page 31, line 33
- 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 collection interval must be decreased the meter is exhausted, either the collection interval must be decreased
or a coarser granularity of aggregation must be used so that the flow or a coarser granularity of aggregation must be used to reduce the
data fits into less space. number of active flows.
Increasing the collection interval effectively stores data in the meter; Increasing the collection interval effectively stores data in the meter;
usage data in transit is limited by the effective bandwidth of the usage data in transit is limited by the effective bandwidth of the
virtual link between the meter and the meter reader, and since these virtual link between the meter and the meter reader, and since these
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
skipping to change at page 32, line 51 skipping to change at page 32, line 32
condition), and for the manager to arbitrate (by decreasing the condition), and for the manager to arbitrate (by decreasing the
polling interval, letting nature take its course, or by telling the polling interval, letting nature take its course, or by telling the
meter to ask for help sooner next time). meter to ask for help sooner next time).
- GRANULARITY CONTROL: Granularity control is a catch-all for all the - GRANULARITY CONTROL: Granularity control is a catch-all for all the
parameters that can be tuned and traded to optimise the system's parameters that can be tuned and traded to optimise the system's
ability to reliably measure and store information on all the ability to reliably measure and store information on all the
traffic (or as close to all the traffic as an administration traffic (or as close to all the traffic as an administration
requires). Granularity requires). Granularity
- Controls flow-id granularities for each interface, and - Controls the amount of address information identifying each
flow, and
- Determines the number of buckets into which user traffic will - Determines the number of buckets into which user traffic will
be lumped together. be lumped together.
Since granularity is controlled by the meter's current rule set, Since granularity is controlled by the meter's current rule set,
the manager can only change it by requesting the meter to switch to the manager can only change it by requesting the meter to switch to
a different rule set. The new rule set could be downloaded when a different rule set. The new rule set could be downloaded when
required, or it could have been downloaded as part of the meter's required, or it could have been downloaded as part of the meter's
initial configuration. initial configuration.
- FLOW LIFETIME CONTROL: Flow termination parameters include timeout - FLOW LIFETIME CONTROL: Flow termination parameters include timeout
parameters for obsoleting inactive flows and removing them from parameters for obsoleting inactive flows and removing them from
tables, and maximum flow lifetimes. This is intertwined with tables, and maximum flow lifetimes. This is intertwined with
reporting interval and granularity, and must be set in accordance reporting interval and granularity, and must be set in accordance
with the other parameters. with the other parameters.
6.3 Exception Conditions 6.3 Exception Conditions
Exception conditions must be handled, particularly occasions when the Exception conditions must be handled, particularly occasions when the
meter runs out of space for flow data. Since, to prevent counting any meter runs out of space for flow data. Since - to prevent an active
packet twice, packets can only be counted in a single flow at any given task from counting any packet twice - packets can only be counted in a
time, discarding records will result in the loss of information. The single flow, discarding records will result in the loss of information.
mechanisms to deal with this are as follows: The 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
data 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
skipping to change at page 34, line 9 skipping to change at page 33, line 41
reader is restarted. reader is restarted.
- MANAGER OUTAGES: If the manager fails for any reason, the meter - MANAGER OUTAGES: If the manager fails for any reason, the meter
should continue measuring and the meter reader(s) should keep should continue measuring and the meter reader(s) should keep
gathering usage records. gathering usage records.
- BUFFER PROBLEMS: The network manager may realise that there is a - BUFFER PROBLEMS: The network manager may realise that there is a
'low memory' condition in the meter. This can usually be 'low memory' condition in the meter. This can usually be
attributed to the interaction between the following controls: attributed to the interaction between the following controls:
- The reporting interval is too infrequent, - The reporting interval is too infrequent, or
- The reporting granularity is too fine, or
- The throughput/bandwidth of circuits carrying the usage data is - The reporting granularity is too fine.
too low.
The manager may change any of these parameters in response to the Either of these may be exacerbated by low throughput or bandwidth
meter (or meter reader's) plea for help. of circuits carrying the usage data. The manager may change any of
these parameters in response to the meter (or meter reader's) plea
for help.
6.4 Standard Rule Sets 6.4 Standard Rule Sets
Although the rule table is a flexible tool, it can also become very Although the rule table is a flexible tool, it can also become very
complex. It may be helpful to develop some rule sets for common complex. It may be helpful to develop some rule sets for common
applications: applications:
- PROTOCOL TYPE: The meter records packets by protocol type. This - PROTOCOL TYPE: The meter records packets by protocol type. This
will be the default rule table for Traffic Flow Meters. will be the default rule table for Traffic Flow Meters.
skipping to change at page 35, line 45 skipping to change at page 35, line 34
- UNAUTHORIZED USE OF SYSTEM RESOURCES is countered through the use - UNAUTHORIZED USE OF SYSTEM RESOURCES is countered through the use
of authentication and access control services. of authentication and access control services.
- UNAUTHORIZED DISCLOSURE OF DATA is countered through the use of a - UNAUTHORIZED DISCLOSURE OF DATA is countered through the use of a
confidentiality (encryption) service. confidentiality (encryption) service.
- UNAUTHORIZED ALTERATION, REPLACEMENT OR DESTRUCTION OF DATA is - UNAUTHORIZED ALTERATION, REPLACEMENT OR DESTRUCTION OF DATA is
countered through the use of an integrity service. countered through the use of an integrity service.
An Internet Accounting system must address all of these concerns. Since A Traffic Measurement system must address all of these concerns. Since
a high degree of protection is required, the use of strong cryptographic a high degree of protection is required, the use of strong cryptographic
methodologies is recommended. The security requirements for methodologies is recommended. The security requirements for
communication between pairs of accounting system elements are summarized communication between pairs of traffic measurmement system elements are
in the table below. It is assumed that meters do not communicate with summarized in the table below. It is assumed that meters do not
other meters, and that meter readers do not communicate directly with communicate with other meters, and that meter readers do not communicate
other meter readers (if synchronization is required, it is handled by directly with other meter readers (if synchronization is required, it is
the manager, see Section 2.5). Each entry in the table indicates which handled by the manager, see Section 2.5). Each entry in the table
kinds of security services are required. Basically, the requirements indicates which kinds of security services are required. Basically, the
are as follows: requirements are as follows:
Security Service Requirements for RTFM elements Security Service Requirements for RTFM elements
+------------------------------------------------------------------+ +------------------------------------------------------------------+
| from\to | meter | meter reader | application | manager | | from\to | meter | meter reader | application | manager |
|---------+--------------+--------------+-------------+------------| |---------+--------------+--------------+-------------+------------|
| meter | N/A | authent | N/A | authent | | meter | N/A | authent | N/A | authent |
| | | acc ctrl | | acc ctrl | | | | acc ctrl | | acc ctrl |
| | | integrity | | | | | | integrity | | |
| | | confid ** | | | | | | confid ** | | |
|---------+--------------+--------------+-------------+------------| |---------+--------------+--------------+-------------+------------|
| meter | authent | N/A | authent | authent | | meter | authent | N/A | authent | authent |
| reader | acc ctrl | | acc ctrl | acc ctrl | | reader | acc ctrl | | acc ctrl | acc ctrl |
| | | | integrity | | | | | | integrity | |
| | | | confid ** | | | | | | confid ** | |
|---------+--------------+--------------+-------------+------------| |---------+--------------+--------------+-------------+------------|
| appl | N/A | authent | | | | appl | N/A | authent | | |
| | | acc ctrl | ## | ## | | | | acc ctrl | ## | ## |
|---------+--------------+--------------+-------------+------------| |---------+--------------+--------------+-------------+------------|
| manager | authent | authent | N/A | authent | | manager | authent | authent | ## | authent |
| | acc ctrl | acc ctrl | | acc ctrl | | | acc ctrl | acc ctrl | | acc ctrl |
| | integrity | integrity | | integrity | | | integrity | integrity | | integrity |
+------------------------------------------------------------------+ +------------------------------------------------------------------+
N/A = Not Applicable ** = optional ## = outside RTFM scope N/A = Not Applicable ** = optional ## = outside RTFM scope
- When any two elements intercommunicate they should mutually - When any two elements intercommunicate they should mutually
authenticate themselves to one another. This is indicated by authenticate themselves to one another. This is indicated by
'authent' in the table. Once authentication is complete, an 'authent' in the table. Once authentication is complete, an
element should check that the requested type of access is allowed; element should check that the requested type of access is allowed;
skipping to change at page 38, line 11 skipping to change at page 38, line 4
STUB/ENTERPRISE networks connect hosts and local area networks. STUB/ENTERPRISE networks connect hosts and local area networks.
STUB/ENTERPRISE networks are SUBSCRIBERS to regional and backbone STUB/ENTERPRISE networks are SUBSCRIBERS to regional and backbone
networks. networks.
END SYSTEMS, colloquially HOSTS, are SUBSCRIBERS to any of the above END SYSTEMS, colloquially HOSTS, are SUBSCRIBERS to any of the above
networks. networks.
Providing a uniform identification of the SUBSCRIBER in finer Providing a uniform identification of the SUBSCRIBER in finer
granularity than that of end-system, (e.g. user/account), is beyond the granularity than that of end-system, (e.g. user/account), is beyond the
scope of the current architecture, although an optional attribute in the scope of the current architecture, although an optional attribute in the
traffic flow measurement record may carry system-specific "accountable
(billable) party" labels so that meters can implement proprietary or traffic flow measurement record may carry system-specific 'user
identification' labels so that meters can implement proprietary or
non-standard schemes for the attribution of network traffic to non-standard schemes for the attribution of network traffic to
responsible parties. responsible parties.
8.2 Appendix B: Recommended Traffic Flow Measurement Capabilities 8.2 Appendix B: Recommended Traffic Flow Measurement Capabilities
Initial recommended traffic flow measurement conventions are outlined Initial recommended traffic flow measurement conventions are outlined
here according to the following Internet building blocks. It is here according to the following Internet building blocks. It is
important to understand what complexity reporting introduces at each important to understand what complexity reporting introduces at each
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
skipping to change at page 40, line 4 skipping to change at page 39, line 45
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 26 Rule Set Number Integer Meter attribute
27 Forward Bytes Counter Source-to-Dest counters 27 Forward Bytes Integer Source-to-Dest counters
28 Forward Packets Counter 28 Forward Packets Integer
29 Reverse Bytes Counter Dest-to-Source counters 29 Reverse Bytes Integer Dest-to-Source counters
30 Reverse Packets Counter 30 Reverse Packets Integer
31 First Time TimeTicks Activity times 31 First Time Timestamp Activity times
32 Last Active Time TimeTicks 32 Last Active Time Timestamp
33 Source Subscriber ID String Session attributes 33 Source Subscriber ID String Session attributes
34 Destination Subscriber ID String 34 Destination Subscriber ID String
35 Session ID String 35 Session ID String
36 Source Class Integer 'Computed' attributes 36 Source Class Integer 'Computed' attributes
37 Destination Class Integer 37 Destination Class Integer
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
skipping to change at page 40, line 41 skipping to change at page 40, line 37
Meter variables: Meter variables:
Flood Mark Percentage Flood Mark Percentage
Inactivity Timeout (seconds) Integer Inactivity Timeout (seconds) Integer
'per task' variables: 'per task' variables:
Current Rule Set Number Integer Current Rule Set Number Integer
Standby Rule Set Number Integer Standby Rule Set Number Integer
High Water Mark Percentage High Water Mark Percentage
'per reader' variables: 'per reader' variables:
Reader Last Time TimeTicks Reader Last Time Timestamp
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
 End of changes. 38 change blocks. 
89 lines changed or deleted 87 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/