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


ID Editor, 

Please post the attached as a personal submission internet draft.


Carl W. Kalbfleisch

Internet Draft                                            C. Kalbfleisch

                                                       25 September 2002

                          Select PDU for SNMPv3


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."

   To view the list Internet-Draft Shadow Directories, see

   Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.


   Traditionally data retrieval from SNMP entities has been done using
   GET, GETNEXT and the GETBULK PDU's. These mechanisms have worked well
   for some instances. However, there are many cases where they are
   inefficient in retrieving data that the management application needs
   to access. The EOS (Evolution of SNMP) Working Group is investigating
   new PDU's to be used to gather information from SNMP entities. This
   memo proposes a select PDU that will operate in much the same way as
   SQL Select.

   Distribution of this memo is unlimited.

1.  Introduction

   This memo defines a new PDU for use with the SNMPv3 framework.

C. Kalbfleisch              Expires Mar 2003                    [Page 1]

INTERNET DRAFT               SNMP SELECT PDU                    Sep 2002

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in [xx].

2.  The SNMP Management Framework

   The SNMP Management Framework presently consists of five major

      o An overall architecture, described in RFC 2271 [1].

      o Mechanisms for describing and naming objects and events for the
      purpose of management. The first version of this Structure of
      Management Information (SMI) is called SMIv1 and described in RFC
      1155 [2], RFC 1212 [3] and RFC 1215 [4]. The second version,
      called SMIv2, is described in RFC 1902 [5], RFC 1903 [6] and RFC
      1904 [7].

      o Message protocols for transferring management information. The
      first version of the SNMP message protocol is called SNMPv1 and
      described in RFC 1157 [8]. A second version of the SNMP message
      protocol, which is not an Internet standards track protocol, is
      called SNMPv2c and described in RFC 1901 [9] and RFC 1906 [10].
      The third version of the message protocol is called SNMPv3 and
      described in RFC 1906 [10], RFC 2272 [11] and RFC 2274 [12].

      o Protocol operations for accessing management information. The
      first set of protocol operations and associated PDU formats is
      described in RFC 1157 [8]. A second set of protocol operations and
      associated PDU formats is described in RFC 1905 [13].

      o A set of fundamental applications described in RFC 2273 [14] and
      the view-based access control mechanism described in RFC 2275

   Managed objects are accessed via a virtual information store, termed
   the Management Information Base or MIB.  Objects in the MIB are
   defined using the mechanisms defined in the SMI.

   This memo specifies a MIB module that is compliant to the SMIv2. A
   MIB conforming to the SMIv1 can be produced through the appropriate
   translations. The resulting translated MIB must be semantically
   equivalent, except where objects or events are omitted because no
   translation is possible (use of Counter64). Some machine readable
   information in SMIv2 will be converted into textual descriptions in
   SMIv1 during the translation process. However, this loss of machine
   readable information is not considered to change the semantics of the

C. Kalbfleisch              Expires Mar 2003                    [Page 2]

INTERNET DRAFT               SNMP SELECT PDU                    Sep 2002

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC2119 [16].

