[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Generalizing element selection in Wes's -02pre OOPS draft




[If anyone thinks that we shouldn't be having this discussion because Wes
missed the publication deadline, just cover your ears.  Our time at the WG
meeting next week will be more productive if people can see some of the
more detailed items ahead of time.]

In order for us to justify the cost of implementing the new object-oriented
PDUs, we need them to solve our most pressing performance problems.  We
have a problem now that the current draft does not solve, or at least does
not solve very well.  After describing the problem below, I'll propose a
change to Wes's ASN.1 that gives us a solution to this problem.

The problem arises from the fact that as a large end system, we have both a
whole lot of TCP connections, and a whole lot of information about each TCP
connection.  We can have 10000, 20000, or more active TCP connections, and
for each one of these we have, in addition to the information in the
standard TCP Connection table, our own 58-column table that AUGMENTs the
TCP Connection table.  So we need an efficient way to retrieve selected
columns from selected rows of the large virtual table formed by
concatenating the 58 columns in our AUGMENTing table to the existing
columns of the AUGMENTed TCP Connection table.

The only way to deal with AUGMENTing tables in the current draft is to
treat them as entirely separate Request-Objects.  The problem with this
approach is that the agent is free to supply the responses for these
Request-Objects in different orders.  Lining data from the different tables
back up in this case is not impossible for the management application to
do, but it would clearly be preferable if it did not have to do this.

So here's our proposal.  The basic idea is to generalize the
ElementSpecifier, from a column number to a SEQUENCE {tableID, column
number}.  This allows it to identify each column within the virtual table
formed by a base table and one or more AUGMENTing tables.  By generalizing
ElementSpecifier, we get the generalization both for the
request-element-list and for the "which" part of the SearchCriteria.  So a
management application can request any combination of columns from the
tables comprising the virtual table, based on filter criteria for any of
the columns from any of these tables.

The only additional wrinkle is that since the object of the game is to
eliminate OID overhead, we list the table OIDs once in the request and
response, and then refer to them positionally in each ElementSpecifier.  In
effect, we're moving to the PDU the arbitrary integer index optimization
commonly used in the design of many MIB modules.

Here are the changes to Wes's ASN.1, which are really very minimal:

  RequestObject ::=
      SEQUENCE {
        max-return-objects      Integer32,
        skip-objects            Integer32,
        max-depth               Integer32,
        cursor                  OCTET STRING,
        request-flags           RequestCharacteristics,

        option-field            OptionField,

   --   request-base-OID        OBJECT IDENTIFIER, *deleted*
        request-table-list      RequestTableList,  -- new
        request-element-list    ElementsRequestList,
        search-criteria         SearchCriteria
    }

...

  -- new
  -- List of SNMP tables that are referenced in this PDU
  -- The first entry is the base table; additional
  -- entries are tables that augment the base table
  RequestTableList ::=
      SEQUENCE OF OBJECT IDENTIFIER

...

 ElementSpecifier ::=
     CHOICE {
       index-number[0]        -- apply criteria to an index
           IMPLICIT INTEGER,

       subcomponent-number[1] -- apply criteria to a subcomponent
           IMPLICIT INTEGER,

   -- new
   -- Apply criteria to a subcomponent in one of the tables
   -- specified in the request-table-list found earlier in this
   -- PDU.  This allows specification of subcomponents in augmenting
   -- tables.  Note, specifying a table-number of zero refers
   -- to the base table (this is the same as specifying the
   -- the criteria using subcomponent-number[1]).  Subsequent tables
   -- in the request-table-list, if any, are numbered 1, 2, etc.
       table-specific-subcomponent-number[2]
           IMPLICIT SEQUENCE
             {
              table-number        IMPLICIT INTEGER,
              subcomponent-number IMPLICIT INTEGER
             }

   -- renumbered
   -- for SMIv3 replace a 0.0 prefix with the baseOID
       multiple-subcomponent[3] -- apply to a sub[sub,...]component
           IMPLICIT OBJECT IDENTIFIER
    }

...

 ReturnObject ::=
    SEQUENCE {
        error-information-list  ErrorInformationList
        cursor                  OCTET STRING,
        response-flags          RequestCharacteristics,
        option-field            OptionField,

   --   request-base-OID        OBJECT IDENTIFIER, *deleted*
        returned-table-list     RequestTableList,  -- new
        returned-data-list      DataList
    }

Note finally that while our requirement for this new capability is based on
a table that truly AUGMENTs its base table, the new ASN.1 will work equally
well for the case where a table sparsely augments its base table.  The only
constraint is that all the tables identified in the request-table-list have
exactly the same set of indexes, in the same order.

Regards,
Bob

Bob Moore
Advanced Design and Technology
Application Integration Middleware Division
IBM Software Group
+1-919-254-4436
remoore@us.ibm.com