[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Row Operations using OID suppression and aggregate row objects
- To: eos@ops.ietf.org
- Subject: Row Operations using OID suppression and aggregate row objects
- From: Sandra McLeod <mcleod@snmp.com>
- Date: Thu, 17 May 2001 13:22:24 -0400 (EDT)
- cc: Sandra McLeod <mcleod@snmp.com>
- Delivery-date: Thu, 17 May 2001 10:23:04 -0700
- Envelope-to: eos-data@psg.com
- Reply-To: Sandra McLeod <mcleod@snmp.com>
Greetings. The following is some text that outlines an alternative
solution for implementing Row Operations. This approach is a bit
orthogonal to the approach in the current Row Operations draft
(draft-ietf-eos-snmp-rowops-00.txt). This text addresses the
representation of rows using a different OID suppression technique to
provide a simple, logical, efficient representation of rows for row-based
operations. As we consider solutions for Row Operations I think it would
be helpful to look at the different approaches and get an idea of what
others think about each of these and how they meet the requirements for
providing simpler, more efficient row operations. Any comments to the
mailing list on the approach below and in relation to the currently
proposed Row Operations approach in the draft-ietf-eos-snmp-rowops-00.txt
would be appreciated.
Sincerely,
Sandra McLeod
********* Row Operations using OID suppression and aggregate row objects
Goals of OID Suppression for performing Row Operations
OID Suppression techniques provide a mechanism for simpler, more
efficient row-based operations through the definition and use of
aggregate row type objects. OID Suppression can be used to address the
need for more efficient bulk data retrieval, increased efficiency for
performing large atomic configuration operations, and simplified
row-based SNMP operations. OID Suppression as described in this memo
meets these needs in the following ways:
- OID suppression reduces the amount of redundant information in SNMP
PDUs, allowing a greater number of varbinds to be encoded in a
smaller amount of space within a single SNMP PDU. This provides for
more efficient bulk PDUs and allows for larger atomic row
operations.
- The OID suppression technique discussed in this memo introduces a new
aggregate row object type which provides the ability to represent and
operate on a conceptual table row as a single logical unit, which is
often how they are managed and communicated by management
applications.
Terminology
The purpose of this memo is to discuss the benefits of OID Suppression
and its application to row-based operations. However, it is important
for clarification purposes to discuss terminology and, in particular,
the difference between OID Suppression and OID Compression. These two
techniques are similar in that they both attempt to reduce the amount of
space required to encode variable bindings in SNMP PDUs by reducing
redundant information in the name portions of the variable bindings. The
goal of both these techniques is to provide for more efficient bulk data
retrieval and to address current problems of passing large amounts of
configuration information to a command responder in a single atomic SNMP
Set Request. However, OID Suppression and OID Compression use different
approaches to achieve both of these goals and can be applied either
independently or in combination.
OID Suppression reduces the amount of redundant information in the
Object Identifiers in a series of variable binding names by reducing the
actual number of OIDs that must be encoded in the SNMP PDU. OID
suppression is particularly well suited for row-based operations (row
retrieval or configuration) where all of the Object Identifiers for a
row of objects share the same base table OID and instance information.
When using OID Suppression techniques the base table OID and instance
information can be provided once for all objects in the same row, with
only a single column identifier (either implicitly or explicitly
provided) required to represent each column in the row.
OID Compression, on the other hand, reduces the amount of redundant
information in a series of variable binding names by reducing the size
of each OID without actually omitting any OIDs in the encoded SNMP PDU.
This technique can potentially be used to compress any collection of
variable binding names, not just row objects, 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 the variable
bindings include both scalars and tabular objects and a large percentage
of the Object Identifiers in the varbind list have some common base set
of subidentifiers.
The rest of this memo is limited to the scope of OID Suppression and its
application to row operations. OID Compression is discussed in more
detail in the Internet Draft draft-ietf-eos-oidcompression-00.txt.
OID Suppression Through Aggregate Row Objects
OID Suppression can be used to provide more efficient retrieval and
configuration of conceptual rows in a table by reducing the amount of
information required to represent a row of objects. Within a row in a
table, the OIDs of each of the objects in the row contain a substantial
amount of redundant information since each of these OIDs contain the
same table name and instance information. The only variation among the
OIDs for a group of objects in the same row of a table is the single
column subidentifier in the OID which uniquely identifies that specific
column in the table.
OID Suppression, as described in this memo, reduces the amount of
redundant information required to represent a row in a table by allowing
the table name and instance information to be provided only once for the
entire row instead of requiring this information to be provided N times
for N objects in a row. This is achieved through the definition of a
new aggregate row type object. The aggregate row object allows multiple
columns from the same conceptual row to be represented as a single
atomic unit with only a single OID required to identify this row in the
table. The OID of this aggregate row type object would include the
table name and instance information for this row. The value of the
aggregate row object would actually consist of a sequence of values
for the columns in this row.
In general, an aggregate row object with N columns would have the
following format :
<tablename>.2.<instance> = (val1, val2, ..., valN)
The OID for this aggregate row object would include the table name and
instance information. The value of the aggregate object would actually
be a sequence of values for the columns in this row of the table.
In the format specified above, the use of the subidentifier '2'
separating the tablename from the instance information is required to be
able to uniquely and unambiguously distinguish aggregate row objects
from single columnar objects since it is anticipated that aggregate row
objects may be included in SNMP PDUs that also contain non-aggregate
type objects as well. OIDs for single columnar objects will always begin
with the OID prefix <tablename>.1 whereas OIDs for aggregate rows will
always begin with the OID prefix <tablename>.2.
The definition and use of the aggregate row object type would allow a
significant amount of OID suppression to be achieved by removing the
redundant OID information that is normally required to represent a
series of objects in a row. With the use of aggregate row objects, the
tablename and instance information for a row of objects would need to be
provided only once per row instead of N times per row for N objects in a
row. This means that the individual representation of each row would be
more efficient and therefore operations to retrieve and configure rows
using aggregate row objects would be more efficient overall.
Row Operations Using Aggregate Row Objects
OID Suppression through the use of aggregate row objects not only
provides the benefit of more efficient retrieval and configuration of
rows, it also simplifies row-based operations by allowing rows to be
represented and operated on as a single logical unit. This is useful to
management applications which tend to manage tables by conceptual rows
and which often treat objects in the same conceptual row as part of a
larger atomic unit for operational purposes.
One of the ways that aggregate row objects and more efficient row
operations would be beneficial is in the case of row-based configuration
operations where it is desirable for manager applications to be able to
configure an entire conceptual row with a single atomic SNMP
SetRequest. For large tables this can be a problem due to the size of
the required encoding for an entire row and may require that the row be
configured in multiple partial SetRequest operations. This adds
complexity to the agent by requiring that they implement complex state
mechanisms such as RowStatus in their MIB tables. However, the use of
OID Suppression, and in particular, aggregate row objects, means that
row operations are substantially more efficient, allowing a greater
number of row objects to be encoded in a smaller amount of space within
a single SNMP PDU. This would make it easier to configure larger tables
in a single atomic SNMP SetRequest.
The use of aggregate row objects would also help to simplify the
implementation of row-based operations by imposing some ordering to the
objects in each row that is encoded as an aggregate row object in an
SNMP PDU. Aggregate row objectgs that provide values for the row in
order by column would be particularly beneficial to agents implementing
tables with interdependency requirements between values of objects in
the same row of a table.
Implicit versus Explicit column identification
Aggregate row objects can be defined with either implicit or explicit
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 or
possibly in combination with the other.
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.
OID Suppression Example
To illustrate the application of OID suppression to a variable bindings
list consider a row of objects in the snmpNotifyTable :
snmpNotifyTable.1.2.101.110.116.114.121.49 = trapMgrs --snmpNotifyTag
snmpNotifyTable.1.3.101.110.116.114.121.49 = 1 --snmpNotifyType
snmpNotifyTable.1.4.101.110.116.114.121.49 = 3 -- snmpNotifyStorageType
snmpNotifyTable.1.5.101.110.116.114.121.49 = 1 --snmpNotifyRowStatus
The variable bindings list above is presented without the use of OID
Suppression. If OID Suppression is applied to this variable bindings
list, the result would be a single aggregate row object. Below is the
aggregate row object for this row in the snmpNotifyTable with implicit
column identification :
snmpNotifyTable.2.101.110.116.114.121.49 = ( NULL,trapMgrs,1,3,1)
In this example above the 4 objects in the row of the snmpNotifyTable
have been combined into a single aggregate row object. The name portion
of this variable binding is of the format <tablename>.2.<instance>. The
value portion of the aggregate row object is actually a sequence of
values. This sequence of values consists of a value for each of the
columns in the snmpNotifyTable. Note that the first column is NULL as
this is the index column that is defined as not-accessible. The NULL
value acts as a placeholder where holes or inaccessible columns in the
table exist.
It is easy to see that the resulting aggregate row object is
considerably more compact with the redundant OID information removed.
The aggregate row object is more efficient and would require fewer bytes
to encode than the original varbind list above.
If explicit column identification was applied instead of implicit column
identification, then the resulting aggregate row object would look
something like this :
snmpNotifyTable.2.101.110.116.114.121.49 = ( (col2,trapMgrs),
(col3, 1),
(col4, 3),
(col5, 1) )
Note that with explicit column identification the columns that are
inaccessible or which have missing values for this row can be omitted
from the value sequence. This is not possible with implicit column
identification since the position of each value in the sequence is used
to determine which column that value corresponds to.
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.
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 {
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 {
implicitAggregateValue
ImplicitAggregate,
explicitAggregateValue
ExplicitAggregate
}
ImplicitAggregate ::=
[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.
OID Suppression Encoding Cost Comparison
The following is a comparison of cost for encoding a variable bindings
list with and without OID Suppression. Using the following example that
was provided previously in this text with the snmpNotifyTable objects :
snmpNotifyTable.1.2.101.110.116.114.121.49 = trapMgrs --snmpNotifyTag
snmpNotifyTable.1.3.101.110.116.114.121.49 = 1 --snmpNotifyType
snmpNotifyTable.1.4.101.110.116.114.121.49 = 3 -- snmpNotifyStorageType
snmpNotifyTable.1.5.101.110.116.114.121.49 = 1 --snmpNotifyRowStatus
the size of the encoded variable binding list for the row shown above
both with and without OID Suppression is as follows (see further below
for actual encodings) :
Without OID Suppression : 101 bytes
Using OID Suppression and Implicit Column Identification : 44 bytes
Using OID Suppression and Explicit Column Identification : 62 bytes
It is obvious that using OID Suppression provides a significant decrease
in the encoded size of the variable bindings list and therefore provides
a much more efficient representation of this row in the snmpNotifyTable.
In this example, OID Suppression provides a 56% decrease in size when
using implicit column identification and a 40% decrease in size when
explicit column identification is used.
The following is an example of the variable binding list above
encoded with and without OID Suppression. The first encoding example is
provided without any use of OID Suppression. The two subsequent encoding
examples illustrate the encoding of the aggregate row object using OID
Suppression first with implicit and then with explicit column
identification.
Encoding of snmpNotifyTable row without OID Suppression
----------------------------------------------------------------------------
30 UNIVERSAL [16] SEQUENCE OF constructor(VarBindList)
63 length = 99
-- varbind for snmpNotifyTag
30 UNIVERSAL [16] SEQUENCE OF constructor (VarBind)
1c length = 28
06 UNIVERSAL [6] OBJECT IDENTIFIER (ObjectName)
10 length = 16
2b 06 01 06 03 0d 01 01 01 02 65 6e 74 72 79 31
= 1.3.6.1.6.1.3.13.1.1.1.2.101.110.116.114.121.49
= snmpNotifyTag. 101.110.116.114.121.49
04 UNIVERSAL [4] OCTET STRING (ObjectName)
08 length = 8
74 72 61 70 4d 67 72 73 = trapMgrs
-- varbind for snmpNotifyType
30 UNIVERSAL [16] SEQUENCE OF constructor (VarBind)
15 length = 21
06 UNIVERSAL [6] OBJECT IDENTIFIER (ObjectName)
10 length = 16
2b 06 01 06 03 0d 01 01 01 03 65 6e 74 72 79 31
= 1.3.6.1.6.1.3.13.1.1.1.3.101.110.116.114.121.49
= snmpNotifyType. 101.110.116.114.121.49
02 UNIVERSAL [2] INTEGER (ObjectSyntax)
01 length = 1
01 = 1
-- varbind for snmpNotifyStorageType
30 UNIVERSAL [16] SEQUENCE OF constructor (VarBind)
15 length = 21
06 UNIVERSAL [6] OBJECT IDENTIFIER (ObjectName)
10 length = 16
2b 06 01 06 03 0d 01 01 01 04 65 6e 74 72 79 31
= 1.3.6.1.6.1.3.13.1.1.1.4.101.110.116.114.121.49
= snmpNotifyStorageType. 101.110.116.114.121.49
02 UNIVERSAL [2] INTEGER (ObjectSyntax)
01 length = 1
03 = 3
-- varbind for snmpNotifyRowStatus
30 UNIVERSAL [16] SEQUENCE OF constructor (VarBind)
15 length = 21
06 UNIVERSAL [6] OBJECT IDENTIFIER (ObjectName)
10 length = 16
2b 06 01 06 03 0d 01 01 01 05 65 6e 74 72 79 31
= 1.3.6.1.6.1.3.13.1.1.1.5.101.110.116.114.121.49
= snmpNotifyRowStatus.101.110.116.114.121.49
02 UNIVERSAL [2] INTEGER (ObjectSyntax)
01 length = 1
01 = 1
Encoding of snmpNotifyTable row using OID Suppression and
Implicit Column Identification
----------------------------------------------------------------------------
30 UNIVERSAL[16] SEQUENCE OF constructor(VarBindList)
28 length = 42
30 UNIVERSAL [16] SEQUENCE OF constructor (VarBind)
26 length =40
06 UNIVERSAL [6] OBJECT IDENTIFIER (ObjectName)
0f length = 15
2b 06 01 06 03 0d 01 01 02 65 6e 74 72 79 31
= 1.3.6.1.6.1.3.13.1.1.2.101.110.116.114.121.49
= snmpNotifyTable.2.101.110.116.114.121.49
4c APPLICATION [12] SEQUENCE OF ObjectSyntaxNonAggregate
(ImplicitAggregate)
15 length = 21
-- column 1 --> snmpNotifyName (non-accessible index)
83 nonInstantiatedRowObject[3] -- placeholder
00 length = 0
-- column 2 --> snmpNotifyTag
04 UNIVERSAL [4] OCTET STRING (ObjectSyntaxNonAggregate)
08 length = 8
74 72 61 70 4d 67 72 73 = trapMgrs ---value of column2
-- column 3 --> snmpNotifyType
02 UNIVERSAL [2] INTEGER (ObjectSyntaxNonAggregate)
01 length = 1
01 = 1 ---value of column3
-- column 4 --> snmpNotifyStorageType
02 UNIVERSAL [2] INTEGER (ObjectSyntaxNonAggregate)
01 length = 1
03 = 3 ---value of column4
-- column 5 --> snmpNotifyRowStatus
02 UNIVERSAL [2] INTEGER (ObjectSyntaxNonAggregate)
01 length = 1
01 = 1 ---value of column5
Encoding of snmpNotifyTable row using OID Suppression and
Explicit Column Identification
----------------------------------------------------------------------------
30 UNIVERSAL[16] SEQUENCE OF constructor(VarBindList)
3c length = 60
30 UNIVERSAL [16] SEQUENCE OF constructor (VarBind)
3a length =58
06 UNIVERSAL [6] OBJECT IDENTIFIER (ObjectName)
0f length = 15
2b 06 01 06 03 0d 01 01 02 65 6e 74 72 79 31
= 1.3.6.1.6.1.3.13.1.1.2.101.110.116.114.121.49
= snmpNotifyTable.2.101.110.116.114.121.49
4e APPLICATION [13] SEQUENCE OF ObjectSyntaxNonAggregate
(ExplicitAggregate)
27 length = 39
-- column 2 --> snmpNotifyTag
30 APPLICATION [16] SEQUENCE OF EaFragment
0c length = 13
02 UNIVERSAL [2] INTEGER (eaFragmentNamePart)
01 length = 1
02 = 2 -- column 2 identifier
04 UNIVERSAL [4] OCTET STRING
(eaFragmentValuePart)
08 length = 8
74 72 61 70 4d 67 72 73 = trapMgrs
-- column 3 --> snmpNotifyType
30 UNIVERSAL [16] SEQUENCE OF constructor
06 length = 06
02 UNIVERSAL [2] INTEGER (eaFragmentNamePart)
01 length = 1
03 = 3 ---column 3 identifier
02 UNIVERSAL [2] INTEGER (eaFragmentValuePart)
01 length = 1
01 = 1 ---column 3 value
-- column 4 --> snmpNotifyStorageType
30 UNIVERSAL [16] SEQUENCE OF constructor
06 length = 06
02 UNIVERSAL [2] INTEGER (eaFragmentNamePart)
01 length = 1
03 = 3 ---column 4 identifier
02 UNIVERSAL [2] INTEGER (eaFragmentValuePart)
01 length = 1
01 = 1 ---column 4 value
-- column 5 --> snmpNotifyRowStatus
30 UNIVERSAL [16] SEQUENCE OF constructor
06 length = 06
02 UNIVERSAL [2] INTEGER (eaFragmentNamePart)
01 length = 1
02 = 5 ---column 5 identifier
02 UNIVERSAL [2] INTEGER (eaFragmentValuePart)
01 length = 1
01 = 1 ---column 5 value
Additional Considerations
It is expected that the aggregate row objects would only be used in new
PDUs that were defined specifically for the purpose of providing more
efficient row operations to SNMP. It may be that the aggregate row objects
would provide enough efficiency to address current problems with bulk data
retrieval and large configuration operations so that a solution requiring
the definition of PDUs that are specific to certain types of row
operations are unnecessary. Or, it may be that the different types of
row-operation PDUs are still necessary but that these new PDUs can take
advantage of the aggregate row objects to simply the representation of
rows in these new PDUs. In either case, it seems that this is something
that should be researched further.
****************************************************************************
Sandra McLeod <mcleod@snmp.com>
SNMP Research International | voice: +1 865 579-3311
3001 Kimberlin Heights Road | fax: +1 865 573-9197
Knoxville, TN 37920 | WWW: http://www.snmp.com