IPSP Working Group W. Hardaker Internet Draft Network Associates Laboratories draft-hardaker-eos-oops-00.txt June 2001 Object Oriented PDUs for SNMP draft-hardaker-eos-oops-00.txt 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. 1. Introduction This draft specifies some new PDU operations intended to optimize SNMP requests for performance. This draft is very incomplete. The operations for SET semantics didn't make it into the draft in time for publication by the summary 2002 draft deadline. There is not much documentation, and there are no error handling codes or elements of procedures defined yet. The concepts, however, have been thought out about a lot. I haven't finished transforming my thoughts into words and definitions, however, so you have been warned. Feedback, however, would still be greatly appreciated at this point. Wes Hardaker [Page 1]
Internet Draft Object Oriented PDU's for SNMP June 2002 2. Background Many recognized problems exist within the SNMP protocol [XXX: cite the recent drafts that explain this problem area] . The problems addressed by the new protocol operations (PDUs) within this draft are: 1) GET-NEXT complexity A large number of problems result from a devices inability to access it's data in a way that can be efficiently traversed when searching for the next object in a series of GET-NEXT or GET-BULK SNMP requests. Internally, many implementations differ and thus it would be impossible in many cases to define a MIB which would be efficient when implemented on every architecture. The operations defined in this document do not suffer from these problems, as the data can be returned in any order that the agent feels is appropriate. It MUST, however, return data in a consistent manner such that if the same data is requested twice the agent will return the data in the same order. The exact order in which objects are returned is implementation specific. 2) OID compression SNMPv2 PDU consist of a sequence of varbinds and in many cases, when multiple objects are requested from the agent, the OIDs contained within have common prefixes. It is widely recognized as a waste of resources to duplicate this prefix repeatedly. The PDUs defined in this document only rely on a base OID (e.g., an object identifier pointing to a SNMP Table) once, and the sub-objects (e.g., a row in a SNMP Table) underneath it are defined as references from the base OID. Each index set which defines the proper reference for a sub-object is only included once as well. This allows large groups of data to be transmitted while only requiring a single OID to identify the grouping. 3) Row operations The ability to manipulate an entire row within a SNMP Table at once has long been a frustration of programmers implementing the protocol. The PDUs defined in this document are able to operate on entire groups of objects at once, where one of these groupings types is a row within a normal SNMP Table. Wes Hardaker [Page 2]
Internet Draft Object Oriented PDU's for SNMP June 2002 4) Complex object relationships Many people do not properly understand the interrelationships between SNMP Tables and have desired the ability to express their data in a more hierarchal fashion, such that SNMP tables can contain other SNMP tables. Although it is not possible to enable nested datatypes within the SMI today, the SMIng working group is trying to solve these problems and create the ability to define more complex relationships. The way object groupings are referenced within the PDUs defined in this document allows hierarchal object data to be transmitted efficiently and as a single group, thus allowing groups defined within the new SMI to be efficiently transmitted within the PDUs defined in this document, should the new SMI objects be deployed. XXX: mention the intention to make the object definitions a bit extensible, so that new types requiring new parameters can be easily handled in the future without replacing the PDUs themselves. 5) Retrieving of more data than is desired. Extracting only the data needed from a SNMP Table has traditionally required pulling the entire table of data to the management station in many cases, when the indexes and their ordering was not sufficient for requesting subsets of the data desired. The request PDUs defined in this document allow more careful selection of indexing data and allow simple search criteria to be fulfilled. A delicate balance is required to ensure that the devices being polled for data are not taxed with expensive search requests, so the criteria imposed within these documents is limited to simple equality operators. The intention is not to shift all the complex decision processing burden from the management station, but to increase efficiency on the wire. XXX: the agent will actually have the ability to gain improvements from this optimization since the manager will perform fewer operations as a whole. 6) Row hole traversal and object grouping When requests to GET, GET-NEXT, and GET-BULK data come back in a SNMP RESPONSE PDU, the data can be hard to organize back into a logical structure again. Holes of data (a row that contains no data for a particular column) within SNMP Tables make processing of the data collected more tedious. Additionally, GET-BULK responses Wes Hardaker [Page 3]
Internet Draft Object Oriented PDU's for SNMP June 2002 interleave it's data, possibly with END-OF-MIB exceptions, which only adds further complexity to the data processing. Since the PDUs defined in this document deal directly with MIB objects as a whole, the data within an object is preserved. This makes transferring large amounts of data efficient on both the sending and receiving side, as neither side needs to sort VarBinds properly as the data groupings have been appropriately marked within the packet itself. 7) Index parsing and OID length restrictions. Although the encoding and decoding of Table indexes into and out out OIDs is algorithmic, many SNMP software packages and toolkits make mistakes in implementing the algorithm. Additionally, since the maximum length of an OID is limited to 128 sub-identifiers, it limits the size of the index data that can be contained within an OID. This limitation results in poorly designed and broken MIBs and MIBs with less-than-ideal table indexes. The indexes within the PDUs defined in this document are encoded directly into the packet as opposed to being encoded into the OID first (which is then encoded into the packet). This simplifies both management and agent code and reduces the chances of one side incorrectly encoding or decoding the indexes. Additionally, it provides the ability to use a set of indexes which is larger than the OID-encoded length imposed. 8) Transactions The limited set of SNMP transactions have been difficult to cope with when large sets of data must be pushed around, since all the objects within a SNMP SET PDU must be set as if simultaneously. In actuality, configuration data often contains independent segments of data. Typically, independent sets of data must be pushed inside individual PDUS when configuring an agent, which is inefficient. The PDUs defined in this document define a less restrictive and more flexible transaction model that lets large quantities of data be pushed efficiently across the network and will still allow individual groupings to specify whether they are inter-related and must be treated as a single transaction or not. [ XXX note: the draft currently doesn't include the write definitions, but they're similar in design to the request definitions but with some extra fields for operational type [ think modify or replace ] and dependency [ objects within a group will be independent or dependent with respect to each other ]] Wes Hardaker [Page 4]
Internet Draft Object Oriented PDU's for SNMP June 2002 9) Easy conversion to and from popular data formats A desire has been shown by network operators for SNMP objects to be easily accessible and convertable to and from more human friendly expression languages and storage systems, like XML or SQL Databases. The objects within the PDUs contained in this document are designed for such a purpose. It should be, for example, trivial to convert them to and from a hierarchial XML schema set describing the objects in question. 3. Protocol Considerations The PDUs defined in this document all the transmission of large data sets. Although the compression of the data is better than that of the original SNMP PDU types, it is still recommended that large requests be transmitted over a SNMP transmission domain which provides for guaranteed network packet delivery (e.g., TCP). Large responses, containing many objects, carried over transmission domains (e.g., UDP) which can not guarantee delivery are still likely to be problematic. 4. New PDU definitions This section defines the new PDUs. OOPS-SNMP-PDU DEFINITIONS ::= BEGIN IMPORTS ObjectName, ObjectSyntax, Integer32 FROM SNMPv2-SMI; -- -- Object[s] Request -- GetObjectRequest-PDU ::= [XXX] -- 9? SEQUENCE { request-id Integer32, max-objects -- 0 = all Integer32, skip-objects -- 0 = none Integer32, request-objects ObjectRequestList Wes Hardaker [Page 5]
Internet Draft Object Oriented PDU's for SNMP June 2002 } ObjectRequestList ::= SEQUENCE (SIZE (0..max-bindings)) OF ObjectRequest ObjectRequest ::= SEQUENCE { base-object ObjectName search-list IndexObjectList } IndexObjectList ::= SEQUENCE (SIZE (0..max-bindings)) OF IndexObject IndexObject ::= SEQUENCE { index-number Integer32 value ObjectSyntax } -- -- Object[s] Response -- GetObjectResponsePDU ::= [XXX] -- 10? SEQUENCE { request-id Integer32, error-status -- 0 = all Integer32, error-index -- 0 = none Integer32, requested-objects ObjectResponseList } ObjectResponseList ::= SEQUENCE (SIZE (0..max-bindings)) OF Wes Hardaker [Page 6]
Internet Draft Object Oriented PDU's for SNMP June 2002 MibObject MibObject ::= SEQUENCE { object-name ObjectName object-data ObjectDataList } ObjectDataList ::= SEQUENCE (SIZE (0..max-objects)) OF CHOICE { index-data, ObjectDataList, object-data ObjectDataList, } ObjectDataList ::= SEQUENCE (SIZE (0..max-bindings)) OF ObjectData ObjectData ::= SEQUENCE { component-number INTEGER (0..max-bindings), CHOICE { value ObjectSyntax, sub-object ObjectData } } END 5. Examples Here are some example requests and response. In each case, the curly brases indicate a sequence of some kind within BER (in the case of index lists, they'd be a application taged sequence as opposed to the normal BER sequence). Example 1) Retrieve the 5th interface from the ifTable GetObjectRequestPDU { request-id 1 Wes Hardaker [Page 7]
Internet Draft Object Oriented PDU's for SNMP June 2002 max-objects 0 -- get all (due to indexes == 1) skip-objects 0 -- starting with the first request-objects ::= { { -- sic base-object ::= OID:ifTable search-list ::= { index-number = INTEGER:1 value = INTEGER:2 } } } GetObjectResponsePDU { request-id 1 error-status 0 -- noError error-index 0 -- must be 0 if noError request-objects ::= { { object-name ::= OID=ifTable object-data ::= { { -- ifIndex { { index-number ::= INTEGER: 1, value ::= INTEGER: 5 } } { -- ifIndex [it's accessible, so it must be returned] { component-number ::= INTEGER: 1, value ::= INTEGER: 5 }, -- ifDescr { component-number ::= INTEGER: 2, value ::= STRING: "interface 5" }, -- ifType { component-number ::= INTEGER: 3, value ::= INTEGER: 6 }, -- -- ... -- -- ifSpecific { component-number ::= INTEGER: 22, value ::= OBJID: 0.0 }, } } } } } } Example 2) Retrieve the entire ifTable as a single group. Note that Wes Hardaker [Page 8]
Internet Draft Object Oriented PDU's for SNMP June 2002 the response has the objects returned in the order the remote agent specified [interface 12, then interface 5, then ...], not in something that would map to proper lexographical ordering. The order returned must be consistent from one request to the next, but the manner in which the ordering is accomplished is ipmlementation specific. GetObjectRequestPDU { request-id 2 max-objects 0 -- get all skip-objects 0 -- starting with the first request-objects ::= { { -- sic base-object = ifTable search-list ::= { } } } GetObjectResponsePDU { request-id 2 error-status 0 -- noError error-index 0 -- must be 0 if noError request-objects ::= { { -- object-name ::= OID=ifTable object-data ::= { { -- ifIndex { { index-number ::= INTEGER: 12, value ::= INTEGER: 1 } } { -- ifIndex [it's accessible, so it must be returned] { component-number ::= INTEGER: 12, value ::= INTEGER: 1 }, -- -- ... -- -- ifSpecific { component-number ::= INTEGER: 22, value ::= OBJID: 0.0 }, } }, { -- ifIndex { { index-number ::= INTEGER: 5, value ::= INTEGER: 2 } } { -- ifIndex [it's accessible, so it must be returned] Wes Hardaker [Page 9]
Internet Draft Object Oriented PDU's for SNMP June 2002 { component-number ::= INTEGER: 5, value ::= INTEGER: 2 }, -- -- ... -- -- ifSpecific { component-number ::= INTEGER: 22, value ::= OBJID: 0.0 }, } }, -- -- ... -- } } } } Example 3) Retrieves 1 entry of the tcpConnTable established to one address from another address. This shows the simple search based mechanisms that lets you retrieve a subset of the total data available and shows how subsets of indexes may be requested. GetObjectRequestPDU { request-id 3 max-objects 1 -- get only 1 skip-objects 0 -- skipping none, (get the first) request-objects ::= { { -- sic base-object = tcpConnTable search-list ::= { { index-number ::= INTEGER: 1, value ::= IPADDR: a.b.c.d } { index-number ::= INTEGER: 3, value ::= IPADDR: v.x.y.z } } } } } GetObjectResponsePDU { request-id 3 error-status 0 -- noError error-index 0 -- must be 0 if noError request-objects ::= { { -- object-name ::= OID=tcpConnTable Wes Hardaker [Page 10]
Internet Draft Object Oriented PDU's for SNMP June 2002 object-data ::= { { -- Indexes { { index-number ::= INTEGER: 1, value ::= IPADDR: a.b.c.d }, { index-number ::= INTEGER: 2, value ::= INTEGER: 9876 }, { index-number ::= INTEGER: 3, value ::= IPADDR: w.x.y.z }, { index-number ::= INTEGER: 4, value ::= INTEGER: 80 } }, { -- tcpConnState { component-number ::= INTEGER: 1, value ::= INTEGER: 5 }, -- established -- tcpConnLocalAddress { index-number ::= INTEGER: 1, value ::= IPADDR: a.b.c.d }, -- tcpConnLocalPort { index-number ::= INTEGER: 2, value ::= INTEGER: 9876 }, -- tcpConnRemAddress { index-number ::= INTEGER: 3, value ::= IPADDR: w.x.y.z }, -- tcpConnRemPort { index-number ::= INTEGER: 4, value ::= INTEGER: 80 } } } } } } 6. Elements of Procedure. To be done... 7. Author's Addresses: Wes Hardaker P.O. Box 382 Davis, CA 95617 Email: hardaker@tislabs.com 8. References I barely had time to write this, let alone make lots of fancy Wes Hardaker [Page 11]
Internet Draft Object Oriented PDU's for SNMP June 2002 references. 9. Full Copyright Statement Copyright (C) The Internet Society (2002). 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 English. 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 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Wes Hardaker [Page 12]