Internet Draft OID Compression April 2001
Internet Engineering Task Force Sandra McLeod
INTERNET-DRAFT SNMP Research
Expires October 2001 David Partain
Matt White
Ericsson
April 2001
SNMP Object Identifier Compression
draft-ietf-eos-oidcompression-00.txt
Revision 1.9
Document Date: 2001/04/23 21:31:04
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
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 [RFC2119].
S. McLeod, et al. Expires October 2001 [Page 1]
Internet Draft OID Compression April 2001
Abstract
This memo defines a mechanism, called OID Compression, for removal of
redundant information in the object identifiers (OIDs) carried in the
name portion of variable bindings in SNMP messages.
1. Background
OID Compression reduces the size of SNMP PDUs by reducing the amount
of redundant information contained within the Object Identifiers
(OIDS) in the name portion of multiple variable bindings in the same
SNMP PDU. The hierarchical structure of OIDs makes it likely that
the OIDs in a message will share some common base set of
subidentifiers. This is particularly true for related objects from
the same groups of MIB scalars or tables. Since SNMP messages often
contain numerous related OIDs, most SNMP messages will contain some
amount of redundant information in the name portion of multiple
variable bindings in the variable binding list. The compression of
these OIDs could result in substantial savings in the amount of
encoding and space required to build SNMP PDUs.
This memo addresses the compression of OIDs within the name portion
of PDU varbinds only. The inclusion of Object Identifiers in the
value portion of PDU varbinds is not nearly as common and would not
likely result in substantial savings.
2. Previous work
There have been a number of OID Compression techniques that have been
discussed and presented in the SNMP community over many years,
including those presented in the IRTF document "SNMP Payload
Compression" by Juergen Schoenwaelder and in the "GetCols Operation"
presentation by David Perkins. A number of OID Compression
techniques that have been presented to date approach OID compression
by encoding OIDs as a delta OID value between the current OID in a
varbind name and a previous OID within the same SNMP PDU.
Previous Delta OID Compression techniques vary substantially in
concept and implementation. However, most Delta OID Compression
algorithms identify "anchor" OIDs that are used for comparison
against the current OID to calculate a smaller delta OID which will
be encoded in the SNMP PDU. The definition of "anchor" OIDs in
previous work can vary quite a bit and may be static or dynamic.
S. McLeod, et al. Expires October 2001 [Page 2]
Internet Draft OID Compression April 2001
There can be one or many "anchor" OIDs per PDU. The "anchor" OIDs
can be either explicitly or implicitly identified in the PDUs. The
algorithms that have been used to generate the delta OIDs between
these "anchor" OIDs and the OIDs in the varbind lists also vary
substantially from one approach to another. As a result, the
different delta OID compression techniques vary substantially in
complexity and efficiency.
With the many choices of Delta OID Compression techniques, the
ultimate compression technique should provide a simple algorithm that
is unambiguous in its implementation and provides good OID
compression returns. The algorithm detailed in this memo provides a
simple Delta OID Compression algorithm with good OID compression
returns. While providing additional choices in how OIDs are
compressed might provide somewhat more compression but at a
complexity of implementation and processing that may not be worth the
cost. The algorithm below attempts to strike a balance between
efficiency of compression and minimization of processing complexity.
3. Terminology
The following is a description and clarification of what is intended
by the terms "compression" and "suppression" as applied to SNMP OIDs:
* Compression
OID compression is the reduction in the amount of information
required to represent each OID in the name portion of an
SNMP PDU varbind. The term compression implies a one-to-one
mapping between the original OIDs in the name portions of
a varbind list and the resulting set of compressed OIDs
for the same varbind list. In the case of OID compression,
OIDs are not omitted in the varbind lists, but rather are
simply reduced in size with redundant information removed
in the name portion of the varbind list.
* Suppression
The suppression of Object Identifiers indicates a reduction
in the number of identifiers required to represent a series
of OIDs in an SNMP PDU varbind list. The term suppression
implies a many-to-one mapping between the original set of
OIDs in a varbind list and the resulting set of encoded
OIDs in an SNMP PDU.
S. McLeod, et al. Expires October 2001 [Page 3]
Internet Draft OID Compression April 2001
4. OID compression versus OID suppression
OID compression and suppression techniques differ in their approach
to reducing redundant information and when used individually are most
useful under different operational circumstances. There are
circumstances, however, in which the use of both of these techniques
in combination can be beneficial as well.
OID Compression reduces the amount of redundant information in a
series of OIDs without omitting any OIDs in the encoded SNMP PDU.
This technique can potentially be used to compress any group of OIDs
in the same SNMP PDU. This makes OID compression well-suited for
operations such as MIB walks, bulk data retrieval, and large
configuration operations where a large percentage of the OIDs in the
varbind list have some common base set of subidentifiers.
OID Suppression, on the other hand, reduces the amount of redundant
information in a series of OIDs by reducing the number of identifiers
that must be included in the SNMP PDU. OID suppression is
particularly well-suited for table row operations (retrieval or
configuration) where most of the OIDs share the same base table OID
as well as instance information. In this case, the base table OID and
instance information can be provided once for all of the objects in
the same row.
OID Suppression will be introduced in Appendix A (and will likely be
moved to a separate document in future revisions). The focus of the
rest of this memo will be exclusively on OID Compression.
5. Delta OID Compression Algorithm
The Delta OID Compression algorithm discussed in this memo provides a
simple technique for reducing the amount of redundant information in
multiple varbind names within the same PDU. This algorithm calculates
the delta OIDs by comparing each varbind name to the previous varbind
name within a varbind list in a single SNMP PDU. The delta OID that
is calculated between the current and previous OIDs identifies a
simple OID tail replacement. The delta OID that is generated from
this algorithm will contain first a value which identifies the
position in the current OID at which this OID diverges from the
previous OID and then following this would be the remaining
subidentifiers from that position forward in the current OID.
For encoding purposes, in order to remain consistent with the current
S. McLeod, et al. Expires October 2001 [Page 4]
Internet Draft OID Compression April 2001
Object Identifier encoding rules, the first value in the delta OID
which identifies the subidentifier position at which the current and
previous OIDs diverge will need to be split into two subidentifiers
and represented in the delta OID as the first and second
subidentifiers of that OID. The formula for determining the first
two subidentifiers in the delta OID is as follows:
S1 = ( Position at which the OIDs diverge) / 40
S2 = ( Position at which the OIDs diverge) % 40
In the formula above, S1 and S2 are the subidentifier values to be
determined for the delta OID. S1 will be assigned to the first
subidentifier in the delta OID and is calculated as the result of the
positional value divided by 40. S2 will be assigned to the second
subidentifier in the delta OID and is calculated as the result of the
positional value modulo 40.
Because the length of an OID is limited to a maximum of 128, the
positional value that indicates the position at which the current and
previous OIDs diverge must be between 0 and 128. As a result, the
first subidentifier could only possibly have the values of 0, 1, 2,
or 3. The second subidentifier, which represents the modulo of 40
could only possibly have a value in the range of 0 to 39. In the
interest of maintaining compatibility with current SNMP
implementations which may only expect values of 0, 1, or 2 (but not
3) for the first subidentifier, it is suggested that this algorithm
could be restricted for use only in compressing OIDs for which the
position at which the current and previous OIDs diverge is 119 or
less. The result of this restriction would be that the first
subidentifier would always have a value of 0, 1, or 2.
The OID Compression mechanism that is described above may only be
used in new PDUs being defined in separate working group documents.
That is, OID Compression MUST not be used in the GetRequest-PDU,
GetNextRequest-PDU, GetBulkRequest-PDU, Response-PDU, SetRequest-PDU,
InformRequest-PDU, SNMPv2-Trap-PDU, or Report-PDU.
5.1. Examples of Compressed OIDs
Example 1: Retrieval of the system group in a single message
might result in following partial list of varbind names being
S. McLeod, et al. Expires October 2001 [Page 5]
Internet Draft OID Compression April 2001
sent:
1.3.6.1.2.1.1.1.0 -- sysDescr.0
1.3.6.1.2.1.1.2.0 -- sysObjectID.0
1.3.6.1.2.1.1.3.0 -- sysUpTime.0
1.3.6.1.2.1.1.4.0 -- sysContact.0
If this payload were compressed, the resulting list of
compressed delta OIDs would be as follows:
1.3.6.1.2.1.1.1.0 -- first OID in varbind list is not compressed
0.8.2.0 -- tail of the next OID starting at the 8th subid
0.8.3.0 -- tail of the next OID starting at the 8th subid
0.8.4.0 -- tail of the next OID starting at the 8th subid
Example 2: Retrieval of a selection of MIB-II objects might
result in the following list of varbind names being sent:
1.3.6.1.2.1.1.1.0 -- sysUpTime.0
1.3.6.1.2.1.2.2.1.8.1 -- ifOperStatus.1
1.3.6.1.2.1.2.2.1.8.2 -- ifOperStatus.2
1.3.6.1.2.1.2.2.1.10.1 -- ifInOctets.1
1.3.6.1.2.1.2.2.1.10.2 -- ifInOctets.2
1.3.6.1.2.1.6.5.0 -- tcpActiveOpens.0
1.3.6.1.2.1.6.7.0 -- tcpAttemptFails.0
1.3.6.1.2.1.6.8.0 -- tcpEstabResets.0
If this payload were compressed, the resulting list of
compressed delta OIDs would be as follows:
1.3.6.1.2.1.1.1.0 -- first OID in varbind list is not compressed
0.7.2.2.1.8.1 -- tail of next OID starting at the 7th subid
0.11.2 -- tail of next OID starting at the 11th subid
0.10.10.1 -- tail of next OID starting at the 10th subid
0.11.2 -- tail of next OID starting at the 11th subid
0.7.6.5.0 -- tail of next OID starting at the 7th subid
0.8.7.0 -- tail of next OID starting at the 8th subid
0.8.8.0 -- tail of next OID starting at the 8th subid
S. McLeod, et al. Expires October 2001 [Page 6]
Internet Draft OID Compression April 2001
5.2. Applicability of the Algorithm
In cases where the objects requested in the same PDU are from
multiple MIB groups then there is likely to be a larger cost, meaning
a larger delta OID, between the OIDs that cross into the different
MIB groups. However, since this algorithm makes use of a dynamic
rather than a static "anchor" (which is always the previous varbind
name) then this allows you to take advantage of the fact that related
objects in requests are commonly grouped together, which allows for
greater compression savings.
This Delta OID Compression approach was chosen primarily for its
simplicity. This algorithm is well-suited for scalar objects as well
as for tabular objects when performing table walks by column.
However, this algorithm may be suboptimal in cases where a row of
objects are being retrieved from a table, especially in cases in
which the table is multiply indexed or indexed by OctetStrings. For
instances of individual objects in the same row in a table, the table
portion of the OIDs can be compressed but the instance information in
these OIDs will not be compressed since two consecutive OIDs
representing instances of different columns in a table will always
diverge at the column subidentifier within the OIDs. As an example,
consider the following two OIDs:
1.3.6.1.2.1.4.1.22.1.2.1.192.147.142.35
^^^ -- ipNetToMediaPhysAddress.1.192.147.142.35
1.3.6.1.2.1.4.1.22.1.4.1.192.147.142.35
^^^ -- ipNetToMediaPhysType.1.192.147.142.35
In this case the instance information is obviously redundant but
cannot be compressed because the first subidentifier at which these
two OIDs will begin to diverge is the subidentifier with the column
identification ('2' for ipNetToMediaPhysAddress and '4' for
ipNetToMediaPhysType). Appendix A discusses the use of OID
suppression to address this case. It is anticipated that OID
suppression can be used independently or in combination with OID
compression to optimize the reduction of redundant information in the
name portion of variable bindings in SNMP PDUs.
6. Use of OID Compression in Notifications
There are at least two reasons why it may not be useful to use OID
compression when sending notifications (traps and informs). These
reasons are:
S. McLeod, et al. Expires October 2001 [Page 7]
Internet Draft OID Compression April 2001
1. Unlike a command generator, the notification originator
has no way of knowing in advance whether the receiver is
capable of parsing compressed OIDs.
Obviously, one could extend the SnmpTargetAddrTable to
include this capability, which is an option the working group
may wish to consider.
2. It is unclear that there is significant benefit in using
OID compression in notifications given the fact that they
generally carry a small number of varbinds.
7. Special Considerations
The delta OID that is used to replace the OID must be no greater in
length than the actual encoded OID that it represents in order for
any benefit to be realized. In cases in which the encoded compressed
OID would be greater than in length than the original encoded OID
then the original OID encoding should be used.
8. Encoding of compressed OIDs
We identify compressed OIDs with two new tags such as the following
(tag numbers will be finalized later):
uncompressedDeltaIdentifier ::=
[APPLICATION 14]
IMPLICIT OBJECT IDENTIFIER (SIZE (0..128)) -- Max OID length
compressedDeltaIdentifier ::=
[APPLICATION 15]
IMPLICIT OBJECT IDENTIFIER (SIZE (0..128)) -- Max OID length
The "uncompressedDeltaIdentifier" would be used for OIDs such as the
first OID in a varbind list that are not compressed but are included
in a PDU that could or should contain compressed OIDs if more than
one varbind is provided in the varbind list.
The "compressedDeltaIdentifier" would be used for OIDs that are
actually compressed in a varbind list of more than one varbind.
As a result of the new compression OID types we need to add a choice
to the ObjectName syntax. This might be redefined to look similar to
S. McLeod, et al. Expires October 2001 [Page 8]
Internet Draft OID Compression April 2001
the following:
ObjectName ::=
CHOICE {
nonDeltaOID OBJECT IDENTIFIER
uncompressedDeltaOID uncompressedDeltaIdentifier
compressedDeltaOID compressedDeltaIdentifier
}
The new ObjectName provides a choice of an original OBJECT IDENTIFIER
which should not be used in PDUs with compression applied or one of
the two delta OID types which will either be compressed or
uncompressed Delta OIDs Object Identifier.
The "nonDeltaOID" and "compressedDeltaOID" tags would provide an
unambigious way to distinguish between compressed and uncompressed
OIDs. The purpose of the "uncompressedDeltaOID" is to allow command
generators to indicate a willlingness to received compressed OIDs in
response to their requests. Typically, the use of compressed OIDs in
the request would indicate to the command responder that compressed
OIDs in the response is desirable. However, if the command generator
issues a GetBulk request with a single varbind included in the
request, then this OID cannot be compressed, and the command
generator cannot explicitly use compression in its request to
indicate to the command resonder that it wishes to receive compressed
OIDs in the response from the agent. However, if we define an
additional uncompressedDeltaIdentifier type object name tag, then we
can indicate that this specific OID is not compressed but compression
in the response is specifically requested. All 3 ObjectName types
would be valid for use with new PDUs. The "nonDeltaOID" object name
type would only be used if compression was specifically not desired.
Note that the two new APPLICATION types are not included in the
ObjectSyntax choices since compressed OIDs are not valid for use in
the value portion of a varbind.
9. When to use compressed versus uncompressed OIDs
It is up to the command generator to determine whether the request
should be made with compressed OIDs. If the command responder
receives a request with one of the new PDU types then this implies
that the request originator is capable of supporting OID compression.
If the request received contains either compressed or uncompressed
S. McLeod, et al. Expires October 2001 [Page 9]
Internet Draft OID Compression April 2001
delta OIDs, the response SHOULD contain compressed OIDs.
10. Encoding Examples
For the following set of Varbind names:
1.3.6.1.2.1.25.1.1.0 -- hrSystemUptime.0
1.3.6.1.2.1.25.1.5.0 -- hrSystemNumUsers.0
1.3.6.1.2.1.25.1.6.0 -- hrSystemProcesses.0
1.3.6.1.2.1.25.1.7.0 -- hrSystemMaxProcesses.0
1.3.6.1.2.1.25.3.2.1.2.1 -- hrDeviceType.1
1.3.6.1.2.1.25.3.2.1.3.1 -- hrDeviceDescr.1
1.3.6.1.2.1.25.3.2.1.5.1 -- hrDeviceStatus.1
The following is the uncompressed version of a PDU containing these
varbinds with values:
30 UNIVERSAL [16] SEQUENCE OF constructor(VarBindList)
81 98 length = 152
30 UNIVERSAL [16] SEQUENCE OF constructor (VarBind)
11 length = 17
06 UNIVERSAL [6] OBJECT IDENTIFIER (ObjectName)
09 length = 9
2b 06 01 02 01 19 01 01 00 = 1.3.6.1.2.1.25.1.1.0
= hrSystemUptime.0
43 APPLICATION [3] IMPLICIT INTEGER (ObjectSyntax)
04 length = 4
02 7c 19 74 = 41687412
30 UNIVERSAL [16] SEQUENCE OF constructor (VarBind)
0e length = 14
06 UNIVERSAL [6] OBJECT IDENTIFIER (ObjectName)
09 length = 9
2b 06 01 02 01 19 01 05 00 = 1.3.6.1.2.1.25.1.5.0
= hrSystemNumUsers.0
42 APPLICATION [2] IMPLICIT INTEGER (ObjectSyntax)
01 length = 1
14 = 20
30 UNIVERSAL [16] SEQUENCE OF constructor (VarBind)
0e length = 14
06 UNIVERSAL [6] OBJECT IDENTIFIER (ObjectName)
09 length = 9
2b 06 01 02 01 19 01 06 00 = 1.3.6.1.2.1.25.1.6.0
= hrSystemProcesses.0
S. McLeod, et al. Expires October 2001 [Page 10]
Internet Draft OID Compression April 2001
42 APPLICATION [2] IMPLICIT INTEGER (ObjectSyntax)
01 length = 1
7e = 126
30 UNIVERSAL [16] SEQUENCE OF constructor (VarBind)
0f length = 15
06 UNIVERSAL [6] OBJECT IDENTIFIER (ObjectName)
09 length = 9
2b 06 01 02 01 19 01 07 00 = 1.3.6.1.2.1.25.1.7.0
= hrSystemMaxProcesses.0
02 UNIVERSAL [2] INTEGER (ObjectSyntax)
02 length = 2
0d ea = 3562
30 UNIVERSAL [16] SEQUENCE OF constructor (VarBind)
18 length = 24
06 UNIVERSAL [6] OBJECT IDENTIFIER (ObjectName)
0b length = 11
2b 06 01 02 01 19 03 02 01 02 01 = 1.3.6.1.2.1.25.3.2.1.2.1
= hrDeviceType.1
06 UNIVERSAL [6] OBJECT IDENTIFIER (ObjectName)
09 length = 9
2b 06 01 02 01 19 03 01 03 = 1.3.6.1.2.1.25.3.1.3
30 UNIVERSAL [16] SEQUENCE OF constructor (VarBind)
26 length = 38
06 UNIVERSAL [6] OBJECT IDENTIFIER (ObjectName)
0b length = 11
2b 06 01 02 01 19 03 02 01 03 01 = 1.3.6.1.2.1.25.3.2.1.3.1
= hrDeviceDescr.1
04 UNIVERSAL [4] OCTET STRING (ObjectSyntax)
17 length = 23
53 75 6e 20 73 70 61 72 63 20 73 75 6e 34 6d 20 31 35 30 20 4d 48 7a
30 UNIVERSAL [16] SEQUENCE OF constructor (VarBind)
10 length = 16
06 UNIVERSAL [6] OBJECT IDENTIFIER (ObjectName)
0b length = 11
2b 06 01 02 01 19 03 02 01 05 01 = 1.3.6.1.2.1.25.3.2.1.5.1
= hrDeviceStatus.1
02 UNIVERSAL [2] INTEGER (ObjectSyntax)
01 length = 1
02 = 2
The following is the compressed version of a PDU containing these
varbinds with values.
1.3.6.1.2.1.25.1.1.0 -- first OID in varbind list is not compressed
0.9.5.0 -- tail of next OID starting at the 9th subid
S. McLeod, et al. Expires October 2001 [Page 11]
Internet Draft OID Compression April 2001
0.9.6.0 -- tail of next OID starting at the 9th subid
0.9.7.0 -- tail of next OID starting at the 9th subid
0.8.3.2.1.2.1 -- tail of next OID starting at the 8th subid
0.11.3.1 -- tail of next OID starting at the 11th subid
0.11.5.1 -- tail of next OID starting at the 11th subid
30 UNIVERSAL [16] SEQUENCE OF constructor(VarBindList)
71 length = 113
30 UNIVERSAL [16] SEQUENCE OF constructor (VarBind)
11 length = 17
4e APPLICATION [14] IMPLICIT OBJECT IDENTIFIER
(nonCompressedDeltaOID )
09 length = 9
2b 06 01 02 01 19 01 01 00 = 1.3.6.1.2.1.25.1.1.0
= uncompressed OID hrSystemUptime.0
43 APPLICATION [3] IMPLICIT INTEGER (ObjectSyntax)
04 length = 4
02 7c 19 74 = 41687412
30 UNIVERSAL [16] SEQUENCE OF constructor (VarBind)
08 length = 8
4f APPLICATION [15] IMPLICIT OBJECT IDENTIFIER
03 length = 3
09 05 00 = 0.9.5.0 -- compressed OID hrSystemNumUsers.0
==> 1.3.6.1.2.1.25.1.5.0
42 APPLICATION [2] IMPLICIT INTEGER (ObjectSyntax)
01 length = 1
14 = 20
30 UNIVERSAL [16] SEQUENCE OF constructor (VarBind)
08 length = 8
4f APPLICATION [15] IMPLICIT OBJECT IDENTIFIER
03 length = 3
09 06 00 = 0.9.6.0 -- compressed OID hrSystemProcesses.0
==> 1.3.6.1.2.1.25.1.6.0
42 APPLICATION [2] IMPLICIT INTEGER (ObjectSyntax)
01 length = 1
7e = 126
30 UNIVERSAL [16] SEQUENCE OF constructor (VarBind)
09 length = 9
4f APPLICATION [15] IMPLICIT OBJECT IDENTIFIER
03 length = 3
09 07 00 = 0.9.7.0 -- compressed OID hrSystemMaxProcesses.0
==> 1.3.6.1.2.1.25.1.7.0
02 UNIVERSAL [2] INTEGER (ObjectSyntax)
02 length = 2
0d ea = 3562
S. McLeod, et al. Expires October 2001 [Page 12]
Internet Draft OID Compression April 2001
30 UNIVERSAL [16] SEQUENCE OF constructor (VarBind)
13 length = 19
4f APPLICATION [15] IMPLICIT OBJECT IDENTIFIER
06 length = 6
08 03 02 01 02 01 = 0.8.3.2.1.2.1 -- compressed OID hrDeviceType.1
==> 1.3.6.1.2.1.25.3.2.1.2.1
06 UNIVERSAL [6] OBJECT IDENTIFIER (ObjectName)
09 length = 9
2b 06 01 02 01 19 03 01 03 = 1.3.6.1.2.1.25.3.1.3
30 UNIVERSAL [16] SEQUENCE OF constructor (VarBind)
1e length = 30
4f APPLICATION [15] IMPLICIT OBJECT IDENTIFIER
03 length = 3
0b 03 01 = 0.11.3.1 -- compressed OID hrDeviceDescr.1
==> 1.3.6.1.2.1.25.3.2.1.3.1
04 UNIVERSAL [4] OCTET STRING (ObjectSyntax)
17 length = 23
53 75 6e 20 73 70 61 72 63 20 73 75 6e 34 6d 20 31 35 30 20 4d 48 7a
30 UNIVERSAL [16] SEQUENCE OF constructor (VarBind)
08 length = 8
4f APPLICATION [15] IMPLICIT OBJECT IDENTIFIER
03 length = 3
0b 05 01 = 0.11.5.1 -- compressed OID hrDeviceStatus.1
==> 1.3.6.1.2.1.25.3.2.1.5.1
02 UNIVERSAL [2] INTEGER (ObjectSyntax)
01 length = 1
02 = 2
The total size of the uncompressed PDU was 155 bytes with 83 bytes
required to encode the OIDs in the name portions of the variable
bindings list.
The total size of the compressed PDU was 115 bytes with only 44 bytes
required to encode the OIDs in the name portions of the variable
bindings list. By applying the lightweight Delta OID Compression
algorithm as described in this document to the variable binding list
above a 47% reduction in the amount of space required to encode the
OIDs for the names in the variable binding list was achieved and the
total PDU size was reduced by 26% overall.
11. When to Compress OIDs
A command generator MAY send messages with compressed OIDs to a
S. McLeod, et al. Expires October 2001 [Page 13]
Internet Draft OID Compression April 2001
command responder if the compressed OID message is expected to
ellicit a response or the command responder has explicitly advertised
the ability to support compressed OIDs. Responses to messages with
compressed OIDs MUST use compressed OIDs if doing so will reduce the
overall size of the response PDU.
If a command generator does not receive a response to a message with
compressed OIDs and was expecting one, the message MUST be resent
without OID compression unless the command responder has advertised,
and the command generator read, the ability to process compressed
payload messages. In the case where a command generator has
determined a priori that a specific command responder is capable of
processing compressed OID messages, the compressed OID message MAY be
resent according to the implementation's retry mechanism.
Before generating messages that ellicit no response, a command
generator MUST ascertain through advertised capabilities that the
command responder is capable of processing compressed OIDs. Once the
command generator has determined whether or not a particular command
responder is capable of processing compressed OID messages, the
command generator SHOULD cache the result and use this for future
messages.
12. OID Compression with Proxy Forwarders
To be written: We must give serious consideration to how OID
compression will function in an environment using proxy forwarding
applications.
13. Security Considerations
To be written, assuming that what we are defining has some effect on
security.
14. IANA Considerations
To be written: Probably nothing, but put here so that we don't
forget about it.
S. McLeod, et al. Expires October 2001 [Page 14]
Internet Draft OID Compression April 2001
15. Appendix A: OID Suppression
NOTE: This appendix is in this document for the purpose of
comparison of the two approaches. It is anticipated that future
companion EOS documents will includes some or all of these
concepts, at which time this appendix will be removed.
OID Suppression reduces the amount of redundant information in a
series of variable bindings by reducing the number of identifiers
required to represent a series of OIDs in an SNMP PDU variable
binding list. OID Suppression is particularly useful in the case of
operations on columnar objects in which the OIDs share the same base
table OID prefix and the same instance information.
Significant suppression of OIDs can be achieved through the
definition of aggregate row objects which would allow multiple
columns from the same conceptual row in a table to be bound together
and represented as a single atomic unit with only a single OID
required to represent the entire row.
15.1. Aggregate Row Objects
Within a single row in a table, the OIDs of each of the columns in
the row contain a substantial amount of redundant information since
each of these OIDs contain the same table prefix and instance
information. The only variation among the OIDs for a group of
objects in the same row of a table is the single subidentifier in the
OID which represents the unique column identifier for that object.
The ability to represent a row as a single aggregate object in an
SNMP PDU would provide a more efficient representation of the row as
this aggregate row object could be represented with a single OID
combined with a sequence of values for the objects in this row. The
aggregate row object's OID would specify the table OID prefix and the
instance information for that row. The value of this row object would
actually be a sequence of individual values for a group of columns in
this row.
15.2. Row Operations Using Aggregate Row Objects
An additional benefit to defining an aggregate row object beyond the
benefit of OID suppression is the ability to perform more efficient
atomic row operations. Instances of objects in the same conceptual
S. McLeod, et al. Expires October 2001 [Page 15]
Internet Draft OID Compression April 2001
row in a table are often treated by manager and agent applications as
a single atomic unit for operational purposes. Until now, though,
the ability to perform row-based operations has been limited to the
scope of MIB implementation rather than protocol implementation.
There is currently no means of representing a conceptual row in a
table as a single atomic unit in an SNMP operation. The ability to
represent a conceptual row as a single aggregate row object would
allow conceptual table rows to be represented in SNMP operations in
the same manner as they are often treated logically by manager and
agent applications and would allow row-based operations to be
performed in a more efficient manner.
15.3. Defining Aggregate Row Objects
In order to identify aggregate row objects uniquely and
unambiguously, it is necessary to define a new naming convention for
aggregate row objects that distinguishes these objects from the
existing conceptual row OIDs. The current convention for naming a
conceptual row, as defined in RFC1902, is to append a subidentifier
of '1' to the table name. For example, the conceptual row 'ifEntry'
is defined by the name 'ifTable.1'.
It is proposed that aggregate row objects be defined by appending the
subidentifier '2' to the table name. Using this naming convention,
'ifTable.2' would be the OID to reference aggregate row objects for
the conceptual ifTable. In order to reference a specific instance of
an aggregate row object, the instance information for that row would
be appended to the aggregate row object's OID. Under this naming
convention, the instance of the aggregate row object that represents
row
In general, the definition of a variable binding for an aggregate row
object would have the following format for a table with N columns:
<table>.2.<instance> = (val1, val2, ..., valN)
The value of the aggregate object would actually be a sequence of
values for the columns in this row of the table.
15.4. Implicit versus Explicit column identification
Aggregate row objects can be defined with either implicit or explicit
S. McLeod, et al. Expires October 2001 [Page 16]
Internet Draft OID Compression April 2001
column identification in the value sequence. Implicit column
identification relies on positional context in order to map a
sequence of values to their corresponding column in a table. Explicit
column identification requires an explicit column identifier to be
specified for each value in the aggregate object. It is foreseeable
that both of these approaches will be useful under different
circumstances.
Implicit column identification would require that a value be
specified for each object in the row. The first value in the
sequence would correspond to the first column in the table. The
second value in the sequence would correspond to the second column,
and so on. This approach requires less encoding for each value as it
would not require that a column identifier be explicitly specified
for each corresponding value. However, in the case where instances of
some of the columns were missing, NULL placeholders would be required
in order to maintain a one-to-one mapping between the sequence of
values and the table columns.
Explicit column identification would require that a column identifier
be explicitly specified for each columnar value in the aggregate row
objects value sequence. This approach would require additional
encoding for the column identifiers but could be beneficial in the
case of tables with a large number of missing columns and could also
be useful for performing operations on a subset of the columns in a
table.
15.5. Encoding Aggregate Row Objects
The ASN.1 variable binding notation requires some changes to
accommodate aggregate objects. It is expected that the new aggregate
row object will only be valid for use in a new set of SNMP PDUs that
are to be defined to address the need for simpler, more efficient row
operations in a separate document. The following is a proposal for
modifying the variable binding notation for these new, yet-to-be-
defined PDUS to allow the varbinds in these PDUs to include both
aggregate and non-aggregate objects. In the following proposal, there
are no changes to the VarBindList or ObjectSyntax definitions.
VarBind ::=
SEQUENCE {
name
ObjectName,
CHOICE {
S. McLeod, et al. Expires October 2001 [Page 17]
Internet Draft OID Compression April 2001
value
ObjectSyntaxNonAggregate,
value
ObjectSyntaxAggregate
}
}
ObjectSyntaxNonAggregate ::=
CHOICE {
ObjectSyntax, -- as in [RFC2578]
ObjectSyntaxExtension, -- new scalar types
ObjectSyntaxNullType -- NULL and exceptions
}
ObjectSyntaxExtension ::=
CHOICE {
-- Nothing for now
-- Eventually there will be new 64 bit types, these
-- are being defined elsewhere
}
-- ObjectSyntaxNullType separated for cleanliness. There is
-- no protocol requirement for this.
ObjectSyntaxNullType ::=
CHOICE {
unSpecified -- in retrieval requests
NULL, -- exceptions in responses
noSuchObject[0]
IMPLICIT NULL,
noSuchInstance[1]
IMPLICIT NULL,
endOfMibView[2]
IMPLICIT NULL
nonInstantiatedRowObject[3] -- plugs holes in rows
IMPLICIT NULL
}
ObjectSyntaxAggregate ::=
CHOICE {
ImplicitAggregate,
ExplicitAggregate
}
ImplicitAggregate ::=
S. McLeod, et al. Expires October 2001 [Page 18]
Internet Draft OID Compression April 2001
[Application 12] IMPLICIT SEQUENCE OF
ObjectSyntaxNonAggregate
ExplicitAggregate ::=
[Application 13] IMPLICIT SEQUENCE OF
EAFragment
EAFragment ::=
SEQUENCE {
EAFragmentNamePart
INTEGER (0..4294967295),
EAFragmentValuePart
ObjectSyntaxNonAggregate
}
Note that, if no aggregate types are used and no
nonInstantiatedRowObject is used, that this notation produces results
equivalent to that of [RFC1905]. That is to say, if no row
operations are used, then the encoding on the wire is unchanged by
this notation.
16. References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC2119, March 1997.
17. Acknowledgements
The authors wish to thank Jeff Case for helpful comments as well as,
in particular, David Perkins and Juergen Schoenwaelder and the NMRG
of the IRTF for their previous work in this area.
18. Authors' Addresses
Sandra McLeod
SNMP Research International
3001 Kimberlin Heights Road
Knoxville, TN 37920
USA
EMail: mcleod@snmp.com
David Partain
S. McLeod, et al. Expires October 2001 [Page 19]
Internet Draft OID Compression April 2001
Ericsson Radio Systems AB
P.O. Box 1248
SE-581 12 Linkoping
Sweden
EMail: David.Partain@ericsson.com
Matt White
Ericsson IP Infrastructure
7301 Calhoun Place
Rockville, MD 20855
EMail: Matt.White@ericsson.com
Table of Contents
1 Background ...................................................... 2
2 Previous work ................................................... 2
3 Terminology ..................................................... 3
4 OID compression versus OID suppression .......................... 4
5 Delta OID Compression Algorithm ................................. 4
5.1 Examples of Compressed OIDs ................................... 5
5.2 Applicability of the Algorithm ................................ 7
6 Use of OID Compression in Notifications ......................... 7
7 Special Considerations .......................................... 8
8 Encoding of compressed OIDs ..................................... 8
9 When to use compressed versus uncompressed OIDs ................. 9
10 Encoding Examples .............................................. 10
11 When to Compress OIDs .......................................... 13
12 OID Compression with Proxy Forwarders .......................... 14
13 Security Considerations ........................................ 14
14 IANA Considerations ............................................ 14
15 Appendix A: OID Suppression ................................... 15
15.1 Aggregate Row Objects ........................................ 15
15.2 Row Operations Using Aggregate Row Objects ................... 15
15.3 Defining Aggregate Row Objects ............................... 16
15.4 Implicit versus Explicit column identification ............... 16
15.5 Encoding Aggregate Row Objects ............................... 17
16 References ..................................................... 19
17 Acknowledgements ............................................... 19
18 Authors' Addresses ............................................. 19
S. McLeod, et al. Expires October 2001 [Page 20]
