Internet Draft C. Kalbfleisch NTT/VERIO 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 http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract 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", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [xx]. 2. The SNMP Management Framework The SNMP Management Framework presently consists of five major components: 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 [15]. 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 MIB. C. Kalbfleisch Expires Mar 2003 [Page 2] INTERNET DRAFT SNMP SELECT PDU Sep 2002 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 [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 criteria. 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 from ifEntry where ifAdminStatus='up' In this case 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.0 SELECT PDU 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 effort. 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 hrSWRunPerfCPU 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. 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 SELECT-PDU DEFINITIONS ::= BEGIN IMPORTS PDU FROM SNMPv2-SMI Integer32 FROM SNMPv2-PDU; Select-PDU ::= [X] IMPLICIT SelectPDU SelectResponse-PDU ::= [X+1] IMPLICIT PDU SelectPDU ::= SEQUENCE { request-id C. Kalbfleisch Expires Mar 2003 [Page 6] INTERNET DRAFT SNMP SELECT PDU Sep 2002 Integer32, max-repetitions INTEGER (0..max-bindings), selected-attributes VarBindList whereClaus WhereClauseList } WhereClauseList ::= SEQUENCE (SIZE (0..where-clauses)) OF WhereClause WhereClause ::= CHOICE { whereItem WhereItem, and(1) WhereClauseList, or(1) WhereClauseList, not(1) WhereClauseList } WhereItem ::= SEQUENCE { attributeAndValue VarBind, condition INTEGER { eq(0), ne(1), gt(2), lt(3), ge(4), le(5), like(6) } } END 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 may be any regular expression. 11. Author's Addresses Carl W. Kalbfleisch NTT/VERIO 8700 Stemmons Freeway, Suite 211 Dallas, TX 75247 USA Tel: +1 972-906-2034 Email: cwk@verio.net C. Kalbfleisch Expires Mar 2003 [Page 8]