3. Overview

   Efficient retrival of data from SNMP entities is important so that
   management applications can scale to handle the demands of Internet
   Service Providers. When the management application can scale, fewer
   devices are required to deploy the application which turns into
   higher revenue for the company and the ability to offer products and
   services to customers at lower cost with less maintenance.

   In the past, bulk data retrieval from SNMP entities has been done in
   several ways: using GET, GETNEXT and GETBULK PDU's. "PDU Packing" has
   also been suggested to maximize the amount of data that can be stored
   in a pdu, however, this requires the management application to know
   in advance what instances of an attribute exist. This is possible
   with certain "discovery" processes and works for fairly static (in
   terms of the creation and deletion of rows) data.  When the tables
   are large, sparse or dynamic (or all three) this method becomes
   problematic. By the time the discovery process has determined which
   rows to acquire, the indexes have already changed. GETNEXT and
   GETBULK help to solve these problems, however, they can not address
   another new class of problem. This problem involves the case where
   the management application is only required to store the data (and
   therefore would prefer to only retrieve the data) when certain
   conditions are met. The discovery process along with GET does not
   work for the above mentioned reasons.  Similarly, GETNEXT and GETBULK
   are only retrieval mechanisms. They would have to retrieve data only
   to determine that the data needs to be discarded. Since re-writing
   all of the relevant MIBs to include the selection criteria in the
   index values so that GETNEXT and GETBULK could effectively be used is
   impractical, this memo proposes a SNMP SELECT PDU to query the MIB.

   3.1 Background on SELECT

   SQL is an ANSI standard language for accessing databases. A MIB is a
   hierarchical database. Since SQL is so popular, it is useful to apply
   the same technology to MIBs for the purpose of selection criteria.
   The SELECT statement selects data from a MIB table based on certain

   <could insert more background here>

   4.0 Examples

   Consider some examples of data retrieval that can benefit from a

C. Kalbfleisch              Expires Mar 2003                    [Page 3]

INTERNET DRAFT               SNMP SELECT PDU                    Sep 2002

   SELECT criteria.

   4.1 Interface statistics

   It is common to collect interface statistics so that they can be used
   for at least the following purposes:

     o graphing utlization
     o usage based billing
     o calculating performance based SLA's

   However, it is also common to only do this when ifAdminStatus is
   "up". Currently, the data must be acquired from the device along with
   ifAdminStatus. Then a comparison to ifAdminStatus must be performed
   by the management application. Data that does not meet the criteria
   is thrown out while the remainder of the processing continues for the
   data that meets the criteria. In this model ifAdminStatus was queried
   for the sole purpose of doing the "select" in the manager.

   If a SELECT PDU could be sent to the agent it could request:

     select <statistics> from ifEntry where ifAdminStatus='up'

   In this case <statistics> represents the arbitrary set of attributes
   that would be gathered from the SNMP entity. This likely includes
   ifInOctets, ifOutOctets as well as potentially their high-speed
   counterparts depending on the interface type.

   4.2 Application Performance

   Many Internet Service Providers are now moving towards management of
   applications as managed services. When managing an application it is
   desireable to have access to MIBs like SYSAPPL, APPL and WWW-MIB.
   However some of these newer MIBs are not as widely deployed as the
   Host Resources MIB. Let's say we want to report utilization of memory
   and cpu for each of the "apache" processes running on a server.
   Something like the following select would work:

     select hrSWRunPerfCPU, hrSWRunPerfMem from hrSWRunPerf
        where hrSWRunName LIKE "*apache*"

   4.3 Selection of interfaces based on multiple criteria

   It may be useful for a management application to select based on
   multiple selection criteria. For example:

C. Kalbfleisch              Expires Mar 2003                    [Page 4]

INTERNET DRAFT               SNMP SELECT PDU                    Sep 2002

     select ifSpeed, ifPhysAddr, ifMtu from ifTable where
       ifType like *Ethernet*" abd ifOperStatus = "up"

   4.4 Selection of BGP route table entries based on AS

   On large routers the BGP routing tables are huge. Retrieving the
   table with SNMP may be impractical. However, if one wanted to
   determine which routes were for some range of AS numbers then:

     select bgpPeerIdentifier from bgpPeerTable where
       (bgpPeerRemoteAs > 1000) and (bgpPeerRemoteAs < 2000)


   5.1 Justification

   Notice that in each of the examples above the select could be done
   using existing technology by querying the attributes used in the
   WHERE clause and doing the computation in the management application.
   However, if the agent entity could do the selection the following
   benefits are realized:

     o less bandwidth to transfer the data
     o distribute the load of the selection accross a number of devices
     o management application can handle higher number of devices

   In addition, the following advantages of this approach exist:

     o SNMP SELECT PDU is really an extention of GetBulk. Thus code
       basis that support GetBulk should be adaptable with minimal
     o SNMP SELECT PDU uses the existing response PDU.

   5.2 Requirements

   In this section we will outline the requiremetns for a SELECT PDU.

     o Able to retrieve multiple Attributes in the same Row
     o Able to use multiple attributes as the select criteria
     o Selected attributes do not have to be in the same table, but
       must use the same indexing scheme. IE hrSWRunName and
       must be selectable because they are indexed the same but in
       different tables. Another way of saying this is handle
       table aggregations.
     o Minimal code changes. Allows for ease of implementation. The hope
       is that operations gets a boast with low overhead for vendors.

