draft-ietf-rmonmib-rmon2-v2-01.txt   draft-ietf-rmonmib-rmon2-v2-02.txt 
Remote Network Monitoring Remote Network Monitoring
Management Information Base Management Information Base
Version 2 Version 2
Using SMIv2 <draft-ietf-rmonmib-rmon2-v2-02.txt>
<draft-ietf-rmonmib-rmon2-v2-01.txt>
February 14, 2004 October 6, 2004
Steven Waldbusser Steven Waldbusser
waldbusser@nextbeacon.com waldbusser@nextbeacon.com
1. Status of this Memo
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance By submitting this Internet-Draft, I certify that any applicable
with all provisions of Section 10 of RFC2026 [7]. patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
This document is an Internet-Draft and is in full
conformance with all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Internet-Drafts are working documents of the Internet
Engineering Task Force (IETF), its areas, and its working Engineering Task Force (IETF), its areas, and its working
groups. Note that other groups may also distribute working groups. Note that other groups may also distribute working
documents as Internet-Drafts. documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of
months and may be updated, replaced, or obsoleted by other six months and may be updated, replaced, or obsoleted by
documents at any time. It is inappropriate to use Internet- other documents at any time. It is inappropriate to use
Drafts as reference material or to cite them other than as Internet- Drafts as reference material or to cite them
"work in progress". other than as "work in progress".
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed The list of Internet-Draft Shadow Directories can be
at http://www.ietf.org/shadow.html. accessed at http://www.ietf.org/shadow.html.
Distribution of this document is unlimited. Please send Distribution of this document is unlimited. Please send
comments to the RMON WG mailing list <rmonmib@ietf.org>. comments to the RMON WG mailing list <rmonmib@ietf.org>.
2. Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Copyright (C) The Internet Society (2004).
Reserved.
3. Abstract Abstract
This memo defines a portion of the Management Information Base This document defines a portion of the Management
(MIB) for use with network management protocols in TCP/IP- Information Base (MIB) for use with network management
based internets. In particular, it defines objects for protocols in TCP/IP-based internets. In particular, it
managing remote network monitoring devices. defines objects for managing remote network monitoring
devices.
4. The Internet-Standard Management Framework This document obsoletes RFC 2021 and the RMON2-MIB module
contained in this memo obsoletes the RMON2-MIB module at
RFC3273 level.
XXX Note To RFC Editor:
Please replace the module at:
ftp://ftp.rfc-editor.org/in-notes/mibs/current.mibs/rmon2.mib
with the RMON2-MIB module in this document
XXX
Table of Contents
1 The Internet-Standard Management Framework ............ 3
2 Overview .............................................. 4
2.1 Remote Network Management Goals ..................... 4
2.2 Structure of MIB .................................... 6
3 Control of Remote Network Monitoring Devices .......... 8
3.1 Resource Sharing Among Multiple Management Sta-
tions .............................................. 8
3.2 Row Addition Among Multiple Management Stations ..... 10
4 Conventions ........................................... 12
5 RMON 2 Conventions .................................... 13
5.1 Usage of the term Application Level ................. 13
5.2 Protocol Directory and Limited Extensibility ........ 13
5.3 Errors in packets ................................... 14
6 Definitions ........................................... 14
7 Security Considerations ............................... 140
8 Appendix - TimeFilter Implementation Notes ............ 142
9 Changes since RFC 2021 ................................ 148
10 Acknowledgments ...................................... 150
11 Author's Address ..................................... 150
12 References ........................................... 151
12.1 Normative References ............................... 151
12.2 Informative References ............................. 151
13 Full Copyright Statement ............................. 152
1. The Internet-Standard Management Framework
For a detailed overview of the documents that describe the For a detailed overview of the documents that describe the
current Internet-Standard Management Framework, please current Internet-Standard Management Framework, please
refer to section 7 of RFC 3410 [8]. refer to section 7 of RFC 3410 [RFC3410].
Managed objects are accessed via a virtual information Managed objects are accessed via a virtual information
store, termed the Management Information Base or MIB. MIB store, termed the Management Information Base or MIB. MIB
objects are generally accessed through the Simple Network objects are generally accessed through the Simple Network
Management Protocol (SNMP). Objects in the MIB are defined Management Protocol (SNMP). Objects in the MIB are defined
using the mechanisms defined in the Structure of Management using the mechanisms defined in the Structure of Management
Information (SMI). This memo specifies a MIB module that Information (SMI). This memo specifies a MIB module that
is compliant to the SMIv2, which is described in STD 58, is compliant to the SMIv2, which is described in STD 58,
RFC 2578 [2], STD 58, RFC 2579 [3] and STD 58, RFC 2580 RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58,
[4]. RFC 2580 [RFC2580].
5. Overview 2. Overview
The RMON2 MIB defines objects that provide RMON analysis up to The RMON2 MIB defines objects that provide RMON analysis up to
the application layer. the application layer.
Remote network monitoring devices, often called monitors or Remote network monitoring devices, often called monitors or
probes, are instruments that exist for the purpose of managing probes, are instruments that exist for the purpose of managing
a network. Often these remote probes are stand-alone devices a network. Often these remote probes are stand-alone devices
and devote significant internal resources for the sole purpose and devote significant internal resources for the sole purpose
of managing a network. An organization may employ many of of managing a network. An organization may employ many of
these devices, one per network segment, to manage its these devices, one per network segment, to manage its
skipping to change at page 4, line 29 skipping to change at page 4, line 29
The objects defined in this document are intended as an The objects defined in this document are intended as an
interface between an RMON agent and an RMON management interface between an RMON agent and an RMON management
application and are not intended for direct manipulation by application and are not intended for direct manipulation by
humans. While some users may tolerate the direct display of humans. While some users may tolerate the direct display of
some of these objects, few will tolerate the complexity of some of these objects, few will tolerate the complexity of
manually manipulating objects to accomplish row creation. manually manipulating objects to accomplish row creation.
These functions should be handled by the management These functions should be handled by the management
application. application.
5.1. Remote Network Management Goals 2.1. Remote Network Management Goals
o Offline Operation o Offline Operation
There are sometimes conditions when a management There are sometimes conditions when a management
station will not be in constant contact with its station will not be in constant contact with its
remote monitoring devices. This is sometimes by remote monitoring devices. This is sometimes by
design in an attempt to lower communications costs design in an attempt to lower communications costs
(especially when communicating over a WAN or (especially when communicating over a WAN or
dialup link), or by accident as network failures dialup link), or by accident as network failures
affect the communications between the management affect the communications between the management
station and the probe. station and the probe.
skipping to change at page 6, line 6 skipping to change at page 6, line 6
o Multiple Managers o Multiple Managers
An organization may have multiple management stations An organization may have multiple management stations
for different units of the organization, for different for different units of the organization, for different
functions (e.g. engineering and operations), and in an functions (e.g. engineering and operations), and in an
attempt to provide disaster recovery. Because attempt to provide disaster recovery. Because
environments with multiple management stations are environments with multiple management stations are
common, the remote network monitoring device has to common, the remote network monitoring device has to
deal with more than own management station, deal with more than own management station,
potentially using its resources concurrently. potentially using its resources concurrently.
5.2. Structure of MIB 2.2. Structure of MIB
The objects are arranged into the following groups: The objects are arranged into the following groups:
- protocol directory - protocol directory
- protocol distribution - protocol distribution
- address mapping - address mapping
- network layer host - network layer host
skipping to change at page 6, line 34 skipping to change at page 6, line 34
- user history - user history
- probe configuration - probe configuration
These groups are the basic units of conformance. If a remote These groups are the basic units of conformance. If a remote
monitoring device implements a group, then it must implement monitoring device implements a group, then it must implement
all objects in that group. For example, a managed agent that all objects in that group. For example, a managed agent that
implements the network layer matrix group must implement the implements the network layer matrix group must implement the
nlMatrixSDTable and the nlMatrixDSTable. nlMatrixSDTable and the nlMatrixDSTable.
Implementations of this MIB must also implement the system Implementations of this MIB must also implement the IF-MIB
group of MIB-II [9] and the IF-MIB [10]. MIB-II may also [RFC2863].
mandate the implementation of additional groups.
These groups are defined to provide a means of assigning These groups are defined to provide a means of assigning
object identifiers, and to provide a method for managed agents object identifiers, and to provide a method for managed agents
to know which objects they must implement. to know which objects they must implement.
This document also contains enhancements to tables defined in This document also contains enhancements to tables defined in
the RMON MIB [5]. These enhancements include: the RMON MIB [RFC2819]. These enhancements include:
1) Adding the DroppedFrames and LastCreateTime 1) Adding the DroppedFrames and LastCreateTime
conventions to each table defined in the RMON MIB. conventions to each table defined in the RMON MIB.
2) Augmenting the RMON filter table with a mechanism 2) Augmenting the RMON filter table with a mechanism
that allows filtering based on an offset from the that allows filtering based on an offset from the
beginning of a particular protocol, even if the beginning of a particular protocol, even if the
protocol headers are variable length. protocol headers are variable length.
3) Augmenting the RMON filter and capture status bits 3) Augmenting the RMON filter and capture status bits
skipping to change at page 8, line 5 skipping to change at page 8, line 5
bits that denote the same condition. bits that denote the same condition.
9 For any media, this bit is set for any packet 9 For any media, this bit is set for any packet
that is too long for the media. This bit may that is too long for the media. This bit may
be set in addition to other media-specific bits be set in addition to other media-specific bits
that denote the same condition. that denote the same condition.
These enhancements are implemented by RMON-2 probes that also These enhancements are implemented by RMON-2 probes that also
implement RMON and do not add any requirements to probes that implement RMON and do not add any requirements to probes that
are compliant to just RMON. are compliant to just RMON.
6. Control of Remote Network Monitoring Devices 3. Control of Remote Network Monitoring Devices
Due to the complex nature of the available functions in these Due to the complex nature of the available functions in these
devices, the functions often need user configuration. In many devices, the functions often need user configuration. In many
cases, the function requires parameters to be set up for a cases, the function requires parameters to be set up for a
data collection operation. The operation can proceed only data collection operation. The operation can proceed only
after these parameters are fully set up. after these parameters are fully set up.
Many functional groups in this MIB have one or more tables in Many functional groups in this MIB have one or more tables in
which to set up control parameters, and one or more data which to set up control parameters, and one or more data
tables in which to place the results of the operation. The tables in which to place the results of the operation. The
skipping to change at page 8, line 38 skipping to change at page 8, line 38
action on the remote monitoring device. These objects may action on the remote monitoring device. These objects may
execute an action as a result of a change in the state of the execute an action as a result of a change in the state of the
object. For those objects in this MIB, a request to set an object. For those objects in this MIB, a request to set an
object to the same value as it currently holds would thus object to the same value as it currently holds would thus
cause no action to occur. cause no action to occur.
To facilitate control by multiple managers, resources have to To facilitate control by multiple managers, resources have to
be shared among the managers. These resources are typically be shared among the managers. These resources are typically
the memory and computation resources that a function requires. the memory and computation resources that a function requires.
6.1. Resource Sharing Among Multiple Management Stations 3.1. Resource Sharing Among Multiple Management Stations
When multiple management stations wish to use functions that When multiple management stations wish to use functions that
compete for a finite amount of resources on a device, a method compete for a finite amount of resources on a device, a method
to facilitate this sharing of resources is required. to facilitate this sharing of resources is required.
Potential conflicts include: Potential conflicts include:
o Two management stations wish to simultaneously use o Two management stations wish to simultaneously use
resources that together would exceed the capability of resources that together would exceed the capability of
the device. the device.
o A management station uses a significant amount of o A management station uses a significant amount of
skipping to change at page 10, line 31 skipping to change at page 10, line 31
the most trust in a monitor-owned row because it should be the most trust in a monitor-owned row because it should be
changed very infrequently. A row owned by the management changed very infrequently. A row owned by the management
application is less long-lived because a network administrator application is less long-lived because a network administrator
is more likely to re-assign resources from a row that is in is more likely to re-assign resources from a row that is in
use by one user than from a monitor-owned row that is use by one user than from a monitor-owned row that is
potentially in use by many users. A row owned by another potentially in use by many users. A row owned by another
application would be even less long-lived because the other application would be even less long-lived because the other
application may delete or modify that row completely at its application may delete or modify that row completely at its
discretion. discretion.
6.2. Row Addition Among Multiple Management Stations 3.2. Row Addition Among Multiple Management Stations
The addition of new rows is achieved using the RowStatus The addition of new rows is achieved using the RowStatus
Textual Convention [3]. In this MIB, rows are often added to Textual Convention [RFC2579]. In this MIB, rows are often
a table in order to configure a function. This configuration added to a table in order to configure a function. This
usually involves parameters that control the operation of the configuration usually involves parameters that control the
function. The agent must check these parameters to make sure operation of the function. The agent must check these
they are appropriate given restrictions defined in this MIB as parameters to make sure they are appropriate given
well as any implementation specific restrictions such as lack restrictions defined in this MIB as well as any implementation
of resources. The agent implementor may be confused as to specific restrictions such as lack of resources. The agent
when to check these parameters and when to signal to the implementor may be confused as to when to check these
management station that the parameters are invalid. There are parameters and when to signal to the management station that
two opportunities: the parameters are invalid. There are two opportunities:
o When the management station sets each parameter object. o When the management station sets each parameter object.
o When the management station sets the row status object o When the management station sets the row status object
to active. to active.
If the latter is chosen, it would be unclear to the management If the latter is chosen, it would be unclear to the management
station which of the several parameters was invalid and caused station which of the several parameters was invalid and caused
the badValue error to be emitted. Thus, wherever possible, the badValue error to be emitted. Thus, wherever possible,
the implementor should choose the former as it will provide the implementor should choose the former as it will provide
skipping to change at page 11, line 24 skipping to change at page 11, line 24
same control table, the managers may collide, attempting to same control table, the managers may collide, attempting to
create the same entry. To guard against these collisions, create the same entry. To guard against these collisions,
each such control entry contains a status object with special each such control entry contains a status object with special
semantics that help to arbitrate among the managers. If an semantics that help to arbitrate among the managers. If an
attempt is made with the row addition mechanism to create such attempt is made with the row addition mechanism to create such
a status object and that object already exists, an error is a status object and that object already exists, an error is
returned. When more than one manager simultaneously attempts returned. When more than one manager simultaneously attempts
to create the same conceptual row, only the first will to create the same conceptual row, only the first will
succeed. The others will receive an error. succeed. The others will receive an error.
In the RMON MIB [5], the EntryStatus textual convention was In the RMON MIB [RFC2819], the EntryStatus textual convention
introduced to provide this mutual exclusion function. Since was introduced to provide this mutual exclusion function.
then, this function was added to the SNMP framework as the Since then, this function was added to the SNMP framework as
RowStatus textual convention. The RowStatus textual the RowStatus textual convention. The RowStatus textual
convention is used for the definition of all new tables. convention is used for the definition of all new tables.
When a manager wishes to create a new control entry, it needs When a manager wishes to create a new control entry, it needs
to choose an index for that row. It may choose this index in to choose an index for that row. It may choose this index in
a variety of ways, hopefully minimizing the chances that the a variety of ways, hopefully minimizing the chances that the
index is in use by another manager. If the index is in use, index is in use by another manager. If the index is in use,
the mechanism mentioned previously will guard against the mechanism mentioned previously will guard against
collisions. Examples of schemes to choose index values collisions. Examples of schemes to choose index values
include random selection or scanning the control table looking include random selection or scanning the control table looking
for the first unused index. Because index values may be any for the first unused index. Because index values may be any
valid value in the range and they are chosen by the manager, valid value in the range and they are chosen by the manager,
the agent must allow a row to be created with any unused index the agent must allow a row to be created with any unused index
value if it has the resources to create a new row. value if it has the resources to create a new row.
Some tables in this MIB reference other tables within this Some tables in this MIB reference other tables within this
MIB. When creating or deleting entries in these tables, it is MIB. When creating or deleting entries in these tables, it is
generally allowable for dangling references to exist. There generally allowable for dangling references to exist. There
is no defined order for creating or deleting entries in these is no defined order for creating or deleting entries in these
tables. tables.
7. Conventions 4. Conventions
The following conventions are used throughout the RMON MIB and The following conventions are used throughout the RMON MIB and
its companion documents. its companion documents.
Good Packets Good Packets
Good packets are error-free packets that have a valid frame Good packets are error-free packets that have a valid frame
length. For example, on Ethernet, good packets are error-free length. For example, on Ethernet, good packets are error-free
packets that are between 64 octets long and 1518 octets long. packets that are between 64 octets long and 1518 octets long.
They follow the form defined in IEEE 802.3 section 3.2.all. They follow the form defined in IEEE 802.3 section 3.2.all.
Bad Packets Bad Packets
Bad packets are packets that have proper framing and are Bad packets are packets that have proper framing and are
therefore recognized as packets, but contain errors within the therefore recognized as packets, but contain errors within the
packet or have an invalid length. For example, on Ethernet, packet or have an invalid length. For example, on Ethernet,
bad packets have a valid preamble and SFD, but have a bad CRC, bad packets have a valid preamble and SFD, but have a bad CRC,
or are either shorter than 64 octets or longer than 1518 or are either shorter than 64 octets or longer than 1518
octets. octets.
8. RMON 2 Conventions 5. RMON 2 Conventions
The following practices and conventions are introduced in the The following practices and conventions are introduced in the
RMON 2 MIB. RMON 2 MIB.
8.1. Usage of the term Application Level 5.1. Usage of the term Application Level
There are many cases in this MIB where the term Application There are many cases in this MIB where the term Application
Level is used to describe a class of protocols or a Level is used to describe a class of protocols or a
capability. This does not typically mean a protocol that is capability. This does not typically mean a protocol that is
an OSI Layer 7 protocol. Rather, it is used to identify a an OSI Layer 7 protocol. Rather, it is used to identify a
class of protocols that is not limited to MAC-layer and class of protocols that is not limited to MAC-layer and
network-layer protocols, but can also include transport, network-layer protocols, but can also include transport,
session, presentation, and application-layer protocols. session, presentation, and application-layer protocols.
8.2. Protocol Directory and Limited Extensibility 5.2. Protocol Directory and Limited Extensibility
Every RMON 2 implementation will have the capability to parse Every RMON 2 implementation will have the capability to parse
certain types of packets and identify their protocol type at certain types of packets and identify their protocol type at
multiple levels. The protocol directory presents an inventory multiple levels. The protocol directory presents an inventory
of those protocol types the probe is capable of monitoring, of those protocol types the probe is capable of monitoring,
and allows the addition, deletion, and configuration of and allows the addition, deletion, and configuration of
protocol types in this list. protocol types in this list.
One concept deserves special attention: the "limited One concept deserves special attention: the "limited
extensibility" of the protocol directory table. The RMON 2 extensibility" of the protocol directory table. The RMON 2
skipping to change at page 14, line 18 skipping to change at page 14, line 18
as DNS, and port 69 as TFTP. The limited extensibility of the as DNS, and port 69 as TFTP. The limited extensibility of the
protocol directory table would allow an SNMP operation to protocol directory table would allow an SNMP operation to
create an entry that would create an additional table mapping create an entry that would create an additional table mapping
for UDP that would recognize UDP port 123 as NTP and begin for UDP that would recognize UDP port 123 as NTP and begin
counting such packets. counting such packets.
This limited extensibility is an option that an implementation This limited extensibility is an option that an implementation
can choose to allow or disallow for any protocol that has can choose to allow or disallow for any protocol that has
child protocols. child protocols.
8.3. Errors in packets 5.3. Errors in packets
Packets with link-level errors are not counted anywhere in Packets with link-level errors are not counted anywhere in
this MIB because most variables in this MIB requires the this MIB because most variables in this MIB requires the
decoding of the contents of the packet, which is meaningless decoding of the contents of the packet, which is meaningless
if there is a link-level error. if there is a link-level error.
Packets in which protocol errors are detected are counted for Packets in which protocol errors are detected are counted for
all protocols below the layer in which the error was all protocols below the layer in which the error was
encountered. The implication of this is that packets in which encountered. The implication of this is that packets in which
errors are detected at the network-layer are not counted errors are detected at the network-layer are not counted
anywhere in this MIB, while packets with errors detected at anywhere in this MIB, while packets with errors detected at
the transport layer may have network-layer statistics counted. the transport layer may have network-layer statistics counted.
9. Definitions 6. Definitions
RMON2-MIB DEFINITIONS ::= BEGIN RMON2-MIB DEFINITIONS ::= BEGIN
IMPORTS IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, Counter32, Integer32, MODULE-IDENTITY, OBJECT-TYPE, Counter32, Integer32,
Gauge32, IpAddress, TimeTicks, mib-2 FROM SNMPv2-SMI Gauge32, IpAddress, TimeTicks, mib-2 FROM SNMPv2-SMI
TEXTUAL-CONVENTION, RowStatus, DisplayString, TimeStamp TEXTUAL-CONVENTION, RowStatus, DisplayString, TimeStamp
FROM SNMPv2-TC FROM SNMPv2-TC
MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF
ifIndex FROM IF-MIB ifIndex FROM IF-MIB
OwnerString, statistics, history, hosts, OwnerString, statistics, history, hosts,
matrix, filter, etherStatsEntry, historyControlEntry, matrix, filter, etherStatsEntry, historyControlEntry,
hostControlEntry, matrixControlEntry, filterEntry, hostControlEntry, matrixControlEntry, filterEntry,
channelEntry FROM RMON-MIB channelEntry FROM RMON-MIB
tokenRing, tokenRingMLStatsEntry, tokenRingPStatsEntry, tokenRing, tokenRingMLStatsEntry, tokenRingPStatsEntry,
ringStationControlEntry, sourceRoutingStatsEntry ringStationControlEntry, sourceRoutingStatsEntry
FROM TOKEN-RING-RMON-MIB; FROM TOKEN-RING-RMON-MIB;
-- Remote Network Monitoring MIB -- Remote Network Monitoring MIB
rmon MODULE-IDENTITY rmon MODULE-IDENTITY
LAST-UPDATED "200402141500Z" -- February 14, 2004 LAST-UPDATED "200410051500Z" -- October 5, 2004
ORGANIZATION "IETF RMON MIB Working Group" ORGANIZATION "IETF RMON MIB Working Group"
CONTACT-INFO CONTACT-INFO
"Author: "Author:
Steve Waldbusser Steve Waldbusser
Phone: +1-650-948-6500 Phone: +1-650-948-6500
Fax : +1-650-745-0671 Fax : +1-650-745-0671
Email: waldbusser@nextbeacon.com Email: waldbusser@nextbeacon.com
Working Group Chair: Working Group Chair:
Andy Bierman Andy Bierman
skipping to change at page 15, line 33 skipping to change at page 15, line 33
E-mail: abierman@cisco.com E-mail: abierman@cisco.com
Working Group Mailing List: <rmonmib@ietf.org> Working Group Mailing List: <rmonmib@ietf.org>
To subscribe send email to: <rmonmib-request@ietf.org> " To subscribe send email to: <rmonmib-request@ietf.org> "
DESCRIPTION DESCRIPTION
"The MIB module for managing remote monitoring "The MIB module for managing remote monitoring
device implementations. This MIB module device implementations. This MIB module
extends the architecture introduced in the original extends the architecture introduced in the original
RMON MIB as specified in RFC 2819. RMON MIB as specified in RFC 2819.
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004). This version of
this MIB module is part of RFC yyyy; see the RFC itself for
full legal notices."
This document and translations of it may be copied and furnished to REVISION "200410051500Z" -- October 5, 2004
others, and derivative works that comment on or otherwise explain it DESCRIPTION
or assist in its implementation may be prepared, copied, published "This version updates the proposed-standard version of the
and distributed, in whole or in part, without restriction of any RMON2 MIB (published as RFC 2021) by adding 2 new enumerations
kind, provided that the above copyright notice and this paragraph are to the nlMatrixTopNControlRateBase object and 4 new
included on all such copies and derivative works. However, this enumerations to the alMatrixTopNControlRateBase object. These
document itself may not be modified in any way, such as by removing new enumerations support the creation of high capacity topN
the copyright notice or references to the Internet Society or other reports in the High Capacity RMON MIB [RFC3273].
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 Additionally, the following object have been deprecated as
revoked by the Internet Society or its successors or assigns. they have not had enough independent implementations to
demonstrate interoperability to meet the requirements of a
Draft Standard:
This document and the information contained herein is provided on an probeDownloadFile
'AS IS' basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING probeDownloadTFTPServer
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING probeDownloadAction
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION probeDownloadStatus
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF serialMode
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." serialProtocol
serialTimeout
serialModemInitString
serialModemHangUpString
serialModemConnectResp
serialModemNoConnectResp
serialDialoutTimeout
serialStatus
serialConnectDestIpAddress
serialConnectType
serialConnectDialString
serialConnectSwitchConnectSeq
serialConnectSwitchDisconnectSeq
serialConnectSwitchResetSeq
serialConnectOwner
serialConnectStatus
netConfigIPAddress
netConfigSubnetMask
netConfigStatus
netDefaultGateway
tokenRingMLStats2DroppedFrames
tokenRingMLStats2CreateTime
tokenRingPStats2DroppedFrames
tokenRingPStats2CreateTime
ringStationControl2DroppedFrames
ringStationControl2CreateTime
sourceRoutingStats2DroppedFrames
sourceRoutingStats2CreateTime
REVISION "200402141500Z" -- February 14, 2004 In addition, two corrections were made. The LastCreateTime
DESCRIPTION Textual Convention had been defined with a base type of
"Added new enumerations to the nlMatrixTopNControlRateBase and another textual convention which isn't allowed in SMIv2. The
alMatrixTopNControlRateBase objects, deprecated a number of definition has been modified to use TimeTicks as the base
infrequently implemented objects and various bug fixes and type.
typos."
REVISION "200110231500Z" -- 23 October, 2001 Further, the SerialConfigEntry SEQUENCE definition included
sub-typing information that is not allowed in SMIv2. This
information has been deleted. Ranges were added to a number of
objects and textual-conventions to constrain their maximum
(and sometimes minimum) sizes:
ControlString
protocolDirID
protocolDirParameters
addressMapNetworkAddress
nlHostAddress
nlMatrixSDSourceAddress
nlMatrixSDDestAddress
nlMatrixDSSourceAddress
nlMatrixDSDestAddress
nlMatrixTopNSourceAddress
nlMatrixTopNDestAddress
alHostEntry
alMatrixSDEntry
alMatrixDSEntry
alMatrixTopNSourceAddress
alMatrixTopNDestAddress
"
REVISION "200207080000Z" -- 08 July, 2002
DESCRIPTION DESCRIPTION
"Added new enumerations to support the High-Capacity RMON "Added new enumerations to support the High-Capacity RMON
MIB as defined in RFC 3273. Also fixed some typos and add MIB as defined in RFC 3273. Also fixed some typos and add
clarifications." clarifications."
REVISION "199605270000Z" -- 27 May, 1996 REVISION "199605270000Z" -- 27 May, 1996
DESCRIPTION DESCRIPTION
"Original version. Published as RFC 2021." "Original version. Published as RFC 2021."
::= { mib-2 16 } ::= { mib-2 16 }
-- { rmon 1 } through { rmon 10 } are defined in RMON and -- { rmon 1 } through { rmon 10 } are defined in RMON and
-- the Token Ring RMON MIB [RFC 1513]
protocolDir OBJECT IDENTIFIER ::= { rmon 11 } protocolDir OBJECT IDENTIFIER ::= { rmon 11 }
protocolDist OBJECT IDENTIFIER ::= { rmon 12 } protocolDist OBJECT IDENTIFIER ::= { rmon 12 }
addressMap OBJECT IDENTIFIER ::= { rmon 13 } addressMap OBJECT IDENTIFIER ::= { rmon 13 }
nlHost OBJECT IDENTIFIER ::= { rmon 14 } nlHost OBJECT IDENTIFIER ::= { rmon 14 }
nlMatrix OBJECT IDENTIFIER ::= { rmon 15 } nlMatrix OBJECT IDENTIFIER ::= { rmon 15 }
alHost OBJECT IDENTIFIER ::= { rmon 16 } alHost OBJECT IDENTIFIER ::= { rmon 16 }
alMatrix OBJECT IDENTIFIER ::= { rmon 17 } alMatrix OBJECT IDENTIFIER ::= { rmon 17 }
usrHistory OBJECT IDENTIFIER ::= { rmon 18 } usrHistory OBJECT IDENTIFIER ::= { rmon 18 }
probeConfig OBJECT IDENTIFIER ::= { rmon 19 } probeConfig OBJECT IDENTIFIER ::= { rmon 19 }
skipping to change at page 19, line 32 skipping to change at page 20, line 32
DataSource ::= TEXTUAL-CONVENTION DataSource ::= TEXTUAL-CONVENTION
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Identifies the source of the data that the associated "Identifies the source of the data that the associated
function is configured to analyze. This source can be any function is configured to analyze. This source can be any
interface on this device. interface on this device.
In order to identify a particular interface, this In order to identify a particular interface, this
object shall identify the instance of the ifIndex object shall identify the instance of the ifIndex
object, defined in [10], for the desired interface. object, defined in [RFC2863], for the desired interface.
For example, if an entry were to receive data from For example, if an entry were to receive data from
interface #1, this object would be set to ifIndex.1." interface #1, this object would be set to ifIndex.1."
SYNTAX OBJECT IDENTIFIER SYNTAX OBJECT IDENTIFIER
-- --
-- Protocol Directory Group -- Protocol Directory Group
-- --
-- Lists the inventory of protocols the probe has the capability of -- Lists the inventory of protocols the probe has the capability of
-- monitoring and allows the addition, deletion, and configuration of -- monitoring and allows the addition, deletion, and configuration of
skipping to change at page 38, line 18 skipping to change at page 39, line 18
addressMapSource OBJECT-TYPE addressMapSource OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER SYNTAX OBJECT IDENTIFIER
MAX-ACCESS not-accessible MAX-ACCESS not-accessible
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The interface or port on which the associated network "The interface or port on which the associated network
address was most recently seen. address was most recently seen.
If this address mapping was discovered on an interface, this If this address mapping was discovered on an interface, this
object shall identify the instance of the ifIndex object shall identify the instance of the ifIndex
object, defined in [10], for the desired interface. object, defined in [RFC2863], for the desired interface.
For example, if an entry were to receive data from For example, if an entry were to receive data from
interface #1, this object would be set to ifIndex.1. interface #1, this object would be set to ifIndex.1.
If this address mapping was discovered on a port, this If this address mapping was discovered on a port, this
object shall identify the instance of the rptrGroupPortIndex object shall identify the instance of the rptrGroupPortIndex
object, defined in [12], for the desired port. object, defined in [RFC2108], for the desired port.
For example, if an entry were to receive data from For example, if an entry were to receive data from
group #1, port #1, this object would be set to group #1, port #1, this object would be set to
rptrGroupPortIndex.1.1. rptrGroupPortIndex.1.1.
Note that while the dataSource associated with this entry Note that while the dataSource associated with this entry
may only point to index objects, this object may at times may only point to index objects, this object may at times
point to repeater port objects. This situation occurs when point to repeater port objects. This situation occurs when
the dataSource points to an interface which is a locally the dataSource points to an interface which is a locally
attached repeater and the agent has additional information attached repeater and the agent has additional information
about the source port of traffic seen on that repeater." about the source port of traffic seen on that repeater."
skipping to change at page 105, line 46 skipping to change at page 106, line 46
-- implementation is not required to download those non-RMON functions -- implementation is not required to download those non-RMON functions
-- with this mechanism. -- with this mechanism.
probeDownloadFile OBJECT-TYPE probeDownloadFile OBJECT-TYPE
SYNTAX DisplayString (SIZE(0..127)) SYNTAX DisplayString (SIZE(0..127))
MAX-ACCESS read-write MAX-ACCESS read-write
STATUS deprecated STATUS deprecated
DESCRIPTION DESCRIPTION
"The file name to be downloaded from the TFTP server when a "The file name to be downloaded from the TFTP server when a
download is next requested via this MIB. This value is set to download is next requested via this MIB. This value is set to
the zero length string when no file name has been specified." the zero length string when no file name has been specified.
This object has been deprecated as it has not had enough
independent implementations to demonstrate interoperability to
meet the requirements of a Draft Standard."
::= { probeConfig 6 } ::= { probeConfig 6 }
probeDownloadTFTPServer OBJECT-TYPE probeDownloadTFTPServer OBJECT-TYPE
SYNTAX IpAddress SYNTAX IpAddress
MAX-ACCESS read-write MAX-ACCESS read-write
STATUS deprecated STATUS deprecated
DESCRIPTION DESCRIPTION
"The IP address of the TFTP server that contains the boot "The IP address of the TFTP server that contains the boot
image to load when a download is next requested via this MIB. image to load when a download is next requested via this MIB.
This value is set to `0.0.0.0' when no IP address has been This value is set to `0.0.0.0' when no IP address has been
specified." specified.
This object has been deprecated as it has not had enough
independent implementations to demonstrate interoperability to
meet the requirements of a Draft Standard."
::= { probeConfig 7 } ::= { probeConfig 7 }
probeDownloadAction OBJECT-TYPE probeDownloadAction OBJECT-TYPE
SYNTAX INTEGER { SYNTAX INTEGER {
notDownloading(1), notDownloading(1),
downloadToPROM(2), downloadToPROM(2),
downloadToRAM(3) downloadToRAM(3)
} }
MAX-ACCESS read-write MAX-ACCESS read-write
STATUS deprecated STATUS deprecated
skipping to change at page 106, line 36 skipping to change at page 107, line 44
by probeDownloadFile from the server specified by by probeDownloadFile from the server specified by
probeDownloadTFTPServer using the TFTP protocol. If probeDownloadTFTPServer using the TFTP protocol. If
downloadToRAM(3) is specified, the new image is copied downloadToRAM(3) is specified, the new image is copied
to RAM only (the old image remains unaltered in the flash to RAM only (the old image remains unaltered in the flash
EPROM). If downloadToPROM(2) is specified EPROM). If downloadToPROM(2) is specified
the new image is written to the flash EPROM the new image is written to the flash EPROM
memory after its checksum has been verified to be correct. memory after its checksum has been verified to be correct.
When the download process is completed, the device will When the download process is completed, the device will
warm boot to restart the newly loaded application. warm boot to restart the newly loaded application.
When the device is not downloading, this object will have When the device is not downloading, this object will have
a value of notDownloading(1)." a value of notDownloading(1).
This object has been deprecated as it has not had enough
independent implementations to demonstrate interoperability to
meet the requirements of a Draft Standard."
::= { probeConfig 8 } ::= { probeConfig 8 }
probeDownloadStatus OBJECT-TYPE probeDownloadStatus OBJECT-TYPE
SYNTAX INTEGER { SYNTAX INTEGER {
downloadSuccess(1), downloadSuccess(1),
downloadStatusUnknown(2), downloadStatusUnknown(2),
downloadGeneralError(3), downloadGeneralError(3),
downloadNoResponseFromServer(4), downloadNoResponseFromServer(4),
downloadChecksumError(5), downloadChecksumError(5),
downloadIncompatibleImage(6), downloadIncompatibleImage(6),
downloadTftpFileNotFound(7), downloadTftpFileNotFound(7),
downloadTftpAccessViolation(8) downloadTftpAccessViolation(8)
} }
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS deprecated STATUS deprecated
DESCRIPTION DESCRIPTION
"The status of the last download procedure, if any. This "The status of the last download procedure, if any. This
object will have a value of downloadStatusUnknown(2) if no object will have a value of downloadStatusUnknown(2) if no
download process has been performed." download process has been performed.
This object has been deprecated as it has not had enough
independent implementations to demonstrate interoperability to
meet the requirements of a Draft Standard."
::= { probeConfig 9 } ::= { probeConfig 9 }
serialConfigTable OBJECT-TYPE serialConfigTable OBJECT-TYPE
SYNTAX SEQUENCE OF SerialConfigEntry SYNTAX SEQUENCE OF SerialConfigEntry
MAX-ACCESS not-accessible MAX-ACCESS not-accessible
STATUS deprecated STATUS deprecated
DESCRIPTION DESCRIPTION
"A table of serial interface configuration entries. This data "A table of serial interface configuration entries. This data
will be stored in non-volatile memory and preserved across will be stored in non-volatile memory and preserved across
probe resets or power loss." probe resets or power loss.
This table has been deprecated as it has not had enough
independent implementations to demonstrate interoperability to
meet the requirements of a Draft Standard."
::= { probeConfig 10 } ::= { probeConfig 10 }
serialConfigEntry OBJECT-TYPE serialConfigEntry OBJECT-TYPE
SYNTAX SerialConfigEntry SYNTAX SerialConfigEntry
MAX-ACCESS not-accessible MAX-ACCESS not-accessible
STATUS deprecated STATUS deprecated
DESCRIPTION DESCRIPTION
"A set of configuration parameters for a particular "A set of configuration parameters for a particular
serial interface on this device. If the device has no serial serial interface on this device. If the device has no serial
interfaces, this table is empty. interfaces, this table is empty.
skipping to change at page 111, line 14 skipping to change at page 112, line 34
An entry may not exist in the active state unless all An entry may not exist in the active state unless all
objects in the entry have an appropriate value." objects in the entry have an appropriate value."
::= { serialConfigEntry 9 } ::= { serialConfigEntry 9 }
netConfigTable OBJECT-TYPE netConfigTable OBJECT-TYPE
SYNTAX SEQUENCE OF NetConfigEntry SYNTAX SEQUENCE OF NetConfigEntry
MAX-ACCESS not-accessible MAX-ACCESS not-accessible
STATUS deprecated STATUS deprecated
DESCRIPTION DESCRIPTION
"A table of netConfigEntries." "A table of netConfigEntries.
This table has been deprecated as it has not had enough
independent implementations to demonstrate interoperability to
meet the requirements of a Draft Standard."
::= { probeConfig 11 } ::= { probeConfig 11 }
netConfigEntry OBJECT-TYPE netConfigEntry OBJECT-TYPE
SYNTAX NetConfigEntry SYNTAX NetConfigEntry
MAX-ACCESS not-accessible MAX-ACCESS not-accessible
STATUS deprecated STATUS deprecated
DESCRIPTION DESCRIPTION
"A set of configuration parameters for a particular "A set of configuration parameters for a particular
network interface on this device. If the device has no network network interface on this device. If the device has no network
interface, this table is empty. interface, this table is empty.
skipping to change at page 114, line 43 skipping to change at page 116, line 21
trapDestAddress OBJECT-TYPE trapDestAddress OBJECT-TYPE
SYNTAX OCTET STRING SYNTAX OCTET STRING
MAX-ACCESS read-create MAX-ACCESS read-create
STATUS deprecated STATUS deprecated
DESCRIPTION DESCRIPTION
"The address to send traps on behalf of this entry. "The address to send traps on behalf of this entry.
If the associated trapDestProtocol object is equal to ip(1), If the associated trapDestProtocol object is equal to ip(1),
the encoding of this object is the same as the snmpUDPAddress the encoding of this object is the same as the snmpUDPAddress
textual convention in [3]: textual convention in [RFC1906]:
-- for a SnmpUDPAddress of length 6: -- for a SnmpUDPAddress of length 6:
-- --
-- octets contents encoding -- octets contents encoding
-- 1-4 IP-address network-byte order -- 1-4 IP-address network-byte order
-- 5-6 UDP-port network-byte order -- 5-6 UDP-port network-byte order
If the associated trapDestProtocol object is equal to ipx(2), If the associated trapDestProtocol object is equal to ipx(2),
the encoding of this object is the same as the snmpIPXAddress the encoding of this object is the same as the snmpIPXAddress
textual convention in [3]: textual convention in [RFC1906]:
-- for a SnmpIPXAddress of length 12: -- for a SnmpIPXAddress of length 12:
-- --
-- octets contents encoding -- octets contents encoding
-- 1-4 network-number network-byte order -- 1-4 network-number network-byte order
-- 5-10 physical-address network-byte order -- 5-10 physical-address network-byte order
-- 11-12 socket-number network-byte order -- 11-12 socket-number network-byte order
This object may not be modified if the associated This object may not be modified if the associated
trapDestStatus object is equal to active(1)." trapDestStatus object is equal to active(1)."
::= { trapDestEntry 4 } ::= { trapDestEntry 4 }
skipping to change at page 116, line 6 skipping to change at page 117, line 30
-- SLIP. In order for the device to send traps via SLIP, it must -- SLIP. In order for the device to send traps via SLIP, it must
-- be able to initiate a connection over the serial interface. The -- be able to initiate a connection over the serial interface. The
-- serialConnectionTable stores the parameters for such connection -- serialConnectionTable stores the parameters for such connection
-- initiation. -- initiation.
serialConnectionTable OBJECT-TYPE serialConnectionTable OBJECT-TYPE
SYNTAX SEQUENCE OF SerialConnectionEntry SYNTAX SEQUENCE OF SerialConnectionEntry
MAX-ACCESS not-accessible MAX-ACCESS not-accessible
STATUS deprecated STATUS deprecated
DESCRIPTION DESCRIPTION
"A list of serialConnectionEntries." "A list of serialConnectionEntries.
This table has been deprecated as it has not had enough
independent implementations to demonstrate interoperability to
meet the requirements of a Draft Standard."
::= { probeConfig 14 } ::= { probeConfig 14 }
serialConnectionEntry OBJECT-TYPE serialConnectionEntry OBJECT-TYPE
SYNTAX SerialConnectionEntry SYNTAX SerialConnectionEntry
MAX-ACCESS not-accessible MAX-ACCESS not-accessible
STATUS deprecated STATUS deprecated
DESCRIPTION DESCRIPTION
"Configuration for a SLIP link over a serial line." "Configuration for a SLIP link over a serial line."
INDEX { serialConnectIndex } INDEX { serialConnectIndex }
::= { serialConnectionTable 1 } ::= { serialConnectionTable 1 }
skipping to change at page 125, line 21 skipping to change at page 127, line 4
activated. This can be used by the management station to activated. This can be used by the management station to
ensure that the table has not been deleted and recreated ensure that the table has not been deleted and recreated
between polls." between polls."
::= { channel2Entry 2 } ::= { channel2Entry 2 }
tokenRingMLStats2Table OBJECT-TYPE tokenRingMLStats2Table OBJECT-TYPE
SYNTAX SEQUENCE OF TokenRingMLStats2Entry SYNTAX SEQUENCE OF TokenRingMLStats2Entry
MAX-ACCESS not-accessible MAX-ACCESS not-accessible
STATUS deprecated STATUS deprecated
DESCRIPTION DESCRIPTION
"Contains the RMON-2 augmentations to RMON-1." "Contains the RMON-2 augmentations to RMON-1.
This table has been deprecated as it has not had enough
independent implementations to demonstrate interoperability to
meet the requirements of a Draft Standard."
::= { statistics 5 } ::= { statistics 5 }
tokenRingMLStats2Entry OBJECT-TYPE tokenRingMLStats2Entry OBJECT-TYPE
SYNTAX TokenRingMLStats2Entry SYNTAX TokenRingMLStats2Entry
MAX-ACCESS not-accessible MAX-ACCESS not-accessible
STATUS deprecated STATUS deprecated
DESCRIPTION DESCRIPTION
"Contains the RMON-2 augmentations to RMON-1." "Contains the RMON-2 augmentations to RMON-1."
AUGMENTS { tokenRingMLStatsEntry } AUGMENTS { tokenRingMLStatsEntry }
::= { tokenRingMLStats2Table 1 } ::= { tokenRingMLStats2Table 1 }
skipping to change at page 126, line 27 skipping to change at page 128, line 14
"The value of sysUpTime when this control entry was last activated. "The value of sysUpTime when this control entry was last activated.
This can be used by the management station to ensure that the This can be used by the management station to ensure that the
table has not been deleted and recreated between polls." table has not been deleted and recreated between polls."
::= { tokenRingMLStats2Entry 2 } ::= { tokenRingMLStats2Entry 2 }
tokenRingPStats2Table OBJECT-TYPE tokenRingPStats2Table OBJECT-TYPE
SYNTAX SEQUENCE OF TokenRingPStats2Entry SYNTAX SEQUENCE OF TokenRingPStats2Entry
MAX-ACCESS not-accessible MAX-ACCESS not-accessible
STATUS deprecated STATUS deprecated
DESCRIPTION DESCRIPTION
"Contains the RMON-2 augmentations to RMON-1." "Contains the RMON-2 augmentations to RMON-1.
This table has been deprecated as it has not had enough
independent implementations to demonstrate interoperability to
meet the requirements of a Draft Standard."
::= { statistics 6 } ::= { statistics 6 }
tokenRingPStats2Entry OBJECT-TYPE tokenRingPStats2Entry OBJECT-TYPE
SYNTAX TokenRingPStats2Entry SYNTAX TokenRingPStats2Entry
MAX-ACCESS not-accessible MAX-ACCESS not-accessible
STATUS deprecated STATUS deprecated
DESCRIPTION DESCRIPTION
"Contains the RMON-2 augmentations to RMON-1." "Contains the RMON-2 augmentations to RMON-1."
AUGMENTS { tokenRingPStatsEntry } AUGMENTS { tokenRingPStatsEntry }
::= { tokenRingPStats2Table 1 } ::= { tokenRingPStats2Table 1 }
skipping to change at page 127, line 32 skipping to change at page 129, line 24
"The value of sysUpTime when this control entry was last activated. "The value of sysUpTime when this control entry was last activated.
This can be used by the management station to ensure that the This can be used by the management station to ensure that the
table has not been deleted and recreated between polls." table has not been deleted and recreated between polls."
::= { tokenRingPStats2Entry 2 } ::= { tokenRingPStats2Entry 2 }
ringStationControl2Table OBJECT-TYPE ringStationControl2Table OBJECT-TYPE
SYNTAX SEQUENCE OF RingStationControl2Entry SYNTAX SEQUENCE OF RingStationControl2Entry
MAX-ACCESS not-accessible MAX-ACCESS not-accessible
STATUS deprecated STATUS deprecated
DESCRIPTION DESCRIPTION
"Contains the RMON-2 augmentations to RMON-1." "Contains the RMON-2 augmentations to RMON-1.
This table has been deprecated as it has not had enough
independent implementations to demonstrate interoperability to
meet the requirements of a Draft Standard."
::= { tokenRing 7 } ::= { tokenRing 7 }
ringStationControl2Entry OBJECT-TYPE ringStationControl2Entry OBJECT-TYPE
SYNTAX RingStationControl2Entry SYNTAX RingStationControl2Entry
MAX-ACCESS not-accessible MAX-ACCESS not-accessible
STATUS deprecated STATUS deprecated
DESCRIPTION DESCRIPTION
"Contains the RMON-2 augmentations to RMON-1." "Contains the RMON-2 augmentations to RMON-1."
AUGMENTS { ringStationControlEntry } AUGMENTS { ringStationControlEntry }
::= { ringStationControl2Table 1 } ::= { ringStationControl2Table 1 }
skipping to change at page 128, line 39 skipping to change at page 130, line 33
"The value of sysUpTime when this control entry was last activated. "The value of sysUpTime when this control entry was last activated.
This can be used by the management station to ensure that the This can be used by the management station to ensure that the
table has not been deleted and recreated between polls." table has not been deleted and recreated between polls."
::= { ringStationControl2Entry 2 } ::= { ringStationControl2Entry 2 }
sourceRoutingStats2Table OBJECT-TYPE sourceRoutingStats2Table OBJECT-TYPE
SYNTAX SEQUENCE OF SourceRoutingStats2Entry SYNTAX SEQUENCE OF SourceRoutingStats2Entry
MAX-ACCESS not-accessible MAX-ACCESS not-accessible
STATUS deprecated STATUS deprecated
DESCRIPTION DESCRIPTION
"Contains the RMON-2 augmentations to RMON-1." "Contains the RMON-2 augmentations to RMON-1.
This table has been deprecated as it has not had enough
independent implementations to demonstrate interoperability to
meet the requirements of a Draft Standard."
::= { tokenRing 8 } ::= { tokenRing 8 }
sourceRoutingStats2Entry OBJECT-TYPE sourceRoutingStats2Entry OBJECT-TYPE
SYNTAX SourceRoutingStats2Entry SYNTAX SourceRoutingStats2Entry
MAX-ACCESS not-accessible MAX-ACCESS not-accessible
STATUS deprecated STATUS deprecated
DESCRIPTION DESCRIPTION
"Contains the RMON-2 augmentations to RMON-1." "Contains the RMON-2 augmentations to RMON-1."
AUGMENTS { sourceRoutingStatsEntry } AUGMENTS { sourceRoutingStatsEntry }
::= { sourceRoutingStats2Table 1 } ::= { sourceRoutingStats2Table 1 }
skipping to change at page 131, line 37 skipping to change at page 133, line 37
SYNTAX INTEGER { SYNTAX INTEGER {
nlMatrixTopNPkts(1), nlMatrixTopNPkts(1),
nlMatrixTopNOctets(2) nlMatrixTopNOctets(2)
} }
DESCRIPTION DESCRIPTION
"Conformance to RMON2 requires only support for these "Conformance to RMON2 requires only support for these
values of nlMatrixTopNControlRateBase." values of nlMatrixTopNControlRateBase."
GROUP rmon1EnhancementGroup GROUP rmon1EnhancementGroup
DESCRIPTION DESCRIPTION
"The rmon1EnhancementGroup is mandatory for systems which "The rmon1EnhancementGroup is mandatory for systems
implement RMON [5]" which implement RMON [RFC2819]"
GROUP rmon1EthernetEnhancementGroup
DESCRIPTION
"The rmon1EthernetEnhancementGroup is optional and is
appropriate for systems that implement the Ethernet
group of RMON [RFC2819]"
::= { rmon2MIBCompliances 1 } ::= { rmon2MIBCompliances 1 }
rmon2MIBApplicationLayerCompliance MODULE-COMPLIANCE rmon2MIBApplicationLayerCompliance MODULE-COMPLIANCE
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Describes the requirements for conformance to "Describes the requirements for conformance to
the RMON2 MIB with Application Layer Enhancements." the RMON2 MIB with Application Layer Enhancements."
MODULE -- this module MODULE -- this module
MANDATORY-GROUPS { protocolDirectoryGroup, MANDATORY-GROUPS { protocolDirectoryGroup,
protocolDistributionGroup, protocolDistributionGroup,
skipping to change at page 132, line 35 skipping to change at page 134, line 40
alMatrixTopNTerminalsOctets(2), alMatrixTopNTerminalsOctets(2),
alMatrixTopNAllPkts(3), alMatrixTopNAllPkts(3),
alMatrixTopNAllOctets(4) alMatrixTopNAllOctets(4)
} }
DESCRIPTION DESCRIPTION
"Conformance to RMON2 requires only support for these "Conformance to RMON2 requires only support for these
values of alMatrixTopNControlRateBase." values of alMatrixTopNControlRateBase."
GROUP rmon1EnhancementGroup GROUP rmon1EnhancementGroup
DESCRIPTION DESCRIPTION
"The rmon1EnhancementGroup is mandatory for systems which "The rmon1EnhancementGroup is mandatory for systems
implement RMON [5]" which implement RMON [RFC2819]"
GROUP rmon1EthernetEnhancementGroup
DESCRIPTION
"The rmon1EthernetEnhancementGroup is optional and is
appropriate for systems that implement the Ethernet
group of RMON [RFC2819]"
::= { rmon2MIBCompliances 2 } ::= { rmon2MIBCompliances 2 }
protocolDirectoryGroup OBJECT-GROUP protocolDirectoryGroup OBJECT-GROUP
OBJECTS { protocolDirLastChange, OBJECTS { protocolDirLastChange,
protocolDirLocalIndex, protocolDirDescr, protocolDirLocalIndex, protocolDirDescr,
protocolDirType, protocolDirAddressMapConfig, protocolDirType, protocolDirAddressMapConfig,
protocolDirHostConfig, protocolDirMatrixConfig, protocolDirHostConfig, protocolDirMatrixConfig,
protocolDirOwner, protocolDirStatus } protocolDirOwner, protocolDirStatus }
STATUS current STATUS current
DESCRIPTION DESCRIPTION
skipping to change at page 138, line 5 skipping to change at page 140, line 5
ringStationControlCreateTime, ringStationControlCreateTime,
sourceRoutingStatsDroppedFrames, sourceRoutingStatsDroppedFrames,
sourceRoutingStatsCreateTime } sourceRoutingStatsCreateTime }
STATUS deprecated STATUS deprecated
DESCRIPTION DESCRIPTION
"This group adds some enhancements to RMON-1 that help "This group adds some enhancements to RMON-1 that help
management stations." management stations."
::= { rmon2MIBGroups 13 } ::= { rmon2MIBGroups 13 }
END END
10. Security Considerations 7. Security Considerations
In order to implement this MIB, a probe must capture all In order to implement this MIB, a probe must capture all
packets on the locally-attached network, including packets packets on the locally-attached network, including packets
between third parties. These packets are analyzed to collect between third parties. These packets are analyzed to collect
network addresses, protocol usage information, and network addresses, protocol usage information, and
conversation statistics. Data of this nature may be considered conversation statistics. Data of this nature may be considered
sensitive in some environments. In such environments the sensitive in some environments. In such environments the
administrator may wish to restrict SNMP access to the probe. administrator may wish to restrict SNMP access to the probe.
The usrHistoryGroup periodically samples the values of user- The usrHistoryGroup periodically samples the values of user-
skipping to change at page 138, line 30 skipping to change at page 140, line 30
is not writable in MIB views that don't already have read is not writable in MIB views that don't already have read
access to the entire agent. Because the access control access to the entire agent. Because the access control
configuration can change over time, information could later be configuration can change over time, information could later be
deemed sensitive that would still be accessible to this deemed sensitive that would still be accessible to this
function. For this reason, an agent SHOULD check the access function. For this reason, an agent SHOULD check the access
control on every sample. If an agent doesn't implement the control on every sample. If an agent doesn't implement the
latter check, there is a potential for sensitive information latter check, there is a potential for sensitive information
to be revealed. to be revealed.
A probe implementing this MIB is likely to also implement RMON A probe implementing this MIB is likely to also implement RMON
[5], which includes functions for returning the contents of [RFC2819], which includes functions for returning the contents
captured packets, potentially including sensitive user data or of captured packets, potentially including sensitive user data
passwords. It is recommended that SNMP access to these or passwords. It is recommended that SNMP access to these
functions be restricted. functions be restricted.
There are a number of management objects defined in this MIB There are a number of management objects defined in this MIB
that have a MAX-ACCESS clause of read-write and/or read- that have a MAX-ACCESS clause of read-write and/or read-
create. Such objects may be considered sensitive or create. Such objects may be considered sensitive or
vulnerable in some network environments. The support for SET vulnerable in some network environments. The support for SET
operations in a non-secure environment without proper operations in a non-secure environment without proper
protection can have a negative effect on network operations. protection can have a negative effect on network operations.
SNMPv1 by itself is not a secure environment. Even if the SNMPv1 by itself is not a secure environment. Even if the
network itself is secure (for example by using IPSec), even network itself is secure (for example by using IPSec), even
then, there is no control as to who on the secure network is then, there is no control as to who on the secure network is
allowed to access and GET/SET (read/change/create/delete) the allowed to access and GET/SET (read/change/create/delete) the
objects in this MIB. objects in this MIB.
It is recommended that the implementors consider the security It is recommended that the implementors consider the security
features as provided by the SNMPv3 framework. Specifically, features as provided by the SNMPv3 framework. Specifically,
the use of the User-based Security Model RFC 2574 [13] and the the use of the User-based Security Model RFC 2574 [RFC3414]
View-based Access Control Model RFC 2575 [14] is recommended. and the View-based Access Control Model RFC 2575 [RFC3415] is
recommended.
It is then a customer/user responsibility to ensure that the It is then a customer/user responsibility to ensure that the
SNMP entity giving access to an instance of this MIB, is SNMP entity giving access to an instance of this MIB, is
properly configured to give access to the objects only to properly configured to give access to the objects only to
those principals (users) that have legitimate rights to indeed those principals (users) that have legitimate rights to indeed
GET or SET (change/create/delete) them. GET or SET (change/create/delete) them.
11. Appendix - TimeFilter Implementation Notes 8. Appendix - TimeFilter Implementation Notes
1) Theory of Operation 1) Theory of Operation
The TimeFilter mechanism allows an NMS to reduce the number of The TimeFilter mechanism allows an NMS to reduce the number of
SNMP transactions required for a 'table-update' operation. SNMP transactions required for a 'table-update' operation.
Polling of tables that incorporate a 'TimeFilter' INDEX can be Polling of tables that incorporate a 'TimeFilter' INDEX can be
reduced to a theoretical minimum (if used correctly). It can reduced to a theoretical minimum (if used correctly). It can
be easily implemented by an agent in a way independent of the be easily implemented by an agent in a way independent of the
number of NMS applications using the same time-filtered table. number of NMS applications using the same time-filtered table.
skipping to change at page 143, line 15 skipping to change at page 145, line 15
2.1) General Assumptions 2.1) General Assumptions
fooEntry INDEX { fooTimeMark, fooIfIndex } fooEntry INDEX { fooTimeMark, fooIfIndex }
FooEntry = SEQUENCE { FooEntry = SEQUENCE {
fooTimeMark TimeFilter, fooTimeMark TimeFilter,
fooIfIndex Integer32, fooIfIndex Integer32,
fooCounts Counter32 fooCounts Counter32
} }
The NMS polls the fooTable every 15 seconds and the The NMS polls the fooTable every 15 seconds and the
baseline baseline poll occurs when the agent has been up for
poll occurs when the agent has been up for 6 seconds, 6 seconds, and the NMS has been up for 10 seconds.
and the NMS has been up for 10 seconds.
There are 2 static rows in this table at system There are 2 static rows in this table at system
initialization initialization (fooCounts.0.1 and fooCounts.0.2).
(fooCounts.0.1 and fooCounts.0.2).
Row 1 was updated as follows: Row 1 was updated as follows:
SysUpTime fooCounts.*.1 value 500 SysUpTime fooCounts.*.1 value
1 900 2 500 1
900 2
2300 3 2300 3
Row 2 was updated as follows: Row 2 was updated as follows:
SysUpTime fooCounts.*.2 value SysUpTime fooCounts.*.2 value
1100 1 1100 1
1400 2 1400 2
2.2) SNMP Transactions from NMS Perspective 2.2) SNMP Transactions from NMS Perspective
Time nms-1000: Time nms-1000:
# NMS baseline poll -- get everything since last agent # NMS baseline poll -- get everything since last agent
restart # restart - TimeFilter == 0
# TimeFilter == 0
get-bulk(nonRptrs=1, maxReps=2, sysUpTime.0, get-bulk(nonRptrs=1, maxReps=2, sysUpTime.0,
fooCounts.0); fooCounts.0);
returns: returns:
sysUpTime.0 == 600 sysUpTime.0 == 600
fooCounts.0.1 == 1 # incremented at time 500 fooCounts.0.1 == 1 # incremented at time 500
fooCounts.0.2 == 0 # visible since created at time 0 fooCounts.0.2 == 0 # visible since created at time
0
Time nms-2500: Time nms-2500:
# NMS 1st poll # NMS 1st poll
# TimeFilter index == 600 # TimeFilter index == 600
get-bulk(nonRptrs=1, maxReps=2, sysUpTime.0, get-bulk(nonRptrs=1, maxReps=2, sysUpTime.0,
fooCounts.600); fooCounts.600);
returns: returns:
sysUpTime.0 == 2100 sysUpTime.0 == 2100
fooCounts.600.1 == 2 # incremented at time 900 fooCounts.600.1 == 2 # incremented at time 900
fooCounts.600.2 == 2 # incremented at times 1100 and fooCounts.600.2 == 2 # incremented at times
1400 # 1100 and 1400
fooCounts.601.1 == 2 # indicates end of sweep fooCounts.601.1 == 2 # indicates end of sweep
Time nms-4000: Time nms-4000:
# NMS 2nd poll # NMS 2nd poll
# TimeFilter == 2100 # TimeFilter == 2100
get-bulk(nonRptrs=1, maxReps=2, sysUpTime.0, get-bulk(nonRptrs=1, maxReps=2, sysUpTime.0,
fooCounts.2100); fooCounts.2100);
returns: returns:
sysUpTime.0 == 3600 sysUpTime.0 == 3600
skipping to change at page 144, line 42 skipping to change at page 146, line 40
# TimeFilter == 3600 # TimeFilter == 3600
get-bulk(nonRptrs=1, maxReps=2, sysUpTime.0, get-bulk(nonRptrs=1, maxReps=2, sysUpTime.0,
fooCounts.3600); fooCounts.3600);
returns: returns:
sysUpTime.0 == 5100 sysUpTime.0 == 5100
some-instance-outside-the-fooTable == <don't care> some-instance-outside-the-fooTable == <don't care>
some-instance-outside-the-fooTable == <don't care> some-instance-outside-the-fooTable == <don't care>
# no 'fooTable' counter values at all are returned # no 'fooTable' counter values at all are returned
because # because neither counter has been updated since
# neither counter has been updated since sysUpTime == # sysUpTime == 3600
3600
2.3) Transactions and TimeFilter Maintenance: Agent 2.3) Transactions and TimeFilter Maintenance: Agent
Perspective Perspective
Time agt-0: Time agt-0:
# initialize fooTable # initialize fooTable
fooCounts.1 = 0; changed.1 = 0; fooCounts.1 = 0; changed.1 = 0;
fooCounts.2 = 0; changed.2 = 0; fooCounts.2 = 0; changed.2 = 0;
Time agt-500: Time agt-500:
# increment fooCounts.1 # increment fooCounts.1
++fooCounts.1; changed.1 = 500; ++fooCounts.1; changed.1 = 500;
Time agt-600 Time agt-600
skipping to change at page 146, line 4 skipping to change at page 147, line 47
Time agt-2300: Time agt-2300:
# increment fooCounts.1 # increment fooCounts.1
++fooCounts.1; changed.1 = 2300; ++fooCounts.1; changed.1 = 2300;
Time agt-3600: Time agt-3600:
# answer get-bulk # answer get-bulk
# get-bulk(nonRptrs=1, maxReps=2, sysUpTime.0, # get-bulk(nonRptrs=1, maxReps=2, sysUpTime.0,
# fooCounts.2100); # fooCounts.2100);
# (changed >= 2100) # (changed >= 2100)
# return only fooCounts.1 from the fooTable--twice # return only fooCounts.1 from the fooTable--twice
Time agt-5100: Time agt-5100:
# answer get-bulk # answer get-bulk
# get-bulk(nonRptrs=1, maxReps=2, sysUpTime.0, # get-bulk(nonRptrs=1, maxReps=2, sysUpTime.0,
# fooCounts.3600); # fooCounts.3600);
# (changed >= 3600) # (changed >= 3600)
# return lexigraphically-next two MIB instances # return lexigraphically-next two MIB instances
12. Changes since RFC 2021 9. Changes since RFC 2021
This version updates the proposed-standard version of the This version updates the proposed-standard version of the
RMON2 MIB (published as RFC 2021) by adding 2 new enumerations RMON2 MIB (published as RFC 2021) by adding 2 new enumerations
to the nlMatrixTopNControlRateBase object and 4 new to the nlMatrixTopNControlRateBase object and 4 new
enumerations to the alMatrixTopNControlRateBase object. These enumerations to the alMatrixTopNControlRateBase object. These
new enumerations support the creation of high capacity topN new enumerations support the creation of high capacity topN
reports in the High Capacity RMON MIB [6]. reports in the High Capacity RMON MIB [RFC3273].
Additionally, the following object have been deprecated as Additionally, the following object have been deprecated as
they have not had enough independent implementations to they have not had enough independent implementations to
demonstrate interoperability to meet the requirements of a demonstrate interoperability to meet the requirements of a
Draft Standard: Draft Standard:
probeDownloadFile probeDownloadFile
probeDownloadTFTPServer probeDownloadTFTPServer
probeDownloadAction probeDownloadAction
probeDownloadStatus probeDownloadStatus
skipping to change at page 147, line 5 skipping to change at page 149, line 4
serialConnectDialString serialConnectDialString
serialConnectSwitchConnectSeq serialConnectSwitchConnectSeq
serialConnectSwitchDisconnectSeq serialConnectSwitchDisconnectSeq
serialConnectSwitchResetSeq serialConnectSwitchResetSeq
serialConnectOwner serialConnectOwner
serialConnectStatus serialConnectStatus
netConfigIPAddress netConfigIPAddress
netConfigSubnetMask netConfigSubnetMask
netConfigStatus netConfigStatus
netDefaultGateway netDefaultGateway
tokenRingMLStatsDroppedFrames tokenRingMLStats2DroppedFrames
tokenRingMLStatsCreateTime tokenRingMLStats2CreateTime
tokenRingPStatsDroppedFrames tokenRingPStats2DroppedFrames
tokenRingPStatsCreateTime tokenRingPStats2CreateTime
ringStationControlDroppedFrames ringStationControl2DroppedFrames
ringStationControlCreateTime ringStationControl2CreateTime
sourceRoutingStatsDroppedFrames sourceRoutingStats2DroppedFrames
sourceRoutingStatsCreateTime sourceRoutingStats2CreateTime
In addition, two corrections were made. The LastCreateTime In addition, two corrections were made. The LastCreateTime
Textual Convention had been defined with a base type of Textual Convention had been defined with a base type of
another textual convention which isn't allowed in SMIv2. The another textual convention which isn't allowed in SMIv2. The
definition has been modified to use TimeTicks as the base definition has been modified to use TimeTicks as the base
type. type.
Further, the SerialConfigEntry SEQUENCE definition included Further, the SerialConfigEntry SEQUENCE definition included
sub-typing information that is not allowed in SMIv2. This sub-typing information that is not allowed in SMIv2. This
information has been deleted. information has been deleted. Ranges were added to a number of
objects and textual-conventions to constrain their maximum
(and sometimes minimum) sizes:
ControlString
protocolDirID
protocolDirParameters
addressMapNetworkAddress
nlHostAddress
nlMatrixSDSourceAddress
nlMatrixSDDestAddress
nlMatrixDSSourceAddress
nlMatrixDSDestAddress
nlMatrixTopNSourceAddress
nlMatrixTopNDestAddress
alHostEntry
alMatrixSDEntry
alMatrixDSEntry
alMatrixTopNSourceAddress
alMatrixTopNDestAddress
13. Acknowledgments 10. Acknowledgments
This document was produced by the IETF Remote Network This document was produced by the IETF Remote Network
Monitoring Working Group. Monitoring Working Group.
The TimeFilter mechanism was invented and documented by Jeanne The TimeFilter mechanism was invented and documented by Jeanne
Haney. Haney.
The User History group was created by Andy Bierman. The User History group was created by Andy Bierman.
14. Author's Address 11. Author's Address
Steve Waldbusser Steve Waldbusser
Phone: +1 650-948-6500 Phone: +1 650-948-6500
Fax: +1 650-745-0671 Fax: +1 650-745-0671
EMail: waldbusser@nextbeacon.com EMail: waldbusser@nextbeacon.com
15. References 12. References
15.1. Normative References
[1] Harrington, D., Presuhn, R., and B. Wijnen, "An 12.1. Normative References
Architecture for Describing SNMP Management Frameworks",
STD 62. RFC 3411, December 2002.
[2] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., [RFC2578]
McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
Rose, M. and S. Waldbusser, "Structure of Management Rose, M. and S. Waldbusser, "Structure of Management
Information Version 2 (SMIv2)", STD 58, RFC 2578, April Information Version 2 (SMIv2)", STD 58, RFC 2578, April
1999. 1999.
[3] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., [RFC2579]
McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
Rose, M. and S. Waldbusser, "Textual Conventions for Rose, M. and S. Waldbusser, "Textual Conventions for
SMIv2", STD 58, RFC 2579, April 1999. SMIv2", STD 58, RFC 2579, April 1999.
[4] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., [RFC2580]
McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
Rose, M. and S. Waldbusser, "Conformance Statements for Rose, M. and S. Waldbusser, "Conformance Statements for
SMIv2", STD 58, RFC 2580, April 1999. SMIv2", STD 58, RFC 2580, April 1999.
[5] Waldbusser, S., "Remote Network Monitoring MIB", RFC [RFC2819]
Waldbusser, S., "Remote Network Monitoring MIB", RFC
2819, Lucent Technologies, May 2000. 2819, Lucent Technologies, May 2000.
[6] Waldbusser, S., "RMON for High Capacity Networks", RFC [RFC3273]
Waldbusser, S., "RMON for High Capacity Networks", RFC
3273, July 2002. 3273, July 2002.
[7] Bradner, S., "The Internet Standards Process -- Revision 12.2. Informative References
3", RFC 2026, October 1996.
15.2. Informative References
[8] Case, J., Mundy, R., Partain, D. and B. Stewart, [RFC3410]
Case, J., Mundy, R., Partain, D. and B. Stewart,
"Introduction and Applicability Statements for Internet "Introduction and Applicability Statements for Internet
Standard Management Framework", RFC 3410, December 2002. Standard Management Framework", RFC 3410, December 2002.
[9] McCloghrie, K. and M. Rose, Editors, "Management [RFC3411]
Information Base for Network Management of TCP/IP-based Harrington, D., Presuhn, R., and B. Wijnen, "An
internets: MIB-II", STD 17, RFC 1213, Hughes LAN Systems, Architecture for Describing SNMP Management Frameworks",
Performance Systems International, March 1991. STD 62. RFC 3411, December 2002.
[10] McCloghrie, K. and F. Kastenholz, "The Interfaces Group [RFC2863]
McCloghrie, K. and F. Kastenholz, "The Interfaces Group
MIB", RFC 2863, Cisco Systems, Argon Networks, June 2000. MIB", RFC 2863, Cisco Systems, Argon Networks, June 2000.
[11] Waldbusser, S., "Token Ring Extensions to the Remote [RFC1513]
Waldbusser, S., "Token Ring Extensions to the Remote
Network Monitoring MIB", RFC 1513, September 1993. Network Monitoring MIB", RFC 1513, September 1993.
[12] De Graaf, K., Romascanu, D., McMaster, D. and K. [RFC2108]
De Graaf, K., Romascanu, D., McMaster, D. and K.
McCloghrie, "Definition of Managed Objects for IEEE 802.3 McCloghrie, "Definition of Managed Objects for IEEE 802.3
Repeater Devices using SMIv2", RFC 2108, February 1997. Repeater Devices using SMIv2", RFC 2108, February 1997.
[13] Blumenthal, U. and B. Wijnen, "The User-Based Security [RFC3414]
Blumenthal, U. and B. Wijnen, "The User-Based Security
Model (USM) for Version 3 of the Simple Network Model (USM) for Version 3 of the Simple Network
Management Protocol (SNMPv3)", STD 62, RFC 3414, December Management Protocol (SNMPv3)", STD 62, RFC 3414, December
2002. 2002.
[14] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based [RFC3415]
Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based
Access Control Model (VACM) for the Simple Network Access Control Model (VACM) for the Simple Network
Management Protocol (SNMP)", STD 62, RFC 3415, December Management Protocol (SNMP)", STD 62, RFC 3415, December
2002. 2002.
16. Intellectual Property Statement 13. Full Copyright Statement
Copyright (C) The Internet Society (2004).
This document is subject to the rights, licenses and
restrictions contained in BCP 78, and except as set forth
therein, the authors retain all their rights.
This document and the information contained herein are
provided on an "AS IS" basis and THE CONTRIBUTOR, THE
ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY),
THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE
DISCLAIM 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of The IETF takes no position regarding the validity or scope of
any intellectual property or other rights that might be any Intellectual Property Rights or other rights that might be
claimed to pertain to the implementation or use of the claimed to pertain to the implementation or use of the
technology described in this document or the extent to which technology described in this document or the extent to which
any license under such rights might or might not be available; any license under such rights might or might not be available;
neither does it represent that it has made any effort to nor does it represent that it has made any independent effort
identify any such rights. Information on the IETF's to identify any such rights. Information on the procedures
procedures with respect to rights in standards-track and with respect to rights in RFC documents can be found in BCP 78
standards-related documentation can be found in BCP-11. and BCP 79.
Copies of claims of rights made available for publication and
any assurances of licenses to be made available, or the result Copies of IPR disclosures made to the IETF Secretariat and any
of an attempt made to obtain a general license or permission assurances of licenses to be made available, or the result of
for the use of such proprietary rights by implementors or an attempt made to obtain a general license or permission for
users of this specification can be obtained from the IETF the use of such proprietary rights by implementers or users of
Secretariat. this specification can be obtained from the IETF on-line IPR
repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its The IETF invites any interested party to bring to its
attention any copyrights, patents or patent applications, or attention any copyrights, patents or patent applications, or
other proprietary rights which may cover technology that may other proprietary rights that may cover technology that may be
be required to practice this standard. Please address the required to implement this standard. Please address the
information to the IETF Executive Director. information to the IETF at ietf-ipr@ietf.org.
17. Full Copyright Statement
Copyright (C) The Internet Society (2004). 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.
Table of Contents Table of Contents
1 Status of this Memo ................................... 1 1 The Internet-Standard Management Framework ............ 3
2 Copyright Notice ...................................... 2 2 Overview .............................................. 4
3 Abstract .............................................. 2 2.1 Remote Network Management Goals ..................... 4
4 The Internet-Standard Management Framework ............ 3 2.2 Structure of MIB .................................... 6
5 Overview .............................................. 4 3 Control of Remote Network Monitoring Devices .......... 8
5.1 Remote Network Management Goals ..................... 4 3.1 Resource Sharing Among Multiple Management Sta-
5.2 Structure of MIB .................................... 6
6 Control of Remote Network Monitoring Devices .......... 8
6.1 Resource Sharing Among Multiple Management Sta-
tions .............................................. 8 tions .............................................. 8
6.2 Row Addition Among Multiple Management Stations ..... 10 3.2 Row Addition Among Multiple Management Stations ..... 10
7 Conventions ........................................... 12 4 Conventions ........................................... 12
8 RMON 2 Conventions .................................... 13 5 RMON 2 Conventions .................................... 13
8.1 Usage of the term Application Level ................. 13 5.1 Usage of the term Application Level ................. 13
8.2 Protocol Directory and Limited Extensibility ........ 13 5.2 Protocol Directory and Limited Extensibility ........ 13
8.3 Errors in packets ................................... 14 5.3 Errors in packets ................................... 14
9 Definitions ........................................... 14 6 Definitions ........................................... 14
10 Security Considerations .............................. 138 7 Security Considerations ............................... 140
11 Appendix - TimeFilter Implementation Notes ........... 140 8 Appendix - TimeFilter Implementation Notes ............ 142
12 Changes since RFC 2021 ............................... 146 9 Changes since RFC 2021 ................................ 148
13 Acknowledgments ...................................... 148 10 Acknowledgments ...................................... 150
14 Author's Address ..................................... 148 11 Author's Address ..................................... 150
15 References ........................................... 149 12 References ........................................... 151
15.1 Normative References ............................... 149 12.1 Normative References ............................... 151
15.2 Informative References ............................. 149 12.2 Informative References ............................. 151
16 Intellectual Property Statement ...................... 150 13 Full Copyright Statement ............................. 152
17 Full Copyright Statement ............................. 151
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/