RFC 4498
The Managed Object Aggregation MIB
The Managed Object Aggregation MIB ๐
okay bestie, first the paperwork ๐ but make it cute. This is RFC 4498, "The Managed Object Aggregation MIB". It was written by G. Keeni from Cyber Solutions Inc., it's in the Experimental category, and it's dated May 2006 ๐ธ It doesn't say it obsoletes or updates any other RFC, so there's no drama there โจ
Status of This Memo ๐
this memo defines an Experimental Protocol for the Internet community ๐งช It does not specify an Internet standard of any kind, so don't go calling it a standard, periodt ๐ The authors are asking for discussion and suggestions for improvement, and the distribution of this memo is unlimited ๐ฆ
Copyright Notice ยฉ๏ธ
Copyright (C) The Internet Society (2006). ๐
IESG Note ๐งพ
okay this part is a little serious, so read it carefully ๐ซถ The content of this RFC was at one time considered by the IETF, so it may look a lot like 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 it specifically notes that the decision to publish was not based on IETF review for things like security, congestion control, or inappropriate interaction with deployed protocols ๐ฌ The RFC Editor picked to publish this document at its own discretion, so readers should be cautious about how much they trust it when implementing or deploying anything ๐ For more info, check out RFC 3932 ๐
Abstract โจ
this memo defines a portion of the Management Information Base (MIB), specifically the Aggregation MIB modules, for use with network management protocols in the Internet community ๐ง The main idea is that the Aggregation MIB modules are used to configure a network management agent so it can aggregate the values of a user-specified set of Managed Object instances, and then answer queries about those aggregated Managed Object instances. It's giving efficiency ๐ฅ
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 ๐
okay so if you want the full tour of the current Internet-Standard Management Framework docs, go check out section 7 of RFC 3410 [RFC3410] ๐บ๏ธ
managed objects are accessed through a virtual information store called 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 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] ๐ซถ these are the official capital-letter power words, so take them seriously, bestie ๐
2. Background ๐ธ
so, for management purposes, you need to be able to access Managed Objects (MOs) ๐ฆ The SNMP framework gives you a way to name and describe managed objects, and you reach them through a virtual information store called a Management Information Base (MIB) ๐๏ธ Equipment, protocol, and application developers have defined MIBs to give management access to their managed entities. In this document, the MOs defined in these MIBs are called simple MOs (SMO) ๐ Management applications access one or more instances of these SMOs, one or more times, to monitor the target entity ๐
there's a cost to accessing MOs ๐ธ The cost is the network bandwidth, plus the packet header processing overhead at the command generator (manager) and at the command responder (agent) ๐ฉ That cost limits how many MO instances can be polled and how often the polling can happen ๐
reducing the number of query-response packets is one way to cut that overhead ๐ง It reduces the packet processing overhead and, to some extent, the bandwidth too โจ
the payloads in a typical SNMP "get" packet and its corresponding response are shown in Figure 1 ๐ฆ In this example, polling is carried out for 'n' Managed Object instances OID1, OID2, ..., OIDn. And it's obvious that a substantial amount of the payload in an SNMP packet is made up of the OIDs ๐
3. MO Aggregation: The Concept ๐
this document defines a mechanism of MO aggregation for payload compression ๐๏ธ 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, so no new protocol operations are required to handle these MOs ๐ Like any other MO, it needs extra instrumentation at the command responder (agent) and at the (command generator) manager ๐ ๏ธ
in this mechanism, the user defines an Aggregate MO (AgMO) that corresponds to one or more (predefined) MO instances ๐ฏ Semantically, the value of an AgMO instance is equivalent to the concatenation of the values of the corresponding MO instances. The order of the concatenation is determined by the order in which the MO instances are specified in the AgMO definition ๐ Once those definitions are done, the user can do an SNMP 'get' on instances of the AgMO whenever needed, to fetch the values of the constituent MO instances ๐
there is substantial bandwidth savings here, since only one instance object identifier is carried in the request and the response ๐คฏ Normally, instance object identifiers for each of the constituent MO instances would be carried in the requests and responses. This is the basic concept of Aggregate Managed Objects ๐ฅ
for every AgMO, an ErrorStatus Managed Object is defined ๐จ This MO indicates any errors that were encountered while fetching the values of the constituent MO instances. The error indication is made up of the index of the MO instance and the corresponding error. If there are no errors, the ErrorStatus Managed Object instance has a null value โจ And yes, that's the basic concept of Aggregate Managed Objects again, because it's worth repeating ๐
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 is 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) โฐ A 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 ๐ธ To define one, the user specifies the MO instance 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 includes 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 appropriate time boundaries (e.g., seconds, minutes, hours) ๐ง With those definitions in place, 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) works like this ๐ธ
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 an 'n' X 'i' microsecond window) ๐ชฃ The TAgMO instance value gets updated at 'n' X 'i' microsecond intervals ๐
4. The Requirements for Managed Object Aggregation โจ
okay so bestie, here's what aggregation is supposed to get us ๐
- it should lead to fewer packets ๐ฆ
- it should lead to less bandwidth consumption ๐
- it should not lead to loss of information ๐ซถ
the catch with Time-Based aggregation is the wait. you won't get the actual data right away, and the minimum delay is basically the duration of the aggregation โณ so plan for that, babe.
the manager application is expected to set up AgMOs (Aggregate MOs) and TAgMOs (Time-Based Aggregate MOs) with care, so the response doesn't get too chunky ๐ if the resulting response size is bigger than the maximum acceptable message size of the originator, or bigger than the local maximum message size, then the error-status field gets set to "tooBig" ๐ญ
also, an aggregate MO can only be defined once you know all the constituent MO instances you care about. if the manager or application has no clue which specific MO instances the management target services, this scheme just won't work for you ๐ in that case, the application can "discover" the MO instances of interest by some means, e.g., by "walking" through the MIB tree on the agent ๐ต๏ธโโ๏ธ then, based on what the walk turned up, it can define an aggregate MO that does the job. but the walk isn't free, so this method is recommended only if the aggregate MO will be used repeatedly, so the benefits of aggregation outweigh the costs of configuration. the math has to math ๐งฎ
5. MIB Design ๐
the main vibe here is keep the MIB as simple as possible, but flexible enough that a whole bunch of users and applications can use it to configure aggregate MOs without a headache ๐
there are two separate MIB modules. the AggrMIB handles aggregating independent MO instances, and the TAggrMIB handles aggregating several samples of the same MO instance ๐ฆ both of them use the textual conventions defined in RMON-MIB [RFC2819] and SNMP-FRAMEWORK-MIB [RFC3411], so they're not reinventing the wheel ๐
the AggrMIB has three tables:
aggrCtlTableis the control panel ๐๏ธ each row defines the attributes of the aggregate object defined in theaggrMOTable.aggrMOTableis the primary MO-based aggregation, i.e., the MOs that will be aggregated ๐งaggrDataTableholds the details of the aggregated object ๐
the TAggrMIB has two tables:
tAggrCtlTableis also a control table ๐๏ธ each row defines the attributes of the aggregate object defined in theaggrMOTable.tAggrDataTableholds the details of the aggregated object ๐
6. The Aggregation MIB Modules ๐
ok the big one is here, the AggrMIB, all of it, no cuts ๐ it's a lot but it's giving everything it needs to be
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
be aggregated."
::= { aggrCtlEntry 2 }
aggrCtlMODescr OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE(0..64))
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"A textual description of the object that is
being aggregated."
::= {aggrCtlEntry 3}
-- only one compression algorithm is defined as of now.
aggrCtlCompressionAlgorithm OBJECT-TYPE
SYNTAX INTEGER {
none (1),
deflate (2)
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The compression algorithm that will be used by
the agent to compress the value of the aggregated
object.
The deflate algorithm and corresponding data format
specification is described in RFC 1951. It is
compatible with the widely used gzip utility.
"
REFERENCE
"RFC1951 : DEFLATE Compressed Data Format Specification
version 1.3
"
DEFVAL { none }
::= {aggrCtlEntry 4}
aggrCtlEntryOwner OBJECT-TYPE
SYNTAX OwnerString
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The entity that created this entry."
::= {aggrCtlEntry 5}
aggrCtlEntryStorageType OBJECT-TYPE
SYNTAX StorageType
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object defines whether the parameters defined in
this row are kept in volatile storage and lost upon
reboot or backed up by non-volatile (permanent)
storage.
Conceptual rows having the value 'permanent' need not
allow write-access to any columnar objects in the row.
"
::= {aggrCtlEntry 6}
Okay bestie, the status column is where the magic happens. ๐ A row can only be changed when it's not active, so you flip it to notInService, edit your values, then flip it back. ๐ฅ
aggrCtlEntryStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The row status variable, used according to row
installation and removal conventions.
Objects in a row can be modified only when the value of
this object in the corresponding conceptual row is not
'active'.
Thus, to modify one or more of the objects in this
conceptual row,
a. change the row status to 'notInService',
b. change the values of the row, and
c. change the row status to 'active'.
The aggrCtlEntryStatus may be changed to 'active' if
all the MOs in the conceptual row have been assigned
valid values.
"
::= {aggrCtlEntry 7}
--
-- The Table of primary(simple) MOs
--
aggrMOTable OBJECT-TYPE
SYNTAX SEQUENCE OF AggrMOEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The table of primary(simple) MOs that will be aggregated.
Each row in this table represents a MO that will be
aggregated. The aggrMOEntryID index is used to identify
the group of MOs that will be aggregated. The
aggrMOIndex instance in the corresponding row of the
aggrCtlTable will have a value equal to the value of
aggrMOEntryID. The aggrMOEntryMOID index is used to
identify an MO in the group.
"
::= {aggrMIB 2}
aggrMOEntry OBJECT-TYPE
SYNTAX AggrMOEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A row of the table that specifies one MO.
Entries in this table are required to survive a reboot
of the managed entity depending on the value of the
corresponding aggrMOEntryStorageType instance.
"
INDEX { aggrMOEntryID, aggrMOEntryMOID }
::= {aggrMOTable 1 }
AggrMOEntry ::= SEQUENCE {
aggrMOEntryID
Unsigned32,
aggrMOEntryMOID
Unsigned32,
aggrMOInstance
OBJECT IDENTIFIER,
aggrMODescr
SnmpAdminString,
aggrMOEntryStorageType
StorageType,
aggrMOEntryStatus
RowStatus
}
aggrMOEntryID OBJECT-TYPE
SYNTAX Unsigned32 (1..2147483647)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An index uniquely identifying a group of MOs
that will be aggregated."
::= { aggrMOEntry 1 }
aggrMOEntryMOID OBJECT-TYPE
SYNTAX Unsigned32 (1..65535)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An index to uniquely identify an MO instance in the
group of MO instances that will be aggregated."
::= { aggrMOEntry 2 }
aggrMOInstance OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The OID of the MO instance, the value of which will
be sampled by the agent."
::= { aggrMOEntry 3 }
aggrMODescr OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE(0..64))
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"A textual description of the object that will
be aggregated."
::= {aggrMOEntry 4}
aggrMOEntryStorageType OBJECT-TYPE
SYNTAX StorageType
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object defines whether the parameters defined in
this row are kept in volatile storage and lost upon
reboot or backed up by non-volatile (permanent)
storage.
Conceptual rows having the value 'permanent' need not
allow write-access to any columnar objects in the row.
"
::= {aggrMOEntry 5}
aggrMOEntryStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The row status variable, used according to row
installation and removal conventions.
Objects in a row can be modified only when the value of
this object in the corresponding conceptual row is not
'active'.
Thus, to modify one or more of the objects in this
conceptual row,
a. change the row status to 'notInService',
b. change the values of the row, and
c. change the row status to 'active'.
The aggrMOEntryStatus may be changed to 'active' iff
all the MOs in the conceptual row have been assigned
valid values.
"
::= {aggrMOEntry 6}
Now for the data table, which is where the values actually live. ๐ฆ The thing to remember here is the access rules: reading the aggregate means you need access to every component object too. Lowkey strict, but it makes sense. ๐
--
-- aggrDataTable: The Table of Data. Each row represents a Data
-- set. aggrCtlEntryID is the key to the table.
-- It is used to identify instances of the
-- aggregated MO that are present in the table.
--
aggrDataTable OBJECT-TYPE
SYNTAX SEQUENCE OF AggrDataEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Each row of this table contains information
about an aggregateMO indexed by aggrCtlEntryID."
::= {aggrMIB 3}
aggrDataEntry OBJECT-TYPE
SYNTAX AggrDataEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Entry containing information pertaining to
an aggregate MO."
INDEX {aggrCtlEntryID}
::= {aggrDataTable 1 }
AggrDataEntry ::= SEQUENCE {
aggrDataRecord
AggrMOValue,
aggrDataRecordCompressed
AggrMOCompressedValue,
aggrDataErrorRecord
AggrMOErrorStatus
}
aggrDataRecord OBJECT-TYPE
SYNTAX AggrMOValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The snapshot value of the aggregated MO.
Note that the access privileges to this object will be
governed by the access privileges of the component
objects. Thus, an entity attempting to access an
instance of this MO MUST have access rights to all the
component instance objects and this MO instance.
"
::= { aggrDataEntry 1}
aggrDataRecordCompressed OBJECT-TYPE
SYNTAX AggrMOCompressedValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The compressed value of the aggregated MO.
The compression algorithm will depend on the
aggrCtlCompressionAlgorithm given in the corresponding
aggrCtlEntry. If the value of the corresponding
aggrCtlCompressionAlgorithm is (1) 'none', then the value
of all instances of this object will be a string of zero
length.
Note that the access privileges to this object will be
governed by the access privileges of the component
objects. Thus, an entity attempting to access an instance
of this MO MUST have access rights to all the component
instance objects and this MO instance.
"
::= { aggrDataEntry 2}
aggrDataErrorRecord OBJECT-TYPE
SYNTAX AggrMOErrorStatus
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The error status corresponding to the MO instances
aggregated in aggrDataRecord (and
aggrDataRecordCompressed)."
::= { aggrDataEntry 3}
Last bit of the AGGREGATE-MIB: the conformance tree and the basic group that bundles all the objects together. โจ
-- Conformance information
aggrConformance OBJECT IDENTIFIER ::= { aggrMIB 4 }
aggrGroups OBJECT IDENTIFIER ::= { aggrConformance 1 }
aggrCompliances OBJECT IDENTIFIER ::= { aggrConformance 2 }
-- Compliance statements
aggrMibCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for SNMP entities
that implement the AGGREGATE-MIB."
MODULE -- this module
MANDATORY-GROUPS { aggrMibBasicGroup }
::= { aggrCompliances 1 }
-- Units of conformance
aggrMibBasicGroup OBJECT-GROUP
OBJECTS {
aggrCtlMOIndex,
aggrCtlMODescr,
aggrCtlCompressionAlgorithm,
aggrCtlEntryOwner,
aggrCtlEntryStorageType,
aggrCtlEntryStatus,
aggrMOInstance,
aggrMODescr,
aggrMOEntryStorageType,
aggrMOEntryStatus,
aggrDataRecord,
aggrDataRecordCompressed,
aggrDataErrorRecord
}
STATUS current
DESCRIPTION
"A collection of objects for aggregation of MOs."
::= { aggrGroups 1 }
END
Next up is the TIME-AGGREGATE-MIB, a sibling module for time-based aggregates. โฐ๐
TIME-AGGREGATE-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, experimental,
OBJECT-TYPE, Opaque, Integer32
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;
tAggrMIB MODULE-IDENTITY
LAST-UPDATED "200604270000Z" -- 27 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 Time-Based 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 124 }
okay bestie, this is where the MIB gets REAL ๐ The tables and textual conventions below are the actual data model, so the exact wording matters. Here's the first chunk ๐
TAggrMOErrorStatus ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"This data type is used to model the error status of the
sampled MO instance. The error status for a sampled MO
instance is given in terms of two elements:
o The moIndex, which indicates the sample number of the MO
instance (starting at 1) in the value of the time-
aggregated MO instance.
o The moError, which indicates the error that was
encountered in sampling that MO instance.
The syntax in ASN.1 Notation will be
ErrorStatus :: = SEQUENCE {
moIndex Integer32,
moError SnmpPduErrorStatus
}
TAggrMOErrorStatus ::= SEQUENCE OF {
ErrorStatus
}
Note1: The command responder will supply values for all
the samples of the MO instance. If an error is
encountered for a sample, then the corresponding
value will have an ASN.1 value NULL, and an error
will be flagged in the corresponding
TAggrMOErrorStatus object.
Only MOs for which errors have been encountered will
the corresponding moIndex and moError values be 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].
"
SYNTAX Opaque (SIZE (0..1024))
TimeAggrMOValue ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"This data type is used to model the time-aggregated MOs. It
will be a sequence of values. The syntax in ASN.1 Notation
will be
MOSampleValue :: = SEQUENCE {
value ObjectSyntax
}
TimeAggrMOValue ::= SEQUENCE OF {
MOSampleValue
}
where the first MOSampleValue, if any, will always be the
timestamp of the first sample in the aggregated object. The
subsequent values are the values of the MO instance sampled
at the specified intervals for the specified number of times.
Note: The command generator will need to know the
constituent MO instance and the sampling interval to
correctly interpret TimeAggrMOValue.
"
SYNTAX Opaque (SIZE (0..1024))
CompressedTimeAggrMOValue ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"This data type is used to model the compressed
TAgMOs."
SYNTAX Opaque (SIZE (0..1024))
--
-- The Time-Based aggregation control table
--
Now we're in the control table era ๐ฆ It's basically the setup page where you tell the agent what to watch, how often, and how many times. Main character energy, fr fr โจ
tAggrCtlTable OBJECT-TYPE
SYNTAX SEQUENCE OF TAggrCtlEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The Time-Based aggregation control table. It controls
the aggregation of the samples of MO instances. There
will be a row for each TAgMO.
"
::= {tAggrMIB 1}
tAggrCtlEntry OBJECT-TYPE
SYNTAX TAggrCtlEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A row of the control table that defines one Time-Based
aggregate MO (TAgMO)."
INDEX {tAggrCtlEntryID }
::= {tAggrCtlTable 1 }
TAggrCtlEntry ::= SEQUENCE {
tAggrCtlEntryID
SnmpAdminString,
tAggrCtlMOInstance
OBJECT IDENTIFIER,
tAggrCtlAgMODescr
SnmpAdminString,
tAggrCtlInterval
Integer32,
tAggrCtlSamples
Integer32,
tAggrCtlCompressionAlgorithm
INTEGER,
tAggrCtlEntryOwner
OwnerString,
tAggrCtlEntryStorageType
StorageType,
tAggrCtlEntryStatus
RowStatus
}
tAggrCtlEntryID 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."
::= { tAggrCtlEntry 1 }
tAggrCtlMOInstance OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The sampled values of this MO instance will be
aggregated by the TAgMO.
"
::= { tAggrCtlEntry 2 }
tAggrCtlAgMODescr OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE(0..64))
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"A textual description of the aggregate object."
::= {tAggrCtlEntry 3}
tAggrCtlInterval OBJECT-TYPE
SYNTAX Integer32
UNITS "micro seconds"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The interval, in microseconds, at which the MO instance
pointed at by tAggrInstance will be sampled for
Time-Based aggregation.
"
::= {tAggrCtlEntry 4}
tAggrCtlSamples OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The number of times at which the MO instance referred
to by tAggrInstance will be sampled for Time-Based
aggregation."
::= {tAggrCtlEntry 5}
-- only one compression algorithm is defined as of now.
tAggrCtlCompressionAlgorithm OBJECT-TYPE
SYNTAX INTEGER {
none (1),
deflate (2)
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The compression algorithm that will be used by
the agent to compress the value of the TAgMO.
The deflate algorithm and corresponding data format
specification is described in RFC 1951. It is
compatible with the widely used gzip utility.
"
REFERENCE
"RFC1951 : DEFLATE Compressed Data Format Specification
version 1.3
"
DEFVAL { none }
::= {tAggrCtlEntry 6}
tAggrCtlEntryOwner OBJECT-TYPE
SYNTAX OwnerString
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"A textual description of the entity that created
this entry.
"
::= {tAggrCtlEntry 7}
tAggrCtlEntryStorageType OBJECT-TYPE
SYNTAX StorageType
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object defines whether the parameters defined in
this row are kept in volatile storage and lost upon
reboot or backed up by non-volatile (permanent)
storage.
Conceptual rows having the value 'permanent' need not
allow write-access to any columnar objects in the row.
"
::= {tAggrCtlEntry 8}
tAggrCtlEntryStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The row status variable, used according to row
installation and removal conventions.
Objects in a row can be modified only when the value of
this object in the corresponding conceptual row is not
'active'.
Thus, to modify one or more of the objects in this
conceptual row,
a. change the row status to 'notInService',
b. change the values of the row, and
c. change the row status to 'active'.
The tAggrCtlEntryStatus may be changed to 'active' iff
all the MOs in the conceptual row have been assigned
valid values.
"
::= {tAggrCtlEntry 9}
Next up is the data table ๐ธ This is where the results actually live, and yes, there's a MUST in here that you should totally notice ๐
--
-- tAggrDataTable: The data table.
--
tAggrDataTable OBJECT-TYPE
SYNTAX SEQUENCE OF TAggrDataEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This is the data table. Each row of this table contains
information about a TAgMO indexed by tAggrCtlEntryID.
tAggrCtlEntryID is the key to the table. It is used to
identify instances of the TAgMO that are present in the
table.
"
::= {tAggrMIB 2}
tAggrDataEntry OBJECT-TYPE
SYNTAX TAggrDataEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Entry containing information pertaining
to a TAgMO."
INDEX {tAggrCtlEntryID}
::= {tAggrDataTable 1 }
TAggrDataEntry ::= SEQUENCE {
tAggrDataRecord
TimeAggrMOValue,
tAggrDataRecordCompressed
CompressedTimeAggrMOValue,
tAggrDataErrorRecord
TAggrMOErrorStatus
}
tAggrDataRecord OBJECT-TYPE
SYNTAX TimeAggrMOValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The snapshot value of the TAgMO."
::= { tAggrDataEntry 1}
tAggrDataRecordCompressed OBJECT-TYPE
SYNTAX CompressedTimeAggrMOValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The compressed value of the TAgMO.
The compression algorithm will depend on the
tAggrCtlCompressionAlgorithm given in the corresponding
tAggrCtlEntry. If the value of the corresponding
tAggrCtlCompressionAlgorithm is (1) 'none', then the
value of all instances of this object will be a string
of zero length.
Note that the access privileges to this object will be
governed by the access privileges of the corresponding MO
instance. Thus, an entity attempting to access an
instance of this MO MUST have access rights to the
instance object pointed at by tAggrCtlMOInstance and this
MO instance.
"
::= { tAggrDataEntry 2}
tAggrDataErrorRecord OBJECT-TYPE
SYNTAX TAggrMOErrorStatus
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The error status corresponding to the MO instance
samples aggregated in tAggrDataRecord (and
tAggrDataRecordCompressed)."
::= { tAggrDataEntry 3}
-- Conformance information
tAggrConformance OBJECT IDENTIFIER ::= { tAggrMIB 3 }
tAggrGroups OBJECT IDENTIFIER ::= { tAggrConformance 1 }
tAggrCompliances OBJECT IDENTIFIER ::= { tAggrConformance 2 }
-- Compliance statements
tAggrMibCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for SNMP entities
that implement the TIME-AGGREGATE-MIB."
MODULE -- this module
MANDATORY-GROUPS { tAggrMibBasicGroup }
::= { tAggrCompliances 1 }
-- Units of conformance
tAggrMibBasicGroup OBJECT-GROUP
OBJECTS {
tAggrCtlMOInstance,
tAggrCtlAgMODescr,
tAggrCtlInterval,
tAggrCtlSamples,
tAggrCtlCompressionAlgorithm,
tAggrCtlEntryOwner,
tAggrCtlEntryStorageType,
tAggrCtlEntryStatus,
tAggrDataRecord,
tAggrDataRecordCompressed,
tAggrDataErrorRecord
}
STATUS current
DESCRIPTION
"A collection of objects for Time-Based aggregation
of MOs."
::= { tAggrGroups 1 }
END
7. Security Considerations ๐
okay bestie, this part is serious but also kind of iconic ๐
Some of the objects in these MIB modules have a MAX-ACCESS clause of read-create, which means they can be created, changed, and deleted over SNMP. In some network environments those objects can be sensitive or vulnerable, and doing SET operations in a non-secure environment without proper protection can seriously mess with network operations ๐ญ The objects and their vulnerabilities are broken down below.
The following MOs are used to configure an agent that implements the aggregate MIB modules โจ
aggrCtlMOIndex,
aggrCtlMODescr,
aggrCtlCompressionAlgorithm,
aggrCtlEntryOwner,
aggrCtlEntryStorageType,
aggrCtlEntryStatus,
aggrMOInstance,
aggrMODescr,
aggrMOEntryStorageType,
aggrMOEntryStatus,
tAggrCtlMOInstance,
tAggrCtlAgMODescr,
tAggrCtlInterval,
tAggrCtlSamples,
tAggrCtlCompressionAlgorithm,
tAggrCtlEntryOwner,
tAggrCtlEntryStorageType,
tAggrCtlEntryStatus,
Access to these objects can be abused to mess with the data collection system, and the big risks are these ๐
- Changing an instance of
aggrCtlEntryStatus,tAggrCtlEntryStatus,aggrMOEntryStatus, ortAggrMOEntryStatusto'notInService'or'destroy'makes the data aggregation operation for that entry unavailable to the management system. - Changing an instance of
aggrMOInstanceortAggrCtlMOInstancemeans the data aggregation operation can be subverted, which may feed wrong information to the management system. - Adding several rows in the
aggrMOTablefor an aggregate MO can make the value of that aggregate MO really, really big. Messing with thetAggrCtlSamplesinstance for a Time-Based aggregate MO can do something similar. The result could be very heavy management traffic and/or fragmented response packets. In some cases the responder may refuse to send the data and just reply with an error saying the response packet size is too big.
An entity trying to access an instance of an aggregated MO MUST have access rights to all the component instance objects and to the aggregate MO instance. An implementation MUST follow this requirement. If you're lax about this, you breach the security model and leave the system open to illegal access ๐
SNMP versions before SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPSec), there is no control over who on that secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module ๐
It is RECOMMENDED that implementers consider the security features provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms for authentication and privacy ๐
Further, deploying SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and enable cryptographic security. After that, it's a customer or operator responsibility to make sure the SNMP entity giving access to an instance of this MIB module is configured so that only the principals (users) with legitimate rights can actually GET or SET (change/create/delete) those objects ๐
8. IANA Considerations ๐ธ
The MIB modules in this document use the following IANA-assigned OBJECT IDENTIFIER values, which are recorded in the SMI Numbers registry ๐ง
Descriptor OBJECT IDENTIFIER value
---------- -----------------------
aggrMIB { experimental 123 }
tAggrMIB { experimental 124 }
9. References ๐
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
[RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999.
[RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999.
[RFC2819] Waldbusser, S., "Remote Network Monitoring Management Information Base", STD 59, RFC 2819, May 2000.
[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002.
[RFC3231] Levi, D. and J. Schoenwaelder, "Definitions of Managed Objects for Scheduling Management Operations", RFC 3231, January 2002.
[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification version 1.3", RFC 1951, May 1996.
9.2. Informative References
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002.
10. Acknowledgements ๐ซถ
This document is the product of discussions and deliberations carried out in the WIDE-netman group. Bert Wijnen and Glenn Waters reviewed the document and gave valuable comments, which is so sweet of them โจ
Authors' Addresses
Glenn Mansfield Keeni
Cyber Solutions Inc.
6-6-3 Minami Yoshinari
Aoba-ku, Sendai 989-3204
Japan
Phone: +81-22-303-4012
EMail: glenn@cysols.com
Full Copyright Statement
Copyright (C) The Internet Society (2006) ๐ฆ
This document is subject to the rights, licenses and restrictions in BCP 78 and at www.rfc-editor.org/copyright.html. Except as set forth there, the authors keep all their rights.
This document and the information in it are provided on an "AS IS" basis. The contributor, the organization they represent or are sponsored by (if any), the Internet Society, and the Internet Engineering Task Force all disclaim every warranty, express or implied. That includes, but isn't limited to, any warranty that using the information here won't infringe any rights, and any implied warranties of merchantability or fitness for a particular purpose.
Intellectual Property
The IETF takes no position on the validity or scope of any Intellectual Property Rights or other rights that might be claimed to apply to the implementation or use of the technology in this document, or on whether any license under those rights is or isn't available. It also doesn't claim to have independently tried to identify any such rights. Information about the procedures for rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, and the results of any attempt to get a general license or permission to use such proprietary rights by implementers or users of this specification can be obtained from the IETF online IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology needed to implement this standard. Please send that information to the IETF at ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA) ๐
๐ฆ where this page comes from
- ietf: rfc4498 2006-05
- ๐ girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms