Request for Comments: 2720 The University of Auckland
Obsoletes: 2064 October 1999
Category: Standards Track
Traffic Flow Measurement: Meter MIB
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (1999). All Rights Reserved.
Abstract
The RTFM Traffic Measurement Architecture provides a general
framework for describing and measuring network traffic flows. Flows
are defined in terms of their Address Attribute values and measured
by a 'Traffic Meter'.
This document defines a Management Information Base (MIB) for use in
controlling an RTFM Traffic Meter, in particular for specifying the
flows to be measured. It also provides an efficient mechanism for
retrieving flow data from the meter using SNMP. Security issues
concerning the operation of traffic meters are summarised.
Table of Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2 The SNMP Management Framework . . . . . . . . . . . . . . . . 2
3 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1 Scope of Definitions, Textual Conventions . . . . . . . . . 4
3.2 Usage of the MIB variables . . . . . . . . . . . . . . . . 4
4 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5 Security Considerations . . . . . . . . . . . . . . . . . . . . 46
5.1 SNMP Concerns . . . . . . . . . . . . . . . . . . . . . . 46
5.2 Traffic Meter Concerns . . . . . . . . . . . . . . . . . . 46
6 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 48
7 Appendix A: Changes Introduced Since RFC2064 . . . . . . . . . 49
8 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 50
9 Intellectual Property Notice . . . . . . . . . . . . . . . . . 50
10 References . . . . . . . . . . . . . . . . . . . . . . . . . . 50
11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 53
12 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 54
1 Introduction
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it describes objects for managing and collecting data
from network Realtime Traffic Flow Meters, as described in [RTFM-
ARC].
The MIB is 'basic' in the sense that it provides more than enough
information for everyday traffic measurment. Furthermore, it can be
easily extended by adding new attributes as required. The RTFM
Working group is actively pursuing the development of the meter in
this way.
2 The SNMP Management Framework
The SNMP Management Framework presently consists of five major
components:
- An overall architecture, described in RFC2571 [RFC2571].
- Mechanisms for describing and naming objects and events for the
purpose of management. The first version of this Structure of
Management Information (SMI) is called SMIv1 and described in STD
16, RFC1155 [RFC1155], STD 16, RFC1212 [RFC1212] and RFC1215
[RFC1215]. The second version, called SMIv2, is described in STD
58, RFC2578 [RFC2578], RFC2579 [RFC2579] and RFC2580 [RFC2580].
- Message protocols for transferring management information. The
first version of the SNMP message protocol is called SNMPv1 and
described in STD 15, RFC1157 [RFC1157]. A second version of the
SNMP message protocol, which is not an Internet standards track
protocol, is called SNMPv2c and described in RFC1901 [RFC1901] and
RFC1906 [RFC1906]. The third version of the message protocol is
called SNMPv3 and described in RFC1906 [RFC1906], RFC2572
[RFC2572] and RFC2574 [RFC2574].
- Protocol operations for accessing management information. The
first set of protocol operations and associated PDU formats is
described in STD 15, RFC1157 [RFC1157]. A second set of protocol
operations and associated PDU formats is described in RFC1905
[RFC1905].
- A set of fundamental applications described in RFC2573 [RFC2573]
and the view-based access control mechanism described in RFC2575
[RFC2575].
A more detailed introduction to the current SNMP Management Framework
can be found in [RFC2570].
Managed objects are accessed via a virtual information store, termed
the Management Information Base or MIB. Objects in the MIB are
defined using the mechanisms defined in the SMI.
This memo specifies a MIB module that is compliant to the SMIv2. A
MIB conforming to the SMIv1 can be produced through the appropriate
translations. The resulting translated MIB must be semantically
equivalent, except where objects or events are omitted because no
translation is possible (use of Counter64). Some machine readable
information in SMIv2 will be converted into textual descriptions in
SMIv1 during the translation process. However, this loss of machine
readable information is not considered to change the semantics of the
MIB.
3 Overview
Traffic Flow Measurement seeks to provide a well-defined method for
gathering traffic flow information from networks and internetworks.
The background for this is given in "Internet Accounting Background"
[ACT-BKG]. The Realtime Traffic Flow Measurement (rtfm) Working Group
has produced a measurement architecture to achieve this goal; this is
documented in "Traffic Flow Measurement: Architecture" [RTFM-ARC].
The architecture defines three entities:
- METERS, which observe network traffic flows and build up a table of
flow data records for them,
- METER READERS, which collect traffic flow data from meters, and
- MANAGERS, which oversee the operation of meters and meter readers.
This memo defines the SNMP management information for a Traffic Flow
Meter (TFM). Work in this field was begun by the Internet Accounting
Working Group. It has been further developed and expanded by the
Realtime Traffic Flow Measurement Working Group.
3.1 Scope of Definitions, Textual Conventions
All objects defined in this memo are registered in a single subtree
within the mib-2 namespace [MIB-II, RFC2578], and are for use in
network devices which may perform a PDU forwarding or monitoring
function. For these devices, this MIB defines a group of objects
with an SMI Network Management MGMT Code [ASG-NBR] of 40, i.e.
flowMIB OBJECT IDENTIFIER ::= mib-2 40
as defined below.
The RTFM Meter MIB was first produced and tested using SNMPv1. It
was converted into SNMPv2 following the guidelines in [RFC1908].
3.2 Usage of the MIB variables
The MIB is organised in four parts - control, data, rules and
conformance statements.
The rules implement the set of packet-matching actions, as described
in the "Traffic Flow Measurment: Architecture" document [RTFM-ARC].
In addition they provide for BASIC-style subroutines, allowing a
network manager to dramatically reduce the number of rules required
to monitor a large network.
Traffic flows are identified by a set of attributes for each of their
end-points. Attributes include network addresses for each layer of
the network protocol stack, and 'subscriber ids', which may be used
to identify an accountable entity for the flow.
The conformance statements are set out as defined in [RFC2580]. They
explain what must be implemented in a meter which claims to conform
to this MIB.
To retrieve flow data one could simply do a linear scan of the flow
table. This would certainly work, but would require a lot of
protocol exchanges. To reduce the overhead in retrieving flow data
the flow table uses a TimeFilter variable, defined as a Textual
Convention in the RMON2 MIB [RMON2-MIB].
As an alternative method of reading flow data, the MIB provides a
view of the flow table called the flowDataPackageTable. This is
(logically) a four-dimensional array, subscripted by package
selector, RuleSet, activity time and starting flow number. The
package selector is a sequence of bytes which specifies a list of
flow attributes.
A data package (as returned by the meter) is a sequence of values for
the attributes specified in its selector, encoded using the Basic
Encoding Rules [ASN-BER]. It allows a meter reader to retrieve all
the attribute values it requires in a single MIB object. This, when
used together with SNMPv2's GetBulk request, allows a meter reader to
scan the flow table and upload a specified set of attribute values
for flows which have changed since the last reading, and which were
created by a specified rule set.
One aspect of data collection which needs emphasis is that all the
MIB variables are set up to allow multiple independent meter readers
to work properly, i.e. the flow table indexes are stateless. An
alternative approach would have been to 'snapshot' the flow table,
which would mean that the meter readers would have to be
synchronized. The stateless approach does mean that two meter
readers will never return exactly the same set of traffic counts, but
over long periods (e.g. 15-minute collections over a day) the
discrepancies are acceptable. If one really needs a snapshot, this
can be achieved by switching to an identical rule set with a
different RuleSet number, hence asynchronous collections may be
regarded as a useful generalisation of synchronised ones.
The control variables are the minimum set required for a meter
reader. Their number has been whittled down as experience has been
gained with the MIB implementation. A few of them are 'general',
i.e. they control the overall behaviour of the meter. These are set
by a single 'master' manager, and no other manager should attempt to
change their values. The decision as to which manager is the '
master' must be made by the network operations personnel responsible;
this MIB does not attempt to define any interaction between managers.
There are three other groups of control variables, arranged into
tables in the same way as in the RMON2 MIB [RMON2-MIB]. They are used
as follows:
- RULE SET INFO: Before attempting to download a RuleSet, a manager
must create a row in the flowRuleSetInfoTable and set its
flowRuleInfoSize to a value large enough to hold the RuleSet. When
the rule set is ready the manager must set flowRuleInfoRulesReady
to 'true', indicating that the rule set is ready for use (but not
yet 'running').
- METER READER INFO: Any meter reader wishing to collect data
reliably for all flows from a RuleSet should first create a row in
the flowReaderInfoTable with flowReaderRuleSet set to that
RuleSet's index in the flowRuleSetInfoTable. It should write that
row's flowReaderLastTime object each time it starts a collection
pass through the flow table. The meter will not recover a flow's
memory until every meter reader holding a row for that flow's
RuleSet has collected the flow's data.
- MANAGER INFO: Any manager wishing to run a RuleSet in the meter
must create a row in the flowManagerInfo table, specifying the
desired RuleSet to run and its corresponding 'standby' RuleSet (if
one is desired). A current RuleSet is 'running' if its
flowManagerRunningStandby value is false(2), similarly a standby
RuleSet is 'running' if flowManagerRunningStandby is true(1).
Times within the meter are in terms of its Uptime, i.e. centiseconds
since the meter started. For meters implemented as self-contained
SNMP agents this will be the same as sysUptime, but this may not be
true for meters implemented as subagents. Managers can read the
meter's Uptime when neccessary (e.g. to set a TimeFilter value) by
setting flowReaderLastTime, then reading its new value.
4 Definitions
FLOW-METER-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE,
Counter32, Counter64, Integer32, mib-2
FROM SNMPv2-SMI
TEXTUAL-CONVENTION, RowStatus, TimeStamp, TruthValue
FROM SNMPv2-TC
OBJECT-GROUP, MODULE-COMPLIANCE
FROM SNMPv2-CONF
ifIndex
FROM IF-MIB
TimeFilter
FROM RMON2-MIB;
flowMIB MODULE-IDENTITY
LAST-UPDATED "9910250000Z" -- October 25, 1999
ORGANIZATION "IETF Realtime Traffic Flow Measurement Working Group"
CONTACT-INFO
"Nevil Brownlee, The University of Auckland
Postal: Information Technology Sytems & Services
The University of Auckland
Private Bag 92-019
Auckland, New Zealand
Phone: +64 9 373 7599 x8941
E-mail: n.brownlee@auckland.ac.nz"
DESCRIPTION
"MIB for the RTFM Traffic Flow Meter."
REVISION "9910250000Z"
DESCRIPTION
"Initial Version, published as RFC2720."
REVISION "9908301250Z"
DESCRIPTION
"UTF8OwnerString Textual Convention added, and used to
replace OwnerString. Conceptually the same as OwnerString,
but facilitating internationalisation by using UTF-8
encoding for its characters rather than US-ASCII."
REVISION "9908191010Z"
DESCRIPTION
"Changes to SIZE specification for two variables:
- flowRuleInfoName SIZE specified as (0..127)
- flowRuleIndex SIZE increased to (1..2147483647)"
REVISION "9712230937Z"
DESCRIPTION
"Two further variables deprecated:
- flowRuleInfoRulesReady (use flowRuleInfoStatus intead)
- flowDataStatus (contains no useful information)"
REVISION "9707071715Z"
DESCRIPTION
"Significant changes since RFC2064 include:
- flowDataPackageTable added
- flowColumnActivityTable deprecated
- flowManagerCounterWrap deprecated"
REVISION "9603080208Z"
DESCRIPTION
"Initial version of this MIB (RFC2064)"
::= { mib-2 40 }
flowControl OBJECT IDENTIFIER ::= { flowMIB 1 }
flowData OBJECT IDENTIFIER ::= { flowMIB 2 }
flowRules OBJECT IDENTIFIER ::= { flowMIB 3 }
flowMIBConformance OBJECT IDENTIFIER ::= { flowMIB 4 }
-- Textual Conventions
UTF8OwnerString ::= TEXTUAL-CONVENTION
DISPLAY-HINT "127t"
STATUS current
DESCRIPTION
"An administratively assigned name for the owner of a
resource, conceptually the same as OwnerString in the RMON
MIB [RMON-MIB].
To facilitate internationalisation, this name information
is represented using the ISO/IEC IS 10646-1 character set,
encoded as an octet string using the UTF-8 transformation
format described in the UTF-8 standard [UTF-8]."
SYNTAX OCTET STRING (SIZE (0..127))
PeerType ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Indicates the type of a PeerAddress (see below). The values
used are from the 'Address Family Numbers' section of the
Assigned Numbers RFC[ASG-NBR]. Peer types from other address
families may also be used, provided only that they are
identified by their assigned Address Family numbers."
SYNTAX INTEGER {
ipv4(1),
ipv6(2),
nsap(3),
ipx(11),
appletalk(12),
decnet(13) }
PeerAddress ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Specifies the value of a peer address for various network
protocols. Address format depends on the actual protocol,
as indicated below:
IPv4: ipv4(1)
4-octet IpAddress (defined in the SNMPv2 SMI [RFC2578])
IPv6: ipv6(2)
16-octet IpAddress (defined in the
IPv6 Addressing RFC[V6-ADDR])
CLNS: nsap(3)
NsapAddress (defined in the SNMPv2 SMI [RFC2578])
Novell: ipx(11)
4-octet Network number,
6-octet Host number (MAC address)
AppleTalk: appletalk(12)
2-octet Network number (sixteen bits),
1-octet Host number (eight bits)
DECnet: decnet(13)
1-octet Area number (in low-order six bits),
2-octet Host number (in low-order ten bits)
"
SYNTAX OCTET STRING (SIZE (3..20))
AdjacentType ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Indicates the type of an adjacent address. May be a medium
type or (if metering is taking place inside a tunnel) a
PeerType (see above).
The values used for IEEE 802 medium types are from the 'Network
Management Parameters (ifType definitions)' section of the
Assigned Numbers RFC[ASG-NBR]. Other medium types may also
be used, provided only that they are identified by their
assigned ifType numbers."
SYNTAX INTEGER {
ip(1),
nsap(3),
ethernet(7), -- ethernet-like [ENET-OBJ],
-- includes ethernet-csmacd(6)
tokenring(9),
ipx(11),
appletalk(12),
decnet(13),
fddi(15) }
AdjacentAddress ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Specifies the value of an adjacent address. May be a Medium
Access Control (MAC) address or (if metering is taking place
inside a tunnel) a PeerAddress (see above).
MAC Address format depends on the actual medium, as follows:
Ethernet: ethernet(7)
6-octet 802.3 MAC address in 'canonical' order
Token Ring: tokenring(9)
6-octet 802.5 MAC address in 'canonical' order
FDDI: fddi(15)
FddiMACLongAddress, i.e. a 6-octet MAC address
in 'canonical' order (defined in [FDDI-MIB])
"
SYNTAX OCTET STRING (SIZE (3..20))
TransportType ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Indicates the type of a TransportAddress (see below). Values
will depend on the actual protocol; for IP they will be those
given in the 'Protocol Numbers' section of the Assigned Numbers
RFC[ASG-NBR], including icmp(1), tcp(6) and udp(17)."
SYNTAX Integer32 (1..255)
TransportAddress ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Specifies the value of a transport address for various
network protocols. Format as follows:
IP:
2-octet UDP or TCP port number
Other protocols:
2-octet port number
"
SYNTAX OCTET STRING (SIZE (2))
RuleAddress ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Specifies the value of an address. Is a superset of
MediumAddress, PeerAddress and TransportAddress."
SYNTAX OCTET STRING (SIZE (2..20))
FlowAttributeNumber ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Uniquely identifies an attribute within a flow data record."
SYNTAX INTEGER {
flowIndex(1),
flowStatus(2),
flowTimeMark(3),
sourceInterface(4),
sourceAdjacentType(5),
sourceAdjacentAddress(6),
sourceAdjacentMask(7),
sourcePeerType(8),
sourcePeerAddress(9),
sourcePeerMask(10),
sourceTransType(11),
sourceTransAddress(12),
sourceTransMask(13),
destInterface(14),
destAdjacentType(15),
destAdjacentAddress(16),
destAdjacentMask(17),
destPeerType(18),
destPeerAddress(19),
destPeerMask(20),
destTransType(21),
destTransAddress(22),
destTransMask(23),
pduScale(24),
octetScale(25),
ruleSet(26),
toOctets(27), -- Source-to-Dest
toPDUs(28),
fromOctets(29), -- Dest-to-Source
fromPDUs(30),
firstTime(31), -- Activity times
lastActiveTime(32),
sourceSubscriberID(33), -- Subscriber ID
destSubscriberID(34),
sessionID(35),
sourceClass(36), -- Computed attributes
destClass(37),
flowClass(38),
sourceKind(39),
destKind(40),
flowKind(41) }
RuleAttributeNumber ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Uniquely identifies an attribute which may be tested in
a rule. These include attributes whose values come directly
from (or are computed from) the flow's packets, and the five
'meter' variables used to hold an Attribute Number."
SYNTAX INTEGER {
null(0),
sourceInterface(4), -- Source Address
sourceAdjacentType(5),
sourceAdjacentAddress(6),
sourcePeerType(8),
sourcePeerAddress(9),
sourceTransType(11),
sourceTransAddress(12),
destInterface(14), -- Dest Address
destAdjacentType(15),
destAdjacentAddress(16),
destPeerType(18),
destPeerAddress(19),
destTransType(21),
destTransAddress(22),
sourceSubscriberID(33), -- Subscriber ID
destSubscriberID(34),
sessionID(35),
sourceClass(36), -- Computed attributes
destClass(37),
flowClass(38),
sourceKind(39),
destKind(40),
flowKind(41),
matchingStoD(50), -- Packet matching
v1(51), -- Meter variables
v2(52),
v3(53),
v4(54),
v5(55) }
ActionNumber ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Uniquely identifies the action of a rule, i.e. the Pattern
Matching Engine's opcode number. Details of the opcodes
are given in the 'Traffic Flow Measurement: Architecture'
document [RTFM-ARC]."
SYNTAX INTEGER {
ignore(1),
noMatch(2),
count(3),
countPkt(4),
return(5),
gosub(6),
gosubAct(7),
assign(8),
assignAct(9),
goto(10),
gotoAct(11),
pushRuleTo(12),
pushRuleToAct(13),
pushPktTo(14),
pushPktToAct(15),
popTo(16),
popToAct(17) }
--
-- Control Group: RuleSet Info Table
--
flowRuleSetInfoTable OBJECT-TYPE
SYNTAX SEQUENCE OF FlowRuleSetInfoEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An array of information about the RuleSets held in the
meter.
Any manager may configure a new RuleSet for the meter by
creating a row in this table with status active(1), and setting
values for all the objects in its rules. At this stage the new
RuleSet is available but not 'running', i.e. it is not being
used by the meter to produce entries in the flow table.
To actually 'run' a RuleSet a manager must create a row in
the flowManagerInfoTable, set it's flowManagerStatus to
active(1), and set either its CurrentRuleSet or StandbyRuleSet
to point to the RuleSet to be run.
Once a RuleSet is running a manager may not change any of the
objects within the RuleSet itself. Any attempt to do so should
result in a notWritable(17) SNMP error-status for such objects.
A manager may stop a RuleSet running by removing all
references to it in the flowManagerInfoTable (i.e. by setting
CurrentRuleSet and StandbyRuleSet values to 0). This provides
a way to stop RuleSets left running if a manager fails.
For example, when a manager is started, it could search the
meter's flowManager table and stop all RuleSets having a
specified value of flowRuleInfoOwner.
To prevent a manager from interfering with variables belonging
to another manager, the meter should use MIB views [RFC2575] so
as to limit each manager's access to the meter's variables,
effectively dividing the single meter into several virtual
meters, one for each independent manager."
::= { flowControl 1 }
flowRuleSetInfoEntry OBJECT-TYPE
SYNTAX FlowRuleSetInfoEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Information about a particular RuleSet."
INDEX { flowRuleInfoIndex }
::= { flowRuleSetInfoTable 1 }
FlowRuleSetInfoEntry ::= SEQUENCE {
flowRuleInfoIndex Integer32,
flowRuleInfoSize Integer32,
flowRuleInfoOwner UTF8OwnerString,
flowRuleInfoTimeStamp TimeStamp,
flowRuleInfoStatus RowStatus,
flowRuleInfoName OCTET STRING,
flowRuleInfoRulesReady TruthValue,
flowRuleInfoFlowRecords Integer32
}
flowRuleInfoIndex OBJECT-TYPE
SYNTAX Integer32 (1..2147483647)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An index which selects an entry in the flowRuleSetInfoTable.
Each such entry contains control information for a particular
RuleSet which the meter may run."
::= { flowRuleSetInfoEntry 1 }
flowRuleInfoSize OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Number of rules in this RuleSet. Setting this variable will
cause the meter to allocate space for these rules."
::= { flowRuleSetInfoEntry 2 }
flowRuleInfoOwner OBJECT-TYPE
SYNTAX UTF8OwnerString
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Identifies the manager which 'owns' this RuleSet. A manager
must set this variable when creating a row in this table."
::= { flowRuleSetInfoEntry 3 }
flowRuleInfoTimeStamp OBJECT-TYPE
SYNTAX TimeStamp
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Time this row's associated RuleSet was last changed."
::= { flowRuleSetInfoEntry 4 }
flowRuleInfoStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The status of this flowRuleSetInfoEntry. If this value is
not active(1) the meter must not attempt to use the row's
associated RuleSet. Once its value has been set to active(1)
a manager may not change any of the other variables in the
row, nor the contents of the associated RuleSet. Any attempt
to do so should result in a notWritable(17) SNMP error-status
for such variables or objects.
To download a RuleSet, a manger could:
- Locate an open slot in the RuleSetInfoTable.
- Create a RuleSetInfoEntry by setting the status for this
open slot to createAndWait(5).
- Set flowRuleInfoSize and flowRuleInfoName as required.
- Download the rules into the row's rule table.
- Set flowRuleInfoStatus to active(1).
The RuleSet would then be ready to run. The manager is not
allowed to change the value of flowRuleInfoStatus from
active(1) if the associated RuleSet is being referenced by any
of the entries in the flowManagerInfoTable.
Setting RuleInfoStatus to destroy(6) destroys the associated
RuleSet together with any flow data collected by it."
::= { flowRuleSetInfoEntry 5 }
flowRuleInfoName OBJECT-TYPE
SYNTAX OCTET STRING (SIZE (0..127))
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"An alphanumeric identifier used by managers and readers to
identify a RuleSet. For example, a manager wishing to run a
RuleSet named WWW-FLOWS could search the flowRuleSetInfoTable
to see whether the WWW-FLOWS RuleSet is already available on
the meter.
Note that references to RuleSets in the flowManagerInfoTable
use indexes for their flowRuleSetInfoTable entries. These may
be different each time the RuleSet is loaded into a meter."
::= { flowRuleSetInfoEntry 6 }
flowRuleInfoRulesReady OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-create
STATUS deprecated
DESCRIPTION
"Indicates whether the rules for this row's associated RuleSet
are ready for use. The meter will refuse to 'run' the RuleSet
unless this variable has been set to true(1).
While RulesReady is false(2), the manager may modify the
RuleSet, for example by downloading rules into it."
::= { flowRuleSetInfoEntry 7 }
flowRuleInfoFlowRecords OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of entries in the flow table for this RuleSet.
These may be current (waiting for collection by one or more
meter readers) or idle (waiting for the meter to recover
their memory)."
::= { flowRuleSetInfoEntry 8 }
--
-- Control Group: Interface Info Table
--
flowInterfaceTable OBJECT-TYPE
SYNTAX SEQUENCE OF FlowInterfaceEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An array of information specific to each meter interface."
::= { flowControl 2 }
flowInterfaceEntry OBJECT-TYPE
SYNTAX FlowInterfaceEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Information about a particular interface."
INDEX { ifIndex }
::= { flowInterfaceTable 1 }
FlowInterfaceEntry ::= SEQUENCE {
flowInterfaceSampleRate Integer32,
flowInterfaceLostPackets Counter32
}
flowInterfaceSampleRate OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The parameter N for statistical counting on this interface.
Set to N to count 1/Nth of the packets appearing at this
interface. A sampling rate of 1 counts all packets.
A sampling rate of 0 results in the interface being ignored
by the meter.
A meter should choose its own algorithm to introduce variance
into the sampling so that exactly every Nth packet is counted.
The IPPM Working Group's RFC'Framework for IP Performance
Metrics' [IPPM-FRM] explains why this should be done, and sets
out an algorithm for doing it."
DEFVAL { 1 }
::= { flowInterfaceEntry 1 }
flowInterfaceLostPackets OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of packets the meter has lost for this interface.
Such losses may occur because the meter has been unable to
keep up with the traffic volume."
::= { flowInterfaceEntry 2 }
--
-- Control Group: Meter Reader Info Table
--
-- Any meter reader wishing to collect data reliably for flows
-- should first create a row in this table. It should write that
-- row's flowReaderLastTime object each time it starts a collection
-- pass through the flow table.
-- If a meter reader (MR) does not create a row in this table, e.g.
-- because its MIB view [RFC2575] did not allow MR create access to
-- flowReaderStatus, collection can still proceed but the meter will
-- not be aware of meter reader MR. This could lead the meter to
-- recover flows before they have been collected by MR.
flowReaderInfoTable OBJECT-TYPE
SYNTAX SEQUENCE OF FlowReaderInfoEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An array of information about meter readers which have
registered their intent to collect flow data from this meter."
::= { flowControl 3 }
flowReaderInfoEntry OBJECT-TYPE
SYNTAX FlowReaderInfoEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Information about a particular meter reader."
INDEX { flowReaderIndex }
::= { flowReaderInfoTable 1 }
FlowReaderInfoEntry ::= SEQUENCE {
flowReaderIndex Integer32,
flowReaderTimeout Integer32,
flowReaderOwner UTF8OwnerString,
flowReaderLastTime TimeStamp,
flowReaderPreviousTime TimeStamp,
flowReaderStatus RowStatus,
flowReaderRuleSet Integer32
}
flowReaderIndex OBJECT-TYPE
SYNTAX Integer32 (1..2147483647)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An index which selects an entry in the flowReaderInfoTable."
::= { flowReaderInfoEntry 1 }
flowReaderTimeout OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Specifies the maximum time (in seconds) between flow data
collections for this meter reader. If this time elapses
without a collection, the meter should assume that this meter
reader has stopped collecting, and delete this row from the
table. A value of zero indicates that this row should not be
timed out."
::= { flowReaderInfoEntry 2 }
flowReaderOwner OBJECT-TYPE
SYNTAX UTF8OwnerString
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Identifies the meter reader which created this row."
::= { flowReaderInfoEntry 3 }
flowReaderLastTime OBJECT-TYPE
SYNTAX TimeStamp
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Time this meter reader began its most recent data collection.
This variable should be written by a meter reader as its first
step in reading flow data. The meter will set this LastTime
value to its current Uptime, and set its PreviousTime value
(below) to the old LastTime. This allows the meter to
recover flows which have been inactive since PreviousTime,
for these have been collected at least once.
If the meter reader fails to write flowLastReadTime, collection
may still proceed but the meter may not be able to recover
inactive flows until the flowReaderTimeout has been reached
for this entry."
::= { flowReaderInfoEntry 4 }
flowReaderPreviousTime OBJECT-TYPE
SYNTAX TimeStamp
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Time this meter reader began the collection before last."
::= { flowReaderInfoEntry 5 }
flowReaderStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The status of this FlowReaderInfoEntry. A value of active(1)
implies that the associated reader should be collecting data
from the meter. Once this variable has been set to active(1)
a manager may only change this row's flowReaderLastTime and
flowReaderTimeout variables."
::= { flowReaderInfoEntry 6 }
flowReaderRuleSet OBJECT-TYPE
SYNTAX Integer32 (1..2147483647)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"An index to the array of RuleSets. Specifies a set of rules
of interest to this meter reader. The reader will attempt to
collect any data generated by the meter for this RuleSet, and
the meter will not recover the memory of any of the RuleSet's
flows until this collection has taken place. Note that a
reader may have entries in this table for several RuleSets."
::= { flowReaderInfoEntry 7 }
--
-- Control Group: Manager Info Table
--
-- Any manager wishing to run a RuleSet must create a row in this
-- table. Once it has a table row, the manager may set the control
-- variables in its row so as to cause the meter to run any valid
-- RuleSet held by the meter.
-- A single manager may run several RuleSets; it must create a row
-- in this table for each of them. In short, each row of this table
-- describes (and controls) a 'task' which the meter is executing.
flowManagerInfoTable OBJECT-TYPE
SYNTAX SEQUENCE OF FlowManagerInfoEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An array of information about managers which have
registered their intent to run RuleSets on this meter."
::= { flowControl 4 }
flowManagerInfoEntry OBJECT-TYPE
SYNTAX FlowManagerInfoEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Information about a particular meter 'task.' By creating
an entry in this table and activating it, a manager requests
that the meter 'run' the indicated RuleSet.
The entry also specifies a HighWaterMark and a StandbyRuleSet.
If the meter's flow table usage exceeds this task's
HighWaterMark the meter will stop running the task's
CurrentRuleSet and switch to its StandbyRuleSet.
If the value of the task's StandbyRuleSet is 0 when its
HighWaterMark is exceeded, the meter simply stops running the
task's CurrentRuleSet. By careful selection of HighWaterMarks
for the various tasks a manager can ensure that the most
critical RuleSets are the last to stop running as the number
of flows increases.
When a manager has determined that the demand for flow table
space has abated, it may cause the task to switch back to its
CurrentRuleSet by setting its flowManagerRunningStandby
variable to false(2)."
INDEX { flowManagerIndex }
::= { flowManagerInfoTable 1 }
FlowManagerInfoEntry ::= SEQUENCE {
flowManagerIndex Integer32,
flowManagerCurrentRuleSet Integer32,
flowManagerStandbyRuleSet Integer32,
flowManagerHighWaterMark Integer32,
flowManagerCounterWrap INTEGER,
flowManagerOwner UTF8OwnerString,
flowManagerTimeStamp TimeStamp,
flowManagerStatus RowStatus,
flowManagerRunningStandby TruthValue
}
flowManagerIndex OBJECT-TYPE
SYNTAX Integer32 (1..2147483647)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An index which selects an entry in the flowManagerInfoTable."
::= { flowManagerInfoEntry 1 }
flowManagerCurrentRuleSet OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Index to the array of RuleSets. Specifies which set of
rules is the 'current' one for this task. The meter will
be 'running' the current RuleSet if this row's
flowManagerRunningStandby value is false(2).
When the manager sets this variable the meter will stop using
the task's old current RuleSet and start using the new one.
Specifying RuleSet 0 (the empty set) stops flow measurement
for this task."
::= { flowManagerInfoEntry 2 }
flowManagerStandbyRuleSet OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Index to the array of RuleSets. After reaching HighWaterMark
(see below) the manager will switch to using the task's
StandbyRuleSet in place of its CurrentRuleSet. For this to be
effective the designated StandbyRuleSet should have a coarser
reporting granularity then the CurrentRuleSet. The manager may
also need to decrease the meter reading interval so that the
meter can recover flows measured by this task's CurrentRuleSet."
DEFVAL { 0 } -- No standby
::= { flowManagerInfoEntry 3 }
flowManagerHighWaterMark OBJECT-TYPE
SYNTAX Integer32 (0..100)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"A value expressed as a percentage, interpreted by the meter
as an indication of how full the flow table should be before
it should switch to the standby RuleSet (if one has been
specified) for this task. Values of 0% or 100% disable the
checking represented by this variable."
::= { flowManagerInfoEntry 4 }
flowManagerCounterWrap OBJECT-TYPE
SYNTAX INTEGER { wrap(1), scale(2) }
MAX-ACCESS read-create
STATUS deprecated
DESCRIPTION
"Specifies whether PDU and octet counters should wrap when
they reach the top of their range (normal behaviour for
Counter64 objects), or whether their scale factors should
be used instead. The combination of counter and scale
factor allows counts to be returned as non-negative binary
floating point numbers, with 64-bit mantissas and 8-bit
exponents."
DEFVAL { wrap }
::= { flowManagerInfoEntry 5 }
flowManagerOwner OBJECT-TYPE
SYNTAX UTF8OwnerString
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Identifies the manager which created this row."
::= { flowManagerInfoEntry 6 }
flowManagerTimeStamp OBJECT-TYPE
SYNTAX TimeStamp
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Time this row was last changed by its manager."
::= { flowManagerInfoEntry 7 }
flowManagerStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The status of this row in the flowManagerInfoTable. A value
of active(1) implies that this task may be activated, by
setting its CurrentRuleSet and StandbyRuleSet variables.
Its HighWaterMark and RunningStandby variables may also be
changed."
::= { flowManagerInfoEntry 8 }
flowManagerRunningStandby OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Set to true(1) by the meter to indicate that it has switched
to runnning this task's StandbyRuleSet in place of its
CurrentRuleSet. To switch back to the CurrentRuleSet, the
manager may simply set this variable to false(2)."
DEFVAL { false }
::= { flowManagerInfoEntry 9 }
--
-- Control Group: General Meter Control Variables
--
flowFloodMark OBJECT-TYPE
SYNTAX Integer32 (0..100)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"A value expressed as a percentage, interpreted by the meter
as an indication of how full the flow table should be before
it should take some action to avoid running out of resources
to handle new flows, as discussed in section 4.6 (Handling
Increasing Traffic Levels) of the RTFM Architecture RFC
[RTFM-ARC].
Values of 0% or 100% disable the checking represented by
this variable."
DEFVAL { 95 } -- Enabled by default.
::= { flowControl 5 }
flowInactivityTimeout OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The time in seconds since the last packet seen, after which
a flow becomes 'idle.' Note that although a flow may be
idle, it will not be discarded (and its memory recovered)
until after its data has been collected by all the meter
readers registered for its RuleSet."
DEFVAL { 600 } -- 10 minutes
::= { flowControl 6 }
flowActiveFlows OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of flows which are currently in use."
::= { flowControl 7 }
flowMaxFlows OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The maximum number of flows allowed in the meter's
flow table. At present this is determined when the meter
is first started up."
::= { flowControl 8 }
flowFloodMode OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"Indicates that the meter has passed its FloodMark and is
not running in its normal mode.
When the manager notices this it should take action to remedy
the problem which caused the flooding. It should then monitor
flowActiveFlows so as to determine when the flood has receded.
At that point the manager may set flowFloodMode to false(2) to
resume normal operation."
::= { flowControl 9 }
--
-- The Flow Table
--
-- This is a table kept by a meter, with one flow data entry for every
-- flow being measured. Each flow data entry stores the attribute
-- values for a traffic flow. Details of flows and their attributes
-- are given in the 'Traffic Flow Measurement: Architecture'
-- document [RTFM-ARC].
-- From time to time a meter reader may sweep the flow table so as
-- to read counts. This is most effectively achieved by using the
-- TimeMark variable together with successive GetBulk requests to
-- retrieve the values of the desired flow attribute variables.
-- This scheme allows multiple meter readers to independently use the
-- same meter; the meter readers do not have to be synchronised and
-- they may use different collection intervals.
-- If identical sets of counts are required from a meter, a manager
-- could achieve this using two identical copies of a RuleSet in that
-- meter and switching back and forth between them. This is discussed
-- further in the RTFM Architecture document [RTFM-ARC].
flowDataTable OBJECT-TYPE
SYNTAX SEQUENCE OF FlowDataEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The list of all flows being measured."
::= { flowData 1 }
flowDataEntry OBJECT-TYPE
SYNTAX FlowDataEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The flow data record for a particular flow."
INDEX { flowDataRuleSet, flowDataTimeMark, flowDataIndex }
::= { flowDataTable 1 }
FlowDataEntry ::= SEQUENCE {
flowDataIndex Integer32,
flowDataTimeMark TimeFilter,
flowDataStatus INTEGER,
flowDataSourceInterface Integer32,
flowDataSourceAdjacentType AdjacentType,
flowDataSourceAdjacentAddress AdjacentAddress,
flowDataSourceAdjacentMask AdjacentAddress,
flowDataSourcePeerType PeerType,
flowDataSourcePeerAddress PeerAddress,
flowDataSourcePeerMask PeerAddress,
flowDataSourceTransType TransportType,
flowDataSourceTransAddress TransportAddress,
flowDataSourceTransMask TransportAddress,
flowDataDestInterface Integer32,
flowDataDestAdjacentType AdjacentType,
flowDataDestAdjacentAddress AdjacentAddress,
flowDataDestAdjacentMask AdjacentAddress,
flowDataDestPeerType PeerType,
flowDataDestPeerAddress PeerAddress,
flowDataDestPeerMask PeerAddress,
flowDataDestTransType TransportType,
flowDataDestTransAddress TransportAddress,
flowDataDestTransMask TransportAddress,
flowDataPDUScale Integer32,
flowDataOctetScale Integer32,
flowDataRuleSet Integer32,
flowDataToOctets Counter64, -- Source->Dest
flowDataToPDUs Counter64,
flowDataFromOctets Counter64, -- Dest->Source
flowDataFromPDUs Counter64,
flowDataFirstTime TimeStamp, -- Activity times
flowDataLastActiveTime TimeStamp,
flowDataSourceSubscriberID OCTET STRING,
flowDataDestSubscriberID OCTET STRING,
flowDataSessionID OCTET STRING,
flowDataSourceClass Integer32,
flowDataDestClass Integer32,
flowDataClass Integer32,
flowDataSourceKind Integer32,
flowDataDestKind Integer32,
flowDataKind Integer32
}
flowDataIndex OBJECT-TYPE
SYNTAX Integer32 (1..2147483647)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Value of this flow data record's index within the meter's
flow table."
::= { flowDataEntry 1 }
flowDataTimeMark OBJECT-TYPE
SYNTAX TimeFilter
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A TimeFilter for this entry. Allows GetNext and GetBulk
to find flow table rows which have changed since a specified
value of the meter's Uptime."
::= { flowDataEntry 2 }
flowDataStatus OBJECT-TYPE
SYNTAX INTEGER { inactive(1), current(2) }
MAX-ACCESS read-only
STATUS deprecated
DESCRIPTION
"Status of this flow data record."
::= { flowDataEntry 3 }
flowDataSourceInterface OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Index of the interface associated with the source address
for this flow. It's value is one of those contained in the
ifIndex field of the meter's interfaces table."
::= { flowDataEntry 4 }
flowDataSourceAdjacentType OBJECT-TYPE
SYNTAX AdjacentType
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Adjacent address type of the source for this flow.
If metering is being performed at the network level,
AdjacentType will indicate the medium for the interface on