C. Kalbfleisch              Expires Mar 2003                    [Page 5]

INTERNET DRAFT               SNMP SELECT PDU                    Sep 2002

   5.3 Limitations

   In this section the limitations are outlined.

   5.3.1 Selected Attributes will have the same indexing

   When thinking of SQL SELECT, joins come to mind. With a join multiple
   tables are selected at the same time with the result being the union
   of the relevant data from each of the tables. Consider if we wanted
   to select all routes from interfaces that are up. The problem is that
   the resulting data does not have the same indexing. Thus if A is
   returned from the first table and B from the second and they have
   different indexes. When they are joined, A is repeated for relevant
   entries of B. So A is actually retrieved multiple times. This could
   be suppressed.

   <need a better, real example>

   The other problem is that the join is both operationally complex
   (against the S in SNMP) and is memory intensive.

   Therefore although this would be a useful operation, it is suggested
   that this type of operation is broken into two queries. The first
   would select the necessary results from the first table. Then the
   indexes from the first query are used to select data from the second
   table. The manager is then responsible for combining the data.

   5.4 Definition


         PDU FROM SNMPv2-SMI

         Integer32 FROM SNMPv2-PDU;

     Select-PDU ::=
         IMPLICIT SelectPDU

     SelectResponse-PDU ::=

     SelectPDU ::=
           SEQUENCE {

C. Kalbfleisch              Expires Mar 2003                    [Page 6]

INTERNET DRAFT               SNMP SELECT PDU                    Sep 2002


                 INTEGER (0..max-bindings),



      WhereClauseList ::=
            SEQUENCE (SIZE (0..where-clauses)) OF

     WhereClause ::=
            CHOICE {
                whereItem WhereItem,

                and(1) WhereClauseList,
                or(1) WhereClauseList,
                not(1) WhereClauseList

     WhereItem ::=
            SEQUENCE {
                    INTEGER {


   5.5 Explanation

   Notice that the "FROM" clause in the SQL examples is not actually
   mapped into the PDU. This is because the OIDs selected are unique to

C. Kalbfleisch              Expires Mar 2003                    [Page 7]

INTERNET DRAFT               SNMP SELECT PDU                    Sep 2002

   the entire MIB tree. It may be possible to do an OID compression
   technique if the FROM clause were there, but then it would also be
   necessary to specify which table the OID reference is to if the
   attributes can come from multiple tables.

   5.5.1 Selecting Attributes

   The selected-attributes is a VarBindList of the attributes that
   should be returned by the Select. The max-repitions causes the
   response to work similar to GETBULK in that it will return multiple
   rows of data up to max-repitions at a time. In this way, a sequence
   of SelectPDU's may be required to retrieve all of the data desired.
   In this case, on subsequent transmission of SelectPDU, the management
   application should store the OID instance information of the last
   returned attribute in the VarBindList for each attribute.

   5.5.2 The Where Clause

   The WhereClause is embedded in the WhereClauseList constructs.  Since
   WhereItem is a VarBind, the VarBind will contain both the OID and the
   value to compare using the associated operator.

   Conditions may be any of the following:

     =, <>, >, <, >=, <= and LIKE

   When using LIKE, the <value> may be any regular expression.

11.  Author's Addresses

        Carl W. Kalbfleisch
        8700 Stemmons Freeway, Suite 211
        Dallas, TX 75247
        Tel: +1 972-906-2034
        Email: cwk@verio.net

C. Kalbfleisch              Expires Mar 2003                    [Page 8]