draft-ietf-rtfm-meter-mib-11.txt   rfc2720.txt 
Internet Engineering Task Force Nevil Brownlee
INTERNET-DRAFT The University of Auckland
September 1999 Network Working Group N. Brownlee
Expires March 2000 Request for Comments: 2720 The University of Auckland
Obsoletes: 2064 October 1999
Category: Standards Track
Traffic Flow Measurement: Meter MIB Traffic Flow Measurement: Meter MIB
<draft-ietf-rtfm-meter-mib-11.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with all This document specifies an Internet standards track protocol for the
provisions of Section 10 of RFC 2026. Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Internet-Drafts are working documents of the Internet Engineering Task Official Protocol Standards" (STD 1) for the standardization state
Force (IETF), its areas, and its working groups. Note that other groups and status of this protocol. Distribution of this memo is unlimited.
may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."
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 Copyright Notice
http://www.ietf.org/shadow.html.
This Internet Draft is a product of the Realtime Traffic Flow Copyright (C) The Internet Society (1999). All Rights Reserved.
Measurement Working Group of the IETF.
Abstract Abstract
The RTFM Traffic Measurement Architecture provides a general framework The RTFM Traffic Measurement Architecture provides a general
for describing and measuring network traffic flows. Flows are defined framework for describing and measuring network traffic flows. Flows
in terms of their Address Attribute values and measured by a 'Traffic are defined in terms of their Address Attribute values and measured
Meter.' 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.
Contents
1 Introduction 2
2 The SNMP Management Framework 2
3 Overview 3
3.1 Scope of Definitions, Textual Conventions . . . . . . . . . . 3
3.2 Usage of the MIB variables . . . . . . . . . . . . . . . . . 4
4 Definitions 6
5 Security Considerations 44
5.1 SNMP Concerns . . . . . . .. . . . . . . . . . . . . . . . . 44
5.2 Traffic Meter Concerns . .. . . . . . . . . . . . . . . . . 45
6 IANA Considerations 46
7 Appendix A: Changes Introduced Since RFC 2064 47
8 Acknowledgements 47 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.
9 References 48 Table of Contents
10 Author's Address 50 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 RFC 2064 . . . . . . . . . 49
8 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 50
9 Intellectual Property Notice . . . . . . . . . . . . . . . . . 50
10 References . . . . . . . . . . . . . . . . . . . . . . . . . . 50
11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 53
12 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 54
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)
use with network management protocols in the Internet community. In for use with network management protocols in the Internet community.
particular, it describes objects for managing and collecting data from In particular, it describes objects for managing and collecting data
network Realtime Traffic Flow Meters, as described in [RTFM-ARC]. from network Realtime Traffic Flow Meters, as described in [RTFM-
ARC].
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
group is actively pursuing the development of the meter in this way. Working group is actively pursuing the development of the meter in
this way.
2 The SNMP Management Framework 2 The SNMP Management Framework
The SNMP Management Framework presently consists of five major The SNMP Management Framework presently consists of five major
components: components:
- An overall architecture, described in RFC 2571 [RFC2571]. - An overall architecture, described in RFC 2571 [RFC2571].
- Mechanisms for describing and naming objects and events for the - Mechanisms for describing and naming objects and events for the
purpose of management. The first version of this Structure of purpose of management. The first version of this Structure of
Management Information (SMI) is called SMIv1 and described in STD Management Information (SMI) is called SMIv1 and described in STD
16, RFC 1155 [RFC1155], STD 16, RFC 1212 [RFC1212] and RFC 1215 16, RFC 1155 [RFC1155], STD 16, RFC 1212 [RFC1212] and RFC 1215
[RFC1215]. The second version, called SMIv2, is described in STD [RFC1215]. The second version, called SMIv2, is described in STD
58, RFC 2578 [RFC2578], RFC 2579 [RFC2579] and RFC 2580 [RFC2580]. 58, RFC 2578 [RFC2578], RFC 2579 [RFC2579] and RFC 2580 [RFC2580].
- Message protocols for transferring management information. The - Message protocols for transferring management information. The
first version of the SNMP message protocol is called SNMPv1 and first version of the SNMP message protocol is called SNMPv1 and
described in STD 15, RFC 1157 [RFC1157]. A second version of the described in STD 15, RFC 1157 [RFC1157]. A second version of the
SNMP message protocol, which is not an Internet standards track SNMP message protocol, which is not an Internet standards track
protocol, is called SNMPv2c and described in RFC 1901 [RFC1901] and protocol, is called SNMPv2c and described in RFC 1901 [RFC1901] and
RFC 1906 [RFC1906]. The third version of the message protocol is RFC 1906 [RFC1906]. The third version of the message protocol is
called SNMPv3 and described in RFC 1906 [RFC1906], RFC 2572 called SNMPv3 and described in RFC 1906 [RFC1906], RFC 2572
[RFC2572] and RFC 2574 [RFC2574]. [RFC2572] and RFC 2574 [RFC2574].
- Protocol operations for accessing management information. The - Protocol operations for accessing management information. The
first set of protocol operations and associated PDU formats is first set of protocol operations and associated PDU formats is
described in STD 15, RFC 1157 [RFC1157]. A second set of protocol described in STD 15, RFC 1157 [RFC1157]. A second set of protocol
operations and associated PDU formats is described in RFC 1905 operations and associated PDU formats is described in RFC 1905
[RFC1905]. [RFC1905].
- A set of fundamental applications described in RFC 2573 [RFC2573] - A set of fundamental applications described in RFC 2573 [RFC2573]
and the view-based access control mechanism described in RFC 2575 and the view-based access control mechanism described in RFC 2575
[RFC2575]. [RFC2575].
A more detailed introduction to the current SNMP Management Framework A more detailed introduction to the current SNMP Management Framework
can be found in [RFC2570]. can be found in [RFC2570].
Managed objects are accessed via a virtual information store, termed the Managed objects are accessed via a virtual information store, termed
Management Information Base or MIB. Objects in the MIB are defined using the Management Information Base or MIB. Objects in the MIB are
the mechanisms defined in the SMI. defined using the mechanisms defined in the SMI.
This memo specifies a MIB module that is compliant to the SMIv2. A MIB This memo specifies a MIB module that is compliant to the SMIv2. A
conforming to the SMIv1 can be produced through the appropriate MIB conforming to the SMIv1 can be produced through the appropriate
translations. The resulting translated MIB must be semantically translations. The resulting translated MIB must be semantically
equivalent, except where objects or events are omitted because no equivalent, except where objects or events are omitted because no
translation is possible (use of Counter64). Some machine readable translation is possible (use of Counter64). Some machine readable
information in SMIv2 will be converted into textual descriptions in information in SMIv2 will be converted into textual descriptions in
SMIv1 during the translation process. However, this loss of machine SMIv1 during the translation process. However, this loss of machine
readable information is not considered to change the semantics of the readable information is not considered to change the semantics of the
MIB. MIB.
3 Overview 3 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.
background for this is given in "Internet Accounting Background" The background for this is given in "Internet Accounting Background"
[ACT-BKG]. The Realtime Traffic Flow Measurement (rtfm) Working Group [ACT-BKG]. The Realtime Traffic Flow Measurement (rtfm) Working Group
has produced a measurement architecture to achieve this goal; this is has produced a measurement architecture to achieve this goal; this is
documented in "Traffic Flow Measurement: Architecture" [RTFM-ARC]. The documented in "Traffic Flow Measurement: Architecture" [RTFM-ARC].
architecture defines three entities: The 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.
3.1 Scope of Definitions, Textual Conventions 3.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 [MIB-II, RFC2578], and are for use in network within the mib-2 namespace [MIB-II, RFC2578], and are for use in
devices which may perform a PDU forwarding or monitoring function. For network devices which may perform a PDU forwarding or monitoring
these devices, this MIB defines a group of objects with an SMI Network function. For these devices, this MIB defines a group of objects
Management MGMT Code [ASG-NBR] of 40, i.e. with an SMI Network Management MGMT Code [ASG-NBR] of 40, i.e.
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
converted into SNMPv2 following the guidelines in [RFC1908]. was converted into SNMPv2 following the guidelines in [RFC1908].
3.2 Usage of the MIB variables 3.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
the "Traffic Flow Measurment: Architecture" document [RTFM-ARC]. In in the "Traffic Flow Measurment: Architecture" document [RTFM-ARC].
addition they provide for BASIC-style subroutines, allowing a network In addition they provide for BASIC-style subroutines, allowing a
manager to dramatically reduce the number of rules required to monitor a network manager to dramatically reduce the number of rules required
large network. to monitor a large 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
network protocol stack, and 'subscriber ids,' which may be used to the network protocol stack, and 'subscriber ids', which may be used
identify an accountable entity for the flow. to identify an accountable entity for the flow.
The conformance statements are set out as defined in [RFC2580]. They The conformance statements are set out as defined in [RFC2580]. They
explain what must be implemented in a meter which claims to conform to explain what must be implemented in a meter which claims to conform
this MIB. 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
exchanges. To reduce the overhead in retrieving flow data the flow protocol exchanges. To reduce the overhead in retrieving flow data
table uses a TimeFilter variable, defined as a Textual Convention in the the flow table uses a TimeFilter variable, defined as a Textual
RMON2 MIB [RMON2-MIB]. Convention in the RMON2 MIB [RMON2-MIB].
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
of the flow table called the flowDataPackageTable. This is (logically) view of the flow table called the flowDataPackageTable. This is
a four-dimensional array, subscripted by package selector, RuleSet, (logically) a four-dimensional array, subscripted by package
activity time and starting flow number. The package selector is a selector, RuleSet, activity time and starting flow number. The
sequence of bytes which specifies a list of flow attributes. 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 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 [ASN-BER]. It allows a meter reader to retrieve all the Encoding Rules [ASN-BER]. It allows a meter reader to retrieve all
attribute values it requires in a single MIB object. This, when used the attribute values it requires in a single MIB object. This, when
together with SNMPv2's GetBulk request, allows a meter reader to scan used together with SNMPv2's GetBulk request, allows a meter reader to
the flow table and upload a specified set of attribute values for flows scan the flow table and upload a specified set of attribute values
which have changed since the last reading, and which were created by a for flows which have changed since the last reading, and which were
specified rule set. created by a 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
variables are set up to allow multiple independent meter readers to work MIB variables are set up to allow multiple independent meter readers
properly, i.e. the flow table indexes are stateless. An alternative to work properly, i.e. the flow table indexes are stateless. An
approach would have been to 'snapshot' the flow table, which would mean alternative approach would have been to 'snapshot' the flow table,
that the meter readers would have to be synchronized. The stateless which would mean that the meter readers would have to be
approach does mean that two meter readers will never return exactly the synchronized. The stateless approach does mean that two meter
same set of traffic counts, but over long periods (e.g. 15-minute readers will never return exactly the same set of traffic counts, but
collections over a day) the discrepancies are acceptable. If one really over long periods (e.g. 15-minute collections over a day) the
needs a snapshot, this can be achieved by switching to an identical rule discrepancies are acceptable. If one really needs a snapshot, this
set with a different RuleSet number, hence asynchronous collections may can be achieved by switching to an identical rule set with a
be regarded as a useful generalisation of synchronised ones. 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. The control variables are the minimum set required for a meter
Their number has been whittled down as experience has been gained with reader. Their number has been whittled down as experience has been
the MIB implementation. A few of them are 'general,' i.e. they control gained with the MIB implementation. A few of them are 'general',
the overall behaviour of the meter. These are set by a single 'master' i.e. they control the overall behaviour of the meter. These are set
manager, and no other manager should attempt to change their values. by a single 'master' manager, and no other manager should attempt to
The decision as to which manager is the 'master' must be made by the change their values. The decision as to which manager is the '
network operations personnel responsible; this MIB does not attempt to master' must be made by the network operations personnel responsible;
define any interaction between managers. this MIB does not attempt to define any interaction between managers.
There are three other groups of control variables, arranged into tables There are three other groups of control variables, arranged into
in the same way as in the RMON2 MIB [RMON2-MIB]. They are used as tables in the same way as in the RMON2 MIB [RMON2-MIB]. They are used
follows: as follows:
- RULE SET INFO: Before attempting to download a RuleSet, a manager - RULE SET INFO: Before attempting to download a RuleSet, a manager
must create a row in the flowRuleSetInfoTable and set its must create a row in the flowRuleSetInfoTable and set its
flowRuleInfoSize to a value large enough to hold the RuleSet. When flowRuleInfoSize to a value large enough to hold the RuleSet. When
the rule set is ready the manager must set flowRuleInfoRulesReady the rule set is ready the manager must set flowRuleInfoRulesReady
to 'true,' indicating that the rule set is ready for use (but not to 'true', indicating that the rule set is ready for use (but not
yet 'running'). yet 'running').
- METER READER INFO: Any meter reader wishing to collect data - METER READER INFO: Any meter reader wishing to collect data
reliably for all flows from a RuleSet should first create a row in reliably for all flows from a RuleSet should first create a row in
the flowReaderInfoTable with flowReaderRuleSet set to that the flowReaderInfoTable with flowReaderRuleSet set to that
RuleSet's index in the flowRuleSetInfoTable. It should write that RuleSet's index in the flowRuleSetInfoTable. It should write that
row's flowReaderLastTime object each time it starts a collection row's flowReaderLastTime object each time it starts a collection
pass through the flow table. The meter will not recover a flow's 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 memory until every meter reader holding a row for that flow's
RuleSet has collected the flow's data. RuleSet has collected the flow's data.
- MANAGER INFO: Any manager wishing to run a RuleSet in the meter - MANAGER INFO: Any manager wishing to run a RuleSet in the meter
must create a row in the flowManagerInfo table, specifying the must create a row in the flowManagerInfo table, specifying the
desired RuleSet to run and its corresponding 'standby' RuleSet (if desired RuleSet to run and its corresponding 'standby' RuleSet (if
one is desired). A current RuleSet is 'running' if its one is desired). A current RuleSet is 'running' if its
flowManagerRunningStandby value is false(2), similarly a standby flowManagerRunningStandby value is false(2), similarly a standby
RuleSet is 'running' if flowManagerRunningStandby is true(1). RuleSet is 'running' if flowManagerRunningStandby is true(1).
Times within the meter are in terms of its Uptime, i.e. centiseconds Times within the meter are in terms of its Uptime, i.e. centiseconds
since the meter started. For meters implemented as self-contained SNMP since the meter started. For meters implemented as self-contained
agents this will be the same as sysUptime, but this may not be true for SNMP agents this will be the same as sysUptime, but this may not be
meters implemented as subagents. Managers can read the meter's Uptime true for meters implemented as subagents. Managers can read the
when neccessary (e.g. to set a TimeFilter value) by setting meter's Uptime when neccessary (e.g. to set a TimeFilter value) by
flowReaderLastTime, then reading its new value. setting flowReaderLastTime, then reading its new value.
4 Definitions 4 Definitions
FLOW-METER-MIB DEFINITIONS ::= BEGIN FLOW-METER-MIB DEFINITIONS ::= BEGIN
IMPORTS IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, MODULE-IDENTITY, OBJECT-TYPE,
Counter32, Counter64, Integer32, mib-2 Counter32, Counter64, Integer32, mib-2
FROM SNMPv2-SMI FROM SNMPv2-SMI
TEXTUAL-CONVENTION, RowStatus, TimeStamp, TruthValue TEXTUAL-CONVENTION, RowStatus, TimeStamp, TruthValue
FROM SNMPv2-TC FROM SNMPv2-TC
OBJECT-GROUP, MODULE-COMPLIANCE OBJECT-GROUP, MODULE-COMPLIANCE
FROM SNMPv2-CONF FROM SNMPv2-CONF
ifIndex ifIndex
FROM IF-MIB FROM IF-MIB
TimeFilter TimeFilter
FROM RMON2-MIB; FROM RMON2-MIB;
flowMIB MODULE-IDENTITY flowMIB MODULE-IDENTITY
LAST-UPDATED "9908301250Z" LAST-UPDATED "9910250000Z" -- October 25, 1999
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 7, line 18 skipping to change at page 7, line 4
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
E-mail: n.brownlee@auckland.ac.nz" E-mail: n.brownlee@auckland.ac.nz"
DESCRIPTION DESCRIPTION
"MIB for the RTFM Traffic Flow Meter." "MIB for the RTFM Traffic Flow Meter."
REVISION "9908301250Z" REVISION "9910250000Z"
DESCRIPTION DESCRIPTION
"UTF8OwnerString Textual Convention added, and used to "Initial Version, published as RFC 2720."
replace OwnerString. Conceptually the same as OwnerString,
but facilitating internationalisation by using UTF-8 REVISION "9908301250Z"
encoding for its characters rather than US-ASCII." 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" REVISION "9908191010Z"
DESCRIPTION DESCRIPTION
"Changes to SIZE specification for two variables: "Changes to SIZE specification for two variables:
- flowRuleInfoName SIZE specified as (0..127) - flowRuleInfoName SIZE specified as (0..127)
- flowRuleIndex SIZE increased to (1..2147483647)" - flowRuleIndex SIZE increased to (1..2147483647)"
REVISION "9712230937Z" REVISION "9712230937Z"
DESCRIPTION DESCRIPTION
"Two further variables deprecated: "Two further variables deprecated:
skipping to change at page 13, line 36 skipping to change at page 13, line 37
SYNTAX SEQUENCE OF FlowRuleSetInfoEntry SYNTAX SEQUENCE OF FlowRuleSetInfoEntry
MAX-ACCESS not-accessible MAX-ACCESS not-accessible
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"An array of information about the RuleSets held in the "An array of information about the RuleSets held in the
meter. meter.
Any manager may configure a new RuleSet for the meter by Any manager may configure a new RuleSet for the meter by
creating a row in this table with status active(1), and setting 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 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 RuleSet 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 RuleSet a manager must create a row in To actually 'run' a RuleSet 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 RuleSet to be run. to point to the RuleSet to be run.
Once a RuleSet is running a manager may not change any of the Once a RuleSet is running a manager may not change any of the
objects within the RuleSet itself. Any attempt to do so should objects within the RuleSet itself. Any attempt to do so should
result in a notWritable(17) SNMP error-status for such objects. result in a notWritable(17) SNMP error-status for such objects.
skipping to change at page 15, line 29 skipping to change at page 15, line 33
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 RuleSet. Once its value has been set to active(1) associated RuleSet. 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 uleSet. Any attempt row, nor the contents of the associated RuleSet. Any attempt
to do so should result in a notWritable(17) SNMP error-status to do so should result in a notWritable(17) SNMP error-status
for such variables or objects. for such variables or objects.
To download a RuleSet, a manger could: To download a RuleSet, 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).
skipping to change at page 40, line 53 skipping to change at page 42, line 10
'Traffic Flow Measurement: Architecture' document [RTFM-ARC]." 'Traffic Flow Measurement: Architecture' document [RTFM-ARC]."
::= { 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 this rule's "A parameter value providing extra information for this rule's
action. Most of the actions use the parameter value to specify action. Most of the actions use the parameter value to specify
which rule to excute after this rule's test has failed; details which rule to execute after this rule's test has failed; details
are given in the 'Traffic Flow Measurement: Architecture' are given in the 'Traffic Flow Measurement: Architecture'
document [RTFM-ARC]." document [RTFM-ARC]."
::= { flowRuleEntry 7 } ::= { flowRuleEntry 7 }
-- --
-- Traffic Flow Meter conformance statement -- Traffic Flow Meter conformance statement
-- --
flowMIBCompliances flowMIBCompliances
OBJECT IDENTIFIER ::= { flowMIBConformance 1 } OBJECT IDENTIFIER ::= { flowMIBConformance 1 }
skipping to change at page 44, line 43 skipping to change at page 47, line 4
MODULE MODULE
MANDATORY-GROUPS { MANDATORY-GROUPS {
flowControlGroup2, flowControlGroup2,
flowDataTableGroup, flowDataTableGroup,
flowDataPackageGroup, flowDataPackageGroup,
flowRuleTableGroup flowRuleTableGroup
} }
::= { flowMIBCompliances 1 } ::= { flowMIBCompliances 1 }
END END
5 Security Considerations 5 Security Considerations
5.1 SNMP Concerns 5.1 SNMP Concerns
There are a number of management objects defined in this MIB that have a There are a number of management objects defined in this MIB that
MAX-ACCESS clause of read-write and/or read-create. Such objects may be have a MAX-ACCESS clause of read-write and/or read-create. Such
considered sensitive or vulnerable in some network environments. The objects may be considered sensitive or vulnerable in some network
support for SET operations in a non-secure environment without proper environments. The support for SET operations in a non-secure
protection can have a negative effect on network operations. environment without proper protection can have a negative effect on
network operations.
There are a number of managed objects in this MIB that may contain There are a number of managed objects in this MIB that may contain
sensitive information. These include all the objects in the Control sensitive information. These include all the objects in the Control
Group (since they control access to meter resources by Managers and Group (since they control access to meter resources by Managers and
Meter Readers) and those in the Flow Table (since they hold the Meter Readers) and those in the Flow Table (since they hold the
collected traffic flow data). collected traffic flow data).
It is thus important to control even GET access to these objects and It is thus important to control even GET access to these objects and
possibly to even encrypt the values of these object when sending them possibly to even encrypt the values of these object when sending them
over the network via SNMP. Not all versions of SNMP provide features for over the network via SNMP. Not all versions of SNMP provide features
such a secure environment. for such a secure environment.
SNMPv1 by itself is not a secure environment. Even if the network SNMPv1 by itself is not a secure environment. Even if the network
itself is secure (for example by using IPSec), even then, there is no itself is secure (for example by using IPSec), even then, there is no
control as to who on the secure network is allowed to access and GET/SET control as to who on the secure network is allowed to access and
(read/change/create/delete) the objects in this MIB. GET/SET (read/change/create/delete) the objects in this MIB.
It is recommended that the implementers consider the security features It is recommended that the implementers consider the security
as provided by the SNMPv3 framework. Specifically, the use of the features as provided by the SNMPv3 framework. Specifically, the use
User-based Security Model [RFC2574] and the View-based Access Control of the User-based Security Model [RFC2574] and the View-based Access
Model [RFC2575] is recommended. Control Model [RFC2575] is recommended.
It is then a customer/user responsibility to ensure that the SNMP entity It is then a customer/user responsibility to ensure that the SNMP
giving access to an instance of this MIB is properly configured to give entity giving access to an instance of this MIB is properly
access to the objects only to those principals (users) that have configured to give access to the objects only to those principals
legitimate rights to indeed GET or SET (change/create/delete) them. (users) that have legitimate rights to indeed GET or SET
(change/create/delete) them.
5.2 Traffic Meter Concerns 5.2 Traffic Meter Concerns
This MIB describes how an RTFM traffic meter is controlled, and provides This MIB describes how an RTFM traffic meter is controlled, and
a way for traffic flow data to be retrieved from it by a meter reader. provides a way for traffic flow data to be retrieved from it by a
This is essentially an application using SNMP as a method of meter reader. This is essentially an application using SNMP as a
communication between co-operating hosts; it does not - in itself - have method of communication between co-operating hosts; it does not - in
any inherent security risks. itself - have 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. In particular, an attacker taken to keep the meter and its data secure. In particular, an
must not be permitted to write any of the meter's variables! This attacker must not be permitted to write any of the meter's variables!
requires that access to the meter for control purposes (e.g. loading This requires that access to the meter for control purposes (e.g.
RuleSets and reading flow data) be restricted. Such restriction could loading RuleSets and reading flow data) be restricted. Such
be achieved in many ways, for example: 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
can be provided by using 'community' strings (which are essentially can be provided by using 'community' strings (which are essentially
clear-text passwords) with SNMPv2C [RFC1157]. Where stronger clear-text passwords) with SNMPv2C [RFC1157]. Where stronger
security is needed, users should consider using the User-based security is needed, users should consider using the User-based
Security Model [RFC2574] and the View-based Access Control Model Security Model [RFC2574] and the View-based Access Control Model
[RFC2575]. [RFC2575].
- Lower-layer Security. Access to the meter can be protected using - Lower-layer Security. Access to the meter can be protected using
encryption at the network layer. For example, one could run SNMP encryption at the network layer. For example, one could run SNMP
to the meter through an encrypted TCP tunnel. to the meter through an encrypted TCP tunnel.
When implementing a meter it may be sensible to use separate network When implementing a meter it may be sensible to use separate network
interfaces for control and for metering. If this is done the control interfaces for control and for metering. If this is done the control
network can be set up so that it doesn't carry any 'user' traffic, and network can be set up so that it doesn't carry any 'user' traffic,
the metering interfaces can ignore any user attempts to take control of and the metering interfaces can ignore any user attempts to take
the meter. control of the meter.
Users should also consider how they will address attempts to circumvent Users should also consider how they will address attempts to
a meter, i.e. to prevent it from measuring flows. Such attempts are circumvent a meter, i.e. to prevent it from measuring flows. Such
essentially denial-of-service attacks on the metering interfaces. For attempts are essentially denial-of-service attacks on the metering
example interfaces. For example
- Port Scan attacks. The attacker sends packets to each of a very - Port Scan attacks. The attacker sends packets to each of a very
large number of IP (Address : Port) pairs. Each of these packets large number of IP (Address : Port) pairs. Each of these packets
creates a new flow in the meter; if there are enough of them the creates a new flow in the meter; if there are enough of them the
meter will recognise a 'flood' condition, and will probably stop meter will recognise a 'flood' condition, and will probably stop
creating new flows. As a minimum, users (and implementors) should creating new flows. As a minimum, users (and implementors) should
ensure that meters can recover from flood conditions as soon as ensure that meters can recover from flood conditions as soon as
possible after they occur. possible after they occur.
- Counter Wrap attacks: The attacker sends enough packets to cause - Counter Wrap attacks: The attacker sends enough packets to cause
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
their meters are read often enough to prevent them being flooded. The that their meters are read often enough to prevent them being
resulting flow data will contain a record of the attacking packets, flooded. The resulting flow data will contain a record of the
which may well be useful in determining where any attack came from. attacking packets, which may well be useful in determining where any
attack came from.
6 IANA Considerations 6 IANA Considerations
The RTFM Architecture document [RTFM-ARC], has two sets of assigned The RTFM Architecture document [RTFM-ARC], has two sets of assigned
numbers: Opcodes for the PME (Pattern Matching Engine) and RTFM numbers: Opcodes for the PME (Pattern Matching Engine) and RTFM
Attribute numbers. All the assigned numbers used in the Meter MIB Attribute numbers. All the assigned numbers used in the Meter MIB
appear in Textual Conventions. The numbers they use are derived as appear in Textual Conventions. The numbers they use are derived as
follows: follows:
The MIB's 'Type' textual conventions use names and numbers from the The MIB's 'Type' textual conventions use names and numbers from the
Assigned Numbers RFC [ASG-NBR]: Assigned Numbers RFC [ASG-NBR]:
MediumType Uses ifType Definitions MediumType Uses ifType Definitions
PeerType Uses Address Family Numbers PeerType Uses Address Family Numbers
TransportType Uses Protocol Numbers TransportType Uses Protocol Numbers
The MIB's 'AttributeNumber' textual conventions use RTFM Attribute The MIB's 'AttributeNumber' textual conventions use RTFM Attribute
names and numbers from the RTFM Architecture document [RTFM-ARC], or names and numbers from the RTFM Architecture document [RTFM-ARC], or
other numbers allocated according to that document's IANA other numbers allocated according to that document's IANA
Considerations section: Considerations section:
FlowAttributeNumber Have values stored in a flow table row FlowAttributeNumber Have values stored in a flow table row
RuleAttributeNumber May be tested in a rule RuleAttributeNumber May be tested in a rule
The MIB's ActionNumber textual convention uses RTFM PME Opcode names and The MIB's ActionNumber textual convention uses RTFM PME Opcode names
numbers from the RTFM Architecture document [RTFM-ARC], or other numbers and numbers from the RTFM Architecture document [RTFM-ARC], or other
allocated according to that document's IANA Considerations section. numbers allocated according to that document's IANA Considerations
section.
7 Appendix A: Changes Introduced Since RFC 2064 7 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
1997. The most significant changes since then are summarised below. January 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 and - PACKET MATCHING ATTRIBUTES: Computed attributes (e.g. FlowClass and
FlowKind) may now be tested. This allows one to use these 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.
A new attribute, MatchingStoD, has been added. Its value is 1 A new attribute, MatchingStoD, has been added. Its value is 1
while a packet is being matched with its adresses in 'wire' while a packet is being matched with its adresses in 'wire'
(source-to-destination) order. (source-to-destination) order.
- FLOOD MODE: This is now a read-write variable. Setting it to - FLOOD MODE: This is now a read-write variable. Setting it to
false(2) switches the meter out of flood mode and back to normal false(2) switches the meter out of flood mode and back to normal
operation. operation.
- CONTROL TABLES: Several variables have been added to the RuleSet, - CONTROL TABLES: Several variables have been added to the RuleSet,
Reader and Manager tables to provide more effective control of the Reader and Manager tables to provide more effective control of the
meter's activities. meter's activities.
- FLOW TABLE: 64-bit counters are used for octet and PDU counts. - FLOW TABLE: 64-bit counters are used for octet and PDU counts.
This reduces the problems caused by the wrap-around of 32-bit This reduces the problems caused by the wrap-around of 32-bit
counters in earlier versions. counters in earlier versions.
flowDataRuleSet is now used as an index to the flow table. This flowDataRuleSet is now used as an index to the flow table. This
allows a meter reader to collect only those flow table rows created allows a meter reader to collect only those flow table rows created
by a specified RuleSet. by a specified RuleSet.
- 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 (a BER-encoded sequence [ASN-1, ASN-BER]). It provides an object (a BER-encoded sequence [ASN-1, ASN-BER]). It provides an
efficient way to recover flow data, particularly when used with efficient way to recover flow data, particularly when used with
SNMP GetBulk requests. SNMP GetBulk requests.
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 8 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
IETF's Accounting Working Group with assistance from the SNMP Working the IETF's Accounting Working Group with assistance from the SNMP
Group and the Security Area Advisory Group. Particular thanks are due Working Group and the Security Area Advisory Group. Particular
to Jim Barnes, Sig Handelman and Stephen Stibler for their support and thanks are due to Jim Barnes, Sig Handelman and Stephen Stibler for
their assistance with checking early versions of the MIB. their support and 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 chapter 5 (above). changes summarized in chapter 5 (above).
9 References 9 Intellectual Property Notice
[ACT-BKG] Mills, C., Hirsch, G. and Ruth, G., "Internet Accounting The IETF takes no position regarding the validity or scope of any
Background," RFC 1272, November 1991. intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementers or users of this specification can
be obtained from the IETF Secretariat."
[ASG-NBR] Reynolds, J., Postel, J., "Assigned Numbers," The IETF invites any interested party to bring to its attention any
RFC 1700, ISI, October 1994. copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
[ASN-1] Information processing systems - Open Systems 10 References
Interconnection - Specification of Abstract Syntax Notation
One (ASN.1), International Organization for Standardization,
International Standard 8824, December 1987.
[ASN-BER] Information processing systems - Open Systems [ACT-BKG] Mills, C., Hirsch, G. and G. Ruth, "Internet Accounting
Interconnection - Specification of Basic Encoding Rules for Background", RFC 1272, November 1991.
Abstract Notation One (ASN.1), International Organization
for Standardization, International Standard 8825,
December 1987.
[ENET-OBJ] Kastenholz., F., "Definitions of Managed Objects for the [ASG-NBR] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2,
Ethernet-like Interface Types," RFC 1643, July 1994 RFC 1700, ISI, October 1994.
[FDDI-MIB] Case, J. and Rijsinghani., A., "FDDI Management [ASN-1] Information processing systems - Open Systems
Information Base," September 1993. Interconnection - Specification of Abstract Syntax
Notation One (ASN.1), International Organization for
Standardization, International Standard 8824, December
1987.
[IPPM-FRM] Paxson, V., Almes, G., Mahdavi, J. and Mathis, M., [ASN-BER] Information processing systems - Open Systems
"Framework for IP Performance Metrics," RFC 2330, May 1998. Interconnection - Specification of Basic Encoding Rules
for Abstract Notation One (ASN.1), International
Organization for Standardization, International Standard
8825, December 1987.
[MIB-II] McCloghrie, K. and Rose, M., Editors, "Management [ENET-OBJ] Kastenholz, F., "Definitions of Managed Objects for the
Information Base for Network Management of TCP/IP-based Ethernet-like Interface Types", RFC 1643, July 1994.
internets: MIB-II," RFC 1213, March 1991.
[RFC1155] Rose, M., and K. McCloghrie, "Structure and Identification [FDDI-MIB] Case, J. and A. Rijsinghani, "FDDI Management Information
of Management Information for TCP/IP-based Internets", Base", RFC 1512, September 1993.
STD 16, RFC 1155, May 1990
[RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple [IPPM-FRM] Paxson, V., Almes, G., Mahdavi, J. and M. Mathis,
Network Management Protocol", STD 15, RFC 1157, May 1990. "Framework for IP Performance Metrics", RFC 2330, May
1998.
[RFC1212] Rose, M., and K. McCloghrie, "Concise MIB Definitions", [MIB-II] McCloghrie, K. and M. Rose, "Management Information Base
STD 16, RFC 1212, March 1991 for Network Management of TCP/IP-based internets: MIB-
II", STD 17, RFC 1213, March 1991.
[RFC1215] M. Rose, "A Convention for Defining Traps for use with [RFC1155] Rose, M., and K. McCloghrie, "Structure and
the SNMP", RFC 1215, March 1991 Identification of Management Information for TCP/IP-based
Internets", STD 16, RFC 1155, May 1990
[RFC1901] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, [RFC1157] Case, J., Fedor, M., Schoffstall, M. and J. Davin,
"Introduction to Community-based SNMPv2", "Simple Network Management Protocol", STD 15, RFC 1157,
RFC 1901, January 1996. May 1990.
[RFC1905] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, [RFC1212] Rose, M. and K. McCloghrie, "Concise MIB Definitions",
"Protocol Operations for Version 2 of the Simple Network STD 16, RFC 1212, March 1991.
Management Protocol (SNMPv2)", RFC 1905, January 1996.
[RFC1906] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, [RFC1215] Rose, M., "A Convention for Defining Traps for use with
"Transport Mappings for Version 2 of the Simple Network the SNMP", RFC 1215, March 1991
Management Protocol (SNMPv2)", RFC 1906, January 1996.
[RFC1908] Case, J., McCloghrie, K., Rose, M. and Waldbusser, S., [RFC1901] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
"Coexistence between version 1 and version 2 of the "Introduction to Community-based SNMPv2", RFC 1901,
Internet-standard Network Management Framework," RFC 1908 January 1996.
[RFC2570] Case, J., Mundy, R., Partain, D., and B. Stewart, [RFC1905] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
"Introduction to Version 3 of the Internet-standard Network "Protocol Operations for Version 2 of the Simple Network
Management Framework", RFC 2570, April 1999 Management Protocol (SNMPv2)", RFC 1905, January 1996.
[RFC2571] Harrington, D., Presuhn, R., and Wijnen, B., [RFC1906] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
"An Architecture for Describing SNMP Management Frameworks", "Transport Mappings for Version 2 of the Simple Network
RFC 2571, April 1999 Management Protocol (SNMPv2)", RFC 1906, January 1996.
[RFC2572] Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message [RFC1908] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
Processing and Dispatching for the Simple Network Management "Coexistence between version 1 and version 2 of the
Protocol (SNMP)", RFC 2572, April 1999 Internet-standard Network Management Framework", RFC
1908, January 1996.
[RFC2573] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", [RFC2570] Case, J., Mundy, R., Partain, D. and B. Stewart,
RFC 2573, April 1999 "Introduction to Version 3 of the Internet-standard
Network Management Framework", RFC 2570, April 1999.
[RFC2574] Blumenthal, U., and B. Wijnen, "User-based Security Model [RFC2571] Harrington, D., Presuhn, R. and B. Wijnen, "An
(USM) for version 3 of the Simple Network Management Architecture for Describing SNMP Management Frameworks",
Protocol (SNMPv3)", RFC 2574, April 1999 RFC 2571, April 1999.
[RFC2575] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based [RFC2572] Case, J., Harrington D., Presuhn R. and B. Wijnen,
Access Control Model (VACM) for the Simple Network "Message Processing and Dispatching for the Simple
Management Protocol (SNMP)", RFC 2575, April 1999 Network Management Protocol (SNMP)", RFC 2572, April
1999.
[RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., [RFC2573] Levi, D., Meyer, P. and B. Stewart, "SNMPv3
Rose, M., and S. Waldbusser, "Structure of Management Applications", RFC 2573, April 1999.
Information Version 2 (SMIv2)",
STD 58, RFC 2578, April 1999
[RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., [RFC2574] Blumenthal, U. and B. Wijnen, "User-based Security Model
Rose, M., and S. Waldbusser, "Textual Conventions for (USM) for version 3 of the Simple Network Management
SMIv2", STD 58, RFC 2579, April 1999 Protocol (SNMPv3)", RFC 2574, April 1999.
[RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., [RFC2575] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based
Rose, M., and S. Waldbusser, "Conformance Statements for Access Control Model (VACM) for the Simple Network
SMIv2", STD 58, RFC 2580, April 1999 Management Protocol (SNMP)", RFC 2575, April 1999.
[RMON-MIB] Waldbusser, S., "Remote Network Monitoring Management [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
Information Base," RFC 1757, February 1995. Rose, M. and S. Waldbusser, "Structure of Management
Information Version 2 (SMIv2)", STD 58, RFC 2578, April
1999.
[RMON2-MIB] Waldbusser, S., "Remote Network Monitoring Management [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
Information Base Version 2 using SMIv2," RFC 2021, Rose, M. and S. Waldbusser, "Textual Conventions for
January 1997. SMIv2", STD 58, RFC 2579, April 1999.
[RTFM-ARC] Brownlee, N., Mills, C. and Ruth, G., "Traffic Flow [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
Measurement: Architecture", RFC 2063, January 1997. Rose, M. and S. Waldbusser, "Conformance Statements for
SMIv2", STD 58, RFC 2580, April 1999.
[UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 10646," [RMON-MIB] Waldbusser, S., "Remote Network Monitoring Management
RFC 2279. January 1998. Information Base", RFC 1757, February 1995.
[V6-ADDR] Hinden, R.and Deering, S., "IP Version 6 Addressing [RMON2-MIB] Waldbusser, S., "Remote Network Monitoring Management
Architecture," RFC 2373, July 1998. Information Base Version 2 using SMIv2", RFC 2021,
January 1997.
10 Author's Address [RTFM-ARC] Brownlee, N., Mills, C. and Ruth, G., "Traffic Flow
Measurement: Architecture", RFC 722, October 1999.
Nevil Brownlee [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO
Information Technology Systems & Services 10646", RFC 2279, January 1998.
The University of Auckland
Private Bag 92-019
Auckland, New Zealand
Phone: +64 9 373 7599 x8941 [V6-ADDR] Hinden, R. and S. Deering, "IP Version 6 Addressing
E-mail: n.brownlee@auckland.ac.nz Architecture", RFC 2373, July 1998.
Expires March 2000 11 Author's Address
Nevil Brownlee
Information Technology Systems & Services
The University of Auckland
Private Bag 92-019
Auckland, New Zealand
Phone: +64 9 373 7599 x8941
EMail: n.brownlee@auckland.ac.nz
12 Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 120 change blocks. 
439 lines changed or deleted 449 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/