[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00                                                            
   Evolution Of SNMP WG                              Satyen Chandragiri
   INTERNET-DRAFT                                   Ranch Networks, Inc
   Expires October 2001                                      April 2001

                   Efficient Transfer of Bulk SNMP Data

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-

   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
   The list of Internet-Draft Shadow Directories can be accessed at

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


   Managing networks and network devices using the Internet Standard
   Management Framework often requires the retrieval of significant
   amounts of MIB data via SNMP, which can result in large latency,
   increased network overhead, and other problems. This memo discusses
   the need for an efficient mechanism for transferring large amounts
   of SNMP data and explores possible solutions for overcoming the
   current limitations of the protocol.

   S.Chandragiri         Expires October 2001                 [Page 1]

                 Efficient Transfer of SNMP Bulk Data       April 2001

Table of Contents

   Status of this Memo................................................1
   Previous Work......................................................3
   Proposed Solution..................................................5
   Security Considerations............................................9
   IANA Considerations................................................9
   Author's Address...................................................9
   Full Copyright Statement..........................................10


   As network elements grow in size and complexity, so do the size of
   MIB tables used to monitor and configure them. Since the first
   introduction of SNMP in the late 1980s, the amount of MIB data that
   is required to be transferred between a command generator and a
   command responder has grown tremendously. For example, the size of
   IP routing tables in a typical backbone router, or the subscriber
   management tables in a cable modem termination system can be quite
   substantial. Retrieving such data via SNMP may involve the transfer
   of several hundred kilobytes of data across a network. Although SNMP
   has evolved substantially, with version 3 providing many desirable
   features such as security and access control, no enhancements have
   been made that address the issue of bulk transfer of SNMP data.

   Using SNMPv1, a command generator has to generate a series of
   GetNextRequests to traverse the MIB tables. For large tables like
   the ones mentioned above, this requires a very large sequence of
   request-response exchanges between the two entities thereby
   resulting in large latency. To address this problem, the
   GetBulkRequest operation was introduced in SNMPv2. This operation
   attempts to reduce the number of protocol exchanges required to
   retrieve a large amount of MIB data by returning a series of
   variable bindings in a single response. The command generator is
   required to specify a "max-repetitions" count, and the command
   responder then fills in as many variable bindings as it can without
   exceeding either this count, or the maximum message size.

   The main problem with retrieving tables using GetBulkRequest is that
   the command generator typically does not know the number of rows in
   the table, and hence cannot set max-repetitions to the optimal
   value. As a result, it must either set max-repetitions to some very
   large value, resulting in a potentially large waste of bandwidth

   S. Chandragiri        Expires October 2001                 [Page 2]

                 Efficient Transfer of SNMP Bulk Data       April 2001

   when many more variable bindings are returned than are needed (this
   is referred to as the "overshoot" problem), or else it must issue
   multiple GetBulkRequests sequentially to traverse a large table.

   Another significant issue affecting the efficiency of bulk transfer
   is network overhead [ref]. This refers to the amount of non-data
   bytes (header information, encoding bytes, etc.) needed to be sent
   along with each PDU. All current versions of SNMP use the Basic
   Encoding Rules (BER) to encode PDUs. Though BER was selected because
   of its simplicity and easy availability, it is quite inefficient in
   terms of network overhead. Added to this is the repetitive
   information contained in OIDs û there are multiple occurrences of
   identical portions of identifiers in the OIDs of the MIB values sent
   in a response. Transferring large amounts of MIB data further
   compounds these problems.

   Retrieving MIB table data (as versus MIB scalars) can pose some
   special problems. The main reason for these problems is that SNMP
   does not recognize table rows and columns and thus all protocol
   operations have to deal with "conceptual" rows and columns. If a
   table allows certain columnar objects of a conceptual row to be
   absent, then it creates "holes" in the table. A command generator
   that is performing a "GetNext" or "GetBulk" on all columnar rows
   will be returned all elements of the following row, except if there
   are "holes", in which case the first columnar object of a row that
   does have this object are returned. The command receiver (generator)
   has to realize that not all returned objects are from the same row,
   and has to correctly reconstruct the MIB table while determining the
   locations of the "holes". This can be very time consuming and
   challenging for a network management application to implement.
   Another problem with tables that have rapidly refreshed values (e.g.
   packet counts, number of active connections, etc.) is that the
   latency in retrieving table rows can create inconsistencies since by
   the time a management application reads a value it may be obsolete
   on the device.

Previous Work

   Several solutions have been proposed and discussed in the past that
   attempt to address the problems mentioned above. These range from
   those requiring no changes to the existing protocol to evolutionary
   changes to the framework to non-SNMP solutions. Some of these
   proposals are described in this section. Each method has its own
   merits and demerits.

  Pipeline Retrieval

   In RFC 1187 "Bulk Table Retrieval with the SNMP", the authors
   propose a pipeline algorithm using multiple threads to traverse
   different sections of a MIB table simultaneously. This improves
   latency because several pieces of MIB data are gathered in parallel,
   however it adds complexity on both the command generator and command

   S. Chandragiri        Expires October 2001                 [Page 3]

                 Efficient Transfer of SNMP Bulk Data       April 2001

   responder especially when packets are dropped and retransmission of
   the request or response is required. It also does not reduce the
   number of request-response exchanges required between the two

  SNMP over TCP

   Another proposal is to extend the transport mapping for SNMP by
   sending the PDUs over a TCP connection rather than UDP. An immediate
   benefit is that UDP's 64KB restriction on the SNMP maximum message
   size is eliminated since TCP's windowing mechanism can be used to
   send several segments of data in parallel. This reduces the number
   of request-response exchanges thereby significantly lowering latency
   as well as network overhead. On the other hand, the SNMP entities
   now have to manage their TCP connections and be able to accommodate
   larger buffers for packet processing.

  Changing PDU Encoding

   As previously mentioned, the BER encoding used for SNMP PDUs is
   inefficient and is a major contributor to network overhead. Several
   alternatives exist, but it should be noted that any other encoding
   scheme in place of BER entails a major change in implementation and
   reduces interoperability. One alternative scheme is "Packed Encoding
   Rules" (PER) which has approximately 30% shorter encodings and
   requires much less encoding buffer space than BER. Other
   possibilities are "Lightweight Encoding Rules" (LER) which allows
   quick encoding and decoding, thereby reducing latency; or
   "Distinguished Encoding Rules" (DER) which have better encoding time
   while also keeping the network overhead low.

  Notification-based GetSubtree

   The GetSubtree operation allows a management application to retrieve
   "subtrees" of MIB data. It first specifies the root of the subtree
   to be retrieved (it can be rooted anywhere û at the head of a table,
   a specific column, etc.) and then triggers the retrieval operation.
   The command responder must then retrieve the MIB data contained
   lexicographically under the specified root and send the retrieved
   values back to the management application. The responder stops when
   it reaches the end of the subtree (thereby eliminating the overshoot
   problem of GetBulk). The responses are sent back as a series of
   Notifications to the management application. Multiple varbinds are
   bundled in each trap packing in as many as allowed by the maximum
   message size constraint. A sequence number is provided so that the
   receiver can detect packet loss and request retransmission (via a
   GetBulk request). The solution can be extended to allow multiple
   subtrees to be retrieved in parallel if the command responder can
   handle it. The limitations of this approach are that a) it requires
   the management application to be registered as a notification
   receiver, b) it tightly couples the command generator and
   notification receiver, and c) in a lossy network this protocol
   degenerates to GetBulk.

   S. Chandragiri        Expires October 2001                 [Page 4]

                 Efficient Transfer of SNMP Bulk Data       April 2001

  Non-SNMP Solutions

   Several non-SNMP based solutions to the bulk MIB-data transfer
   problem have been implemented or proposed. Prominent among them is
   Cisco Systems' FTP-based solution, where the MIB data is retrieved
   and stored in a file on the device, and then transferred to the
   management application via FTP. Two MIB modules are involved: the
   consists of three tables that are used to specify the MIB data
   objects to retrieve and the name of the file, its storage type, and
   encoding format (BER / binary / ASCII). The FTP client MIB has a
   single table that allows the management application to specify the
   FTP server details, and the name of the local file where the data
   should be uploaded. This solution requires FTP capability on both
   SNMP entities and since a non-SNMP transfer mechanism is used,
   security considerations need to be taken into account by the

   Other non-SNMP alternatives for bulk transfer include using MIME or
   XML Document Type Definition (DFD) to encode the MIB data. The data
   can then be transferred via the well-known HTTP protocol since it is
   well suited for bulk transfer of MIME-encapsulated data. However,
   since HTTP is primarily intended for transferring World Wide Web
   data, it has many features and options that are not required for
   management data. However, a compliant implementation will
   nevertheless have to implement those features thereby increasing the
   size and complexity of the SNMP implementations without additional
   benefit. In addition, future evolution of HTTP may add features or
   requirements that make it unsuitable for transferring MIB data.

Proposed Solution

   While each of the proposals above attempts to improve/eliminate one
   or more problem areas (latency, overhead, table retrieval) none
   addresses them all. Specifically, the question of how to handle
   "holes" in MIB tables is not addressed. Moreover, for a solution to
   be widely adopted by the development community it would have to be
   easily implementable and not be overly complex or require special
   resources. Similarly, solutions that are proprietary or rely on non-
   SNMP mechanisms are also not good candidates for standardization as
   an evolutionary change to the SNMP protocol.

   A solution that fits these requirements and adequately addresses the
   problems associated with bulk transfer is the "GetCols" operation
   proposed by David Perkins. This solution requires the addition of a
   new PDU type called "GetColsRequest" to SNMP that will operate as
   explained below. This PDU type will have the same syntax as the
   GetBulkRequest and Response PDUs thus minimizing the effect on

   Columnar objects in MIB tables are usually attributes of modeled
   entities. Management applications often need to retrieve specific

   S. Chandragiri        Expires October 2001                 [Page 5]

                 Efficient Transfer of SNMP Bulk Data       April 2001

   columns of MIB data rather than all columns (i.e. entire rows are
   not required). Moreover, only a certain segment of MIB data (called
   a "slice") may be required rather than the entire table. The
   GetColsRequest is used to specify columns of interest to the
   management application. The command responder sends back only the
   data of interest & terminates the PDU with an "end-of-data" marker.

   The GetColsRequest PDU is identical to the GetBulk PDU, and is as

        BulkPDU ::=
            SEQUENCE {

                    INTEGER (0..max-bindings),

                    INTEGER (0..max-bindings),


   The Response PDU is unchanged from that currently used, and is as

        PDU ::=
            SEQUENCE {

                error-status            -- sometimes ignored
                    INTEGER {
                        noSuchName(2),   -- for proxy compatibility
                        badValue(3),     -- for proxy compatibility
                        readOnly(4),     -- for proxy compatibility

   S. Chandragiri        Expires October 2001                 [Page 6]

                 Efficient Transfer of SNMP Bulk Data       April 2001


                error-index            -- sometimes ignored
                    INTEGER (0..max-bindings),

                variable-bindings   -- values are sometimes ignored

   GetCols Example: The Interfaces Table (ifTable) has 18 columns, but
   a management application may only be interested in retrieving
   ifIndex, ifType, ifAdminStatus and ifOperStatus for all the
   interfaces on a router, and the value of ifTableLastChange. The
   application could use a GetBulkRequest to retrieve the data, but not
   knowing the number of instances present, it would not be able to set
   the "max-repetitions" parameter to an optimal value. As explained
   earlier, this may require the application to make multiple requests
   until the entire table is traversed, or it may cause an overshoot
   problem where a large number of unwanted data from past the end of
   the table is retrieved.

   The GetColsRequest operation can therefore be utilized here in place
   of GetBulkRequest. The request would be constructed as follows:

        GetColsRequest (<request-id>,

   The command responder will reply with a list of varbinds containing
   the value of ifTableLastChange and repetitions of the other varbinds
   and values similar to a GetBulk response, BUT there are important

        a. There will be no "holes" in the response. If an instance
           of a columnar object does not exist, it will use a
           "noSuchInstance" exception in its place rather than skip
           over to the next instance for that column. Thus, each set
           of repetitions in the response has the same instance value.

        b. If the max-repetitions value exceeds the number of instances
           available in the table, the command responder stops at the
           end of the table and adds a "End-Of-Rows" marker in the
           Response PDU rather than overshoot and provide irrelevant
           MIB data that will be discarded by the requester.

   S. Chandragiri        Expires October 2001                 [Page 7]

                 Efficient Transfer of SNMP Bulk Data       April 2001

        c. The OIDs in the Response PDU are compressed to eliminate
           redundancy. Since all repetitions of a columnar value have
           a common OID prefix û differing only in the instance part,
           the Response PDU only needs to use the suffix identifiers
           to distinguish between instance values.

   The OID compression is done as follows: Either two or three sub-
   identifiers are used in place of the complete OID û
        <first sub-id>.<second sub-id>.<third sub-id>  or
        <first sub-id>.<second sub-id>

   The <first sub-id> represents the MIB table to which the instance
   value belongs. In the example above, since all the varbinds belong
   to the same MIB table (ifTable), <first sub-id> would be '0'. Had
   there been objects from other tables, <first sub-id> for those
   instances would be '1', '2', etc.
   The <second sub-id> represents the column to which the instances
   belong. The first requested column will have a value of '0' for
   <second sub-id>, the second column will have a value of '1', and so
   The <third sub-id> is only present for the first columnar instance
   of a row and represents the index value. Since subsequent columnar
   objects of that row have the same index value, it need not be
   specified in the Response, and hence the <third sub-id> is not
   required for these objects.

   An <End-Of-Rows> indication for a table is provided by setting the
   <second sub-id> for that table equal to one more than the number of
   columns requested for the table.

   The Response PDU to the GetCols request in the example presented
   above would therefore be:

        Response (<request-id>,
                  0.0.1:<value>, 0.1:<value>, 0.2:<value>, 0.3:<value>,
                  0.0.2:<value>, 0.1:<value>, 0.2:<value>, 0.3:<value>,
                  0.0.n:<value>, 0.1:<value>, 0.2:<value>, 0.3:<value>,

   The Response contains the non-repeaters (ifTableLastChange in this
   example) followed by a VarBindList for the repeaters. The compressed
   OID values '0.0.x' represent the first requested column (ifIndex in
   this example) where 'x' is the row index. Compressed OID '0.1'
   represents the second requested column (ifType), '0.2' represents
   the third requested column (ifAdminStatus), and '0.3' represents the
   fourth requested column (ifOperStatus). Note that for the second,
   third and fourth columns the row index is not included. The special
   OID '0.4' marks the end of rows for this table (ifTable). Of course,

   S. Chandragiri        Expires October 2001                 [Page 8]

                 Efficient Transfer of SNMP Bulk Data       April 2001

   this is present only if the number of rows returned (n) is less than
   or equal to the max-repetitions requested in the GetCols request. If
   there are more rows in the table, the absence of this marker
   notifies the command generator that there are more rows to be


   The GetCols operation adds a new PDU type to the SNMP protocol, but
   by reusing the same message formats it minimizes the implementation
   effort required to add this feature to existing applications. It
   provides many desirable features such as reduced latency and network
   overhead, elimination of problems caused by holes in MIB tables, and
   OID compression to greatly reduce the amount of data transmitted in
   the Response PDU. The overshoot problem of GetBulk is also
   eliminated because GetCols stops at the end of the table and hence
   the management application can choose a very large value for the
   max-repetitions parameter (constrained mainly by the maximum message
   size limit). Calculations (presented by David Perkins) demonstrate
   that significant performance improvements can be gained by using
   GetCols versus GetBulk operations to retrieve large amounts of MIB

Security Considerations

   <To be completed>

IANA Considerations

   <To be completed>

Author's Address

   Satyen Chandragiri
   Ranch Networks, Inc
   65 Route 34 North
   Suite 200                    Phone:  1-732-817-1900 x264
   Morganville, NJ 07751        Email:  satyen@ranchnetworks.com


   The author wishes to acknowledge Ron Sprenkels, Jean-Philippe
   Martin-Flatin, Juergen Schoenwaelder and other members of the
   Network Management Research Group (NMRG) of the IRTF for their prior

   S. Chandragiri        Expires October 2001                 [Page 9]

                 Efficient Transfer of SNMP Bulk Data       April 2001

   work in this area; and David Perkins for the GetCols proposal
   presented in this document.


   [1] M. Rose, K. McCloghrie, J. Davin, "Bulk Table Retrieval with the
       SNMP", RFC 1187, October 1990

   [2] R. Sprenkels, J. Martin-Flatin, "Bulk Transfers of MIB Data",
       The Simple Times Volume 7 Number 1, March 1999

   [3] D. Thaler, "Subtree Retrieval MIB", Presentation at the 48th
       IETF meeting in Pittsburgh, PA, July 2000

   [4] D. Perkins, "GetCols Operation", Presentation at the 50th IETF
       meeting in Minneapolis, MN, March 2001

Full Copyright Statement

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

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph
   are included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an

   S. Chandragiri        Expires October 2001                [Page 10]