draft-ietf-rtfm-architecture-06.txt   draft-ietf-rtfm-architecture-07.txt 
Internet Engineering Task Force Brownlee, Mills, Ruth Internet Engineering Task Force Nevil Brownlee
INTERNET-DRAFT The University of Auckland INTERNET-DRAFT The University of Auckland
Cyndi Mills Cyndi Mills
GTE Laboratories, Inc GTE Laboratories, Inc
Greg Ruth Greg Ruth
GTE Laboratories, Inc GTE Laboratories, Inc
Expires November 1999
June 99
Expires December 99
Traffic Flow Measurement: Architecture Traffic Flow Measurement: Architecture
<draft-ietf-rtfm-architecture-06.txt> <draft-ietf-rtfm-architecture-07.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet-Drafts. may also distribute working documents as Internet-Drafts.
skipping to change at page 2, line ? skipping to change at page 2, line ?
This Internet Draft is a product of the Realtime Traffic Flow This Internet Draft is a product of the Realtime Traffic Flow
Measurement Working Group of the IETF. Measurement Working Group of the IETF.
Abstract Abstract
This document provides a general framework for describing network This document provides a general framework for describing network
traffic flows, presents an architecture for traffic flow measurement and traffic flows, presents an architecture for traffic flow measurement and
reporting, discusses how this relates to an overall network traffic flow reporting, discusses how this relates to an overall network traffic flow
architecture and indicates how it can be used within the Internet. architecture and indicates how it can be used within the Internet.
INTERNET-DRAFT Traffic Flow Measurement: Architecture May 99 INTERNET-DRAFT Traffic Flow Measurement: Architecture June 99
Contents Contents
1 Statement of Purpose and Scope 3 1 Statement of Purpose and Scope 2
1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2 Traffic Flow Measurement Architecture 5 2 Traffic Flow Measurement Architecture 4
2.1 Meters and Traffic Flows . . . . . . . . . . . . . . . . . . . 5 2.1 Meters and Traffic Flows . . . . . . . . . . . . . . . . . . . 4
2.2 Interaction Between METER and METER READER . . . . . . . . . . 7 2.2 Interaction Between METER and METER READER . . . . . . . . . . 6
2.3 Interaction Between MANAGER and METER . . . . . . . . . . . . 7 2.3 Interaction Between MANAGER and METER . . . . . . . . . . . . 6
2.4 Interaction Between MANAGER and METER READER . . . . . . . . . 8 2.4 Interaction Between MANAGER and METER READER . . . . . . . . . 7
2.5 Multiple METERs or METER READERs . . . . . . . . . . . . . . . 9 2.5 Multiple METERs or METER READERs . . . . . . . . . . . . . . . 8
2.6 Interaction Between MANAGERs (MANAGER - MANAGER) . . . . . . . 10 2.6 Interaction Between MANAGERs (MANAGER - MANAGER) . . . . . . . 9
2.7 METER READERs and APPLICATIONs . . . . . . . . . . . . . . . . 10 2.7 METER READERs and APPLICATIONs . . . . . . . . . . . . . . . . 9
3 Traffic Flows and Reporting Granularity 10 3 Traffic Flows and Reporting Granularity 9
3.1 Flows and their Attributes . . . . . . . . . . . . . . . . . . 11 3.1 Flows and their Attributes . . . . . . . . . . . . . . . . . . 10
3.2 Granularity of Flow Measurements . . . . . . . . . . . . . . . 13 3.2 Granularity of Flow Measurements . . . . . . . . . . . . . . . 12
3.3 Rolling Counters, Timestamps, Report-in-One-Bucket-Only . . . 15 3.3 Rolling Counters, Timestamps, Report-in-One-Bucket-Only . . . 14
4 Meters 17 4 Meters 16
4.1 Meter Structure . . . . . . . . . . . . . . . . . . . . . . . 17 4.1 Meter Structure . . . . . . . . . . . . . . . . . . . . . . . 16
4.2 Flow Table . . . . . . . . . . . . . . . . . . . . . . . . . . 19 4.2 Flow Table . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.3 Packet Handling, Packet Matching . . . . . . . . . . . . . . . 19 4.3 Packet Handling, Packet Matching . . . . . . . . . . . . . . . 18
4.4 Rules and Rule Sets . . . . . . . . . . . . . . . . . . . . . 23 4.4 Rules and Rule Sets . . . . . . . . . . . . . . . . . . . . . 22
4.5 Maintaining the Flow Table . . . . . . . . . . . . . . . . . . 28 4.5 Maintaining the Flow Table . . . . . . . . . . . . . . . . . . 27
4.6 Handling Increasing Traffic Levels . . . . . . . . . . . . . . 29 4.6 Handling Increasing Traffic Levels . . . . . . . . . . . . . . 28
5 Meter Readers 29 5 Meter Readers 28
5.1 Identifying Flows in Flow Records . . . . . . . . . . . . . . 30 5.1 Identifying Flows in Flow Records . . . . . . . . . . . . . . 29
5.2 Usage Records, Flow Data Files . . . . . . . . . . . . . . . . 30 5.2 Usage Records, Flow Data Files . . . . . . . . . . . . . . . . 29
5.3 Meter to Meter Reader: Usage Record Transmission . . . . . . . 31 5.3 Meter to Meter Reader: Usage Record Transmission . . . . . . . 30
6 Managers 32 6 Managers 31
6.1 Between Manager and Meter: Control Functions . . . . . . . . . 32 6.1 Between Manager and Meter: Control Functions . . . . . . . . . 31
6.2 Between Manager and Meter Reader: Control Functions . . . . . 33 6.2 Between Manager and Meter Reader: Control Functions . . . . . 32
6.3 Exception Conditions . . . . . . . . . . . . . . . . . . . . . 34 6.3 Exception Conditions . . . . . . . . . . . . . . . . . . . . . 33
6.4 Standard Rule Sets . . . . . . . . . . . . . . . . . . . . . . 35 6.4 Standard Rule Sets . . . . . . . . . . . . . . . . . . . . . . 34
7 Security Considerations 36 7 Security Considerations 35
7.1 Threat Analysis . . . . . . . . . . . . . . . . . . . . . . . 36 7.1 Threat Analysis . . . . . . . . . . . . . . . . . . . . . . . 35
7.2 Countermeasures . . . . . . . . . . . . . . . . . . . . . . . 37 7.2 Countermeasures . . . . . . . . . . . . . . . . . . . . . . . 36
8 IANA Considerations 39 8 IANA Considerations 38
8.1 PME Opcodes . . . . . . . . . . . . . . . . . . . . . . . . . 39 8.1 PME Opcodes . . . . . . . . . . . . . . . . . . . . . . . . . 38
8.2 RTFM Attributes . . . . . . . . . . . . . . . . . . . . . . . 39 8.2 RTFM Attributes . . . . . . . . . . . . . . . . . . . . . . . 38
9 APPENDICES 40 9 APPENDICES 39
9.1 Appendix A: Network Characterisation . . . . . . . . . . . . . 40 9.1 Appendix A: Network Characterisation . . . . . . . . . . . . 39
9.2 Appendix B: Recommended Traffic Flow Measurement Capabilities 41 9.2 Appendix B: Recommended Traffic Flow Measurement Capabilities 40
9.3 Appendix C: List of Defined Flow Attributes . . . . . . . . . 42 9.3 Appendix C: List of Defined Flow Attributes . . . . . . . . . 41
9.4 Appendix D: List of Meter Control Variables . . . . . . . . . 43 9.4 Appendix D: List of Meter Control Variables . . . . . . . . . 42
9.5 Appendix E: Changes Introduced Since RFC 2063 . . . . . . . . 44 9.5 Appendix E: Changes Introduced Since RFC 2063 . . . . . . . . 43
INTERNET-DRAFT Traffic Flow Measurement: Architecture May 99 INTERNET-DRAFT Traffic Flow Measurement: Architecture June 99
10 Acknowledgments 44 10 Acknowledgments 43
11 References 45 11 References 44
12 Author's Addresses 45 12 Author's Addresses 44
1 Statement of Purpose and Scope 1 Statement of Purpose and Scope
1.1 Introduction 1.1 Introduction
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 protocol, - The traffic flow model can be consistently applied to any protocol,
using address attributes in any combination at the adjacent, using address attributes in any combination at the 'adjacent' (see
network and transport layers of the networking stack. below), network and transport layers of the networking stack.
- Traffic flow attributes are defined in such a way that they are - Traffic flow attributes are defined in such a way that they are
valid for multiple networking protocol stacks, and that traffic valid for multiple networking protocol stacks, and that traffic
flow measurement implementations are useful in multi-protocol flow measurement implementations are useful in multi-protocol
environments. environments.
- Users may specify their traffic flow measurement requirements by - Users may specify their traffic flow measurement requirements by
writing 'rule sets,' allowing them to collect the flow data they writing 'rule sets,' allowing them to collect the flow data they
need while ignoring other traffic. need while ignoring other traffic.
- The data reduction effort to produce requested traffic flow - The data reduction effort to produce requested traffic flow
information is placed as near as possible to the network information is placed as near as possible to the network
measurement point. This minimises the volume of data to be measurement point. This minimises the volume of data to be
obtained (and transmitted across the network for storage), and obtained (and transmitted across the network for storage), and
reduces the amount of processing required in traffic flow analysis reduces the amount of processing required in traffic flow analysis
applications. applications.
'Adjacent' (as used above) is a layer-neutral term for the next layer
down in a particular instantiation of protocol layering. Although
'adjacent' will usually imply the link layer (MAC addresses), it does
not implicitly advocate or dismiss any particular form of tunnelling or
layering.
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:
INTERNET-DRAFT Traffic Flow Measurement: Architecture June 99
- Understanding the behaviour of existing networks, - Understanding the behaviour of existing networks,
- Planning for network development and expansion, - Planning for network development and expansion,
- Quantification of network performance, - Quantification of network performance,
INTERNET-DRAFT Traffic Flow Measurement: Architecture May 99
- Verifying the quality of network service, and - Verifying the quality of network service, and
- Attribution of network usage to users. - Attribution of network usage to users.
The traffic flow measurement architecture is deliberately structured The traffic flow measurement architecture is deliberately structured
using address attributes which are defined in a consistent way at the using address attributes which are defined in a consistent way at the
Adjacent, Network and Transport layers of the networking stack, allowing Adjacent, Network and Transport layers of the networking stack, allowing
specific implementations of the architecture to be used effectively in specific implementations of the architecture to be used effectively in
multi-protocol environments. Within this document the term 'usage data' multi-protocol environments. Within this document the term 'usage data'
is used as a generic term for the data obtained using the traffic flow is used as a generic term for the data obtained using the traffic flow
skipping to change at page 4, line 51 skipping to change at page 5, line 5
A cost recovery structure decides "who pays for what." The major issue A cost recovery structure decides "who pays for what." The major issue
here is how to construct a tariff (who gets billed, how much, for which here is how to construct a tariff (who gets billed, how much, for which
things, based on what information, etc). Tariff issues include things, based on what information, etc). Tariff issues include
fairness, predictability (how well can subscribers forecast their fairness, predictability (how well can subscribers forecast their
network charges), practicality (of gathering the data and administering network charges), practicality (of gathering the data and administering
the tariff), incentives (e.g. encouraging off-peak use), and cost the tariff), incentives (e.g. encouraging off-peak use), and cost
recovery goals (100% recovery, subsidisation, profit making). Issues recovery goals (100% recovery, subsidisation, profit making). Issues
such as these are not covered here. such as these are not covered here.
Background information explaining why this approach was selected is INTERNET-DRAFT Traffic Flow Measurement: Architecture June 99
provided by the 'Internet Accounting: Background' RFC [2].
INTERNET-DRAFT Traffic Flow Measurement: Architecture May 99 Background information explaining why this approach was selected is
provided by the 'Internet Accounting Background' RFC [2].
2 Traffic Flow Measurement Architecture 2 Traffic Flow Measurement Architecture
A traffic flow measurement system is used by Network Operations A traffic flow measurement system is used by Network Operations
personnel to aid in managing and developing a network. It provides a personnel to aid in managing and developing a network. It provides a
tool for measuring and understanding the network's traffic flows. This tool for measuring and understanding the network's traffic flows. This
information is useful for many purposes, as mentioned in section 1 information is useful for many purposes, as mentioned in section 1
(above). (above).
The following sections outline a model for traffic flow measurement, The following sections outline a model for traffic flow measurement,
skipping to change at page 5, line 32 skipping to change at page 5, line 35
point on their way through the network and classify them into certain point on their way through the network and classify them into certain
groups. For each such group a meter will accumulate certain attributes, groups. For each such group a meter will accumulate certain attributes,
for example the numbers of packets and bytes observed for the group. for example the numbers of packets and bytes observed for the group.
These METERED TRAFFIC GROUPS may correspond to a user, a host system, a These METERED TRAFFIC GROUPS may correspond to a user, a host system, a
network, a group of networks, a particular transport address (e.g. an network, a group of networks, a particular transport address (e.g. an
IP port number), any combination of the above, etc, depending on the IP port number), any combination of the above, etc, depending on the
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 'Internet Accounting
Measurement: Background' RFC [2]. An important aspect of meters is Background' RFC [2]. An important aspect of meters is that they provide
that they provide a way of succinctly aggregating traffic information. 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
TRAFFIC FLOW, which is like an artificial logical equivalent to a call TRAFFIC FLOW, which is like an artificial logical equivalent to a call
or connection. A flow is a portion of traffic, delimited by a start and or connection. A flow is a portion of traffic, delimited by a start and
stop time, that belongs to one of the metered traffic groups mentioned stop time, that belongs to one of the metered traffic groups mentioned
above. Attribute values (source/destination addresses, packet counts, above. Attribute values (source/destination addresses, packet counts,
byte counts, etc.) associated with a flow are aggregate quantities byte counts, etc.) associated with a flow are aggregate quantities
reflecting events which take place in the DURATION between the start and reflecting events which take place in the DURATION between the start and
stop times. The start time of a flow is fixed for a given flow; the stop times. The start time of a flow is fixed for a given flow; the
stop time may increase with the age of the flow. stop time may increase with the age of the flow.
For connectionless network protocols such as IP there is by definition For connectionless network protocols such as IP there is by definition
no way to tell whether a packet with a particular source/destination no way to tell whether a packet with a particular source/destination
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
INTERNET-DRAFT Traffic Flow Measurement: Architecture June 99
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
INTERNET-DRAFT Traffic Flow Measurement: Architecture May 99
economical and practical way to measure network traffic and subdivide it economical and practical way to measure network traffic and subdivide it
into well-defined groups. into well-defined groups.
Usage information which is not derivable from traffic flows may also be Usage information which is not derivable from traffic flows may also be
of interest. For example, an application may wish to record accesses to of interest. For example, an application may wish to record accesses to
various different information resources or a host may wish to record the various different information resources or a host may wish to record the
username (subscriber id) for a particular network session. Provision is username (subscriber id) for a particular network session. Provision is
made in the traffic flow architecture to do this. In the future the made in the traffic flow architecture to do this. In the future the
measurement model may be extended to gather such information from measurement model may be extended to gather such information from
applications and hosts so as to provide values for higher-layer flow applications and hosts so as to provide values for higher-layer flow
attributes. attributes.
As well as FLOWS and METERS, the traffic flow measurement model includes As well as FLOWS and METERS, the traffic flow measurement model includes
MANAGERS, METER READERS and ANALYSIS APPLICAIONS, which are explained in MANAGERS, METER READERS and ANALYSIS APPLICATIONS, which are explained
following sections. The relationships between them are shown by the in 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
skipping to change at page 6, line 50 skipping to change at page 7, line 5
- 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 transports usage data from meters so - METER READER: A meter reader transports usage data from meters so
that it is available to analysis applications. that it is available to analysis applications.
INTERNET-DRAFT Traffic Flow Measurement: Architecture June 99
- 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:
INTERNET-DRAFT Traffic Flow Measurement: Architecture May 99
- TRAFFIC FLOW MATRICES, showing the total flow rates for many of - TRAFFIC FLOW MATRICES, showing the total flow rates for many of
the possible paths within an internet. the possible paths within an internet.
- FLOW RATE FREQUENCY DISTRIBUTIONS, summarizing flow rates over - FLOW RATE FREQUENCY DISTRIBUTIONS, summarizing flow rates over
a period of time. a period of time.
- USAGE DATA showing the total traffic volumes sent and received - USAGE DATA showing the total traffic volumes sent and received
by particular hosts. by particular hosts.
The operation of the traffic measurement system as a whole is best The operation of the traffic measurement system as a whole is best
skipping to change at page 7, line 48 skipping to change at page 8, line 5
meters. Each meter's configuration includes information such as: meters. Each meter's configuration includes information such as:
- Flow specifications, e.g. which traffic flows are to be measured, - Flow specifications, e.g. which traffic flows are to be measured,
how they are to be aggregated, and any data the meter is required how they are to be aggregated, and any data the meter is required
to compute for each flow being measured. to compute for each flow being measured.
- Meter control parameters, e.g. the 'inactivity' time for flows (if - Meter control parameters, e.g. the 'inactivity' time for flows (if
no packets belonging to a flow are seen for this time the flow is no packets belonging to a flow are seen for this time the flow is
considered to have ended, i.e. to have become idle). considered to have ended, i.e. to have become idle).
INTERNET-DRAFT Traffic Flow Measurement: Architecture June 99
- Sampling behaviour. Normally every packet will be observed. It - Sampling behaviour. Normally every packet will be observed. It
may sometimes be necessary to use sampling techniques so as to may sometimes be necessary to use sampling techniques so as to
observe only some of the packets (see following note). observe only some of the packets (see following note).
INTERNET-DRAFT Traffic Flow Measurement: Architecture May 99
A note about sampling: Current experience with the measurement A note about sampling: Current experience with the measurement
architecture shows that a carefully-designed and implemented meter architecture shows that a carefully-designed and implemented meter
compresses the data sufficiently well that in normal LANs and WANs of compresses the data sufficiently well that in normal LANs and WANs of
today sampling is seldom, if ever, needed. For this reason sampling today sampling is seldom, if ever, needed. For this reason sampling
algorithms are not prescribed by the architecture. If sampling is algorithms are not prescribed by the architecture. If sampling is
needed, e.g. for metering a very-high-speed network with fine-grained needed, e.g. for metering a very-high-speed network with fine-grained
flows, the sampling technique should be carefully chosen so as not to flows, the sampling technique should be carefully chosen so as not to
bias the results. For a good introduction to this topic see the IPPM bias the results. For a good introduction to this topic see the IPPM
Working Group's RFC "Framework for IP Performance Metrics" [4]. Working Group's RFC "Framework for IP Performance Metrics" [4].
skipping to change at page 9, line 5 skipping to change at page 9, line 5
a particular rule set, flows which have been active since a given a particular rule set, flows which have been active since a given
time, etc.). time, etc.).
- Which attribute values are to be collected for the required flow - Which attribute values are to be collected for the required flow
records (e.g. all attributes, or a small subset of them) records (e.g. all attributes, or a small subset of them)
Since redundant reporting may be used in order to increase the Since redundant reporting may be used in order to increase the
reliability of usage data, exchanges among multiple entities must be reliability of usage data, exchanges among multiple entities must be
considered as well. These are discussed below. considered as well. These are discussed below.
INTERNET-DRAFT Traffic Flow Measurement: Architecture May 99 INTERNET-DRAFT Traffic Flow Measurement: Architecture June 99
2.5 Multiple METERs or METER READERs 2.5 Multiple METERs or METER READERs
-- METER READER A -- -- METER READER A --
/ | \ / | \
/ | \ / | \
=====METER 1 METER 2=====METER 3 METER 4===== =====METER 1 METER 2=====METER 3 METER 4=====
\ | / \ | /
\ | / \ | /
-- METER READER B -- -- METER READER B --
skipping to change at page 10, line 5 skipping to change at page 10, line 5
manager to switch rulesets in more than one meter at the same time. manager to switch rulesets in more than one meter at the same time.
If there is only one meter reader and it fails, the meters continue to If there is only one meter reader and it fails, the meters continue to
run. When the meter reader is restarted it can collect all of the run. When the meter reader is restarted it can collect all of the
accumulated flow data. Should this happen, time resolution will be lost accumulated flow data. Should this happen, time resolution will be lost
(because of the missed collections) but overall traffic flow information (because of the missed collections) but overall traffic flow information
will not. The only exception to this would occur if the traffic volume will not. The only exception to this would occur if the traffic volume
was sufficient to 'roll over' counters for some flows during the was sufficient to 'roll over' counters for some flows during the
failure; this is addressed in the section on 'Rolling Counters.' failure; this is addressed in the section on 'Rolling Counters.'
INTERNET-DRAFT Traffic Flow Measurement: Architecture May 99 INTERNET-DRAFT Traffic Flow Measurement: Architecture June 99
2.6 Interaction Between MANAGERs (MANAGER - MANAGER) 2.6 Interaction Between MANAGERs (MANAGER - MANAGER)
Synchronization between multiple management systems is the province of Synchronization between multiple management systems is the province of
network management protocols. This traffic flow measurement network management protocols. This traffic flow measurement
architecture specifies only the network management controls necessary to architecture specifies only the network management controls necessary to
perform the traffic flow measurement function and does not address the perform the traffic flow measurement function and does not address the
more global issues of simultaneous or interleaved (possibly conflicting) more global issues of simultaneous or interleaved (possibly conflicting)
commands from multiple network management stations or the process of commands from multiple network management stations or the process of
transferring control from one network management station to another. transferring control from one network management station to another.
skipping to change at page 11, line 5 skipping to change at page 11, line 5
"A TRAFFIC FLOW is an artifical logical equivalent to a call or "A TRAFFIC FLOW is an artifical logical equivalent to a call or
connection, belonging to a (user-specieied) METERED TRAFFIC connection, belonging to a (user-specieied) METERED TRAFFIC
GROUP." GROUP."
In practical terms, a flow is a stream of packets observed by the meter In practical terms, a flow is a stream of packets observed by the meter
as they pass across a network between two end points (or from a single as they pass across a network between two end points (or from a single
end point), which have been summarized by a traffic meter for analysis end point), which have been summarized by a traffic meter for analysis
purposes. purposes.
INTERNET-DRAFT Traffic Flow Measurement: Architecture May 99 INTERNET-DRAFT Traffic Flow Measurement: Architecture June 99
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 11, line 51 skipping to change at page 11, line 51
specified only that "source address = IP address 10.1.0.1," then all IP specified only that "source address = IP address 10.1.0.1," then all IP
packets from and to 10.1.0.1 would be counted in that flow. packets from and to 10.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 address in the the next layer down
immediate source or destination on the path of the packet. For from the peer address in a particular instantiation of protocol
example, if flow measurement is being performed at the IP layer on layering. Although 'adjacent' will usually imply the link layer,
INTERNET-DRAFT Traffic Flow Measurement: Architecture May 99 INTERNET-DRAFT Traffic Flow Measurement: Architecture June 99
an Ethernet LAN [5], an adjacent address will normally be a it does not implicitly advocate or dismiss any particular form of
six-octet Media Access Control (MAC) address. For a host connected tunnelling or layering.
to the same LAN segment as the meter the adjacent address will be
the MAC address of that host. For hosts on other LAN segments it For example, if flow measurement is being performed using IP as the
will be the MAC address of the adjacent (upstream or downstream) network layer on an Ethernet LAN [5], an adjacent address will
router carrying the traffic flow. normally be a six-octet Media Access Control (MAC) address. For a
host connected to the same LAN segment as the meter the adjacent
address will be the MAC address of that host. For hosts on other
LAN segments it will be the MAC address of the adjacent (upstream
or downstream) 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
packet for the network layer (n) at which traffic measurement is packet for the network layer (n) at which traffic measurement is
being performed. The form of a peer address will depend on the being performed. The form of a peer address will depend on the
network-layer protocol in use, and the measurement network layer network-layer protocol in use, and the measurement network layer
(n). (n).
- 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
skipping to change at page 12, line 46 skipping to change at page 12, line 50
protocols. This is straightforward for peer addresses; although the protocols. This is straightforward for peer addresses; although the
form of addresses differs for the various protocols, the meaning of a form of addresses differs for the various protocols, the meaning of a
'peer address' remains the same. It becomes harder to maintain this 'peer address' remains the same. It becomes harder to maintain this
correspondence at higher layers - for example, at the Network layer IP, correspondence at higher layers - for example, at the Network layer IP,
Novell IPX and AppleTalk all use port numbers as a 'transport address,' Novell IPX and AppleTalk all use port numbers as a 'transport address,'
but CLNP and DECnet have no notion of ports. but CLNP and DECnet have no notion of ports.
Reporting by adjacent intermediate sources and destinations or simply by Reporting by adjacent intermediate sources and destinations or simply by
meter interface (most useful when the meter is embedded in a router) meter interface (most useful when the meter is embedded in a router)
supports hierarchical Internet reporting schemes as described in the supports hierarchical Internet reporting schemes as described in the
'Internet Accounting: Background' RFC [2]. That is, it allows backbone 'Internet Accounting Background' RFC [2]. That is, it allows backbone
and regional networks to measure usage to just the next lower level of and regional networks to measure usage to just the next lower level of
granularity (i.e. to the regional and stub/enterprise levels, granularity (i.e. to the regional and stub/enterprise levels,
respectively), with the final breakdown according to end user (e.g. to respectively), with the final breakdown according to end user (e.g. to
source IP address) performed by the stub/enterprise networks. source IP address) performed by the stub/enterprise networks.
INTERNET-DRAFT Traffic Flow Measurement: Architecture June 99
In cases where network addresses are dynamically allocated (e.g. In cases where network addresses are dynamically allocated (e.g.
dial-in subscribers), further subscriber identification will be dial-in subscribers), further subscriber identification will be
necessary if flows are to ascribed to individual users. Provision is necessary if flows are to ascribed to individual users. Provision is
made to further specify the metered traffic group through the use of an made to further specify the metered traffic group through the use of an
optional SUBSCRIBER ID as part of the flow id. A subscriber ID may be optional SUBSCRIBER ID as part of the flow id. A subscriber ID may be
INTERNET-DRAFT Traffic Flow Measurement: Architecture May 99
associated with a particular flow either through the current rule set or associated with a particular flow either through the current rule set or
by unspecified means within a meter. At this time a subscriber ID is an by unspecified means within a meter. 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
details of its contents. details of its contents.
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 its level of detail. A coarser granularity means a reporting against its level of detail. A coarser granularity means a
skipping to change at page 13, line 48 skipping to change at page 14, line 4
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 NUMBER. Granularity of metered traffic identifiable via a RULE SET NUMBER. Granularity of metered traffic
INTERNET-DRAFT Traffic Flow Measurement: Architecture June 99
groups is further specified by additional ATTRIBUTES. These attributes groups is further specified by additional ATTRIBUTES. These attributes
include: include:
INTERNET-DRAFT Traffic Flow Measurement: Architecture May 99
- 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
skipping to change at page 15, line 5 skipping to change at page 15, line 5
before recovering a flow record the meter should be sure that the flow's before recovering a flow record the meter should be sure that the flow's
data has been collected by all meter readers which registered to collect data has been collected by all meter readers which registered to collect
it. These two wait conditions are desired goals for the meter; they are it. These two wait conditions are desired goals for the meter; they are
not difficult to achieve in normal usage, however the meter cannot not difficult to achieve in normal usage, however the meter cannot
guarantee to fulfil them absolutely. guarantee to fulfil them absolutely.
These 'lifetime' issues are considered further in the section on meter These 'lifetime' issues are considered further in the section on meter
readers (below). A complete list of the attributes currently defined is readers (below). A complete list of the attributes currently defined is
given in Appendix C later in this document. given in Appendix C later in this document.
INTERNET-DRAFT Traffic Flow Measurement: Architecture May 99 INTERNET-DRAFT Traffic Flow Measurement: Architecture June 99
3.3 Rolling Counters, Timestamps, Report-in-One-Bucket-Only 3.3 Rolling Counters, Timestamps, Report-in-One-Bucket-Only
Once a usage record is sent, the decision needs to be made whether to Once a usage record is sent, the decision needs to be made whether to
clear any existing flow records or to maintain them and add to their clear any existing flow records or to maintain them and add to their
counts when recording subsequent traffic on the same flow. The second counts when recording subsequent traffic on the same flow. The second
method, called rolling counters, is recommended and has several method, called rolling counters, is recommended and has several
advantages. Its primary advantage is that it provides greater advantages. Its primary advantage is that it provides greater
reliability - the system can now often survive the loss of some usage reliability - the system can now often survive the loss of some usage
records, such as might occur if a meter reader failed and later records, such as might occur if a meter reader failed and later
skipping to change at page 16, line 5 skipping to change at page 16, line 5
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. A flow which has sporadic bursts of recent FLOW START timestamp. A flow which has sporadic bursts of
activity interspersed with long periods of inactivity will produce a activity interspersed with long periods of inactivity will produce a
sequence of flow activity records, each with the same set of address sequence of flow activity records, each with the same set of address
attributes, but with increasing FLOW START times. attributes, but with increasing FLOW START times.
Each packet is counted in at most one flow for each running ruleset, so Each packet is counted in at most one flow for each running ruleset, so
as to avoid multiple counting of a single packet. The record of a as to avoid multiple counting of a single packet. The record of a
single flow is informally called a "bucket." If multiple, sometimes single flow is informally called a "bucket." If multiple, sometimes
INTERNET-DRAFT Traffic Flow Measurement: Architecture May 99 INTERNET-DRAFT Traffic Flow Measurement: Architecture June 99
overlapping, records of usage information are required (aggregate, overlapping, records of usage information are required (aggregate,
individual, etc), the network manager should collect the counts in individual, etc), the network manager should collect the counts in
sufficiently detailed granularity so that aggregate and combination sufficiently detailed granularity so that aggregate and combination
counts can be reconstructed in post-processing of the raw usage data. counts can be reconstructed in post-processing of the raw usage data.
Alternatively, multiple rulesets could be used to collect data at Alternatively, multiple rulesets could be used to collect data at
different granularities. different granularities.
For example, consider a meter from which it is required to record both For example, consider a meter from which it is required to record both
'total packets coming in interface #1' and 'total packets arriving from 'total packets coming in interface #1' and 'total packets arriving from
any interface sourced by IP address = a.b.c.d,' using a single rule set. any interface sourced by IP address = a.b.c.d,' using a single rule set.
Although a bucket can be declared for each case, it is not clear how to Although a bucket can be declared for each case, it is not clear how to
handle a packet which satisfies both criteria. It must only be counted handle a packet which satisfies both criteria. It must only be counted
once. By default it will be counted in the first bucket for which it once. By default it will be counted in the first bucket for which it
qualifies, and not in the other bucket. Further, it is not possible to qualifies, and not in the other bucket. Further, it is not possible to
reconstruct this information by post-processing. The solution in this reconstruct this information by post-processing. The solution in this
skipping to change at page 17, line 5 skipping to change at page 17, line 5
Alternatively, the above could be achieved by running two rule sets (A Alternatively, the above could be achieved by running two rule sets (A
and B), as follows: and B), as follows:
Bucket 1: Packets which came in interface 1; Bucket 1: Packets which came in interface 1;
counted by rule set A. counted by rule set A.
Bucket 2: Packets which were sourced by IP address a.b.c.d; Bucket 2: Packets which were sourced by IP address a.b.c.d;
counted by rule set B. counted by rule set B.
INTERNET-DRAFT Traffic Flow Measurement: Architecture May 99 INTERNET-DRAFT Traffic Flow Measurement: Architecture June 99
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:
skipping to change at page 18, line 5 skipping to change at page 18, line 5
Processor, executes the rules in the current rule set as described Processor, executes the rules in the current rule set as described
in section 4.3 below, and returns instructions on what to do with in section 4.3 below, and returns instructions on what to do with
the packet. the packet.
- Some packets are classified as 'to be ignored.' They are discarded - Some packets are classified as 'to be ignored.' They are discarded
by the Packet Processor. by the Packet Processor.
- Other packets are matched by the PME, which returns a FLOW KEY - Other packets are matched by the PME, which returns a FLOW KEY
describing the flow to which the packet belongs. describing the flow to which the packet belongs.
INTERNET-DRAFT Traffic Flow Measurement: Architecture May 99 INTERNET-DRAFT Traffic Flow Measurement: Architecture June 99
- The flow key is used to locate the flow's entry in the FLOW TABLE; - The flow key is used to locate the flow's entry in the FLOW TABLE;
a new entry is created when a flow is first seen. The entry's data a new entry is created when a flow is first seen. The entry's data
fields (e.g. packet and byte counters) are updated. fields (e.g. packet and byte counters) are updated.
- A meter reader may collect data from the flow table at any time. - A meter reader may collect data from the flow table at any time.
It may use the 'collect' index to locate the flows to be collected It may use the 'collect' index to locate the flows to be collected
within the flow table. within the flow table.
packet +------------------+ packet +------------------+
skipping to change at page 19, line 5 skipping to change at page 19, line 5
Meter Reader Meter Reader
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 containing flows from all the rule sets. One way to single flow table containing flows from all the rule sets. One way to
implement this is to use the Rule Set Number attribute in each flow as implement this is to use the Rule Set Number attribute in each flow as
part of the flow key. part of the flow key.
INTERNET-DRAFT Traffic Flow Measurement: Architecture May 99 INTERNET-DRAFT Traffic Flow Measurement: Architecture June 99
A packet may only be counted once in a rule set (as explained in section A packet may only be counted once in a rule set (as explained in section
3.3 above), but it may be counted in any of the current rulesets. The 3.3 above), but it may be counted in any of the current rulesets. The
overall effect of doing this is somewhat similar to running several overall effect of doing this is somewhat similar to running several
independent meters, one for each rule set. independent meters, one for each rule set.
4.2 Flow Table 4.2 Flow Table
Every traffic meter maintains 'flow table,' i.e. a table of TRAFFIC Every traffic meter maintains 'flow table,' i.e. a table of TRAFFIC
FLOW RECORDS for flows seen by the meter. Details of how the flow table FLOW RECORDS for flows seen by the meter. Details of how the flow table
skipping to change at page 20, line 5 skipping to change at page 20, line 5
- IDLE: The record is in use and the flow which it describes is part - IDLE: The record is in use and the flow which it describes is part
of the current flow set. In addition, no packets belonging to this of the current flow set. In addition, no packets belonging to this
flow have been seen for a period specified by the meter's flow have been seen for a period specified by the meter's
InactivityTime variable. InactivityTime variable.
4.3 Packet Handling, Packet Matching 4.3 Packet Handling, Packet Matching
Each packet header received by the traffic meter program is processed as Each packet header received by the traffic meter program is processed as
follows: follows:
INTERNET-DRAFT Traffic Flow Measurement: Architecture May 99 INTERNET-DRAFT Traffic Flow Measurement: Architecture June 99
- 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
skipping to change at page 20, line 54 skipping to change at page 21, line 5
'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 header, and D indicates its address attribute values) from the packet header, and D indicates its
destination address. destination address.
There are several cases to consider. These are: INTERNET-DRAFT Traffic Flow Measurement: Architecture June 99
INTERNET-DRAFT Traffic Flow Measurement: Architecture May 99 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 would MATCH IN EITHER DIRECTION. One situation in which - The packet would MATCH IN EITHER DIRECTION. One situation in which
this could happen would be a rule set which matches flows within this could happen would be a rule set which matches flows within
network X (Source = X, Dest = X) but specifies that flows are to be network X (Source = X, Dest = X) but specifies that flows are to be
created for each subnet within network X, say subnets y and z. If, created for each subnet within network X, say subnets y and z. If,
for example a packet is seen for y->z, the meter must check that for example a packet is seen for y->z, the meter must check that
flow z->y is not already current before creating y->z. flow z->y is not already current before creating y->z.
skipping to change at page 21, line 54 skipping to change at page 22, line 5
* *
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:
INTERNET-DRAFT Traffic Flow Measurement: Architecture June 99
'Ignore' means that the packet was matched but this flow is not 'Ignore' means that the packet was matched but this flow is not
to be counted. to be counted.
INTERNET-DRAFT Traffic Flow Measurement: Architecture May 99
'NoMatch' means that the packet did not match. It might, however 'NoMatch' means that the packet did not match. It might, however
match with its direction reversed, i.e. from B to A. match with its direction reversed, i.e. from B to A.
'Suc' means that the packet did match, i.e. it belongs to a flow 'Suc' means that the packet did match, i.e. it belongs to a flow
which is to be counted. which is to be counted.
current(A->B) succeeds if the flow A-to-B is current - i.e. has current(A->B) succeeds if the flow A-to-B is current - i.e. has
a record in the flow table whose state is Current - and fails a record in the flow table whose state is Current - and fails
otherwise. otherwise.
skipping to change at page 23, line 5 skipping to change at page 23, line 5
meter to handle reverse-travelling packets. meter to handle reverse-travelling packets.
Occasionally there can be situations when a rule set needs to know the Occasionally there can be situations when a rule set needs to know the
direction in which a packet is being matched. Consider, for example, a direction in which a packet is being matched. Consider, for example, a
rule set which wants to save some attribute values (source and rule set which wants to save some attribute values (source and
destination addresses perhaps) for any 'unusual' packets. The rule set destination addresses perhaps) for any 'unusual' packets. The rule set
will contain a sequence of tests for all the 'usual' source addresses, will contain a sequence of tests for all the 'usual' source addresses,
follwed by a rule which will execute a 'NoMatch' action. If the match follwed by a rule which will execute a 'NoMatch' action. If the match
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
INTERNET-DRAFT Traffic Flow Measurement: Architecture May 99 INTERNET-DRAFT Traffic Flow Measurement: Architecture June 99
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 save whatever attribute values are of in both directions; we can save whatever attribute values are of
skipping to change at page 24, line 5 skipping to change at page 24, line 5
The test group allows PME to test the value of an attribute. This is The test group allows PME to test the value of an attribute. This is
done by ANDing the attribute value with the mask and comparing the done by ANDing the attribute value with the mask and comparing the
result with the value field. Note that there is no explicit provision result with the value field. Note that there is no explicit provision
to test a range, although this can be done where the range can be to test a range, although this can be done where the range can be
covered by a mask, e.g. attribute value less than 2048. covered by a mask, e.g. attribute value less than 2048.
The PME maintains a Boolean indicator called the 'test indicator,' which The PME maintains a Boolean indicator called the 'test indicator,' which
determines whether or not a rule's test is performed. The test determines whether or not a rule's test is performed. The test
indicator is initially set (true). indicator is initially set (true).
INTERNET-DRAFT Traffic Flow Measurement: Architecture May 99 INTERNET-DRAFT Traffic Flow Measurement: Architecture June 99
The opcode group specifies what action may be performed when the rule is The opcode group specifies what action may be performed when the rule is
executed. Opcodes contain two flags: 'goto' and 'test,' as detailed in executed. Opcodes contain two flags: 'goto' and 'test,' as detailed in
the table below. Execution begins with rule 1, the first in the rule the table below. Execution begins with rule 1, the first in the rule
set. It proceeds as follows: set. It 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
skipping to change at page 25, line 5 skipping to change at page 25, line 5
of opcode actions below. of opcode actions below.
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 -
INTERNET-DRAFT Traffic Flow Measurement: Architecture May 99 INTERNET-DRAFT Traffic Flow Measurement: Architecture June 99
4 CountPkt 0 - 4 CountPkt 0 -
5 Return 0 0 5 Return 0 0
6 Gosub 1 1 6 Gosub 1 1
7 GosubAct 1 0 7 GosubAct 1 0
8 Assign 1 1 8 Assign 1 1
9 AssignAct 1 0 9 AssignAct 1 0
10 Goto 1 1 10 Goto 1 1
11 GotoAct 1 0 11 GotoAct 1 0
12 PushRuleTo 1 1 12 PushRuleTo 1 1
skipping to change at page 26, line 5 skipping to change at page 26, line 5
GosubAct: Same as Gosub, except that the test indicator is GosubAct: Same as Gosub, except that the test indicator is
cleared before going to the specified rule. cleared before going to the specified rule.
Return: Return from a rule-matching subroutine. Pop the Return: Return from a rule-matching subroutine. Pop the
number of the calling gosub rule from the PME's number of the calling gosub rule from the PME's
'return' stack and add this rule's parameter value 'return' stack and add this rule's parameter value
to it to determine the 'target' rule. Clear the to it to determine the 'target' rule. Clear the
test indicator then goto the target rule. test indicator then goto the target rule.
INTERNET-DRAFT Traffic Flow Measurement: Architecture May 99 INTERNET-DRAFT Traffic Flow Measurement: Architecture June 99
A subroutine call appears in a rule set as a Gosub A subroutine call appears in a rule set as a Gosub
rule followed by a small group of following rules. rule followed by a small group of following rules.
Since a Return action clears the test flag, the Since a Return action clears the test flag, the
action of one of these 'following' rules will be action of one of these 'following' rules will be
executed; this allows the subroutine to return a executed; this allows the subroutine to return a
result (in addition to any information it may save result (in addition to any information it may save
in the PME's pattern queue). in the PME's pattern queue).
Assign: Set the attribute specified in this rule to the Assign: Set the attribute specified in this rule to the
skipping to change at page 27, line 5 skipping to change at page 27, line 5
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 header using a specified mask. The the packet header using a specified mask. The
simplest way to program this is to use a zero value simplest way to program this is to use a zero value
for the PushPktTo rule's value field, and to for the PushPktTo rule's value field, and to
GoToAct to the PushPktTo rule (so that it's test is GoToAct to the PushPktTo rule (so that it's test is
not executed). not executed).
INTERNET-DRAFT Traffic Flow Measurement: Architecture May 99 INTERNET-DRAFT Traffic Flow Measurement: Architecture June 99
PopTo: Delete the most recent item from the pattern PopTo: Delete the most recent item from the pattern
queue, so as to remove the information saved by queue, so as to remove the information saved by
an earlier 'push' action. Set the test indicator an earlier 'push' action. Set the test indicator
then goto the specified rule. then goto the specified rule.
PopToAct: Same as PopTo, except that the test indicator PopToAct: Same as PopTo, except that the test indicator
is cleared before going to the specified rule. is cleared before going to the specified rule.
As well as the attributes applying directly to packets (such as As well as the attributes applying directly to packets (such as
skipping to change at page 28, line 5 skipping to change at page 28, line 5
information which has been built up during matching. information which has been built up during matching.
Their values may be tested in rules; this allows one Their values may be tested in rules; this allows one
to set them early in a rule set, and test them later. to set them early in a rule set, and test them later.
The opcodes detailed above (with their above 'goto'and 'test' values) The opcodes detailed above (with their above 'goto'and 'test' values)
form a minimum set, but one which has proved very effective in current form a minimum set, but one which has proved very effective in current
meter implementations. From time to time it may be useful to add meter implementations. From time to time it may be useful to add
further opcodes; IANA considerations for allocating these are set out in further opcodes; IANA considerations for allocating these are set out in
section 8 below. section 8 below.
INTERNET-DRAFT Traffic Flow Measurement: Architecture May 99 INTERNET-DRAFT Traffic Flow Measurement: Architecture June 99
4.5 Maintaining the Flow Table 4.5 Maintaining the Flow Table
The flow table may be thought of as a 1-origin array of flow records. The flow table may be thought of as a 1-origin array of flow records.
(A particular implementation may, of course, use whatever data structure (A particular implementation may, of course, use whatever data structure
is most suitable). When the meter starts up there are no known flows; is most suitable). When the meter starts up there are no known flows;
all the flow records are in the 'inactive' state. all the flow records are in the 'inactive' state.
Each time a packet is matched for a flow which is not in a current flow Each time a packet is matched for a flow which is not in a current flow
set a flow record is created for it; the state of such a record is set a flow record is created for it; the state of such a record is
skipping to change at page 29, line 5 skipping to change at page 29, line 5
background process which scans the flow table looking for 'current' background process which scans the flow table looking for 'current'
flows whose 'last packet' time is earlier than the meter's flows whose 'last packet' time is earlier than the meter's
LastCollectTime. LastCollectTime.
Another recovery strategy is to leave idle flows alone as long as Another recovery strategy is to leave idle flows alone as long as
possible, which would be acceptable if one was only interested in possible, which would be acceptable if one was only interested in
measuring total traffic volumes. It could be implemented by having the measuring total traffic volumes. It could be implemented by having the
meter search for collected idle flows only when it ran low on 'inactive' meter search for collected idle flows only when it ran low on 'inactive'
flow records. flow records.
INTERNET-DRAFT Traffic Flow Measurement: Architecture May 99 INTERNET-DRAFT Traffic Flow Measurement: Architecture June 99
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.
Of course a meter reader may fail, so the meter cannot wait forever for Of course a meter reader may fail, so the meter cannot wait forever for
it. Instead the meter must keep a table of active meter readers, with a it. Instead the meter must keep a table of active meter readers, with a
timeout specified for each. If a meter reader fails to collect flow timeout specified for each. If a meter reader fails to collect flow
data within its timeout interval, the meter should delete that reader data within its timeout interval, the meter should delete that reader
skipping to change at page 30, line 5 skipping to change at page 30, line 5
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 readers, as specified by a manager. The collected data is recorded in
stable storage as a FLOW DATA FILE, as a sequence of USAGE RECORDS. stable storage as 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
records and files is not specified in the architecture. Specifying a records and files is not specified in the architecture. Specifying a
common format for them would be a worthwhile future development. common format for them would be a worthwhile future development.
INTERNET-DRAFT Traffic Flow Measurement: Architecture May 99 INTERNET-DRAFT Traffic Flow Measurement: Architecture June 99
5.1 Identifying Flows in Flow Records 5.1 Identifying Flows in Flow Records
Once a packet has been classified and is ready to be counted, an Once a packet has been classified and is ready to be counted, an
appropriate flow data record must already exist in the flow table; appropriate flow data record must already exist in the flow table;
otherwise one must be created. The flow record has a flexible format otherwise one must be created. The flow record has a flexible format
where unnecessary identification attributes may be omitted. The where unnecessary identification attributes may be omitted. The
determination of which attributes of the flow record to use, and of what determination of which attributes of the flow record to use, and of what
values to put in them, is specified by the current rule set. values to put in them, is specified by the current rule set.
skipping to change at page 31, line 5 skipping to change at page 31, line 5
Each usage record contains the metered traffic group identifier of the Each usage record contains the metered traffic group identifier of the
meter (a set of network addresses), a time stamp and a list of reported meter (a set of network addresses), a time stamp and a list of reported
flows (FLOW DATA RECORDS). A meter reader will build up a file of usage flows (FLOW DATA RECORDS). A meter reader will build up a file of usage
records by regularly collecting flow data from a meter, using this data records by regularly collecting flow data from a meter, using this data
to build usage records and concatenating them to the tail of a file. to build usage records and concatenating them to the tail of a file.
Such a file is called a FLOW DATA 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:
INTERNET-DRAFT Traffic Flow Measurement: Architecture May 99 INTERNET-DRAFT Traffic Flow Measurement: Architecture June 99
+-------------------------------------------------------------------+ +-------------------------------------------------------------------+
| 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 |
| Address List | Packet Count | | Address List | Packet Count |
| Subscriber ID (Optional) | Byte Count | | Subscriber ID (Optional) | Byte Count |
skipping to change at page 32, line 5 skipping to change at page 32, line 5
implementor must decide how to handle this, for example by switching to implementor must decide how to handle this, for example by switching to
a default (extremely coarse granularity) rule set, by sending a trap a default (extremely coarse granularity) rule set, by sending a trap
message to the manager, or by attempting to dump flow data to the meter message to the manager, or by attempting to dump flow data to the meter
reader. reader.
Users of the Traffic Flow Measurement system should analyse their Users of the Traffic Flow Measurement system should analyse their
requirements carefully and assess for themselves whether it is more requirements carefully and assess for themselves whether it is more
important to attempt to collect flow data at normal granularity important to attempt to collect flow data at normal granularity
(increasing the collection frequency as needed to keep up with traffic (increasing the collection frequency as needed to keep up with traffic
INTERNET-DRAFT Traffic Flow Measurement: Architecture May 99 INTERNET-DRAFT Traffic Flow Measurement: Architecture June 99
volumes), or to accept flow data with a coarser granularity. Similarly, volumes), or to accept flow data with a coarser granularity. Similarly,
it may be acceptable to lose flow data for a short time in return for it may be acceptable to lose flow data for a short time in return for
being sure that the meter keeps running properly, i.e. is not being sure that the meter keeps running properly, i.e. is not
overwhelmed by rising traffic levels. overwhelmed by rising traffic levels.
6 Managers 6 Managers
A manager configures meters and controls meter readers. It does this A manager configures meters and controls meter readers. It does this
via the interactions described below. via the interactions described below.
skipping to change at page 33, line 5 skipping to change at page 33, line 5
each task it is currently running. each task it is currently running.
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:
INTERNET-DRAFT Traffic Flow Measurement: Architecture May 99 INTERNET-DRAFT Traffic Flow Measurement: Architecture June 99
- Flows that have already been reported to all registered meter - Flows that have already been reported to all registered meter
readers, 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 observed packets. - Flows with the smallest number of observed packets.
- SET INACTIVITY TIMEOUT: This is a time in seconds since the last - SET INACTIVITY TIMEOUT: This is a time in seconds since the last
packet was seen for a flow. Flow records may be reclaimed if they packet was seen for a flow. Flow records may be reclaimed if they
skipping to change at page 33, line 50 skipping to change at page 34, line 5
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:
INTERNET-DRAFT Traffic Flow Measurement: Architecture June 99
- MANAGER and METER READER IDENTIFICATION: The manager should ensure - MANAGER and METER READER IDENTIFICATION: The manager should ensure
that meters are read by 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
INTERNET-DRAFT Traffic Flow Measurement: Architecture May 99
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 even with a correctly set reporting interval. Some mechanism
skipping to change at page 35, line 5 skipping to change at page 35, line 5
tables, and maximum flow lifetimes. This is intertwined with tables, and maximum flow lifetimes. This is intertwined with
reporting interval and granularity, and must be set in accordance reporting interval and granularity, and must be set in accordance
with the other parameters. with the other parameters.
6.3 Exception Conditions 6.3 Exception Conditions
Exception conditions must be handled, particularly occasions when the Exception conditions must be handled, particularly occasions when the
meter runs out of space for flow data. Since - to prevent an active meter runs out of space for flow data. Since - to prevent an active
task from counting any packet twice - packets can only be counted in a task from counting any packet twice - packets can only be counted in a
INTERNET-DRAFT Traffic Flow Measurement: Architecture May 99 INTERNET-DRAFT Traffic Flow Measurement: Architecture June 99
single flow, discarding records will result in the loss of information. single flow, discarding records will result in the loss of information.
The 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
skipping to change at page 36, line 5 skipping to change at page 36, line 5
of circuits carrying the usage data. The manager may change any of of circuits carrying the usage data. The manager may change any of
these parameters in response to the meter (or meter reader's) plea these parameters in response to the meter (or meter reader's) plea
for help. for help.
6.4 Standard Rule Sets 6.4 Standard Rule Sets
Although the rule table is a flexible tool, it can also become very Although the rule table is a flexible tool, it can also become very
complex. It may be helpful to develop some rule sets for common complex. It may be helpful to develop some rule sets for common
applications: applications:
INTERNET-DRAFT Traffic Flow Measurement: Architecture May 99 INTERNET-DRAFT Traffic Flow Measurement: Architecture June 99
- 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.
- ADJACENT SYSTEMS: The meter records packets by the MAC address of - ADJACENT SYSTEMS: The meter records packets by the MAC address of
the Adjacent Systems (neighbouring originator or next-hop). the Adjacent Systems (neighbouring originator or next-hop).
(Variants on this table are "report source" or "report sink" only.) (Variants on this table are "report source" or "report sink" only.)
This strategy might be used by a regional or backbone network which This strategy might be used by a regional or backbone network which
wants to know how much aggregate traffic flows to or from its wants to know how much aggregate traffic flows to or from its
subscriber networks. subscriber networks.
skipping to change at page 37, line 5 skipping to change at page 37, line 5
a sudden rise in the number of flows in a meter's flow table, thus a sudden rise in the number of flows in a meter's flow table, thus
forcing it to use its coarser standby rule set. forcing it to use its coarser standby rule set.
- UNAUTHORIZED USE OF SYSTEM RESOURCES: An attacker may wish to gain - UNAUTHORIZED USE OF SYSTEM RESOURCES: An attacker may wish to gain
advantage or cause mischief (e.g. denial of service) by subverting advantage or cause mischief (e.g. denial of service) by subverting
any of the system elements - meters, meter readers or managers. any of the system elements - meters, meter readers or managers.
- UNAUTHORIZED DISCLOSURE OF DATA: Any data that is sensitive to - UNAUTHORIZED DISCLOSURE OF DATA: Any data that is sensitive to
disclosure can be read through active or passive attacks unless it disclosure can be read through active or passive attacks unless it
INTERNET-DRAFT Traffic Flow Measurement: Architecture May 99 INTERNET-DRAFT Traffic Flow Measurement: Architecture June 99
is suitably protected. Usage data may or may not be of this type. is suitably protected. Usage data may or may not be of this type.
Control messages, traps, etc. are not likely to be considered Control messages, traps, etc. are not likely to be considered
sensitive to disclosure. sensitive to disclosure.
- UNAUTHORIZED ALTERATION, REPLACEMENT OR DESTRUCTION OF DATA: - UNAUTHORIZED ALTERATION, REPLACEMENT OR DESTRUCTION OF DATA:
Similarly, any data whose integrity is sensitive can be altered, Similarly, any data whose integrity is sensitive can be altered,
replaced/injected or deleted through active or passive attacks replaced/injected or deleted through active or passive attacks
unless it is suitably protected. Attackers may modify message unless it is suitably protected. Attackers may modify message
streams to falsify usage data or interfere with the proper streams to falsify usage data or interfere with the proper
skipping to change at page 38, line 5 skipping to change at page 38, line 5
a high degree of protection is required, the use of strong cryptographic a high degree of protection is required, the use of strong cryptographic
methodologies is recommended. The security requirements for methodologies is recommended. The security requirements for
communication between pairs of traffic measurmement system elements are communication between pairs of traffic measurmement system elements are
summarized in the table below. It is assumed that meters do not summarized in the table below. It is assumed that meters do not
communicate with other meters, and that meter readers do not communicate communicate with other meters, and that meter readers do not communicate
directly with other meter readers (if synchronization is required, it is directly with other meter readers (if synchronization is required, it is
handled by the manager, see Section 2.5). Each entry in the table handled by the manager, see Section 2.5). Each entry in the table
indicates which kinds of security services are required. Basically, the indicates which kinds of security services are required. Basically, the
requirements are as follows: requirements are as follows:
INTERNET-DRAFT Traffic Flow Measurement: Architecture May 99 INTERNET-DRAFT Traffic Flow Measurement: Architecture June 99
Security Service Requirements for RTFM elements Security Service Requirements for RTFM elements
+------------------------------------------------------------------+ +------------------------------------------------------------------+
| from\to | meter | meter reader | application | manager | | from\to | meter | meter reader | application | manager |
|---------+--------------+--------------+-------------+------------| |---------+--------------+--------------+-------------+------------|
| meter | N/A | authent | N/A | authent | | meter | N/A | authent | N/A | authent |
| | | acc ctrl | | acc ctrl | | | | acc ctrl | | acc ctrl |
| | | integrity | | | | | | integrity | | |
| | | confid ** | | | | | | confid ** | | |
skipping to change at page 39, line 5 skipping to change at page 39, line 5
- Whenever there is a transfer of usage data it should be possible to - Whenever there is a transfer of usage data it should be possible to
ensure its confidentiality if it is deemed sensitive to disclosure. ensure its confidentiality if it is deemed sensitive to disclosure.
This is indicated by 'confid' in the table. This is indicated by 'confid' in the table.
Security protocols are not specified in this document. The system Security protocols are not specified in this document. The system
elements' management and collection protocols are responsible for elements' management and collection protocols are responsible for
providing sufficient data integrity, confidentiality, authentication and providing sufficient data integrity, confidentiality, authentication and
access control services. access control services.
INTERNET-DRAFT Traffic Flow Measurement: Architecture May 99 INTERNET-DRAFT Traffic Flow Measurement: Architecture June 99
8 IANA Considerations 8 IANA Considerations
The RTFM Architecture, as set out in this document, has two sets of The RTFM Architecture, as set out in this document, has two sets of
assigned numbers. Considerations for assigning them are discussed in assigned numbers. Considerations for assigning them are discussed in
this section, using the example policies as set out in the "Guidelines this section, using the example policies as set out in the "Guidelines
for IANA Considerations" document [8]. for IANA Considerations" document [8].
8.1 PME Opcodes 8.1 PME Opcodes
skipping to change at page 39, line 40 skipping to change at page 39, line 40
8.2 RTFM Attributes 8.2 RTFM Attributes
Attribute numbers in the range of 0-511 are globally unique and are Attribute numbers in the range of 0-511 are globally unique and are
allocated according to an IETF Consensus action [8]. Appendix C of this allocated according to an IETF Consensus action [8]. Appendix C of this
document allocates a basic (i.e. useful minimum) set of attribtes; they document allocates a basic (i.e. useful minimum) set of attribtes; they
are assigned numbers in the range 0 to 63. The RTFM working group is are assigned numbers in the range 0 to 63. The RTFM working group is
working on an extended set of attributes, which will have numbers in the working on an extended set of attributes, which will have numbers in the
range 64 to 127. range 64 to 127.
Vendor-specific attribute numbers are in the range 512-1023, and will be Vendor-specific attribute numbers are in the range 512-1023, and will be
allocated using the First Come First Served policy [8]. Vendors allocated using the First Come FIrst Served policy [8]. Vendors
requiring attribute numbers should submit a request to IANA giving the requiring attribute numbers should submit a request to IANA giving the
attribute names: IANA will allocate them the next available numbers. attribute names: IANA will allocate them the next available numbers.
Attribute numbers 1024 and higher are Reserved for Private Use [8]. Attribute numbers 1024 and higher are Reserved for Private Use [8].
Implementors wishing to experiment with further new attributes should Implementors wishing to experiment with further new attributes should
use attribute numbers in this range. use attribute numbers in this range.
Attribute numbers are simply non-negative integers. When writing Attribute numbers are simply non-negative integers. When writing
specifications for attributes, implementors must give sufficient detail specifications for attributes, implementors must give sufficient detail
for the new attributes to be easily added to the RTFM Meter MIB [7]. for the new attributes to be easily added to the RTFM Meter MIB [7].
INTERNET-DRAFT Traffic Flow Measurement: Architecture May 99
In particular, they must indicate whether the new attributes may be: In particular, they must indicate whether the new attributes may be:
INTERNET-DRAFT Traffic Flow Measurement: Architecture June 99
- tested in an IF statement - tested in an IF statement
- saved by a SAVE statement or set by a STORE statement - saved by a SAVE statement or set by a STORE statement
- read from an RTFM meter - read from an RTFM meter
(IF, SAVE and STORE are statements in the SRL Ruleset Language [6]). (IF, SAVE and STORE are statements in the SRL Ruleset Language [6]).
9 APPENDICES 9 APPENDICES
9.1 Appendix A: Network Characterisation 9.1 Appendix A: Network Characterisation
skipping to change at page 41, line 5 skipping to change at page 41, line 5
networks. Individual hosts (with the exception of network management networks. Individual hosts (with the exception of network management
devices and backbone service hosts) typically are not directly connected devices and backbone service hosts) typically are not directly connected
to backbones. to backbones.
REGIONAL networks are closely related to backbones, and differ only in REGIONAL networks are closely related to backbones, and differ only in
size, the number of networks connected via each port, and geographical size, the number of networks connected via each port, and geographical
coverage. Regionals may have directly connected hosts, acting as hybrid coverage. Regionals may have directly connected hosts, acting as hybrid
backbone/stub networks. A regional network is a SUBSCRIBER to the backbone/stub networks. A regional network is a SUBSCRIBER to the
backbone. backbone.
INTERNET-DRAFT Traffic Flow Measurement: Architecture May 99 INTERNET-DRAFT Traffic Flow Measurement: Architecture June 99
STUB/ENTERPRISE networks connect hosts and local area networks. STUB/ENTERPRISE networks connect hosts and local area networks. STUB/
STUB/ENTERPRISE networks are SUBSCRIBERS to regional and backbone 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 'user traffic flow measurement record may carry system-specific 'user
identification' labels so that meters can implement proprietary or identification' labels so that meters can implement proprietary or
non-standard schemes for the attribution of network traffic to non-standard schemes for the attribution of network traffic to
skipping to change at page 42, line 5 skipping to change at page 42, line 5
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 reporting end-system network address or network address pair if detailed reporting
is required in the local area network. If no local reporting is is required in the local area network. If no local reporting is
required, they may record usage information in the exit router to track required, they may record usage information in the exit router to track
external traffic only. (These are the only networks which routinely use external traffic only. (These are the only networks which routinely use
attributes to perform reporting at granularities finer than end-system attributes to perform reporting at granularities finer than end-system
or intermediate-system network address.) or intermediate-system network address.)
INTERNET-DRAFT Traffic Flow Measurement: Architecture May 99 INTERNET-DRAFT Traffic Flow Measurement: Architecture June 99
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
entity (or vice versa), the meter is said to be operating as a HYBRID entity (or vice versa), the meter is said to be operating as a HYBRID
skipping to change at page 42, line 34 skipping to change at page 42, line 34
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.
9.3 Appendix C: List of Defined Flow Attributes 9.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.
Note that this table gives only a very brief summary. The Meter MIB [7]
provides the definitive specification of attributes and their allowed
values. The MIB variables which represent flow attributes have
'flowData' prepended to their names to indicate that they belong to the
MIB's flowData table.
0 Null 0 Null
1 Flow Subscript Integer Flow table info
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
13 Source Trans Mask String 13 Source Trans Mask String
14 Destination Interface Integer Destination Address INTERNET-DRAFT Traffic Flow Measurement: Architecture June 99
15 Destination Adjacent Type Integer
16 Destination Adjacent Address String
17 Destination AdjacentMask String
18 Destination PeerType Integer
19 Destination PeerAddress String
INTERNET-DRAFT Traffic Flow Measurement: Architecture May 99
20 Destination PeerMask String 14 DestInterface Integer Destination Address
21 Destination TransType Integer 15 DestAdjacentType Integer
22 Destination TransAddress String 16 DestAdjacentAddress String
23 Destination TransMask String 17 DestAdjacentMask String
18 DestPeerType Integer
19 DestPeerAddress String
20 DestPeerMask String
21 DestTransType Integer
22 DestTransAddress String
23 DestTransMask String
26 Rule Set Number Integer Meter attribute 26 RuleSet Integer Meter attribute
27 Forward Bytes Integer Source-to-Dest counters 27 ToOctets Integer Source-to-Dest counters
28 Forward Packets Integer 28 ToPDUs Integer
29 Reverse Bytes Integer Dest-to-Source counters 29 FromOctets Integer Dest-to-Source counters
30 Reverse Packets Integer 30 FromPDUs Integer
31 First Time Timestamp Activity times 31 First Time Timestamp Activity times
32 Last Active Time Timestamp 32 Last Active Time Timestamp
33 Source Subscriber ID String Session attributes 33 Source Subscriber ID String Session attributes
34 Destination Subscriber ID String 34 DestSubscriberID 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 DestClass Integer
38 Flow Class Integer 38 Flow Class Integer
39 Source Kind Integer 39 Source Kind Integer
40 Destination Kind Integer 40 DestKind Integer
41 Flow Kind Integer 41 Flow Kind Integer
50 MatchingStoD Integer PME variable 50 MatchingStoD Integer PME variable
51 v1 Integer Meter Variables 51 v1 Integer Meter Variables
52 v2 Integer 52 v2 Integer
53 v3 Integer 53 v3 Integer
54 v4 Integer 54 v4 Integer
55 v5 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
9.4 Appendix D: List of Meter Control Variables 9.4 Appendix D: List of Meter Control Variables
Meter variables: Meter variables:
Flood Mark Percentage Flood Mark Percentage
Inactivity Timeout (seconds) Integer Inactivity Timeout (seconds) Integer
INTERNET-DRAFT Traffic Flow Measurement: Architecture June 99
'per task' variables: 'per task' variables:
Current Rule Set Number Integer Current Rule Set Number Integer
Standby Rule Set Number Integer Standby Rule Set Number Integer
High Water Mark Percentage High Water Mark Percentage
'per reader' variables: 'per reader' variables:
Reader Last Time Timestamp Reader Last Time Timestamp
INTERNET-DRAFT Traffic Flow Measurement: Architecture May 99
9.5 Appendix E: Changes Introduced Since RFC 2063 9.5 Appendix E: Changes Introduced Since RFC 2063
The first version of the Traffic Flow Measurement Architecture was The first version of the Traffic Flow Measurement Architecture was
published as RFC 2063 in January 1997. The most significant changes published as RFC 2063 in January 1997. The most significant changes
made since then are summarised below. made since then are summarised below.
- A Traffic Meter can now run multiple rule sets concurrently. This - A Traffic Meter can now run multiple rule sets concurrently. This
makes a meter much more useful, and required only minimal changes makes a meter much more useful, and required only minimal changes
to the architecture. to the architecture.
skipping to change at page 44, line 40 skipping to change at page 45, line 5
rule set. This lifts an unneccessary earlier restriction. rule set. This lifts an unneccessary earlier restriction.
- 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.
INTERNET-DRAFT Traffic Flow Measurement: Architecture June 99
10 Acknowledgments 10 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. Particular thanks are due to Stephen Stibler and SAAG working groups. Particular thanks are due to Stephen Stibler
(IBM Research) for his patient and careful comments during the (IBM Research) for his patient and careful comments during the
preparation of this draft. preparation of this draft.
INTERNET-DRAFT Traffic Flow Measurement: Architecture May 99
11 References 11 References
[1] Handelman, S.W., Brownlee, N., Ruth, G., Stibler, S., "New [1] Handelman, S.W., Brownlee, N., Ruth, G., Stibler, S.,
Attributes for Traffic Flow Measurment," Internet Draft, "New Attributes for Traffic Flow Measurment," Internet Draft,
'Working draft' to become an Experimental RFC, IBM, The 'Working draft' to become an Experimental RFC,
University of Auckland, BBN, IBM. IBM, The University of Auckland, BBN, IBM.
[2] Mills, C., Hirsch, G. and Ruth, G., "Internet Accounting [2] Mills, C., Hirsch, G. and Ruth, G., "Internet Accounting
Background", RFC 1272, November 1991. Background", RFC 1272, November 1991.
[3] International Standards Organisation (ISO), "Management [3] International Standards Organisation (ISO), "Management
Framework," Part 4 of Information Processing Systems Open Framework," Part 4 of Information Processing Systems Open
Systems Interconnection Basic Reference Model, ISO 7498-4, Systems Interconnection Basic Reference Model, ISO 7498-4,
1994. 1994.
[4] Paxson, V., Almes, G., Mahdavi, J. and Mathis, M., [4] Paxson, V., Almes, G., Mahdavi, J. and Mathis, M.,
"Framework for IP Performance Metrics," RFC 2330, May 1998. "Framework for IP Performance Metrics," RFC 2330, May 1998.
[5] IEEE 802.3/ISO 8802-3 Information Processing Systems - [5] IEEE 802.3/ISO 8802-3 Information Processing Systems - Local
Local Area Networks - Part 3: Carrier sense multiple access Area Networks - Part 3: Carrier sense multiple access with
with collision detection (CSMA/CD) access method and physical collision detection (CSMA/CD) access method and physical
layer specifications, 2nd edition, September 21, 1990. layer specifications, 2nd edition, September 21, 1990.
[6] Brownlee, N., "SRL: A Language for Describing Traffic Flows [6] Brownlee, N., "SRL: A Language for Describing Traffic Flows
and Specifying Actions for Flow Groups," Internet Draft, and Specifying Actions for Flow Groups," Internet Draft,
'Working draft' to become an Informational RFC, The University 'Working draft' to become an Informational RFC,
of Auckland. The University of Auckland.
[7] Brownlee, N., "Traffic Flow Measurement: Meter MIB", RFC [7] Brownlee, N., "Traffic Flow Measurement: Meter MIB",
2064, January 1997. RFC 2064, January 1997.
[8] Alvestrand, H. and T. Narten, "Guidelines for Writing an [8] Alvestrand, H. and T. Narten, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434, October IANA Considerations Section in RFCs", BCP 26, RFC 2434,
1998. October 1998.
INTERNET-DRAFT Traffic Flow Measurement: Architecture June 99
12 Author's Addresses 12 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
INTERNET-DRAFT Traffic Flow Measurement: Architecture May 99
Cyndi Mills Cyndi Mills
GTE Laboratories, Inc GTE Laboratories, Inc
Phone: +1 617 466 4278 Phone: +1 617 466 4278
E-mail: cmills@gte.com E-mail: cmills@gte.com
Greg Ruth Greg Ruth
GTE Laboratories, Inc GTE Laboratories, Inc
Phone: +1 617 466 2448 Phone: +1 617 466 2448
E-mail: gruth@gte.com E-mail: gruth@gte.com
Expires November 99 Expires December 99
 End of changes. 98 change blocks. 
167 lines changed or deleted 180 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/