draft-ietf-rtfm-meter-mib-06.txt   draft-ietf-rtfm-meter-mib-07.txt 
Internet Engineering Task Force Nevil Brownlee Internet Engineering Task Force Nevil Brownlee
INTERNET-DRAFT The University of Auckland INTERNET-DRAFT The University of Auckland
September 1998 Expires October 1999
Traffic Flow Measurement: Meter MIB Traffic Flow Measurement: Meter MIB
<draft-ietf-rtfm-meter-mib-06.txt> <draft-ietf-rtfm-meter-mib-07.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft and is in full conformance with all
documents of the Internet Engineering Task Force (IETF), its Areas, and provisions of Section 10 of RFC2026.
its Working Groups. Note that other groups may also distribute working
documents as Internet-Drafts. This Internet Draft is a product of the
Realtime Traffic Flow Measurement Working Group of the IETF.
Internet Drafts are draft documents valid for a maximum of six months. Internet-Drafts are working documents of the Internet Engineering Task
Internet Drafts may be updated, replaced, or obsoleted by other Force (IETF), its areas, and its working groups. Note that other groups
documents at any time. It is not appropriate to use Internet Drafts as may also distribute working documents as Internet-Drafts.
reference material or to cite them other than as a "working draft" or
"work in progress."
To view the entire list of current Internet-Drafts, please check the Internet-Drafts are draft documents valid for a maximum of six months
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow and may be updated, replaced, or obsoleted by other documents at any
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), time. It is inappropriate to use Internet-Drafts as reference material
ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), or to cite them other than as "work in progress."
ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet Draft is a product of the Realtime Traffic Flow
Measurement Working Group of the IETF.
Abstract Abstract
A 'Traffic Meter' collects data relating to traffic flows within a A 'Traffic Meter' collects data relating to traffic flows within a
network. This document defines a Management Information Base (MIB) for network. This document defines a Management Information Base (MIB) for
use in controlling a traffic meter, in particular for specifying the use in controlling a traffic meter, in particular for specifying the
flows to be measured. It also provides an efficient mechanism for flows to be measured. It also provides an efficient mechanism for
retrieving flow data from the meter using SNMP. Security issues retrieving flow data from the meter using SNMP. Security issues
concerning the operation of traffic meters are summarised. concerning the operation of traffic meters are summarised.
Contents Contents
1 Introduction 2 1 Introduction 2
2 The Network Management Framework 2 2 The Network Management Framework 3
3 Objects 3 3 Objects 3
3.1 Format of Definitions . . . . . . . . . . . . . . . . . . . . 4 3.1 Format of Definitions . . . . . . . . . . . . . . . . . . . . 4
4 Overview 4 4 Overview 4
4.1 Scope of Definitions, Textual Conventions . . . . . . . . . . 4 4.1 Scope of Definitions, Textual Conventions . . . . . . . . . . 5
4.2 Usage of the MIB variables . . . . . . . . . . . . . . . . . . 5 4.2 Usage of the MIB variables . . . . . . . . . . . . . . . . . . 5
5 Definitions 7 5 Definitions 7
6 Security Considerations 44 6 Security Considerations 45
6.1 SNMP Concerns . . . . . . . . . . . . . . . . . . . . . . . . 44 6.1 SNMP Concerns . . . . . . . . . . . . . . . . . . . . . . . . 45
6.2 Traffic Meter Concerns . . . . . . . . . . . . . . . . . . . . 44 6.2 Traffic Meter Concerns . . . . . . . . . . . . . . . . . . . . 45
7 Appendix A: Changes Introduced Since RFC 2064 46 7 IANA Considerations 47
8 Acknowledgements 47 8 Appendix A: Changes Introduced Since RFC 2064 47
9 References 47 9 Acknowledgements 48
10 Author's Address 48 10 References 49
11 Author's Address 50
1 Introduction 1 Introduction
This memo defines a portion of the Management Information Base (MIB) for This memo defines a portion of the Management Information Base (MIB) for
use with network management protocols in the Internet community. In use with network management protocols in the Internet community. In
particular, it describes objects for managing and collecting data from particular, it describes objects for managing and collecting data from
network Realtime Traffic Flow Meters, as described in [9]. network Realtime Traffic Flow Meters, as described in [1].
The MIB is 'basic' in the sense that it provides more than enough The MIB is 'basic' in the sense that it provides more than enough
information for everyday traffic measurment. Furthermore, it can be information for everyday traffic measurment. Furthermore, it can be
easily extended by adding new attributes as required. The RTFM Working easily extended by adding new attributes as required. The RTFM Working
group is actively pursuing the development of the meter in this way. group is actively pursuing the development of the meter in this way.
2 The Network Management Framework 2 The Network Management Framework
The Internet-standard Network Management Framework consists of three The Internet-standard Network Management Framework consists of three
components. They are: components. They are:
RFC 1155 defines the SMI, the mechanisms used for describing RFC 1155 defines the SMI, the mechanisms used for describing
and naming objects for the purpose of management. RFC 1212 and naming objects for the purpose of management. RFC 1212
defines a more concise description mechanism, which is wholly defines a more concise description mechanism, which is wholly
consistent with the SMI. consistent with the SMI.
RFC 1156 defines MIB-I, the core set of managed objects for the RFC 1156 defines MIB-I, the core set of managed objects for the
Internet suite of protocols. RFC 1213 [1] defines MIB-II, an Internet suite of protocols. RFC 1213 [2] defines MIB-II, an
evolution of MIB-I based on implementation experience and new evolution of MIB-I based on implementation experience and new
operational requirements. operational requirements.
RFC 1157 defines the SNMP, the protocol used for network access RFC 1157 defines the SNMP, the protocol used for network access
to managed objects. to managed objects.
RFC 1902 [2] defines the SMI for version 2 of the Simple RFC 1902 [3] defines the SMI for version 2 of the Simple
Network Management Protocol. Network Management Protocol.
RFCs 1903 and 1904 [3,4] define Textual Conventions and RFCs 1903 and 1904 [4,5] define Textual Conventions and
Conformance Statements for version 2 of the Simple Network Conformance Statements for version 2 of the Simple Network
Management Protocol. Management Protocol.
RFC 1908 [5] describes how versions 1 and 2 of the Simple RFC 1908 [6] describes how versions 1 and 2 of the Simple
Network Management Protocol should coexist. Network Management Protocol should coexist.
The Framework permits new objects to be defined for the purpose of The Framework permits new objects to be defined for the purpose of
experimentation and evaluation. experimentation and evaluation.
3 Objects 3 Objects
Managed objects are accessed via a virtual information store, termed the Managed objects are accessed via a virtual information store, termed the
Management Information Base or MIB. Objects in the MIB are defined using Management Information Base or MIB. Objects in the MIB are defined using
the subset of Abstract Syntax Notation One (ASN.1) [6] defined in the the subset of Abstract Syntax Notation One (ASN.1) [7] defined in the
SMI. In particular, each object has a name, a syntax, and an encoding. SMI. In particular, each object has a name, a syntax, and an encoding.
The name is an object identifier, an administratively assigned name, The name is an object identifier, an administratively assigned name,
which specifies an object type. The object type together with an object which specifies an object type. The object type together with an object
instance serves to uniquely identify a specific instantiation of the instance serves to uniquely identify a specific instantiation of the
object. For human convenience, we often use a textual string, termed object. For human convenience, we often use a textual string, termed
the OBJECT DESCRIPTOR, to also refer to the object type. the OBJECT DESCRIPTOR, to also refer to the object type.
The syntax of an object type defines the abstract data structure The syntax of an object type defines the abstract data structure
corresponding to that object type. The ASN.1 language is used for this corresponding to that object type. The ASN.1 language is used for this
purpose. However, the SMI [2] purposely restricts the ASN.1 constructs purpose. However, the SMI [3] purposely restricts the ASN.1 constructs
which may be used. These restrictions are explicitly made for which may be used. These restrictions are explicitly made for
simplicity. simplicity.
The encoding of an object type is simply how that object type is The encoding of an object type is simply how that object type is
represented using the object type's syntax. Implicitly tied to the represented using the object type's syntax. Implicitly tied to the
notion of an object type's syntax and encoding is how the object type is notion of an object type's syntax and encoding is how the object type is
represented when being transmitted on the network. represented when being transmitted on the network.
The SMI specifies the use of the basic encoding rules of ASN.1 [7], The SMI specifies the use of the basic encoding rules of ASN.1 [8],
subject to the additional requirements imposed by the SNMP. subject to the additional requirements imposed by the SNMP.
3.1 Format of Definitions 3.1 Format of Definitions
Section 4 contains the specification of all object types contained in Section 4 contains the specification of all object types contained in
this MIB module. These object types are specified using the conventions this MIB module. These object types are specified using the conventions
defined in [2] and [3]. defined in [3] and [4].
4 Overview 4 Overview
Traffic Flow Measurement seeks to provide a well-defined method for Traffic Flow Measurement seeks to provide a well-defined method for
gathering traffic flow information from networks and internetworks. The gathering traffic flow information from networks and internetworks. The
background for this is given in "Traffic Flow Measurement: Background" background for this is given in "Traffic Flow Measurement: Background"
[8]. The Realtime Traffic Flow Measurement (rtfm) Working Group has [9]. The Realtime Traffic Flow Measurement (rtfm) Working Group has
produced a measurement architecture to achieve this goal; this is produced a measurement architecture to achieve this goal; this is
documented in "Traffic Flow Measurement: Architecture" [9]. The documented in "Traffic Flow Measurement: Architecture" [1]. The
architecture defines three entities: architecture defines three entities:
- METERS, which observe network traffic flows and build up a table of - METERS, which observe network traffic flows and build up a table of
flow data records for them, flow data records for them,
- METER READERS, which collect traffic flow data from meters, and - METER READERS, which collect traffic flow data from meters, and
- MANAGERS, which oversee the operation of meters and meter readers. - MANAGERS, which oversee the operation of meters and meter readers.
This memo defines the SNMP management information for a Traffic Flow This memo defines the SNMP management information for a Traffic Flow
Meter (TFM). Work in this field was begun by the Internet Accounting Meter (TFM). Work in this field was begun by the Internet Accounting
Working Group. It has been further developed and expanded by the Working Group. It has been further developed and expanded by the
Realtime Traffic Flow Measurement Working Group. Realtime Traffic Flow Measurement Working Group.
4.1 Scope of Definitions, Textual Conventions 4.1 Scope of Definitions, Textual Conventions
All objects defined in this memo are registered in a single subtree All objects defined in this memo are registered in a single subtree
within the mib-2 namespace [1,2], and are for use in network devices within the mib-2 namespace [2,3], and are for use in network devices
which may perform a PDU forwarding or monitoring function. For these which may perform a PDU forwarding or monitoring function. For these
devices, the value of the ifSpecific variable in the MIB-II [1] has the devices, the value of the ifSpecific variable in the MIB-II [2] has the
OBJECT IDENTIFIER value: OBJECT IDENTIFIER value:
flowMIB OBJECT IDENTIFIER ::= mib-2 40 flowMIB OBJECT IDENTIFIER ::= mib-2 40
as defined below. as defined below.
The RTFM Meter MIB was first produced and tested using SNMPv1. It was The RTFM Meter MIB was first produced and tested using SNMPv1. It was
converted into SNMPv2 following the guidelines in RFC 1908 [5]. converted into SNMPv2 following the guidelines in RFC 1908 [6].
4.2 Usage of the MIB variables 4.2 Usage of the MIB variables
The MIB is organised in four parts - control, data, rules and The MIB is organised in four parts - control, data, rules and
conformance statements. conformance statements.
The rules implement the set of packet-matching actions, as described in The rules implement the set of packet-matching actions, as described in
the "Traffic Flow Measurment: Architecture" document [9]. In addition the "Traffic Flow Measurment: Architecture" document [1]. In addition
they provide for BASIC-style subroutines, allowing a network manager to they provide for BASIC-style subroutines, allowing a network manager to
dramatically reduce the number of rules required to monitor a large dramatically reduce the number of rules required to monitor a large
network. network.
Traffic flows are identified by a set of attributes for each of their Traffic flows are identified by a set of attributes for each of their
end-points. Attributes include network addresses for each layer of the end-points. Attributes include network addresses for each layer of the
network protocol stack, and 'subscriber ids,' which may be used to network protocol stack, and 'subscriber ids,' which may be used to
identify an accountable entity for the flow. identify an accountable entity for the flow.
The conformance statements are set out as defined in [4]. They explain The conformance statements are set out as defined in [5]. They explain
what must be implemented in a meter which claims to conform to this MIB. 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 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 table. This would certainly work, but would require a lot of protocol
exchanges. To reduce the overhead in retrieving flow data the flow exchanges. To reduce the overhead in retrieving flow data the flow
table uses a TimeFilter variable, defined as a Textual Convention in the table uses a TimeFilter variable, defined as a Textual Convention in the
RMON2 MIB [10]. RMON2 MIB [10].
As an alternative method of reading flow data, the MIB provides a view As an alternative method of reading flow data, the MIB provides a view
of the flow table called the flowDataPackageTable. This is (logically) of the flow table called the flowDataPackageTable. This is (logically)
a four-dimensional array, subscripted by package selector, ruleset, a four-dimensional array, subscripted by package selector, ruleset,
activity time and starting flow number. The package selector is a activity time and starting flow number. The package selector is a
sequence of bytes which specifies a list of flow attributes. sequence of bytes which specifies a list of flow attributes.
A data package (as returned by the meter) is a sequence of values for A data package (as returned by the meter) is a sequence of values for
the attributes specified in its selector, encoded using the Basic the attributes specified in its selector, encoded using the Basic
Encoding Rules [7]. It allows a meter reader to retrieve all the Encoding Rules [8]. It allows a meter reader to retrieve all the
attribute values it requires in a single MIB object. This, when used attribute values it requires in a single MIB object. This, when used
together with SNMPv2's GetBulk request, allows a meter reader to scan 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 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 which have changed since the last reading, and which were created by a
specified rule set. specified rule set.
One aspect of data collection which needs emphasis is that all the MIB 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 variables are set up to allow multiple independent meter readers to work
properly, i.e. the flow table indexes are stateless. An alternative properly, i.e. the flow table indexes are stateless. An alternative
approach would have been to 'snapshot' the flow table, which would mean approach would have been to 'snapshot' the flow table, which would mean
that the meter readers would have to be synchronized. The stateless that the meter readers would have to be synchronized. The stateless
approach does mean that two meter readers will never return exactly the 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 same set of traffic counts, but over long periods (e.g. 15-minute
collections over a day) the discrepancies are acceptable. If one really collections over a day) the discrepancies are acceptable. If one really
needs a snapshot, this can be achieved by switching to an identical rule needs a snapshot, this can be achieved by switching to an identical rule
set with a different RuleSet number, hence asynchronous collections may set with a different RuleSet number, hence asynchronous collections may
be regarded as a useful generalisation of synchronised ones. be regarded as a useful generalisation of synchronised ones.
The control variables are the minimum set required for a meter reader. The control variables are the minimum set required for a meter reader.
skipping to change at page 7, line 27 skipping to change at page 7, line 35
OBJECT-GROUP, MODULE-COMPLIANCE OBJECT-GROUP, MODULE-COMPLIANCE
FROM SNMPv2-CONF FROM SNMPv2-CONF
mib-2, ifIndex mib-2, ifIndex
FROM RFC1213-MIB FROM RFC1213-MIB
OwnerString OwnerString
FROM RMON-MIB FROM RMON-MIB
TimeFilter TimeFilter
FROM RMON2-MIB; FROM RMON2-MIB;
flowMIB MODULE-IDENTITY flowMIB MODULE-IDENTITY
LAST-UPDATED "9712230937Z" LAST-UPDATED "9904061529Z"
ORGANIZATION "IETF Realtime Traffic Flow Measurement Working Group" ORGANIZATION "IETF Realtime Traffic Flow Measurement Working Group"
CONTACT-INFO CONTACT-INFO
"Nevil Brownlee, The University of Auckland "Nevil Brownlee, The University of Auckland
Postal: Information Technology Sytems & Services Postal: Information Technology Sytems & Services
The University of Auckland The University of Auckland
Private Bag 92-019 Private Bag 92-019
Auckland, New Zealand Auckland, New Zealand
Phone: +64 9 373 7599 x8941 Phone: +64 9 373 7599 x8941
skipping to change at page 8, line 25 skipping to change at page 8, line 37
flowMIBConformance OBJECT IDENTIFIER ::= { flowMIB 4 } flowMIBConformance OBJECT IDENTIFIER ::= { flowMIB 4 }
-- Textual Conventions -- Textual Conventions
MediumType ::= TEXTUAL-CONVENTION MediumType ::= TEXTUAL-CONVENTION
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Specifies the type of a MediumAddress (see below). The "Specifies the type of a MediumAddress (see below). The
values used for IEEE 802 media are from the 'Network values used for IEEE 802 media are from the 'Network
Management Parameters (ifType definitions)' section of the Management Parameters (ifType definitions)' section of the
Assigned Numbers RFC [11]." Assigned Numbers RFC [11]. Other medium types may also
be used, provided only that they are identified by their
assigned numbers."
SYNTAX INTEGER { SYNTAX INTEGER {
ethernet(7), ethernet(7),
tokenring(9), tokenring(9),
fddi(15) } fddi(15) }
MediumAddress ::= TEXTUAL-CONVENTION MediumAddress ::= TEXTUAL-CONVENTION
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Specifies the value of a Medium Access Control (MAC) address. "Specifies the value of a Medium Access Control (MAC) address.
Address format depends on the actual Medium, as follows: Address format depends on the actual Medium, as follows:
skipping to change at page 9, line 6 skipping to change at page 9, line 18
FddiMACLongAddress, i.e. a 6-octet MAC address FddiMACLongAddress, i.e. a 6-octet MAC address
in 'canonical' order (defined in the FDDI MIB [12]) in 'canonical' order (defined in the FDDI MIB [12])
" "
SYNTAX OCTET STRING (SIZE (6..20)) SYNTAX OCTET STRING (SIZE (6..20))
PeerType ::= TEXTUAL-CONVENTION PeerType ::= TEXTUAL-CONVENTION
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Indicates the type of a PeerAddress (see below). The values "Indicates the type of a PeerAddress (see below). The values
used are from the 'Address Family Numbers' section of the used are from the 'Address Family Numbers' section of the
Assigned Numbers RFC [11]." Assigned Numbers RFC [11]. Peer types from other address
types may also be used, provided only that they are identified
by their assigned numbers."
SYNTAX INTEGER { SYNTAX INTEGER {
ipv4(1), ipv4(1),
ipv6(2), ipv6(2),
nsap(3), nsap(3),
ipx(11), ipx(11),
appletalk(12), appletalk(12),
decnet(13) } decnet(13) }
PeerAddress ::= TEXTUAL-CONVENTION PeerAddress ::= TEXTUAL-CONVENTION
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Specifies the value of a peer address for various network "Specifies the value of a peer address for various network
protocols. Address format depends on the actual protocol, protocols. Address format depends on the actual protocol,
as indicated below: as indicated below:
IPv4: ipv4(1) IPv4: ipv4(1)
4-octet IpAddress (defined in the SNMPv2 SMI [2]) 4-octet IpAddress (defined in the SNMPv2 SMI [3])
IPv6: ipv6(2) IPv6: ipv6(2)
16-octet IpAddress (defined in the 16-octet IpAddress (defined in the
IPv6 Addressing RFC [13]) IPv6 Addressing RFC [13])
CLNS: nsap(3) CLNS: nsap(3)
NsapAddress (defined in the SNMPv2 SMI [2]) NsapAddress (defined in the SNMPv2 SMI [3])
Novell: ipx(11) Novell: ipx(11)
4-octet Network number, 4-octet Network number,
6-octet Host number (MAC address) 6-octet Host number (MAC address)
AppleTalk: appletalk(12) AppleTalk: appletalk(12)
2-octet Network number (sixteen bits), 2-octet Network number (sixteen bits),
1-octet Host number (eight bits) 1-octet Host number (eight bits)
DECnet: decnet(13) DECnet: decnet(13)
1-octet Area number (in low-order six bits), 1-octet Area number (in low-order six bits),
2-octet Host number (in low-order ten bits) 2-octet Host number (in low-order ten bits)
" "
SYNTAX OCTET STRING (SIZE (3..20)) SYNTAX OCTET STRING (SIZE (3..20))
AdjacentType ::= TEXTUAL-CONVENTION AdjacentType ::= TEXTUAL-CONVENTION
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Indicates the type of an adjacent address. "Indicates the type of an adjacent address.
skipping to change at page 12, line 48 skipping to change at page 13, line 12
v3(53), v3(53),
v4(54), v4(54),
v5(55) } v5(55) }
ActionNumber ::= TEXTUAL-CONVENTION ActionNumber ::= TEXTUAL-CONVENTION
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Uniquely identifies the action of a rule, i.e. the Pattern "Uniquely identifies the action of a rule, i.e. the Pattern
Matching Engine's opcode number. Details of the opcodes Matching Engine's opcode number. Details of the opcodes
are given in the 'Traffic Flow Measurement: Architecture' are given in the 'Traffic Flow Measurement: Architecture'
document [9]." document [1]."
SYNTAX INTEGER { SYNTAX INTEGER {
ignore(1), ignore(1),
noMatch(2), noMatch(2),
count(3), count(3),
countPkt(4), countPkt(4),
return(5), return(5),
gosub(6), gosub(6),
gosubAct(7), gosubAct(7),
assign(8), assign(8),
assignAct(9), assignAct(9),
skipping to change at page 13, line 41 skipping to change at page 14, line 6
values for all the objects in its rules. At this stage the new values for all the objects in its rules. At this stage the new
rule set is available but not 'running,' i.e. it is not being rule set is available but not 'running,' i.e. it is not being
used by the meter to produce entries in the flow table. used by the meter to produce entries in the flow table.
To actually 'run' a rule set a manager must create a row in To actually 'run' a rule set a manager must create a row in
the flowManagerInfoTable, set it's flowManagerStatus to the flowManagerInfoTable, set it's flowManagerStatus to
active(1), and set either its CurrentRuleSet or StandbyRuleSet active(1), and set either its CurrentRuleSet or StandbyRuleSet
to point to the rule set to be run. to point to the rule set to be run.
Once a rule set is running a manager may not change any of the Once a rule set is running a manager may not change any of the
objects within the rule set itself. objects within the rule set itself. Any attempt to do so should
result in a notWritable(17) SNMP error-status for such objects.
Any manager may stop a rule set running by removing all A manager may stop a rule set running by removing all
references to it in the flowManagerInfoTable (i.e. by setting references to it in the flowManagerInfoTable (i.e. by setting
CurrentRuleSet and StandbyRuleSet values to 0). This provides a CurrentRuleSet and StandbyRuleSet values to 0). This provides
way to stop rule sets left running if a manager fails." a way to stop rule sets left running if a manager fails.
For example, when a manager is started, it could search the
meter's flowManager table and stop all rule sets having a
specified value of flowRuleInfoOwner.
To prevent a manager from interfering with variables belonging
to another manager, the meter should use SNMP views 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 } ::= { flowControl 1 }
flowRuleSetInfoEntry OBJECT-TYPE flowRuleSetInfoEntry OBJECT-TYPE
SYNTAX FlowRuleSetInfoEntry SYNTAX FlowRuleSetInfoEntry
MAX-ACCESS not-accessible MAX-ACCESS not-accessible
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Information about a particular rule set." "Information about a particular rule set."
INDEX { flowRuleInfoIndex } INDEX { flowRuleInfoIndex }
::= { flowRuleSetInfoTable 1 } ::= { flowRuleSetInfoTable 1 }
skipping to change at page 15, line 14 skipping to change at page 15, line 38
flowRuleInfoStatus OBJECT-TYPE flowRuleInfoStatus OBJECT-TYPE
SYNTAX RowStatus SYNTAX RowStatus
MAX-ACCESS read-create MAX-ACCESS read-create
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The status of this flowRuleSetInfoEntry. If this value is "The status of this flowRuleSetInfoEntry. If this value is
not active(1) the meter must not attempt to use the row's not active(1) the meter must not attempt to use the row's
associated rule set. Once its value has been set to active(1) associated rule set. Once its value has been set to active(1)
a manager may not change any of the other variables in the a manager may not change any of the other variables in the
row, nor the contents of the associated rule set. row, nor the contents of the associated rule set. Any attempt
to do so should result in a notWritable(17) SNMP error-status
for such variables or objects.
To download a rule set, a manger could: To download a rule set, a manger could:
- Locate an open slot in the RuleSetInfoTable. - Locate an open slot in the RuleSetInfoTable.
- Create a RuleSetInfoEntry by setting the status for this - Create a RuleSetInfoEntry by setting the status for this
open slot to createAndWait(5). open slot to createAndWait(5).
- Set flowRuleInfoSize and flowRuleInfoName as required. - Set flowRuleInfoSize and flowRuleInfoName as required.
- Download the rules into the row's rule table. - Download the rules into the row's rule table.
- Set flowRuleInfoStatus to active(1). - Set flowRuleInfoStatus to active(1).
The rule set would then be ready to run. The manager is not The rule set would then be ready to run. The manager is not
skipping to change at page 16, line 53 skipping to change at page 17, line 29
flowInterfaceLostPackets Counter32 flowInterfaceLostPackets Counter32
} }
flowInterfaceSampleRate OBJECT-TYPE flowInterfaceSampleRate OBJECT-TYPE
SYNTAX Integer32 SYNTAX Integer32
MAX-ACCESS read-write MAX-ACCESS read-write
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The parameter N for statistical counting on this interface. "The parameter N for statistical counting on this interface.
Set to N to count 1/Nth of the packets appearing at this Set to N to count 1/Nth of the packets appearing at this
interface. A meter should choose its own algorithm to interface. A sampling rate of 1 counts all packets.
introduce variance into the sampling so that exactly every Nth A sampling rate of 0 results in the interface being ignored
packet is not counted. A sampling rate of 1 counts all by the meter.
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 not
counted. The IPPM Working Group's RFC 'Framework for IP
Performance Metrics' [16] explains why this should be done,
and sets out an algorithm for doing it."
DEFVAL { 1 } DEFVAL { 1 }
::= { flowInterfaceEntry 1 } ::= { flowInterfaceEntry 1 }
flowInterfaceLostPackets OBJECT-TYPE flowInterfaceLostPackets OBJECT-TYPE
SYNTAX Counter32 SYNTAX Counter32
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The number of packets the meter has lost for this interface. "The number of packets the meter has lost for this interface.
Such losses may occur because the meter has been unable to Such losses may occur because the meter has been unable to
skipping to change at page 22, line 12 skipping to change at page 22, line 43
flowManagerCounterWrap OBJECT-TYPE flowManagerCounterWrap OBJECT-TYPE
SYNTAX INTEGER { wrap(1), scale(2) } SYNTAX INTEGER { wrap(1), scale(2) }
MAX-ACCESS read-create MAX-ACCESS read-create
STATUS deprecated STATUS deprecated
DESCRIPTION DESCRIPTION
"Specifies whether PDU and octet counters should wrap when "Specifies whether PDU and octet counters should wrap when
they reach the top of their range (normal behaviour for they reach the top of their range (normal behaviour for
Counter64 objects), or whether their scale factors should Counter64 objects), or whether their scale factors should
be used instead. The combination of counter and scale be used instead. The combination of counter and scale
factor allows counts to be returned as binary floating factor allows counts to be returned as non-negative binary
point numbers, with 64-bit mantissas and 8-bit exponents." floating point numbers, with 64-bit mantissas and 8-bit
exponents."
DEFVAL { wrap } DEFVAL { wrap }
::= { flowManagerInfoEntry 5 } ::= { flowManagerInfoEntry 5 }
flowManagerOwner OBJECT-TYPE flowManagerOwner OBJECT-TYPE
SYNTAX OwnerString SYNTAX OwnerString
MAX-ACCESS read-create MAX-ACCESS read-create
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Identifies the manager which created this row." "Identifies the manager which created this row."
::= { flowManagerInfoEntry 6 } ::= { flowManagerInfoEntry 6 }
skipping to change at page 23, line 18 skipping to change at page 23, line 50
-- --
flowFloodMark OBJECT-TYPE flowFloodMark OBJECT-TYPE
SYNTAX Integer32 (0..100) SYNTAX Integer32 (0..100)
MAX-ACCESS read-write MAX-ACCESS read-write
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"A value expressed as a percentage, interpreted by the meter "A value expressed as a percentage, interpreted by the meter
as an indication of how full the flow table should be before as an indication of how full the flow table should be before
it should take some action to avoid running out of resources it should take some action to avoid running out of resources
to handle new flows. Values of 0% or 100% disable the to handle new flows, as discussed in section 4.6 (Handling
checking represented by this variable." Increasing Traffic Levels) of the RTFM Architecture RFC [1].
Values of 0% or 100% disable the checking represented by
this variable."
DEFVAL { 95 } -- Enabled by default. DEFVAL { 95 } -- Enabled by default.
::= { flowControl 5 } ::= { flowControl 5 }
flowInactivityTimeout OBJECT-TYPE flowInactivityTimeout OBJECT-TYPE
SYNTAX Integer32 SYNTAX Integer32
MAX-ACCESS read-write MAX-ACCESS read-write
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The time in seconds since the last packet seen, after which "The time in seconds since the last packet seen, after which
a flow becomes 'idle.' Note that although a flow may be a flow becomes 'idle.' Note that although a flow may be
skipping to change at page 23, line 41 skipping to change at page 24, line 25
until after its data has been collected by all the meter until after its data has been collected by all the meter
readers registered for its RuleSet." readers registered for its RuleSet."
DEFVAL { 600 } -- 10 minutes DEFVAL { 600 } -- 10 minutes
::= { flowControl 6 } ::= { flowControl 6 }
flowActiveFlows OBJECT-TYPE flowActiveFlows OBJECT-TYPE
SYNTAX Integer32 SYNTAX Integer32
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The numbers of flows which are currently in use." "The number of flows which are currently in use."
::= { flowControl 7 } ::= { flowControl 7 }
flowMaxFlows OBJECT-TYPE flowMaxFlows OBJECT-TYPE
SYNTAX Integer32 SYNTAX Integer32
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The maximum number of flows allowed in the meter's "The maximum number of flows allowed in the meter's
flow table. At present this is determined when the meter flow table. At present this is determined when the meter
is first started up." is first started up."
::= { flowControl 8 } ::= { flowControl 8 }
flowFloodMode OBJECT-TYPE flowFloodMode OBJECT-TYPE
SYNTAX TruthValue SYNTAX TruthValue
MAX-ACCESS read-write MAX-ACCESS read-write
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Indicates that the meter has passed its FloodMark and is "Indicates that the meter has passed its FloodMark and is
not running in its normal mode. When a manager notices this not running in its normal mode.
it should take action to remedy the problem which caused the
flooding. Once the flood has receded, the manager may set When the manager notices this it should take action to remedy
this variable to false(2) to resume normal operaation." the problem which caused the flooding. It should them 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 } ::= { flowControl 9 }
-- --
-- The Flow Table -- The Flow Table
-- --
-- This is a table kept by a meter, with one flow data entry for every -- 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 -- flow being measured. Each flow data entry stores the attribute
-- values for a traffic flow. Details of flows and their attributes -- values for a traffic flow. Details of flows and their attributes
-- are given in the 'Traffic Flow Measurement: Architecture' -- are given in the 'Traffic Flow Measurement: Architecture'
-- document [1].
-- From time to time a meter reader may sweep the flow table so as -- 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 -- to read counts. This is most effectively achieved by using the
-- TimeMark variable together with successive GetBulk requests to -- TimeMark variable together with successive GetBulk requests to
-- retrieve the values of the desired flow attribute variables. -- retrieve the values of the desired flow attribute variables.
-- This scheme allows multiple meter readers to independently use the -- This scheme allows multiple meter readers to independently use the
-- same meter; the meter readers do not have to be synchronised and -- same meter; the meter readers do not have to be synchronised and
-- they may use different collection intervals. -- they may use different collection intervals.
-- If identical sets of counts are requires 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 [1].
flowDataTable OBJECT-TYPE flowDataTable OBJECT-TYPE
SYNTAX SEQUENCE OF FlowDataEntry SYNTAX SEQUENCE OF FlowDataEntry
MAX-ACCESS not-accessible MAX-ACCESS not-accessible
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The list of all flows being measured." "The list of all flows being measured."
::= { flowData 1 } ::= { flowData 1 }
flowDataEntry OBJECT-TYPE flowDataEntry OBJECT-TYPE
SYNTAX FlowDataEntry SYNTAX FlowDataEntry
skipping to change at page 30, line 4 skipping to change at page 30, line 47
flowDataDestTransMask OBJECT-TYPE flowDataDestTransMask OBJECT-TYPE
SYNTAX TransportAddress SYNTAX TransportAddress
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"1-bits in this mask indicate which bits must match when "1-bits in this mask indicate which bits must match when
comparing the transport destination address for this flow." comparing the transport destination address for this flow."
::= { flowDataEntry 23 } ::= { flowDataEntry 23 }
flowDataPDUScale OBJECT-TYPE flowDataPDUScale OBJECT-TYPE
SYNTAX Integer32 (1..255) SYNTAX Integer32 (0..255)
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The scale factor applied to this particular flow. Indicates "The scale factor applied to this particular flow. Indicates
the number of bits the PDU counter values should be moved left the number of bits the PDU counter values should be moved left
to obtain the actual values." to obtain the actual values."
::= { flowDataEntry 24 } ::= { flowDataEntry 24 }
flowDataOctetScale OBJECT-TYPE flowDataOctetScale OBJECT-TYPE
SYNTAX Integer32 (1..255) SYNTAX Integer32 (0..255)
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The scale factor applied to this particular flow. Indicates "The scale factor applied to this particular flow. Indicates
the number of bits the octet counter values should be moved the number of bits the octet counter values should be moved
left to obtain the actual values." left to obtain the actual values."
::= { flowDataEntry 25 } ::= { flowDataEntry 25 }
flowDataRuleSet OBJECT-TYPE flowDataRuleSet OBJECT-TYPE
SYNTAX Integer32 (1..255) SYNTAX Integer32 (1..255)
skipping to change at page 30, line 38 skipping to change at page 31, line 30
"The RuleSet number of the rule set which created this flow. "The RuleSet number of the rule set which created this flow.
Allows a manager to use GetNext or GetBulk requests to find Allows a manager to use GetNext or GetBulk requests to find
flows belonging to a particular RuleSet." flows belonging to a particular RuleSet."
::= { flowDataEntry 26 } ::= { flowDataEntry 26 }
flowDataToOctets OBJECT-TYPE flowDataToOctets OBJECT-TYPE
SYNTAX Counter64 SYNTAX Counter64
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The count of octets flowing from source to dest address and "The count of octets flowing from source to destination
being delivered to the protocol level being metered. In the for this flow."
case of IP this would count the number of octets delivered to
the IP level."
::= { flowDataEntry 27 } ::= { flowDataEntry 27 }
flowDataToPDUs OBJECT-TYPE flowDataToPDUs OBJECT-TYPE
SYNTAX Counter64 SYNTAX Counter64
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The count of protocol packets flowing from source to dest "The count of packets flowing from source to destination
address and being delivered to the protocol level being for this flow."
metered. In the case of IP, for example, this would count the
IP packets delivered to the IP protocol level."
::= { flowDataEntry 28 } ::= { flowDataEntry 28 }
flowDataFromOctets OBJECT-TYPE flowDataFromOctets OBJECT-TYPE
SYNTAX Counter64 SYNTAX Counter64
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The count of octets flowing from dest to source address and "The count of octets flowing from destination to source
being delivered to the protocol level being metered." for this flow."
::= { flowDataEntry 29 } ::= { flowDataEntry 29 }
flowDataFromPDUs OBJECT-TYPE flowDataFromPDUs OBJECT-TYPE
SYNTAX Counter64 SYNTAX Counter64
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The count of protocol packets flowing from dest to source "The count of packets flowing from destination to source
address and being delivered to the protocol level being for this flow."
metered. In the case of IP, for example, this would count
the IP packets delivered to the IP protocol level."
::= { flowDataEntry 30 } ::= { flowDataEntry 30 }
flowDataFirstTime OBJECT-TYPE flowDataFirstTime OBJECT-TYPE
SYNTAX TimeStamp SYNTAX TimeStamp
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The time at which this flow was first entered in the table" "The time at which this flow was first entered in the table"
::= { flowDataEntry 31 } ::= { flowDataEntry 31 }
skipping to change at page 31, line 48 skipping to change at page 32, line 33
"The last time this flow had activity, i.e. the time of "The last time this flow had activity, i.e. the time of
arrival of the most recent PDU belonging to this flow." arrival of the most recent PDU belonging to this flow."
::= { flowDataEntry 32 } ::= { flowDataEntry 32 }
flowDataSourceSubscriberID OBJECT-TYPE flowDataSourceSubscriberID OBJECT-TYPE
SYNTAX OCTET STRING (SIZE (4..20)) SYNTAX OCTET STRING (SIZE (4..20))
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Subscriber ID associated with the source address for this "Subscriber ID associated with the source address for this
flow." flow. A Subscriber ID is an unspecified text string, used
to ascribe traffic flows to individual users. At this time
the means by which a Subscriber ID may be associated with a
flow is unspecified."
::= { flowDataEntry 33 } ::= { flowDataEntry 33 }
flowDataDestSubscriberID OBJECT-TYPE flowDataDestSubscriberID OBJECT-TYPE
SYNTAX OCTET STRING (SIZE (4..20)) SYNTAX OCTET STRING (SIZE (4..20))
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Subscriber ID associated with the dest address for this "Subscriber ID associated with the destination address for
flow." this flow. A Subscriber ID is an unspecified text string,
used to ascribe traffic flows to individual users. At this
time the means by which a Subscriber ID may be associated
with a flow is unspecified."
::= { flowDataEntry 34 } ::= { flowDataEntry 34 }
flowDataSessionID OBJECT-TYPE flowDataSessionID OBJECT-TYPE
SYNTAX OCTET STRING (SIZE (4..10)) SYNTAX OCTET STRING (SIZE (4..10))
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Session ID for this flow. Such an ID might be allocated "Session ID for this flow. Such an ID might be allocated
by a network access server to distinguish a series of sessions by a network access server to distinguish a series of sessions
between the same pair of addresses, which would otherwise between the same pair of addresses, which would otherwise
skipping to change at page 36, line 51 skipping to change at page 37, line 43
a specified flowPackageTime." a specified flowPackageTime."
::= { flowDataPackageEntry 4 } ::= { flowDataPackageEntry 4 }
flowPackageData OBJECT-TYPE flowPackageData OBJECT-TYPE
SYNTAX OCTET STRING SYNTAX OCTET STRING
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"A collection of attribute values for a single flow, as "A collection of attribute values for a single flow, as
specified by this row's indexes. The attribute values are specified by this row's indexes. The attribute values are
contained within a BER-encoded sequence [7], in the order contained within a BER-encoded sequence [8], in the order
they appear in their flowPackageSelector. they appear in their flowPackageSelector.
For example, to retrieve a flowPackage containing values for For example, to retrieve a flowPackage containing values for
attributes 11, 18 and 29, for a flow in rule set 7, with flow attributes 11, 18 and 29, for a flow in rule set 7, with flow
index 3447, one would GET the package whose Object Identifier index 3447, one would GET the package whose Object Identifier
(OID) is (OID) is
flowPackageData . 3.11.18.29 . 7. 0 . 3447 flowPackageData . 3.11.18.29 . 7. 0 . 3447
To get a package for the next such flow which had been To get a package for the next such flow which had been
active since time 12345 one would GETNEXT the package whose active since time 12345 one would GETNEXT the package whose
skipping to change at page 37, line 26 skipping to change at page 38, line 18
-- The Rule Table -- The Rule Table
-- --
-- This is an array of rule sets; the 'running' ones are indicated -- This is an array of rule sets; the 'running' ones are indicated
-- by the entries in the meter's flowManagerInfoTable. Several rule -- by the entries in the meter's flowManagerInfoTable. Several rule
-- sets can be held in a meter so that the manager can change the -- sets can be held in a meter so that the manager can change the
-- running rule sets easily, for example with time of day. Note that -- running rule sets easily, for example with time of day. Note that
-- a manager may not change the rules in any rule set currently -- a manager may not change the rules in any rule set currently
-- referenced within the flowManagerInfoTable (either as 'current' or -- referenced within the flowManagerInfoTable (either as 'current' or
-- 'standby')! See the 'Traffic Flow Measurement: Architecture' -- 'standby')! See the 'Traffic Flow Measurement: Architecture'
-- document [1] for details of rules and how they are used.
-- Space for a rule set is allocated by setting the value of
-- flowRuleInfoSize in the rule table's flowRuleSetInfoTable row. -- flowRuleInfoSize in the rule table's flowRuleSetInfoTable row.
-- Values for each row in the rule set (Selector, Mask, MatchedValue,
-- Action and Parameter) can then be set by the meter.
-- Although an individual rule within a rule set could be modified,
-- it is much safer to simply download a complete new rule set.
flowRuleTable OBJECT-TYPE flowRuleTable OBJECT-TYPE
SYNTAX SEQUENCE OF FlowRuleEntry SYNTAX SEQUENCE OF FlowRuleEntry
MAX-ACCESS not-accessible MAX-ACCESS not-accessible
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Contains all the rule sets which may be used by the meter." "Contains all the rule sets which may be used by the meter."
::= { flowRules 1 } ::= { flowRules 1 }
flowRuleEntry OBJECT-TYPE flowRuleEntry OBJECT-TYPE
skipping to change at page 38, line 39 skipping to change at page 39, line 37
DESCRIPTION DESCRIPTION
"Indicates the attribute to be matched. "Indicates the attribute to be matched.
null(0) is a special case; null rules always succeed. null(0) is a special case; null rules always succeed.
matchingStoD(50) is set by the meter's Packet Matching Engine. matchingStoD(50) is set by the meter's Packet Matching Engine.
Its value is true(1) if the PME is attempting to match the Its value is true(1) if the PME is attempting to match the
packet with its addresses in Source-to-Destination order (i.e. packet with its addresses in Source-to-Destination order (i.e.
as they appear in the packet), and false(2) otherwise. as they appear in the packet), and false(2) otherwise.
Details of how packets are matched are given in the 'Traffic Details of how packets are matched are given in the 'Traffic
Flow Measurement: Architecture' document [9]. Flow Measurement: Architecture' document [1].
v1(51), v2(52), v3(53), v4(54) and v5(55) select meter v1(51), v2(52), v3(53), v4(54) and v5(55) select meter
variables, each of which can hold the name (i.e. selector variables, each of which can hold the name (i.e. selector
value) of an address attribute. When one of these is used value) of an address attribute. When one of these is used
as a selector, its value specifies the attribute to be as a selector, its value specifies the attribute to be
tested. Variable values are set by an Assign action." tested. Variable values are set by an Assign action."
::= { flowRuleEntry 3 } ::= { flowRuleEntry 3 }
flowRuleMask OBJECT-TYPE flowRuleMask OBJECT-TYPE
SYNTAX RuleAddress SYNTAX RuleAddress
skipping to change at page 39, line 28 skipping to change at page 40, line 25
::= { flowRuleEntry 5 } ::= { flowRuleEntry 5 }
flowRuleAction OBJECT-TYPE flowRuleAction OBJECT-TYPE
SYNTAX ActionNumber SYNTAX ActionNumber
MAX-ACCESS read-write MAX-ACCESS read-write
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The action to be taken if this rule's test succeeds, or if "The action to be taken if this rule's test succeeds, or if
the meter's 'test' flag is off. Actions are opcodes for the the meter's 'test' flag is off. Actions are opcodes for the
meter's Packet Matching Engine; details are given in the meter's Packet Matching Engine; details are given in the
'Traffic Flow Measurement: Architecture' document [9]." 'Traffic Flow Measurement: Architecture' document [1]."
::= { flowRuleEntry 6 } ::= { flowRuleEntry 6 }
flowRuleParameter OBJECT-TYPE flowRuleParameter OBJECT-TYPE
SYNTAX Integer32 (1..65535) SYNTAX Integer32 (1..65535)
MAX-ACCESS read-write MAX-ACCESS read-write
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"A parameter value providing extra information for the "A parameter value providing extra information for the
rule's action." rule's action."
::= { flowRuleEntry 7 } ::= { flowRuleEntry 7 }
skipping to change at page 45, line 10 skipping to change at page 46, line 10
This MIB describes how an RTFM traffic meter is controlled, and provides This MIB describes how an RTFM traffic meter is controlled, and provides
a way for traffic flow data to be retrieved from it by a meter reader. a way for traffic flow data to be retrieved from it by a meter reader.
This is essentially an application using SNMP as a method of This is essentially an application using SNMP as a method of
communication between co-operating hosts; it does not - in itself - have communication between co-operating hosts; it does not - in itself - have
any inherent security risks. any inherent security risks.
Since, however, the traffic flow data can be extremely valuable for Since, however, the traffic flow data can be extremely valuable for
network management purposes it is vital that sensible precautions be network management purposes it is vital that sensible precautions be
taken to keep the meter and its data secure. This requires that access taken to keep the meter and its data secure. In particular, an attacker
to the meter for control purposes (e.g. loading RuleSets and reading must not be permitted to write any of the meter's variables! This
flow data) be restricted. Such restriction could be achieved in many requires that access to the meter for control purposes (e.g. loading
ways, for example RuleSets and reading flow data) be restricted. Such restriction could
be achieved in many ways, for example:
- Physical Separation. Meter(s) and meter reader(s) could be - Physical Separation. Meter(s) and meter reader(s) could be
deployed so that control capabilities are kept within a separate deployed so that control capabilities are kept within a separate
network, access to which is carefully controlled. network, access to which is carefully controlled.
- Application-layer Security. A minimal level of security for SNMP - Application-layer Security. A minimal level of security for SNMP
is provided by using 'community' strings, which are essentially is provided by using 'community' strings, which are essentially
clear-text passwords. Stronger security for SNMP is being clear-text passwords. Stronger security for SNMP is being
developed within the IETF (see above); when this becomes available developed within the IETF (see above); when this becomes available
it should be used to protect managed network equipment. it should be used to protect managed network equipment.
skipping to change at page 46, line 10 skipping to change at page 47, line 12
the counters in a flow to wrap several times between meter the counters in a flow to wrap several times between meter
readings, thus causing the counts to be artificially low. The readings, thus causing the counts to be artificially low. The
change to using 64-bit counters in this MIB reduces this problem change to using 64-bit counters in this MIB reduces this problem
significantly. significantly.
Users can reduce the severity of both the above attacks by ensuring that Users can reduce the severity of both the above attacks by ensuring that
their meters are read often enough to prevent them being flooded. The their meters are read often enough to prevent them being flooded. The
resulting flow data will contain a record of the attacking packets, resulting flow data will contain a record of the attacking packets,
which may well be useful in determining where any attack came from. which may well be useful in determining where any attack came from.
7 Appendix A: Changes Introduced Since RFC 2064 7 IANA Considerations
The RTFM Architecture document [1], has two sets of assigned numbers:
Opcodes for the PME (Pattern Matching Engine) and RTFM Attribute
numbers. All the assigned numbers used in the Meter MIB appear in
Textual Conventions. The numbers they use are derived as follows:
The MIB's 'Type' textual conventions use names and numbers from the
Assigned Numbers RFC [11]:
MediumType Uses ifType Definitions
PeerType Uses Address Family Numbers
TransportType Uses Protocol Numbers
The MIB's 'AttributeNumber' textual conventions use RTFM Attribute names
and numbers from the RTFM Architecture document [1], or other numbers
allocated according to that document's IANA Considerations section:
FlowAttributeNumber Have values stored in a flow table row
RuleAttributeNumber May be tested in a rule
The MIB's ActionNumber textual convention uses RTFM PME Opcode names and
numbers from the RTFM Architecture document [1], or other numbers
allocated according to that document's IANA Considerations section.
8 Appendix A: Changes Introduced Since RFC 2064
The first version of the Meter MIB was published as RFC 2064 in January The first version of the Meter MIB was published as RFC 2064 in January
1997. The most significant changes since then are summarised below. 1997. The most significant changes since then are summarised below.
- TEXTUAL CONVENTIONS: Greater use is made of textual conventions to - TEXTUAL CONVENTIONS: Greater use is made of textual conventions to
describe the various types of addresses used by the meter. describe the various types of addresses used by the meter.
- PACKET MATCHING ATTRIBUTES: Computed attributes (e.g. FlowClass - PACKET MATCHING ATTRIBUTES: Computed attributes (e.g. FlowClass
and FlowKind) may now be tested. This allows one to use these and FlowKind) may now be tested. This allows one to use these
variables to store information during packet matching. variables to store information during packet matching.
skipping to change at page 47, line 5 skipping to change at page 48, line 38
- DATA PACKAGES: This is a new table, allowing a meter reader to - DATA PACKAGES: This is a new table, allowing a meter reader to
retrieve values for a list of attributes from a flow as a single retrieve values for a list of attributes from a flow as a single
object. When used with SNMP GetBulk requests it provides an object. When used with SNMP GetBulk requests it provides an
efficient way to recover flow data. efficient way to recover flow data.
Earlier versions had a 'Column Activity Table;' using this it was Earlier versions had a 'Column Activity Table;' using this it was
difficult to collect all data for a flow efficiently in a single difficult to collect all data for a flow efficiently in a single
SNMP request. SNMP request.
8 Acknowledgements 9 Acknowledgements
An early draft of this document was produced under the auspices of the An early draft of this document was produced under the auspices of the
IETF's Accounting Working Group with assistance from the SNMP Working IETF's Accounting Working Group with assistance from the SNMP Working
Group and the Security Area Advisory Group. Particular thanks are due Group and the Security Area Advisory Group. Particular thanks are due
to Jim Barnes, Sig Handelman and Stephen Stibler for their support and to Jim Barnes, Sig Handelman and Stephen Stibler for their support and
their assistance with checking early versions of the MIB. their assistance with checking early versions of the MIB.
Stephen Stibler shared the development workload of producing the MIB Stephen Stibler shared the development workload of producing the MIB
changes summarized in chpter 5 (above). changes summarized in chapter 5 (above).
9 References 10 References
[1] McCloghrie, K., and Rose, M., Editors, "Management [ 1] Brownlee, N., Mills, C. and G. Ruth, "Traffic Flow
Measurement: Architecture", RFC 2063, The University of
Auckland, GTE Laboratories, Inc, January 1997.
[ 2] McCloghrie, K. and Rose, M., Editors, "Management
Information Base for Network Management of TCP/IP-based Information Base for Network Management of TCP/IP-based
internets," RFC 1213, Performance Systems International, internets," RFC 1213, Performance Systems International,
March 1991. March 1991.
[2] Case J., McCloghrie K., Rose M., and Waldbusser S., [ 3] Case J., McCloghrie K., Rose M. and Waldbusser S.,
"Structure of Management Information for version 2 of the "Structure of Management Information for version 2 of the
Simple Network Managemenet Protocol," RFC 1902, SNMP Simple Network Managemenet Protocol," RFC 1902,
Research Inc., Hughes LAN Systems, Dover Beach Consulting, SNMP Research Inc., Hughes LAN Systems, Dover Beach
Carnegie Mellon University, January 1996. Consulting, Carnegie Mellon University, January 1996.
[3] Case J., McCloghrie, K., Rose, M., and Waldbusser, S., [ 4] Case J., McCloghrie, K., Rose, M. and Waldbusser, S.,
"Textual Conventions for version 2 of the Simple Network "Textual Conventions for version 2 of the Simple Network
Managemenet Protocol SNMPv2", RFC 1903, SNMP Research Inc., Managemenet Protocol SNMPv2", RFC 1903, SNMP Research Inc.,
Hughes LAN Systems, Dover Beach Consulting, Carnegie Mellon Hughes LAN Systems, Dover Beach Consulting, Carnegie Mellon
University, January 1996. University, January 1996.
[4] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., [ 5] Case, J., McCloghrie, K., Rose, M. and Waldbusser, S.,
"Conformance Statements for version 2 of the Simple Network "Conformance Statements for version 2 of the Simple Network
Managemenet Protocol (SNMPv2)," RFC 1904, SNMP Research Inc., Managemenet Protocol (SNMPv2)," RFC 1904, SNMP Research Inc.,
Hughes LAN Systems, Dover Beach Consulting, Carnegie Mellon Hughes LAN Systems, Dover Beach Consulting, Carnegie Mellon
University, January 1996. University, January 1996.
[5] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., [ 6] Case, J., McCloghrie, K., Rose, M. and Waldbusser, S.,
"Coexistence between version 1 and version 2 of the "Coexistence between version 1 and version 2 of the
Internet-standard Network Management Framework," RFC 1908, SNMP Internet-standard Network Management Framework," RFC 1908,
Research Inc., Hughes LAN Systems, Dover Beach Consulting, SNMP Research Inc., Hughes LAN Systems, Dover Beach
Carnegie Mellon University, January 1996. Consulting, Carnegie Mellon University, January 1996.
[6] Information processing systems - Open Systems [ 7] Information processing systems - Open Systems
Interconnection - Specification of Abstract Syntax Notation One Interconnection - Specification of Abstract Syntax Notation
(ASN.1), International Organization for Standardization, One (ASN.1), International Organization for Standardization,
International Standard 8824, December 1987. International Standard 8824, December 1987.
[7] Information processing systems - Open Systems [ 8] Information processing systems - Open Systems
Interconnection - Specification of Basic Encoding Rules for Interconnection - Specification of Basic Encoding Rules for
Abstract Notation One (ASN.1), International Organization for Abstract Notation One (ASN.1), International Organization for
Standardization, International Standard 8825, December 1987. Standardization, International Standard 8825, December 1987.
[8] Mills, C., Hirsch, G. and Ruth, G., "Internet Accounting [ 9] Mills, C., Hirsch, G. and Ruth, G., "Internet Accounting
Background," RFC 1272, Bolt Beranek and Newman Inc., Meridian Background," RFC 1272, Bolt Beranek and Newman Inc., Meridian
Technology Corporation, November 1991. Technology Corporation, November 1991.
[9] Brownlee, N., Mills, C., and G. Ruth, "Traffic Flow
Measurement: Architecture", RFC 2063, The University of
Auckland, Bolt Beranek and Newman Inc., GTE Laboratories, Inc,
January 1997.
[10] Waldbusser, S., "Remote Network Monitoring Management [10] Waldbusser, S., "Remote Network Monitoring Management
Information Base Version 2 using SMIv2," RFC 2021, INS, Information Base Version 2 using SMIv2," RFC 2021, INS,
January 1997. January 1997.
[11] Reynolds, J., Postel, J., "Assigned Numbers," RFC 1700, [11] Reynolds, J., Postel, J., "Assigned Numbers," RFC 1700,
ISI, October 1994. ISI, October 1994.
[12] Case, J., "FDDI Management Information Base," RFC 1285, [12] Case, J., "FDDI Management Information Base," RFC 1285,
SNMP Research Incorporated, January 1992. SNMP Research Incorporated, January 1992.
[13] Hinden, R., Deering, S., "IP Version 6 Addressing [13] Hinden, R.and Deering, S., "IP Version 6 Addressing
Architecture," RFC 1884, Ipsilon Networks, Xerox PARC, Architecture," RFC 2373, Nokia, XCisco Systems, July 1998.
December 1995.
[14] Blumenthal, U., and B. Wijnen, "User-based Security Model [14] Blumenthal, U, and B. Wijnen, "User-based Security Model
(USM) for version 3 of the Simple Network Management (USM) for version 3 of the Simple Network Management
Protocol (SNMPv3)", RFC 2274, January 1998. Protocol (SNMPv3)", RFC 2274, January 1998.
[15] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based [15] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based
Access Control Model for the Simple Network Management Access Control Model for the Simple Network Management
Protocol (SNMP)", RFC 2275, January 1998. Protocol (SNMP)", RFC 2275, January 1998.
10 Author's Address [16] Paxson, V., Almes, G., Mahdavi, J. and Mathis, M.,
"Framework for IP Performance Metrics," RFC 2330, May 1998.
11 Author's Address
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
Expires October 1999
 End of changes. 83 change blocks. 
127 lines changed or deleted 202 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/