Request for Comments: 4498 Cyber Solutions Inc.
Category: Experimental May 2006
The Managed Object Aggregation MIB
Status of This Memo
This memo defines an Experimental Protocol for the Internet
community. It does not specify an Internet standard of any kind.
Discussion and suggestions for improvement are requested.
Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
IESG Note
The content of this RFC was at one time considered by the IETF, and
therefore it may resemble a current IETF work in progress or a
published IETF work. This RFC is not a candidate for any level of
Internet Standard. The IETF disclaims any knowledge of the fitness
of this RFC for any purpose and in particular notes that the decision
to publish is not based on IETF review for such things as security,
congestion control, or inappropriate interaction with deployed
protocols. The RFC Editor has chosen to publish this document at its
discretion. Readers of this RFC should exercise caution in
evaluating its value for implementation and deployment. See RFC 3932
for more information.
Abstract
This memo defines a portion of the Management Information Base (MIB),
the Aggregation MIB modules, for use with network management
protocols in the Internet community. In particular, the Aggregation
MIB modules will be used to configure a network management agent to
aggregate the values of a user-specified set of Managed Object
instances and to service queries related to the aggregated Managed
Object instances.
Table of Contents
1. The Internet-Standard Management Framework ......................2
2. Background ......................................................2
3. MO Aggregation: The Concept .....................................3
4. The Requirements for Managed Object Aggregation .................6
5. MIB Design ......................................................6
6. The Aggregation MIB Modules .....................................7
7. Security Considerations ........................................25
8. IANA Considerations ............................................27
9. References .....................................................27
9.1. Normative References ......................................27
9.2. Informative References ....................................27
10. Acknowledgements ..............................................28
1. The Internet-Standard Management Framework
For a detailed overview of the documents that describe the current
Internet-Standard Management Framework, please refer to section 7 of
RFC 3410 [RFC3410].
Managed objects are accessed via a virtual information store, termed
the Management Information Base or MIB. MIB objects are generally
accessed through the Simple Network Management Protocol (SNMP).
Objects in the MIB are defined using the mechanisms defined in the
Structure of Management Information (SMI). This memo specifies a MIB
module that is compliant to the SMIv2, which is described in STD 58,
RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580
[RFC2580].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119
[RFC2119].
2. Background
For the purpose of management, it is necessary to access Managed
Objects (MOs). The SNMP framework provides a mechanism for naming
and describing managed objects. These objects are accessed via a
virtual information store termed a Management Information Base (MIB).
MIBs have been defined by equipment, protocol, and application
developers to provide management access to the managed entities. We
will call the MOs defined in these MIBs simple MOs (SMO). Management
applications will access one or more instances of these SMOs, one or
more times, to monitor the target entity.
There is a cost associated with accessing MOs. The cost is the
network bandwidth and the packet header processing overhead at the
command generator (manager) and the command responder (agent). This
cost constrains the number of MO instances that can be polled and the
interval at which polling can be carried out.
The overhead reduction can be carried out by reducing the number of
query-response packets. This will reduce the packet processing
overhead, and to some extent, the bandwidth.
The payloads in a typical SNMP "get" packet and the corresponding
response are as shown in Figure 1. In this example, polling is
carried out for ’n’ Managed Object instances OID1, OID2, ..., OIDn.
It is obvious that a substantial amount of the payload in an SNMP
packet consists of the OIDs.
3. MO Aggregation: The Concept
In this document, a mechanism of MO aggregation for payload
compression is defined. The idea is simple: we introduce the concept
of an Aggregate MO (AgMO). An AgMO is just another MO as far as the
SNMP protocol is concerned. No new protocol operations will be
required to handle these MOs. As in the case of any other MO, it
requires additional instrumentation at the command responder (agent)
and at the (command generator) manager. In this mechanism, the user
defines an Aggregate MO (AgMO) corresponding to one or more
(predefined) MO instances. Semantically, the value of an AgMO
instance will be equivalent to the concatenation of the values of the
corresponding MO instances. The order of the concatenation will be
determined by the order in which the MO instances are specified in
the AgMO definition. With the definitions done, the user can, as and
when the necessity arises, do an SNMP ’get’ on instances of the AgMO
to fetch the value of the constituent MO instances. There is
substantial savings on bandwidth, as only one instance object
identifier is carried in the request and the response. In the normal
case, instance object identifiers for each of the constituent MO
instances would be carried in the requests and the responses. This
is the basic concept of Aggregate Managed Objects. For every AgMO,
an ErrorStatus Managed Object is defined. This MO indicates errors,
if any, that have been encountered while fetching the values of the
constituent MO instances. The error indication is comprised of the
index of the MO instance and the corresponding error. If there are
no errors, the ErrorStatus Managed Object instance will have a null
value. This is the basic concept of Aggregate Managed Objects.
The concepts are explained in Figure 2. An aggregate managed object,
AgMOx, has been defined for the MO instances MOI1, ... MOIn. The
value of an instance of AgMOx will be a concatenation of the values
of MOI1, ... MOIn, in that order.
Polling for MO Instances [MOI1, MOI2, ... MOIn]:
+--------+------+-------+... -+------+------+
Query: |Get req | MOI1 | NULL | | MOIn | NULL |
+--------+------+-------+... -+------+------+
+--------+------+-------+... -+------+------+
Response: |Get resp| MOI1 | Val1 | | MOIn | Valn |
+--------+------+-------+... -+------+------+
Figure 1. Polling for MO instances
Polling for an instance (AgMOIx) of an aggregate MO (AgMOx):
AgMOx = aggr{AgMOI1, AgMOI2, ......AgMOIn}
+--------+--------+-------+
Query: |Get req | AgMOIx | NULL |
+--------+--------+-------+
+--------+--------+------------------------+
Response: |Get resp| AgMOIx | Val1,Val2,...,Valn |
+--------+--------+------------------------+
Figure 2. MO aggregation
As a further refinement of the AgMO, we introduce the Time-Based
Aggregated Managed Object (TAgMO). The TAgMO is an MO that
represents the values of a user-specified MO instance sampled at
user-specified intervals for a user-specified number of times. In
this case, the user defines a TAgMO by specifying the MO instance
that needs to be sampled, the sampling interval, and the desired
number of samples that will be included in one TAgMO. The value of a
TAgMO instance will include the timestamp (sysUpTime) at which the
first sample was taken. The start time is not specified when the
TAgMO is defined. Implementations may choose to align the start time
with the appropriate time boundaries (e.g., seconds, minutes, hours).
With the definitions, the user can do an SNMP "get" on an instance of
the TAgMO to fetch the values of the constituent MO instance sampled
at the specified intervals. This is the concept of Time-Based
aggregation.
Polling for ’n’ samples of an MO Instance [MOI] at an interval ’i’:
Query Time Response
===== ==== ========
+--------+-----+-----------+
|Get req | MOI | NULL | t
+--------+-----+-----------+ : +--------+-----+--------------+
: |Get resp| MOI | Val(t) |
: +--------+-----+--------------+
+--------+-----+-----------+ t+i
|Get req | MOI | NULL | :
+--------+-----+-----------+ : +--------+-----+--------------+
: |Get resp| MOI | Val(t+i) |
X +--------+-----+--------------+
X
:
+--------+-----+-----------+ t+(n-1)i
|Get req | MOI | NULL | :
+--------+-----+-----------+ : +--------+-----+--------------+
: |Get resp| MOI | Val(t+(n-1)i)|
+--------+-----+--------------+
Figure 3. Periodic polling for samples of an MO instance
Polling for an instance (TAgMOIx) of a Time-Based aggregate MO
(TAgMOx):
TAgMOx = aggr{’n’ polled samples of an instance (MOI) of MO
at intervals = ’i’ microseconds}
+--------+---------+-------+
Query: |Get req | TAgMOIx | NULL |
+--------+---------+-------+
+--------+---------+--------------------------------------+
Response: |Get resp| TAgMOIx | t,Val(t),Val(t+i),.,Val(t + (n-1)*i) |
+--------+---------+--------------------------------------+
Figure 4. Time-Based aggregation
The TAgMO instance is a "bucket" of data representing the value of
the corresponding MO instance sampled at ’i’ microsecond intervals,
’n’ times (i.e., over a ’n’ X ’i’ microsecond window). The TAgMO
instance value gets updated at ’n’ X ’i’ microsecond intervals.
4. The Requirements for Managed Object Aggregation
The general requirements of managed object aggregation are as
follows:
o It should lead to fewer packets.
o It should lead to less bandwidth consumption.
o It should not lead to loss of information.
In the case of Time-Based aggregation, there will be a delay involved
in getting the actual data. The minimum delay in this case will be
the duration of the aggregation.
The manager application is expected to configure AgMOs (Aggregate
MOs) and TAgMOs (Time-Based Aggregate MOs) with care so that the
response size is not too large. In case the resultant response size
is larger than the maximum acceptable message size of the originator
or larger than the local maximum message size, then the error-status
field will be set to "tooBig".
Note that an aggregate MO can be defined only when all the
constituent MO instances of interest are known. This scheme cannot
be employed if a manager/application does not know the specific MO
instances (of interest) that are serviced by the management target.
In such cases, the application may "discover" the MO instances of
interest by some means, e.g., by "walking" through the MIB tree on
the agent. According to the results of the "walk", the application
can define an appropriate aggregate MO that will serve the purpose.
Considering the cost involved in this exercise, this method is
recommended only if the aggregate MO will be used repeatedly, so that
the benefits of aggregation outweigh the costs of configuration.
5. MIB Design
The basic principle has been to keep the MIB as simple as possible
and at the same time to make it flexible enough that a large number
of users and applications can use the MIB to configure aggregate MOs
conveniently.
Two separate MIB modules have been defined. The AggrMIB supports the
aggregation of independent MO instances, while TAggrMIB supports the
aggregation of several samples of the same MO instance. Both of
these MIB modules use the textual conventions defined in RMON-MIB
[RFC2819] and SNMP-FRAMEWORK-MIB [RFC3411].
The AggrMIB is comprised of three tables, described below.
- The aggrCtlTable controls the aggregation process. Each row in
this table defines the attributes of the aggregate object defined
in the aggrMOTable.
- The aggrMOTable defines the primary MO-based aggregation, i.e.,
the MOs that will be aggregated.
- The aggrDataTable contains the details of the aggregated object.
The TAggrMIB is comprised of two tables described below.
- The tAggrCtlTable controls the aggregation process. Each row in
this table defines the attributes of the aggregate object defined
in the aggrMOTable.
- The tAggrDataTable contains the details of the aggregated object.
6. The Aggregation MIB Modules
AGGREGATE-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, experimental, Unsigned32,
OBJECT-TYPE, Opaque
FROM SNMPv2-SMI
OwnerString
FROM RMON-MIB
RowStatus, StorageType, TEXTUAL-CONVENTION
FROM SNMPv2-TC
MODULE-COMPLIANCE, OBJECT-GROUP
FROM SNMPv2-CONF
SnmpAdminString
FROM SNMP-FRAMEWORK-MIB;
aggrMIB MODULE-IDENTITY
LAST-UPDATED "200604270000Z" -- 27th April, 2006
ORGANIZATION "Cyber Solutions Inc. NetMan Working Group"
CONTACT-INFO
" Glenn Mansfield Keeni
Postal: Cyber Solutions Inc.
6-6-3, Minami Yoshinari
Aoba-ku, Sendai, Japan 989-3204.
Tel: +81-22-303-4012
Fax: +81-22-303-4015
E-mail: glenn@cysols.com
Support Group E-mail: mibsupport@cysols.com"
DESCRIPTION
"The MIB for servicing aggregate objects.
Copyright (C) The Internet Society (2006). This
version of this MIB module is part of RFC 4498;
see the RFC itself for full legal notices.
"
REVISION "200604270000Z" -- 27th April, 2006
DESCRIPTION "Initial version, published as RFC 4498."
::= { experimental 123 }
AggrMOErrorStatus ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"This data type is used to model the error status of the
constituent MO instances. The error status for a
constituent MO instance is given in terms of two elements:
o The moIndex, which indicates the position of the MO
instance (starting at 1) in the value of the aggregated
MO instance.
o The moError, which indicates the error that was
encountered in fetching that MO instance.
The syntax in ASN.1 Notation will be
ErrorStatus :: = SEQUENCE {
moIndex Integer32,
moError SnmpPduErrorStatus
}
AggrMOErrorStatus ::= SEQUENCE OF {
ErrorStatus
}
Note1: The command responder will supply values for all
constituent MO instances, in the same order in
which the MO instances are specified for the AgMO.
If an error is encountered for an MO instance, then
the corresponding value will have an ASN.1 value NULL,
and an error will be flagged in the corresponding
AggrMOErrorStatus object.
Only MOs for which errors have been encountered will
have their corresponding moIndex and moError values
set.
Note2: The error code for the component MO instances will be
in accordance with the SnmpPduErrorStatus TC defined
in the DISMAN-SCHEDULE-MIB [RFC3231].
Note3: The command generator will need to know
constituent MO instances and their order to correctly
interpret AggrMOErrorStatus.
"
SYNTAX Opaque (SIZE (0..1024))
AggrMOValue ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"This data type is used to model the aggregate
MOs. It will have a format dependent on the constituent
MOs, a sequence of values. The syntax in ASN.1 Notation will
be
MOValue :: = SEQUENCE {
value ObjectSyntax
}
where ’value’ is the value of a constituent MO instance.
AggrMOValue :: = SEQUENCE OF {
MOValue
}
Note: The command generator will need to know the
constituent MO instances and their order to
correctly interpret AggrMOValue."
SYNTAX Opaque (SIZE (0..1024))
AggrMOCompressedValue ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"This data type is used to model the compressed
aggregate MOs."
SYNTAX OCTET STRING (SIZE (0..1024))
--
-- The aggregation control table
-- There will be a row for each aggregate MO
--
aggrCtlTable OBJECT-TYPE
SYNTAX SEQUENCE OF AggrCtlEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A table that controls the aggregation of the MOs."
::= {aggrMIB 1}
aggrCtlEntry OBJECT-TYPE
SYNTAX AggrCtlEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A row of the control table that defines one aggregated
MO.
Entries in this table are required to survive a reboot
of the managed entity depending on the value of the
corresponding aggrCtlEntryStorageType instance.
"
INDEX {aggrCtlEntryID }
::= {aggrCtlTable 1 }
AggrCtlEntry ::= SEQUENCE {
aggrCtlEntryID
SnmpAdminString,
aggrCtlMOIndex
Unsigned32,
aggrCtlMODescr
SnmpAdminString,
aggrCtlCompressionAlgorithm
INTEGER,
aggrCtlEntryOwner
OwnerString,
aggrCtlEntryStorageType
StorageType,
aggrCtlEntryStatus
RowStatus
}
aggrCtlEntryID OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE(1..32))
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A locally unique, administratively assigned name
for this aggregated MO. It is used as an index to
uniquely identify this row in the table."
::= { aggrCtlEntry 1 }
aggrCtlMOIndex OBJECT-TYPE
SYNTAX Unsigned32 (1..2147483647)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"A pointer to a group of MOs identified by aggrMOEntryID
in the aggrMOTable. This is the group of MOs that will