Request for Comments: 2021 INS
Category: Standards Track January 1997
Remote Network Monitoring Management Information Base
Version 2
using SMIv2
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Abstract
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in TCP/IP-based internets.
In particular, it defines objects for managing remote network
monitoring devices.
Table of Contents
1 The Network Management Framework ...................... 2
2 Overview .............................................. 2
2.1 Remote Network Management Goals ..................... 3
2.2 Structure of MIB .................................... 5
3 Control of Remote Network Monitoring Devices .......... 6
3.1 Resource Sharing Among Multiple Management Sta-
tions .............................................. 7
3.2 Row Addition Among Multiple Management Stations ..... 9
4 Conventions ........................................... 10
5 RMON 2 Conventions .................................... 10
5.1 Usage of the term Application Level ................. 10
5.2 Protocol Directory and Limited Extensibility ........ 11
5.3 Errors in packets ................................... 11
6 Definitions ........................................... 12
7 Security Considerations ............................... 122
8 Appendix - TimeFilter Implementation Notes ........... 123
9 Acknowledgments ...................................... 129
10 References ........................................... 129
11 Author's Address...................................... 130
1. The Network Management Framework
The Internet-standard Network Management Framework consists of three
components. They are:
RFC1902 [1] which defines the SMI, the mechanisms used for
describing and naming objects for the purpose of management.
RFC1213, STD 17, [3] which defines MIB-II, the core set of
managed objects for the Internet suite of protocols.
RFC1905 [4] which defines the SNMP, the protocol used for
network access to managed objects.
The Framework permits new objects to be defined for the purpose of
experimentation and evaluation.
Managed objects are accessed via a virtual information store, termed
the Management Information Base or MIB. Within a given MIB module,
objects are defined using the SMI's OBJECT-TYPE macro. At a minimum,
each object has a name, a syntax, an access-level, and an
implementation-status.
The name is an object identifier, an administratively assigned name,
which specifies an object type. The object type together with an
object instance serves to uniquely identify a specific instantiation
of the object. For human convenience, we often use a textual string,
termed the object descriptor, to also refer to the object type.
The syntax of an object type defines the abstract data structure
corresponding to that object type. The ASN.1 [6] language is used
for this purpose. However, RFC1902 purposely restricts the ASN.1
constructs which may be used. These restrictions are explicitly made
for simplicity.
The access-level of an object type defines whether it makes "protocol
sense" to read and/or write the value of an instance of the object
type. (This access-level is independent of any administrative
authorization policy.)
The implementation-status of an object type indicates whether the
object is mandatory, optional, obsolete, or deprecated.
2. Overview
This document continues the architecture created in the RMON MIB [RFC
1757] by providing a major feature upgrade, primarily by providing
RMON analysis up to the application layer.
Remote network monitoring devices, often called monitors or probes,
are instruments that exist for the purpose of managing a network.
Often these remote probes are stand-alone devices and devote
significant internal resources for the sole purpose of managing a
network. An organization may employ many of these devices, one per
network segment, to manage its internet. In addition, these devices
may be used for a network management service provider to access a
client network, often geographically remote.
The objects defined in this document are intended as an interface
between an RMON agent and an RMON management application and are not
intended for direct manipulation by humans. While some users may
tolerate the direct display of some of these objects, few will
tolerate the complexity of manually manipulating objects to
accomplish row creation. These functions should be handled by the
management application.
2.1. Remote Network Management Goals
o Offline Operation
There are sometimes conditions when a management
station will not be in constant contact with its
remote monitoring devices. This is sometimes by
design in an attempt to lower communications costs
(especially when communicating over a WAN or
dialup link), or by accident as network failures
affect the communications between the management
station and the probe.
For this reason, this MIB allows a probe to be
configured to perform diagnostics and to collect
statistics continuously, even when communication with
the management station may not be possible or
efficient. The probe may then attempt to notify
the management station when an exceptional condition
occurs. Thus, even in circumstances where
communication between management station and probe is
not continuous, fault, performance, and configuration
information may be continuously accumulated and
communicated to the management station conveniently
and efficiently.
o Proactive Monitoring
Given the resources available on the monitor, it
is potentially helpful for it continuously to run
diagnostics and to log network performance. The
monitor is always available at the onset of any
failure. It can notify the management station of the
failure and can store historical statistical
information about the failure. This historical
information can be played back by the management
station in an attempt to perform further diagnosis
into the cause of the problem.
o Problem Detection and Reporting
The monitor can be configured to recognize
conditions, most notably error conditions, and
continuously to check for them. When one of these
conditions occurs, the event may be logged, and
management stations may be notified in a number of
ways.
o Value Added Data
Because a remote monitoring device represents a
network resource dedicated exclusively to network
management functions, and because it is located
directly on the monitored portion of the network, the
remote network monitoring device has the opportunity
to add significant value to the data it collects.
For instance, by highlighting those hosts on the
network that generate the most traffic or errors, the
probe can give the management station precisely the
information it needs to solve a class of problems.
o Multiple Managers
An organization may have multiple management stations
for different units of the organization, for different
functions (e.g. engineering and operations), and in an
attempt to provide disaster recovery. Because
environments with multiple management stations are
common, the remote network monitoring device has to
deal with more than own management station,
potentially using its resources concurrently.
2.2. Structure of MIB
The objects are arranged into the following groups:
- protocol directory
- protocol distribution
- address mapping
- network layer host
- network layer matrix
- application layer host
- application layer matrix
- user history
- probe configuration
These groups are the basic units of conformance. If a remote
monitoring device implements a group, then it must implement all
objects in that group. For example, a managed agent that implements
the network layer matrix group must implement the nlMatrixSDTable and
the nlMatrixDSTable.
Implementations of this MIB must also implement the system and
interfaces group of MIB-II [3]. MIB-II may also mandate the
implementation of additional groups.
These groups are defined to provide a means of assigning object
identifiers, and to provide a method for managed agents to know which
objects they must implement.
This document also contains enhancements to tables defined in the
RMON MIB [RFC1757]. These enhancements include:
1) Adding the DroppedFrames and LastCreateTime
conventions to each table defined in the RMON MIB.
2) Augmenting the RMON filter table with a mechanism
that allows filtering based on an offset from the
beginning of a particular protocol, even if the
protocol headers are variable length.
3) Augmenting the RMON filter and capture status bits
with additional bits for WAN media and generic media.
These bits are defined here as:
Bit Definition
6 For WAN media, this bit is set for packets
coming from one direction and cleared for
packets coming from the other direction.
It is an implementation specific matter
as to which bit is assigned to which
direction, but it must be consistent for
all packets received by the agent, and if
the agent knows which end of the link is
"local" and which end is "network", the bit
should be set for packets from the "local"
side and should be cleared for packets from
the "network" side.
7 For any media, this bit is set for any packet
with a physical layer error. This bit may be
set in addition to other media-specific bits
that denote the same condition.
8 For any media, this bit is set for any packet
that is too short for the media. This bit may
be set in addition to other media-specific
bits that denote the same condition.
9 For any media, this bit is set for any packet
that is too long for the media. This bit may
be set in addition to other media-specific bits
that denote the same condition.
These enhancements are implemented by RMON-2 probes that also
implement RMON and do not add any requirements to probes that are
compliant to just RMON.
3. Control of Remote Network Monitoring Devices
Due to the complex nature of the available functions in these
devices, the functions often need user configuration. In many cases,
the function requires parameters to be set up for a data collection
operation. The operation can proceed only after these parameters are
fully set up.
Many functional groups in this MIB have one or more tables in which
to set up control parameters, and one or more data tables in which to
place the results of the operation. The control tables are typically
read/write in nature, while the data tables are typically read/only.
Because the parameters in the control table often describe resulting
data in the data table, many of the parameters can be modified only
when the control entry is not active. Thus, the method for modifying
these parameters is to de-activate the entry, perform the SNMP Set
operations to modify the entry, and then re-activate the entry.
Deleting the control entry causes the deletion of any associated data
entries, which also gives a convenient method for reclaiming the
resources used by the associated data.
Some objects in this MIB provide a mechanism to execute an action on
the remote monitoring device. These objects may 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 to the same value as it
currently holds would thus cause no action to occur.
To facilitate control by multiple managers, resources have to be
shared among the managers. These resources are typically the memory
and computation resources that a function requires.
3.1. Resource Sharing Among Multiple Management Stations
When multiple management stations wish to use functions that compete
for a finite amount of resources on a device, a method to facilitate
this sharing of resources is required. Potential conflicts include:
o Two management stations wish to simultaneously use
resources that together would exceed the capability of
the device.
o A management station uses a significant amount of
resources for a long period of time.
o A management station uses resources and then crashes,
forgetting to free the resources so others may
use them.
The OwnerString mechanism is provided for each management station
initiated function in this MIB to avoid these conflicts and to help
resolve them when they occur. Each function has a label identifying
the initiator (owner) of the function. This label is set by the
initiator to provide for the following possibilities:
o A management station may recognize resources it owns
and no longer needs.
o A network operator can find the management station that
owns the resource and negotiate for it to be freed.
o A network operator may decide to unilaterally free
resources another network operator has reserved.
o Upon initialization, a management station may recognize
resources it had reserved in the past. With this
information it may free the resources if it no longer
needs them.
Management stations and probes should support any format of the owner
string dictated by the local policy of the organization. It is
suggested that this name contain one or more of the following: IP
address, management station name, network manager's name, location,
or phone number. This information will help users to share the
resources more effectively.
There is often default functionality that the device or the
administrator of the probe (often the network administrator) wishes
to set up. The resources associated with this functionality are then
owned by the device itself or by the network administrator, and are
intended to be long-lived. In this case, the device or the
administrator will set the relevant owner object to a string starting
with 'monitor'. Indiscriminate modification of the monitor-owned
configuration by network management stations is discouraged. In
fact, a network management station should only modify these objects
under the direction of the administrator of the probe.
Resources on a probe are scarce and are typically allocated when
control rows are created by an application. Since many applications
may be using a probe simultaneously, indiscriminate allocation of
resources to particular applications is very likely to cause resource
shortages in the probe.
When a network management station wishes to utilize a function in a
monitor, it is encouraged to first scan the control table of that
function to find an instance with similar parameters to share. This
is especially true for those instances owned by the monitor, which
can be assumed to change infrequently. If a management station
decides to share an instance owned by another management station, it
should understand that the management station that owns the instance
may indiscriminately modify or delete it.
It should be noted that a management application should have the most
trust in a monitor-owned row because it should be changed very
infrequently. A row owned by the management application is less
long-lived because a network administrator 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 potentially in use by many users. A row
owned by another application would be even less long-lived because
the other application may delete or modify that row completely at its
discretion.
3.2. Row Addition Among Multiple Management Stations
The addition of new rows is achieved using the RowStatus method
described in RFC1903 [2]. In this MIB, rows are often added to a
table in order to configure a function. This configuration usually
involves parameters that control the operation of the function. The
agent must check these parameters to make sure they are appropriate
given restrictions defined in this MIB as well as any implementation
specific restrictions such as lack of resources. The agent
implementor may be confused as to when to check these parameters and
when to signal to the management station that the parameters are
invalid. There are two opportunities:
o When the management station sets each parameter object.
o When the management station sets the row status object
to active.
If the latter is chosen, it would be unclear to the management
station which of the several parameters was invalid and caused the
badValue error to be emitted. Thus, wherever possible, the
implementor should choose the former as it will provide more
information to the management station.
A problem can arise when multiple management stations attempt to set
configuration information simultaneously using SNMP. When this
involves the addition of a new conceptual row in the same control
table, the managers may collide, attempting to create the same entry.
To guard against these collisions, each such control entry contains a
status object with special semantics that help to arbitrate among the
managers. If an attempt is made with the row addition mechanism to
create such a status object and that object already exists, an error
is returned. When more than one manager simultaneously attempts to
create the same conceptual row, only the first will succeed. The
others will receive an error.
In the RMON MIB [RFC1757], the EntryStatus textual convention was
introduced to provide this mutual exclusion function. Since then,
this function was added to the SNMP framework as the RowStatus
textual convention. The RowStatus textual convention is used for the
definition of all new tables.
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 a variety
of ways, hopefully minimizing the chances that the index is in use by
another manager. If the index is in use, the mechanism mentioned
previously will guard against collisions. Examples of schemes to
choose index values include random selection or scanning the control
table looking for the first unused index. Because index values may
be any 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 value
if it has the resources to create a new row.
Some tables in this MIB reference other tables within this MIB. When
creating or deleting entries in these tables, it is generally
allowable for dangling references to exist. There is no defined
order for creating or deleting entries in these tables.
4. Conventions
The following conventions are used throughout the RMON MIB and its
companion documents.
Good Packets
Good packets are error-free packets that have a valid frame length.
For example, on Ethernet, good packets are error-free packets that
are between 64 octets long and 1518 octets long. They follow the
form defined in IEEE 802.3 section 3.2.all.
Bad Packets
Bad packets are packets that have proper framing and are therefore
recognized as packets, but contain errors within the packet or have
an invalid length. For example, on Ethernet, bad packets have a
valid preamble and SFD, but have a bad CRC, or are either shorter
than 64 octets or longer than 1518 octets.
5. RMON 2 Conventions
The following practices and conventions are introduced in the RMON 2
MIB.
5.1. Usage of the term Application Level
There are many cases in this MIB where the term Application Level is
used to describe a class of protocols or a capability. This does not
typically mean a protocol that is an OSI Layer 7 protocol. Rather,
it is used to identify a class of protocols that is not limited to
MAC-layer and network-layer protocols, but can also include
transport, session, presentation, and application-layer protocols.
5.2. Protocol Directory and Limited Extensibility
Every RMON 2 implementation will have the capability to parse certain
types of packets and identify their protocol type at multiple levels,
The protocol directory presents an inventory of those protocol types
the probe is capable of monitoring, and allows the addition,
deletion, and configuration of protocol types in this list.
One concept deserves special attention: the "limited extensibility"
of the protocol directory table. The RMON 2 model is that protocols
are detected by static software that has been written at
implementation time. Therefore, as a matter of configuration, an
implementation does not have the ability to suddenly learn how to
parse new packet types. However, an implementation may be written
such that the software knows where the demultiplexing field is for a
particular protocol, and can be written in such a way that the
decoding of the next layer up is table-driven. This works when the
code has been written to accomodate it and can be extended no more
than one level higher. This extensibility is called "limited
extensibility" to highlight these limitations. However, this can be
a very useful tool.
For example, suppose that an implementation has C code that
understands how to decode IP packets on any of several ethernet
encapsulations, and also knows how to interpret the IP protocol field
to recognize UDP packets and how to decode the UDP port number
fields. That implementation may be table- driven so that among the
many different UDP port numbers possible, it is configured to
recognize 161 as SNMP, port 53 as DNS, and port 69 as TFTP. The
limited extensibility of the protocol directory table would allow an
SNMP operation to create an entry that would create an additional
table mapping for UDP that would recognize UDP port 123 as NTP and
begin counting such packets.
This limited extensibility is an option that an implementation can
choose to allow or disallow for any protocol that has child
protocols.
5.3. Errors in packets
Packets with link-level errors are not counted anywhere in this MIB
because most variables in this MIB requires the decoding of the
contents of the packet, which is meaningless if there is a link-level
error.
Packets in which protocol errors are detected are counted for all
protocols below the layer in which the error was encountered. The
implication of this is that packets in which errors are detected at
the network-layer are not counted anywhere in this MIB, while packets
with errors detected at the transport layer may have network-layer
statistics counted.
6. Definitions
RMON2-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, Counter32, Integer32,
Gauge32, IpAddress, TimeTicks FROM SNMPv2-SMI
TEXTUAL-CONVENTION, RowStatus, DisplayString, TimeStamp
FROM SNMPv2-TC
MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF
mib-2, ifIndex FROM RFC1213-MIB
OwnerString, statistics, history, hosts,
matrix, filter, etherStatsEntry, historyControlEntry,
hostControlEntry, matrixControlEntry, filterEntry,
channelEntry FROM RMON-MIB
tokenRing, tokenRingMLStatsEntry, tokenRingPStatsEntry,
ringStationControlEntry, sourceRoutingStatsEntry
FROM TOKEN-RING-RMON-MIB;
-- Remote Network Monitoring MIB
rmon MODULE-IDENTITY
LAST-UPDATED "9605270000Z"
ORGANIZATION "IETF RMON MIB Working Group"
CONTACT-INFO
"Steve Waldbusser (WG Editor)
Postal: International Network Services
650 Castro Street, Suite 260
Mountain View, CA 94041
Phone: +1 415 254 4251
Email: waldbusser@ins.com
Andy Bierman (WG Chair)
Phone: +1 805 648 2028
Email: abierman@west.net"
DESCRIPTION
"The MIB module for managing remote monitoring
device implementations. This MIB module
augments the original RMON MIB as specified in
RFC1757."
::= { mib-2 16 }
-- { rmon 1 } through { rmon 10 } are defined in RMON and
-- the Token Ring RMON MIB [RFC1513]
protocolDir OBJECT IDENTIFIER ::= { rmon 11 }
protocolDist OBJECT IDENTIFIER ::= { rmon 12 }
addressMap OBJECT IDENTIFIER ::= { rmon 13 }
nlHost OBJECT IDENTIFIER ::= { rmon 14 }
nlMatrix OBJECT IDENTIFIER ::= { rmon 15 }
alHost OBJECT IDENTIFIER ::= { rmon 16 }
alMatrix OBJECT IDENTIFIER ::= { rmon 17 }
usrHistory OBJECT IDENTIFIER ::= { rmon 18 }
probeConfig OBJECT IDENTIFIER ::= { rmon 19 }
rmonConformance OBJECT IDENTIFIER ::= { rmon 20 }
-- Textual Conventions
ZeroBasedCounter32 ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"This TC describes an object which counts events with the
following semantics: objects of this type will be set to
zero(0) on creation and will thereafter count appropriate
events, wrapping back to zero(0) when the value 2^32 is
reached.
Provided that an application discovers the new object within
the minimum time to wrap it can use the initial value as a
delta since it last polled the table of which this object is
part. It is important for a management station to be aware of
this minimum time and the actual time between polls, and to
discard data if the actual time is too long or there is no
defined minimum time.
Typically this TC is used in tables where the INDEX space is
constantly changing and/or the TimeFilter mechanism is in use."
SYNTAX Gauge32
LastCreateTime ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"This TC describes an object that stores the last time its
entry was created.
This can be used for polling applications to determine that an
entry has been deleted and re-created between polls, causing
an otherwise undetectable discontinuity in the data."
SYNTAX TimeStamp
TimeFilter ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"To be used for the index to a table. Allows an application
to download only those rows changed since a particular time.
A row is considered changed if the value of any object in the
row changes or if the row is created or deleted.
When sysUpTime is equal to zero, this table shall be empty.
One entry exists for each past value of sysUpTime, except that
the whole table is purged should sysUpTime wrap.
As this basic row is updated new conceptual rows are created
(which still share the now updated object values with all
other instances). The number of instances which are created
is determined by the value of sysUpTime at which the basic row
was last updated. One instance will exist for each value of
sysUpTime at the last update time for the row. A new
timeMark instance is created for each new sysUpTime value.
Each new conceptual row will be associated with the timeMark
instance which was created at the value of sysUpTime with
which the conceptual row is to be associated.
By definition all conceptual rows were updated at or after
time zero and so at least one conceptual row (associated with
timeMark.0) must exist for each underlying (basic) row.
See the appendix for further discussion of this variable.
Consider the following fooTable:
fooTable ...
INDEX { fooTimeMark, fooIndex }
FooEntry {
fooTimeMark TimeFilter
fooIndex INTEGER,
fooCounts Counter
}
Should there be two basic rows in this table (fooIndex == 1,
fooIndex == 2) and row 1 was updated most recently at time 6,
while row 2 was updated most recently at time 8, and both rows
had been updated on several earlier occasions such that the
current values were 5 and 9 respectively then the following
fooCounts instances would exist.
fooCounts.0.1 5
fooCounts.0.2 9
fooCounts.1.1 5
fooCounts.1.2 9
fooCounts.2.1 5
fooCounts.2.2 9
fooCounts.3.1 5
fooCounts.3.2 9
fooCounts.4.1 5
fooCounts.4.2 9
fooCounts.5.1 5
fooCounts.5.2 9
fooCounts.6.1 5
fooCounts.6.2 9
fooCounts.7.2 9 -- note that row 1 doesn't exist for
fooCounts.8.2 9 -- times 7 and 8"
SYNTAX TimeTicks
DataSource ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Identifies the source of the data that the associated
function is configured to analyze. This source can be any
interface on this device.
In order to identify a particular interface, this
object shall identify the instance of the ifIndex
object, defined in [3,5], for the desired interface.
For example, if an entry were to receive data from
interface #1, this object would be set to ifIndex.1."
SYNTAX OBJECT IDENTIFIER
--
-- Protocol Directory Group
--
-- Lists the inventory of protocols the probe has the capability of
-- monitoring and allows the addition, deletion, and configuration of
-- entries in this list.
protocolDirLastChange OBJECT-TYPE
SYNTAX TimeStamp
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of sysUpTime at the time the protocol directory
was last modified, either through insertions or deletions,
or through modifications of either the
protocolDirAddressMapConfig, protocolDirHostConfig, or
protocolDirMatrixConfig."
::= { protocolDir 1 }
protocolDirTable OBJECT-TYPE
SYNTAX SEQUENCE OF ProtocolDirEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table lists the protocols that this agent has the
capability to decode and count. There is one entry in this
table for each such protocol. These protocols represent
different network layer, transport layer, and higher-layer
protocols. The agent should boot up with this table
preconfigured with those protocols that it knows about and
wishes to monitor. Implementations are strongly encouraged to
support protocols higher than the network layer (at least for
the protocol distribution group), even for implementations
that don't support the application layer groups."
::= { protocolDir 2 }
protocolDirEntry OBJECT-TYPE
SYNTAX ProtocolDirEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A conceptual row in the protocolDirTable.
An example of the indexing of this entry is
protocolDirLocalIndex.8.0.0.0.1.0.0.8.0.2.0.0, which is the
encoding of a length of 8, followed by 8 subids encoding the
protocolDirID of 1.2048, followed by a length of 2 and the
2 subids encoding zero-valued parameters."
INDEX { protocolDirID, protocolDirParameters }
::= { protocolDirTable 1 }
ProtocolDirEntry ::= SEQUENCE {
protocolDirID OCTET STRING,
protocolDirParameters OCTET STRING,
protocolDirLocalIndex Integer32,
protocolDirDescr DisplayString,
protocolDirType BITS,
protocolDirAddressMapConfig INTEGER,
protocolDirHostConfig INTEGER,
protocolDirMatrixConfig INTEGER,
protocolDirOwner OwnerString,
protocolDirStatus RowStatus
}
protocolDirID OBJECT-TYPE
SYNTAX OCTET STRING
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A unique identifier for a particular protocol. Standard
identifiers will be defined in a manner such that they
can often be used as specifications for new protocols - i.e.
a tree-structured assignment mechanism that matches the
protocol encapsulation `tree' and which has algorithmic
assignment mechanisms for certain subtrees. See RFCXXX for
more details.
Despite the algorithmic mechanism, the probe will only place
entries in here for those protocols it chooses to collect. In
other words, it need not populate this table with all of the
possible ethernet protocol types, nor need it create them on
the fly when it sees them. Whether or not it does these
things is a matter of product definition (cost/benefit,
usability), and is up to the designer of the product.
If an entry is written to this table with a protocolDirID that
the agent doesn't understand, either directly or
algorithmically, the SET request will be rejected with an
inconsistentName or badValue (for SNMPv1) error."
::= { protocolDirEntry 1 }
protocolDirParameters OBJECT-TYPE
SYNTAX OCTET STRING
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A set of parameters for the associated protocolDirID.
See the associated RMON2 Protocol Identifiers document
for a description of the possible parameters. There
will be one octet in this string for each sub-identifier in
the protocolDirID, and the parameters will appear here in the
same order as the associated sub-identifiers appear in the
protocolDirID.
Every node in the protocolDirID tree has a different, optional
set of parameters defined (that is, the definition of
parameters for a node is optional). The proper parameter
value for each node is included in this string. Note that the
inclusion of a parameter value in this string for each node is
not optional - what is optional is that a node may have no
parameters defined, in which case the parameter field for that
node will be zero."
::= { protocolDirEntry 2 }
protocolDirLocalIndex OBJECT-TYPE
SYNTAX Integer32 (1..2147483647)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The locally arbitrary, but unique identifier associated
with this protocolDir entry.
The value for each supported protocol must remain constant at
least from one re-initialization of the entity's network
management system to the next re-initialization, except that
if a protocol is deleted and re-created, it must be re-created
with a new value that has not been used since the last
re-initialization.
The specific value is meaningful only within a given SNMP
entity. A protocolDirLocalIndex must not be re-used until the
next agent-restart in the event the protocol directory entry
is deleted."
::= { protocolDirEntry 3 }
protocolDirDescr OBJECT-TYPE
SYNTAX DisplayString (SIZE (1..64))
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"A textual description of the protocol encapsulation.
A probe may choose to describe only a subset of the
entire encapsulation (e.g. only the highest layer).
This object is intended for human consumption only.
This object may not be modified if the associated
protocolDirStatus object is equal to active(1)."
::= { protocolDirEntry 4 }
protocolDirType OBJECT-TYPE
SYNTAX BITS {
extensible(0),
addressRecognitionCapable(1)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object describes 2 attributes of this protocol
directory entry.
The presence or absence of the `extensible' bit describes
whether or not this protocol directory entry can be extended
by the user by creating protocol directory entries which are
children of this protocol.
An example of an entry that will often allow extensibility is
`ip.udp'. The probe may automatically populate some children
of this node such as `ip.udp.snmp' and `ip.udp.dns'.
A probe administrator or user may also populate additional
children via remote SNMP requests that create entries in this
table. When a child node is added for a protocol for which the
probe has no built in support, extending a parent node (for
which the probe does have built in support),
that child node is not extendible. This is termed `limited
extensibility'.
When a child node is added through this extensibility
mechanism, the values of protocolDirLocalIndex and
protocolDirType shall be assigned by the agent.
The other objects in the entry will be assigned by the
manager who is creating the new entry.
This object also describes whether or not this agent can
recognize addresses for this protocol, should it be a network
level protocol. That is, while a probe may be able to
recognize packets of a particular network layer protocol and
count them, it takes additional logic to be able to recognize
the addresses in this protocol and to populate network layer
or application layer tables with the addresses in this
protocol. If this bit is set, the agent will recognize
network layer addresses for this protoocl and populate the
network and application layer host and matrix tables with
these protocols.
Note that when an entry is created, the agent will supply
values for the bits that match the capabilities of the agent
with respect to this protocol. Note that since row creations
usually exercise the limited extensibility feature, these
bits will usually be set to zero."
::= { protocolDirEntry 5 }
protocolDirAddressMapConfig OBJECT-TYPE
SYNTAX INTEGER {
notSupported(1),
supportedOff(2),
supportedOn(3)
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object describes and configures the probe's support for
address mapping for this protocol. When the probe creates
entries in this table for all protocols that it understands,
it will set the entry to notSupported(1) if it doesn't have
the capability to perform address mapping for the protocol or
if this protocol is not a network-layer protocol. When
an entry is created in this table by a management operation as
part of the limited extensibility feature, the probe must set
this value to notSupported(1), because limited extensibility
of the protocolDirTable does not extend to interpreting
addresses of the extended protocols.
If the value of this object is notSupported(1), the probe
will not perform address mapping for this protocol and
shall not allow this object to be changed to any other value.
If the value of this object is supportedOn(3), the probe
supports address mapping for this protocol and is configured
to perform address mapping for this protocol for all
addressMappingControlEntries and all interfaces.
If the value of this object is supportedOff(2), the probe
supports address mapping for this protocol but is configured
to not perform address mapping for this protocol for any
addressMappingControlEntries and all interfaces.
Whenever this value changes from supportedOn(3) to
supportedOff(2), the probe shall delete all related entries in
the addressMappingTable."
::= { protocolDirEntry 6 }
protocolDirHostConfig OBJECT-TYPE
SYNTAX INTEGER {
notSupported(1),
supportedOff(2),
supportedOn(3)
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object describes and configures the probe's support for
the network layer and application layer host tables for this
protocol. When the probe creates entries in this table for
all protocols that it understands, it will set the entry to
notSupported(1) if it doesn't have the capability to track the
nlHostTable for this protocol or if the alHostTable is
implemented but doesn't have the capability to track this
protocol. Note that if the alHostTable is implemented, the
probe may only support a protocol if it is supported in both
the nlHostTable and the alHostTable.
If the associated protocolDirType object has the
addressRecognitionCapable bit set, then this is a network
layer protocol for which the probe recognizes addresses, and
thus the probe will populate the nlHostTable and alHostTable
with addresses it discovers for this protocol.
If the value of this object is notSupported(1), the probe
will not track the nlHostTable or alHostTable for this
protocol and shall not allow this object to be changed to any
other value. If the value of this object is supportedOn(3),
the probe supports tracking of the nlHostTable and alHostTable
for this protocol and is configured to track both tables
for this protocol for all control entries and all interfaces.
If the value of this object is supportedOff(2), the probe
supports tracking of the nlHostTable and alHostTable for this
protocol but is configured to not track these tables
for any control entries or interfaces.
Whenever this value changes from supportedOn(3) to
supportedOff(2), the probe shall delete all related entries in
the nlHostTable and alHostTable.
Note that since each alHostEntry references 2 protocol
directory entries, one for the network address and one for the
type of the highest protocol recognized, that an entry will
only be created in that table if this value is supportedOn(3)
for both protocols."
::= { protocolDirEntry 7 }
protocolDirMatrixConfig OBJECT-TYPE
SYNTAX INTEGER {
notSupported(1),
supportedOff(2),
supportedOn(3)
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object describes and configures the probe's support for
the network layer and application layer matrix tables for this
protocol. When the probe creates entries in this table for
all protocols that it understands, it will set the entry to
notSupported(1) if it doesn't have the capability to track the
nlMatrixTables for this protocol or if the alMatrixTables are
implemented but don't have the capability to track this
protocol. Note that if the alMatrix tables are implemented,
the probe may only support a protocol if it is supported in
the the both of the nlMatrixTables and both of the
alMatrixTables.
If the associated protocolDirType object has the
addressRecognitionCapable bit set, then this is a network
layer protocol for which the probe recognizes addresses, and
thus the probe will populate both of the nlMatrixTables and
both of the alMatrixTables with addresses it discovers for
this protocol.
If the value of this object is notSupported(1), the probe
will not track either of the nlMatrixTables or the
alMatrixTables for this protocol and shall not allow this
object to be changed to any other value. If the value of this
object is supportedOn(3), the probe supports tracking of both
of the nlMatrixTables and (if implemented) both of the
alMatrixTables for this protocol and is configured to track
these tables for this protocol for all control entries and all
interfaces. If the value of this object is supportedOff(2),
the probe supports tracking of both of the nlMatrixTables and
(if implemented) both of the alMatrixTables for this protocol
but is configured to not track these tables for this
protocol for any control entries or interfaces.
Whenever this value changes from supportedOn(3) to
supportedOff(2), the probe shall delete all related entries in
the nlMatrixTables and the alMatrixTables.
Note that since each alMatrixEntry references 2 protocol
directory entries, one for the network address and one for the
type of the highest protocol recognized, that an entry will
only be created in that table if this value is supportedOn(3)
for both protocols."
::= { protocolDirEntry 8 }
protocolDirOwner OBJECT-TYPE
SYNTAX OwnerString
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The entity that configured this entry and is
therefore using the resources assigned to it."
::= { protocolDirEntry 9 }
protocolDirStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The status of this protocol directory entry.
An entry may not exist in the active state unless all
objects in the entry have an appropriate value.
If this object is not equal to active(1), all associated
entries in the nlHostTable, nlMatrixSDTable, nlMatrixDSTable,
alHostTable, alMatrixSDTable, and alMatrixDSTable shall be
deleted."
::= { protocolDirEntry 10 }
--
-- Protocol Distribution Group (protocolDist)
--
-- Collects the relative amounts of octets and packets for the
-- different protocols detected on a network segment.
-- protocolDistControlTable,
-- protocolDistStatsTable
protocolDistControlTable OBJECT-TYPE
SYNTAX SEQUENCE OF ProtocolDistControlEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Controls the setup of protocol type distribution statistics
tables.
Implementations are encouraged to add an entry per monitored
interface upon initialization so that a default collection
of protocol statistics is available.
Rationale:
This table controls collection of very basic statistics
for any or all of the protocols detected on a given interface.
An NMS can use this table to quickly determine bandwidth
allocation utilized by different protocols.
A media-specific statistics collection could also
be configured (e.g. etherStats, trPStats) to easily obtain
total frame, octet, and droppedEvents for the same
interface."
::= { protocolDist 1 }
protocolDistControlEntry OBJECT-TYPE
SYNTAX ProtocolDistControlEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A conceptual row in the protocolDistControlTable.
An example of the indexing of this entry is
protocolDistControlDroppedFrames.7"
INDEX { protocolDistControlIndex }
::= { protocolDistControlTable 1 }
ProtocolDistControlEntry ::= SEQUENCE {
protocolDistControlIndex Integer32,
protocolDistControlDataSource DataSource,
protocolDistControlDroppedFrames Counter32,
protocolDistControlCreateTime LastCreateTime,
protocolDistControlOwner OwnerString,
protocolDistControlStatus RowStatus
}
protocolDistControlIndex OBJECT-TYPE
SYNTAX Integer32 (1..65535)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A unique index for this protocolDistControlEntry."
::= { protocolDistControlEntry 1 }
protocolDistControlDataSource OBJECT-TYPE
SYNTAX DataSource
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The source of data for the this protocol distribution.
The statistics in this group reflect all packets
on the local network segment attached to the
identified interface.
This object may not be modified if the associated
protocolDistControlStatus object is equal to active(1)."
::= { protocolDistControlEntry 2 }
protocolDistControlDroppedFrames OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of frames which were received by the probe
and therefore not accounted for in the *StatsDropEvents, but
for which the probe chose not to count for this entry for
whatever reason. Most often, this event occurs when the probe
is out of some resources and decides to shed load from this
collection.
This count does not include packets that were not counted
because they had MAC-layer errors.
Note that, unlike the dropEvents counter, this number is the
exact number of frames dropped."
::= { protocolDistControlEntry 3 }
protocolDistControlCreateTime OBJECT-TYPE
SYNTAX LastCreateTime
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of sysUpTime when this control entry was last
activated. This can be used by the management station to
ensure that the table has not been deleted and recreated
between polls."
::= { protocolDistControlEntry 4 }
protocolDistControlOwner OBJECT-TYPE
SYNTAX OwnerString
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The entity that configured this entry and is
therefore using the resources assigned to it."
::= { protocolDistControlEntry 5 }
protocolDistControlStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The status of this row.
An entry may not exist in the active state unless all
objects in the entry have an appropriate value.
If this object is not equal to active(1), all associated
entries in the protocolDistStatsTable shall be deleted."
::= { protocolDistControlEntry 6 }