SNMP GetRows: an effective scheme for retrieving management information from MIB tables

INTERNATIONAL JOURNAL OF NETWORK MANAGEMENT Int. J. Network Mgmt 2007; 17: 51 67 Published online 6 April 2006 in Wiley InterScience (www.interscience.wiley.com).613 SNMP GetRows: an effective scheme for retrieving management information from MIB tables Yen-Cheng Chen*, and Io-Kuan Chan Department of Information Management, National Chi Nan University, Puli, Nantou 545, Taiwan SUMMARY Management information accessible via SNMP is organized in the Management Information Base (MIB). Many management applications are based on management information within an MIB table. The management information useful for management applications may be located in some rows of an MIB table. Owing to the limitation of current SNMP GetNext and GetBulk services, it is usually inevitable to retrieve all the rows of an MIB table even if some of them are needed. As the size of the MIB table grows, the object retrieval will incur considerable bandwidth and latency. Without loss of the simplicity of SNMP, we propose a novel SNMP service, called GetRows, to provide the capability of object selection via SNMP. Using GetRows, a management application can specify criteria for evaluating rows of an MIB table. Only the object instances in the rows selected by the criteria will be retrieved. Thus, less bandwidth and latency can be achieved by using the proposed GetRows service. Copyright 2006 John Wiley & Sons, Ltd. 1. INTRODUCTION The Simple Network Management Protocol (SNMP) [1] is the current Internet standard for the management of IP networks. As its name indicates, SNMP was designed to be simple such that SNMP can be easily implemented in a variety of network devices. Since the early 1990s, SNMPv1 [2], the first version of SNMP, indeed has been widely supported in many network devices to provide basic and limited network management functions. In recent years, along with the rapid growth of the Internet, various novel network technologies have appeared. The advance of network technologies also brings more complexity and functionality to network elements. This further leads to the growth of size and complexity of the management information in network elements. Management information accessible via SNMP is organized in the Management Information Base (MIB) [3]. Many SNMP management applications are developed based on the MIBs supported in network elements. As the MIBs in network elements grow in size and complexity, there is an increasing need to have a more effective way to access MIBs via SNMP. Thus, versions 2 and 3 of SNMP, called SNMPv2 [4] and SNMPv3 [5] respectively, were proposed to enhance the original version of SNMP, i.e., SNMPv1. One of the enhancements over SNMPv1 is the GetBulk service, proposed in SNMPv2, for retrieving a contiguous sequence of managed objects through a single SNMP request message. The facility of bulk data transfer provided by GetBulk improves the GetNext service in SNMPv1, especially for retrieving managed objects in MIB tables. MIB tables resemble tables in a relational database. Each column of an MIB table is composed of objects of the same type, termed columnar objects; each row of an MIB table is composed of a list of columnar objects, which together represents an entity manageable to SNMP managers. In the SNMP world, each *Correspondence to: Yen-Cheng Chen, Department of Information Management, National Chi Nan University, Puli, Nantou 545, Taiwan E-mail: ycchen@ncnu.edu.tw Copyright 2006 John Wiley & Sons, Ltd. Received 13 September 2003 Revised 2 January 2006 Accepted 2 January 2006

52 Y.-C. CHEN AND I.-K. CHAN object type is identified by a unique object identifier (OID). Each object instance of a columnar object is identified by an object instance identifier, which is the OID of the object type followed by an instance identifier. The instance identifier, similar to the primary key of a database table, is further composed of the values of one or more columnar objects. From the viewpoint of a SNMP manager, object instances in an MIB table are arranged in the lexicographical order of object instance identifiers. The GetBulk service is used to get a bulk of contiguous object instances ordered by object instance identifiers. In practice, the GetBulk service is also often used to find certain object instances in an MIB table if their instance identifiers cannot be determined in advance. For example, a network manager would like to know which interfaces of a network element are abnormal. The operational status of each interface is available in the ifoperstatus object of the iftable table of MIB II [6]. The manager will use GetBulk to get all the instances of the ifoperstatus object, and then determine the interfaces with the value of ifoperstatus equal to down. For such a management application, if the desired objects are within a large MIB table, considerable SNMP traffic will be consumed for retrieving all the object instances, even though very few of the object instances are of interest. This also increases the end-to-end latency for the message transmission. This is a noticeable disadvantage owing to the protocol limitation of SNMP. In practice, a management application may be interested in certain rows that contain specific instances of management information. Usually, these rows can be specified by the values of some columnar objects in the rows. Currently, the underlying SNMP services do not allow a management application to specify the object instances to be accessed by their values. On the other hand, current SNMP agents in network elements are deployed to provide basic object access services. In fact, the advance of computer hardware technologies has made cheaper and more powerful agents possible. It is thus made possible to delegate management tasks to agents. In this paper, we will propose a possible enhancement over SNMP to provide a more effective way to access object instances. A new service, called GetRows, will be proposed to improve the GetBulk service in retrieving objects from MIB tables. Using GetRows, a management application can specify criteria, called a filter, for evaluating rows of an MIB table. Upon receiving a GetRows request, an SNMP agent will find the rows that satisfy the given filter specification, and then only return those object instances in the selected rows. As a consequence, only moderate bandwidth will be consumed for the transmission of those selected objects. In addition, it is no longer necessary for management applications to filter out irrelevant objects from the responses sent by the agent. The GetRows service is designed to adhere to the simplicity property of SNMP. The protocol data unit (PDU) of GetRows follows the same structure as the GetBulk PDU. Therefore, current SNMP implementations can be easily modified to provide the GetRows service. The GetRows service is also designed to minimize the possible processing overheads introduced in SNMP agents. By limiting the complexity of filter specifications, the GetRows service supports simple but practical filters, by which SNMP agents can efficiently extract desired rows of MIB tables. Therefore, it is feasible to implement agents with the GetRows service in a variety of network elements. In this paper, we will describe the protocol details of GetRows, implement the GetRows service, design an MIB browser with the support of GetRows, and develop several efficient management applications by using the GetRows service. Via a proxy agent implementation, we will also compare GetRows with GetNext and GetBulk in number of requests, responses, total octets transmitted, and latency. The comparison will show that GetRows significantly outperforms GetNext and GetBulk for management applications that require a selective retrieval on an MIB table. 2. RELATED WORKS GetNext and GetBulk were designed especially for retrieving objects in MIB tables. The GetNext service was proposed to retrieve an object instance with an OID immediately after a given OID in lexicographical order. Via a sequence of GetNext requests, we can get all object instances of an MIB table. Obviously, the number of GetNext iterations required will be at least the number of rows to retrieve. If the MIB table is large, retrieving object instances will be very time-consuming. Therefore, the GetBulk service was

SNMP GetRows 53 PDU type request-id non-repeaters max-repetitions variable-bindings Figure 1. GetBulkRequest PDU proposed to improve the performance of the GetNext service. GetBulk can be regarded as m GetNext requests packed into a single protocol data unit (PDU), where m is a parameter called max-repetitions, set by the manager. Given max-repetitions m, a single GetBulk request can retrieve at most m contiguous object instances for each requested columnar object at a time. Figure 1 depicts the format of the Get- BulkRequest PDU. The OIDs of the objects to retrieve are specified in the variable-bindings field, which is a sequence of (object name, object value) pairs. Both scalar objects and columnar objects can be specified in variable-bindings. The non-repeaters field indicates the number of scalar objects in variablebindings. If the value of non-repeaters is n, the first n OIDs of variable-bindings will be the OIDs of scalar objects. The remaining OIDs indicate the columns of an MIB table to retrieve. For each columnar object, the max-repetitions field indicates the maximum number of contiguous object instances requested. Several problems have been found when GetNext and GetBulk are used in bulk data transfer of large MIB tables. There are three major issues addressed: latency, network overhead, and table retrieval [7]. Latency refers to the end-to-end delay caused by a number of request/response message exchanges, especially when the GetNext service is used for retrieving large MIB tables. Network overhead is the amount of non-data octets carried in each PDU. Retrieving objects in large MIB tables usually imposes the transmission of a number of SNMP PDUs. Accordingly, considerable network overhead will be incurred. Table retrieval refers to some problems found in retrieving MIB tables. Three table retrieval problems have been identified: holes in tables, table consistency, and GetBulk overshoot. The holes in tables problem is caused by the absence of some object instances in a row entry. The holes in rows may result in a response message containing a set of object instances located in different rows. A considerable effort will be taken to align those object instances for further processing. The table consistency problem is the possible inconsistency of object states caused by the long latency taken to retrieve a large MIB table. GetBulk overshoot is a particular problem in using GetBulk. It is caused by the difficulty of specifying a proper value of max-repetitions in a GetBulk request. A small max-repetitions will result in a number of GetBulk iterations required to retrieve an MIB table. On the other hand, if a larger value of max-repetitions is used, a large number of unwanted data beyond the MIB table will also be retrieved [7,8]. GetBulk overshoot thus takes place. Several improvements have been proposed to address the above issues. End-to-end latency can be reduced by using a pipeline retrieval algorithm [9] or using SNMP over TCP [7]. The network overhead introduced by BER encoding can be shortened by using more effective encoding schemes. In addition, several new SNMP services have been proposed to provide a more effective way to retrieve bulk of objects. The GetCols [8] service was proposed to address table holes, overshoots, and the inefficiency in retrieving tables. To overcome the table holes problem, GetCols uses a nosuchinstance exception to indicate the absence of an object instance instead of returning a subsequent object instance in a different row. To further avoid table overshoots, GetCols adds an End-of-Rows marker in a response when the end of an MIB table is reached. For better efficiency, GetCols also compresses the OIDs in responses to eliminate the redundancy of the common OID prefixes of those object instances in the same table. Heintz [10] proposed GetRow, GetNextRow, and GetBulkRow in a set of possible SNMP extensions to provide row operations on MIB tables. These services facilitate the retrieval of a specific row, the next row, and a range of rows within an MIB table. An OID suppression technique is also adopted in this set of services to eliminate redundant OID information. GetBulkBumper [11] was proposed to overcome the overshoot problem. A new bumper object is defined. The OID of the bumper object will be included as one of the non-repeaters objects in a GetBulk request. The index part in the OID is an end-of-usable-data marker, which guides the agent to limit the range of columnar objects to retrieve. Thus, table overshoots will not occur. GetSubtree [7] was proposed for retrieving objects in an MIB sub-tree. Since the object instances of an MIB table are located in the same MIB sub-tree, one can use GetSubtree to retrieve an MIB table to avoid overshoots. GetPrev [12] was proposed to find the previous object instance of a given OID. With

54 Y.-C. CHEN AND I.-K. CHAN the capability of object search in descending order of OIDs, GetPrev provides a more efficient way to find the object instances of interest. GetModify [13] was proposed to retrieve only the changed data of a MIB table during a polling interval. Many SNMP applications run periodically to collect management information routinely. GetModify is designed to get only the object instances whose values were changed since the previous polling. Thus, considerable SNMP traffic overhead can be reduced. For many management applications, only specific rows of an MIB table are considered necessary. The above solutions still impose a number of object instances returned by the agent, if the object instances of interest are in a large MIB table. Several solutions were proposed to provide the capability of object selection. Gavalas et al. [14] proposed the use of mobile agents (MAs) to support selective retrieval of MIB table objects. MAs are dispatched locally to acquire MIB tables, perform data aggregation, or select useful data. Each MA retrieves an MIB table locally and applies a predetermined filtering pattern to it. Only the rows that meet the filtering criteria will be selected. By delegating the data-filtering task to MAs, the manager can get the selected object instances from MAs. The proposed scheme requires the employment of MAs, and it is still required for each MA to use GetNext or GetBulk to retrieve MIB tables. Hardaker [15] proposed GetObject in his design of new PDUs for use within SNMP. One of the new features in GetObject is the selective retrieval of table objects. In the proposed GetObject request PDU, called Get- Object-PDU, the manager can use the SearchCriteria field to specify a logical expression that indicates the conditions to select objects of interest. SearchCriteria is a recursive data structure, which allows any form of logical expressions for search criteria. Different from other SNMP improvements, Get-Object- PDU is a brand new PDU structure to provide a new way to access objects by SNMP. In addition, the proposed PDU structure is very complicated compared to the original SNMP. It will be a challenge to enhance current SNMP implementations to support GetObject. Furthermore, the high complexity of the provided search criteria will also make difficult the development of SNMP agents. Thus, the enhanced SNMP will probably no longer be a simple network management protocol. 3. THE PROPOSED GETROWS SERVICE In this section, we will propose a new effective solution to selective retrieval of MIB table objects. A new SNMP service called GetRows will be proposed. The new GetRows service preserves the simplicity nature of SNMP by following the same PDU structure as GetBulk and by limiting the complexity of the search criteria for object selection. Thus, without much effort, current SNMP implementations can be modified to support GetRows. In the following, we will first introduce a simple but practical filter construct for object selection. The GetRows service with its PDU structure is then described in detail. 3.1 Filter Construct for Object Selection To provide object selection within an MIB table, we need a scheme to specify the criteria where object instances should be selected for response. We propose the use of a filter construct to specify the criteria for object selection. Essentially, a filter construct can be expressed by a logical expression of conditions that defines the matching criteria to select rows of an MIB table. In principle, one can specify any logical expression of conditions to build a filter construct. However, to support object selection, the agent in a network element should be implemented with considerable effort such that any form of filter constructs can be interpreted and processed properly. This is a challenge for an agent implementation under limited resource in a network element. In fact, a practical logical expression is usually not too complicated. Therefore, we propose the use of simplified logical expressions in filter constructs. A simplified logical expression of conditions can be a single condition, a disjunctive form of conditions, or a conjunctive form of conditions. A condition is represented by a relational expression (objname OP objvalue), where objname indicates a columnar object in an MIB table, OP is a comparison operator, and objvalue is a possible value of the columnar object. A disjunctive (conjunctive) form of conditions is a set of conditions joined by logical operator OR (AND). Figure 2(a c) shows several examples of filter construct. For example, a management

SNMP GetRows 55 (ifdesc = NCNU-to-Hinet-ADSL-1 ) (ifouterrors 0) (a). Single condition (ifspeed 1250000) OR (ifphysaddress = 0090CC08B5DE ) (iftype = 5) OR (iftype = 6) OR (iftype = 22) (b). Disjunctive form (ifadminstatus = 1) AND (ifoperstatus = 2) (ifindex 1) AND (ifindex 16) AND (iflastchange > 60000) (c). Conjunctive form Figure 2. Filter construct examples application is developed to find abnormal network interfaces from the iftable table in MIB II. The ifadminstatus and ifoperstatus objects of iftable indicate the administrative and operational statuses of an interface, respectively. An abnormal interface will be one with ifadminstatus = 1 but ifoperstatus = 2, where 1 denotes up and 2 denotes down. Thus, the filter construct for the management application can be set to a conjunctive form of conditions: (ifadminstatus = 1) AND (ifoperstatus = 2). In spite of the limitation in representing complicated logical expressions, the plain and flat form of filter constructs will facilitate the design the GetRows service and simplify the implementation of agents to support object selection. 3.2 GetRows Service The simplicity characteristic of SNMP has brought the wide employment of SNMP-enabled devices. One of the simplicity features of SNMP is the simple and common PDU structure for use within SNMP. To follow the same philosophy of SNMP, we aim to develop a new SNMP service, called GetRows, without the introduction of new PDU structures in SNMP. Thus, current SNMP implementations can be easily adapted to provide the new GetRows service. The GetRows service is performed by a GetRows request issued by the manager and one or more GetRows responses returned by the agent. The manager specifies a filter construct with other parameters in a GetRows request. The GetRows request is then sent to the agent. The agent selects rows of an MIB table according to the given filter construct in a GetRows request. The requested columnar objects in the selected rows are then sent to the manager via one of more GetRows responses. We define a simple PDU structure RowsPDU for GetRows requests. The Response-PDU, defined in SNMP previously, is used for GetRows responses. Figure 3 shows the modified definition of SNMP PDUs in ASN.1 [16] notations. RowsPDU follows the same PDU structure of GetBulk PDU (BulkPDU). Both PDUs consist of three integer fields and a variable binding list. RowsPDU is composed of four fields: request-id, cond-and-logic, max-return-rows, and variable-bindings, as shown in Figure 4. The PDU structure of Response-PDU, called PDU, is shown in Figure 5. Two additional errors are defined in PDU especially for the GetRows service. A detailed description of SNMP PDUs can be found in RFC 3416 [17]. 3.3 GetRows Request The major purpose of RowsPDU is to carry a filter construct in a GetRows request. As described in Section 3.1, a filter construct is usually composed by several ANDed or ORed conditions. We assume that the number of conditions in a filter construct will not be greater than 127. Since MIB tables are usually composed of several columns, the number of conditions in a filter construct will be usually small. On the other hand, the limited size of SNMP PDUs will not allow the specification of a large filter construct. In

56 Y.-C. CHEN AND I.-K. CHAN -- protocol data units PDUs ::= CHOICE { get-request get-next-request get-bulk-request response set-request inform-request snmpv2-trap report get-rows-request } -- PDUs GetRequest-PDU ::= GetNextRequest-PDU ::= Response-PDU ::= SetRequest-PDU ::= -- [4] is obsolete GetBulkRequest-PDU ::= InformRequest-PDU ::= SNMPv2-Trap-PDU ::= Report-PDU ::= GetRowsRequest-PDU ::= GetRequest-PDU, GetNextRequest-PDU, GetBulkRequest-PDU, Response-PDU, SetRequest-PDU, InformRequest-PDU, SNMPv2-Trap-PDU, Report-PDU, GetRowsRequest-PDU [0] IMPLICIT PDU [1] IMPLICIT PDU [2] IMPLICIT PDU [3] IMPLICIT PDU [5] IMPLICIT BulkPDU [6] IMPLICIT PDU [7] IMPLICIT PDU [8] IMPLICIT PDU [9] IMPLICIT RowsPDU Figure 3. Modified definition of SNMP PDUs addition, it will be convenient for the agent to manipulate a filter construct with fewer conditions. Suppose a filter construct with n conditions is to be included in a RowsPDU. The n conditions will be specified individually in the first n variable bindings (VarBind s) of the variable binding list variablebindings of RowsPDU. The cond-and-logic field of RowsPDU is used to denote the number of conditions and to specify the type of logical operator, either AND or OR, joining those conditions. If the n conditions are joined by AND, the value of cond-and-logic will be set to n. If the n conditions are joined by OR, the value of cond-and-logic will be set to n + 128. In summary, a filter construct is specified by using the cond-and-logic field together with the first n VarBind s of variable-bindings. When used as a condition, VarBind will be a (name, value) pair, where name is an OID and value is a possible value of the columnar object indicated by name. Recall that a condition is in a form of (objname OP objvalue). To store a condition in a VarBind, we need a way to map (objname OP objvalue) to (name, value). For the mapping purpose, each possible comparison operator OP is represented by a unique integer denoted by x. Table 1 lists available comparison operators with their x values. Thus, condition (objname OP objvalue) can be represented by ({objname x}, objvalue), where {objectname x} is of an OID type. Then, {objname x} and objvalue are stored in the name and value part of a VarBind, respectively. Accordingly, the n conditions can be successfully specified in the first n VarBind s. The max-return-rows field of RowsPDU is to denote the maximum number of rows to be returned by the agent. Suppose the value of max-return-rows is m. Then, the agent will return the requested columnar objects within at most the first m rows that satisfy the criteria specified by a filter construct. If the value of max-return-rows is set to 0, the agent will return all the requested columnar objects within the rows satisfying the criteria. The variable-bindings field in RowsPDU is used to specify both conditions and requested columns. Suppose there are n conditions in a filter construct and r columns of objects to be retrieved. There will be n + r VarBind s in the variable-bindings field. The first n VarBind s are

SNMP GetRows 57 RowsPDU ::= SEQUENCE { request-id INTEGER (-214783648..214783647), cond-and-logic INTEGER (0..max-bindings), -- 0..127: conjunctive form of conditions -- 128..255: disjunctive form of conditions -- If cond-and-logic is greater than 127, -- the number of conditions is cond-and-logic 128. max-return-rows INTEGER (0..max-bindings), variable-bindings VarBindList } VarBindList ::= SEQUENCE (SIZE (0..max-bindings)) OF VarBind VarBind ::= SEQUENCE { name ObjectName, -- When used as part of a condition in a GetRows request: -- {ObjectName 0}: ObjectName with an equal-to operator(=) -- {ObjectName 1}: ObjectName with a less-than operator(<) -- {ObjectName 2}: ObjectName with a greater-than operator(>) -- {ObjectName 3}: ObjectName with a less-than-or-equal-to -- operator(<=) -- {ObjectName 4}: ObjectName with a greater-than-or-equal-to -- operator(>=) -- {ObjectName 5}: ObjectName with a not-equal-to operator(!=) -- {ObjectName 6}: ObjectName with a contain operator(?) CHOICE { value ObjectSyntax, -- in responses or -- in conditions of a GetRows request unspecified NULL, -- in retrieval requests -- exceptions in responses nosuchobject [0] IMPLICIT NULL, nosuchinstance [1] IMPLICIT NULL, endofmibview [2] IMPLICIT NULL, endoftable [3] IMPLICIT NULL } } Figure 4. ASN.1 definition of RowsPDU conditions, and the remaining r VarBind s indicate requested columns. Like GetNext and GetBulk, when used to specify a requested column, each VarBind will be a (name, NULL) pair, where name is the OID of a requested columnar object. Since GetRows is designed to retrieve objects from an MIB table, the r columnar objects should be within the same MIB table. In addition, GetRows allows the search of objects started from a certain row of an MIB table. The row can be specified by using the instance identifier of a columnar object. To reduce the length of RowsPDU, we mandate the use of an instance identifier only in the first one of the r VarBind s. Accordingly, the agent will first find the next existing row after the instance identifier and the then start object selection using the given filter construct. For comparison, the cond-and-logic field of RowsPDU corresponds to the non-repeaters field of BulkPDU, used by GetBulk. The non-repeaters field in BulkPDU is to denote the number of scalar objects

58 Y.-C. CHEN AND I.-K. CHAN Operator Integer value (x) Applicable data types Description = 0 Integer, octet string, OID Equal to < 1 Integer Less than > 2 Integer Greater than <= 3 Integer Less than or equal to >= 4 Integer Greater than or equal to!= 5 Integer, octet string, OID Not equal to? 6 Octet string Contain Table 1. Comparison operators used in a condition specified in the variable-bindings field of BulkPDU. Since GetRows is designed especially for retrieving columnar objects in MIB tables, no scalar objects will be specified in the variable-bindings field. Instead, scalar objects are replaced with conditions of a filter construct. Besides, the max-return-rows field resembles the max-repetitions field of BulkPDU. The GetRows service manipulates managed objects of an MIB table in a row-by-row manner. Thus, it will be more convenient to specify the number of rows in the max-return-rows field. 3.4 GetRows Response The object instances selected by a GetRows request will be sent to the manager in one or more GetRows responses. The Response-PDU is used for GetRows responses. If no errors are found, the selected object instances will be held in the variable-bindings filed of Response-PDU. Normally, each VarBind of variable-bindings will store the OID of a columnar object and the value of the object instance. Like the table retrieval problems found in GetNext and GetBulk, table holes may exist in selected rows. To prevent troubles of table holes, the agent will put exception nosuchinstance in a VarBind to indicate a table hole in a certain column. As a result, selected object instances will be returned row by row. In addition, table overshoots may occur when a larger value of max-return-rows was given in the GetRows request. If the number of rows selected is less than the value of max-return-rows, the agent will reach the end of the MIB table and stop object selection. The agent will set flag end OfTable in a VarBind to indicate the end of a requested column. As a result, table overshoots can be avoided. The agent may find errors when processing a GetRows request. The error-status field in a GetRows response will be used to indicate an error found by the agent. Several possible values have been defined for use in the error-status field, as shown in Figure 5. Among them, declareincorrect and notinsametable are defined especially for the GetRows service. Error declareincorrect is used to indicate that an incorrect filter construct was declared in a GetRows request. Error notinsametable indicates that the columnar objects specified in the variable-bindings field are not in the same MIB table. 4. IMPLEMENTATION GetRows is designed to lead to a possible evolution for the enhancement of SNMP. Ease of implementation is key to a successful SNMP evolution. In addition, the required modification to current SNMP implementations should be kept minimal. Currently, there have been a number of SNMP toolkits to facilitate the development of SNMP applications. In fact, most components of current SNMP packages can be reused to implement GetRows. In this section we will present a GetRows implementation based on AdventNet SNMP API [18], which is a Java programming toolkit for rapid development of SNMP-based management applications. AdventNet SNMP API supports all the standard services in SNMPv1, SNMPv2, and SNMPv3. Since GetRows is designed to use PDU structures the same as SNMPv2 s GetBulk, we make use of the AdventNet s low-level API to help the encoding and decoding of GetRows messages.

SNMP GetRows 59 PDU ::= SEQUENCE { request-id INTEGER (-214783648..214783647), error-status -- sometimes ignored INTEGER { noerror(0), toobig(1), nosuchname(2), -- for proxy compatibility badvalue(3), -- for proxy compatibility readonly(4), -- for proxy compatibility generr(5), noaccess(6), wrongtype(7), wronglength(8), wrongencoding(9), wrongvalue(10), nocreation(11), inconsistentvalue(12), resourceunavailable(13), commitfailed(14), undofailed(15), authorizationerror(16), notwritable(17), inconsistentname(18), notinsametable(19), -- for GetRows declareincorrect(20) -- for GetRows }, } error-index -- sometimes ignored INTEGER (0..max-bindings), variable-bindings -- values are sometimes ignored VarBindList Figure 5. ASN.1 definition of PDU A GetRows service requires interactions between the manager in a management station and the agent in a network element. Therefore, our GetRows implementation will involve implementations in both the manager and the agent. In the management station, the manager uses a GetRows request to remotely invoke a GetRows operation, and receives one or more responses to obtain selected objects. For easier implementation, we treat a GetRows PDU as a BulkPDU with a different tag value. Thus, AdventNet s low-level APIs for BulkPDU can be reused to prepare a GetRows PDU. Based on these low-level APIs, we develop a high-level API for invoking GetRows requests. Besides the programming approach, the manager may also use an MIB browser to specify a filter construct and to view selected rows of an MIB table. Network managers usually use a graphical MIB browser to view MIB objects in agents. Advent- Net s high-level API supports a MibBrowser bean for the development of a MIB browser. We use the MibBrowser bean to develop a customized MIB browser with the GetRows service. Different from traditional MIB browsers, our MIB browser allows the manager to specify conditions of a filter construct via graphical interfaces. Then, only the objects selected by the filter construct will be shown in the MIB browser. Figure 6 is the main window of the MIB browser. Figure 7 illustrates the setting of a condition for a filter construct, and Figure 8 shows the display of search results.

60 Y.-C. CHEN AND I.-K. CHAN Figure 6. Main window of the MIB browser Figure 7. Setting a condition of a filter construct

SNMP GetRows 61 Figure 8. Display of search results by GetRows Figure 9. The proxy architecture of the GetRows implementation In a network element, an agent supporting GetRows is required. The agent receives a GetRows request, builds a filter, search objects in an MIB table, and then returns selected objects in one or more responses. Since most SNMP agents are firmware embedded in network elements, we develop a proxy agent on a standalone server to act as an agent with the support of GetRows. Figure 9 illustrates the proxy architecture. While a GetRows request is emitted by a management station, the request will be first forwarded to the proxy agent, where GetRows operations are performed. The proxy agent then uses GetNext or GetBulk to retrieve an MIB table from the agent in a network element. The proxy agent selects the rows that satisfy the filter construct specified in the previous GetRows request. Those requested columns in the selected rows are then sent to the manager via one or more GetRows responses. By the proxy implementation, the manager can use GetRows to manage existing network elements as if their agents support the GetRows service. In the next section, several GetRows experiments will be conducted based on the proxy architecture. In the proxy agent implementation, we also make use of AdventNet s low-level APIs for BulkPDU for helping the decoding of GetRows requests and the encoding of GetRows responses. In summary, the agent performs the following steps of operations for GetRows processing:

62 Y.-C. CHEN AND I.-K. CHAN 1. Decodes a GetRows PDU to obtain each field of a GetRows request. 2. Determines the number of conditions n and the type of logical operator lop from the cond-andlogic field. 3. Determines the maximum number of rows m from the max-return-rows field. 4. Extracts all the variable bindings in the variable-bindings field. 5. Examines all the OIDs specified in variable bindings. If those OIDs are all within the same MIB table, the agent determines the MIB table for object selection and then goes to Step 6. Otherwise, the agent sends a response with a notinsametable error status to the manager. 6. For each of the first n variable bindings, verifies whether the contained condition is valid. If no invalid condition is found, go to Step 7. Otherwise, the agent sends a response with a declareincorrect error status to the manager. 7. Creates a filter by joining the n conditions with logical operator lop. 8. Retrieves the instance identifier of the OID in the n + 1th variable binding and finds the next existing row of the MIB table. 9. Gets the values of the columnar objects used in conditions and determines whether the current row satisfies the criteria specified in the filter construct. If the row is selected for response, the agent retrieves the object instances of requested columns within the row. Those object instances are appended to a variable binding list for response. 10. Finds the next row and goes to Step 9 until m rows are selected or the end of this MIB table is reached. 11. During the fetch of rows, if there is any other error, the agent stops object selection and sends a response with an appropriate error status to the manager. 12. Considering SNMP message size limitation, the agent prepares one or more responses to contain the selected object instances. Then, the responses are sent to the manager. 5. PERFORMANCE EVALUATION Several experiments are conducted to evaluate the performance of GetRows. For comparison, we also evaluate the performance of GetNext and GetBulk when they are used for retrieving the same set of objects specified by GetRows. We compare GetRows with GetNext and GetBulk in number of requests, number of responses, total octets transmitted by the agent, and the end-to-end latency for retrieval of all the selected objects. To perform experiments on real network elements, we adopt our proxy agent architecture in experiments. A proxy agent is configured to perform the required GetRows operations on a network element. In essence, the proxy agent can be regarded as a real agent for a network element in use. We develop GetRows applications in a management station. The performance of GetRows is evaluated based on the message transmissions between the management station and the proxy agent. For performing a GetRows operation, the proxy agent will use GetNext or GetBulk to retrieve MIB tables from the network element. The proxy agent can be regarded as a manager of the network element. The performances of GetNext and GetBulk are thus evaluated based on the message transmissions between the proxy agent and the network element. The network element used in our experiments is a Cisco 7609 router connected to the 10 Gbps backbone of the TWAREN network in Taiwan. TWAREN (TaiWan Advanced Research and Education Network) [19] is an advanced network for research and education in Taiwan. The maximum message size of the Cisco 7609 router is 1400 octets. We perform three experiments on three MIB-II tables of the router: iftable (59 rows), iproutetable (9531 rows), and ipnettomediatable (30 rows). In these experiments, we perform GetRows with different values of max-return-rows. For comparison, while using GetBulk, we set the value of max-repetitions to double of max-return-rows, assuming that in average 50% of rows will be selected. In the case of max-return-rows = 0 (i.e., all the rows of the MIB table will have to be examined), we set the value of max-repetitions to the total number of rows of the MIB table, assuming that the number of rows is known in advance.

SNMP GetRows 63 5.1 Experiment 1: Finding Abnormal Interfaces Our first experiment is conducted to find abnormal interfaces of a router. The iftable table of MIB II provides the required management information for this experiment. An abnormal interface is an interface whose administration status is up but the operational status is down. The two statuses are stored in the ifadminstatus and ifoperstatus objects of iftable. Therefore, to find those abnormal interfaces, we use a GetRows request with a filter construct: (ifadminstatus = 1) AND (ifoperstatus = 2). The requested columns are ifindex, ifphyaddress and iftype. The iftable in the Cisco 7609 router has 59 rows. Suppose all the abnormal interfaces are to be found. Thus, the value of max-return-rows is set to 0, while the maxrepetition in GetBulk is set to 59. In this experiment, only five abnormal interfaces are found. The management station received only one GetRows response containing all the requested columns of the five interfaces. On the other hand, three responses are required for GetBulk to carry the requested columns of all the 59 interfaces. Table 2 shows the performance comparisons of GetRows, GetBulk, and GetNext in terms of number of requests, number of responses, number of octets sent, and latency. The experimental results of total octets and latency are also illustrated in Figure 10. 5.2 Experiment 2: Finding IP Address from Physical Address The second experiment is conducted to perform GetRows operations on the ipnettomedia table of MIB II. The ipnettomedia table is often used for the mapping between IP addresses and physical addresses. Owing to the indexing method of the ipnettomedia table, it will be time-consuming to use the standard SNMP to find the mapped IP address from a physical address. This experiment shows the superiority of GetRows in search of objects by their values. This experiment is designed to find GetRows GetBulk GetNext max-return-rows = 0 max-repetitions = 59 Number of requests 1 1 59 Number of responses 1 3 59 Number of octets for responses 317 3459 4897 Latency (seconds) 0.672 1.109 1.5 Table 2. Experimental results (Experiment 1) Figure 10. Total octets and latency (Experiment 1)

64 Y.-C. CHEN AND I.-K. CHAN the corresponding IP address for a given physical address. The filter construct for this experiment is (ipnettomediaphysaddress = 0107be81e60 ). Suppose the requested columns are ipnettomedia- NetAddress and ipnettomediaifindex. Usually, only one IP address is assigned for each physical address. Therefore, we set max-return-rows = 1 for GetRows and thus max-repetitions = 2 for GetBulk. The ipnet- ToMedia table of the Cisco 7609 router has 30 rows. In this experiment, only one row of requested columns is returned in one GetRows response. Table 3 shows the performance comparisons of GetRows, GetBulk, and GetNext in terms of number of requests, number of responses, number of octets sent, and latency. The experimental results of total octets and latency are also illustrated in Figure 11. 5.3 Experiment 3: Finding Routing Entries for a Particular Routing Protocol The third experiment is designed to demonstrate the superiority of GetRows when the rows to be selected are within a large MIB table. This experiment is conducted to perform GetRows operations on the iproutetable of MIB II, i.e., the routing table of a network element. The Cisco 7609 router has a large iproutetable table with 9531 rows. This experiment is to find the first 10 routing entries established by the IS-IS routing protocol. Thus, the prerequisite filter construct is (iprouteproto = 9), according to the syntax definition of iprouteproto in MIB II. Suppose the requested columns are iproutedest, iproutemask, iproutetype, and iproutenexthop. Table 4 shows the result of this experiment when maxreturn-rows = 10 and max-repetitions = 20. Since there are more than 10 routing entries built by the IS-IS routing protocol, it is not required to traverse the entire routing table when GetBulk and GetNext are used. Nevertheless, the experiment shows that using GetBulk and GetNext still imposes much more bandwidth and latency than GetRows. Figure 12 illustrates the experimental results of total octets and latency. GetRows GetBulk GetNext max-return-rows = 1 max-repetitions = 2 Number of requests 1 8 16 Number of responses 1 8 16 Number of octets for responses 61 768 976 Latency (seconds) 0.329 0.547 1.375 Table 3. Experimental result (Experiment 2) Figure 11. Total octets and latency (Experiment 2)

SNMP GetRows 65 GetRows GetBulk GetNext max-return-rows = 10 max-repetitions = 20 Number of requests 1 18 4 530 Number of responses 1 29 4 530 Number of octets for responses 960 21 171 539 070 Latency (seconds) 0.783 42.766 112.594 Table 4. Experimental result (Experiment 3) Figure 12. Total octets and latency (Experiment 3) 5.4 Observations From the above experiment results, we find that the use of the GetRows service can reduce the number of objects transmitted over the network. Therefore, both the number of octets sent and the number of responses can be kept minimal. This further results in lower end-to-end latency. In addition, GetRows significantly outperforms GetBulk and GetNext especially when object retrievals are performed over a large MIB table. The reason is that it is inevitable for GetNext and GetBulk to retrieve a large portion of the MIB table and then find object instances of interest in the manager side. On the contrary, when GetRows is used, usually only a small portion of the large table will be selected for responses. Besides, with the object selection capability of GetRows, it becomes easier to develop a management application that involves search of objects within an MIB table. On the other hand, additional effort should be taken in the development of the same management application by using GetNext or GetBulk. 6. CONCLUSION SNMP was developed to provide a simple solution to the management of IP networks. For simplicity, GetNext was proposed to retrieve a sequence of columnar objects in MIB tables. For better efficiency, GetBulk was proposed in SNMPv2 to provide the capability of bulk data transfer. Both GetNext and GetBulk are inefficient when used in management applications for a selective retrieval of objects within an MIB table. In this paper, we have proposed the GetRows service to provide an effective object selection scheme for retrieving objects from MIB tables. Compared with other possible improvements

66 Y.-C. CHEN AND I.-K. CHAN over SNMP, the GetRows service was designed carefully to follow the simplicity principle inherent in SNMP. The PDU format of GetRows is identical to current SNMP PDUs. Thus, GetRows can be easily introduced into current SNMP implementations. Furthermore, GetRows was designed to provide a limited but useful logical expression of filter constructs. This feature can greatly minimize processing overheads incurred in the agent for filtering objects. Indeed, our GetRows implementation has demonstrated elegant features. Our experiments have also shown the merits of GetRows in many management applications. With the advance of network technologies and the growth of the Internet, more capabilities supported by SNMP are expected for effective network management. Therefore, it is anticipated that the evolution of SNMP will continue. However, the widespread acceptance by network equipment vendors is key to the delivery of a newer SNMP. One of the barriers to acceptance is the implementation cost of the network management protocol. We have successfully enhanced SNMP with a minimum implementation cost. Experiments have also shown that GetRows achieves better performance due to its capability of object selection. This paper can be a good reference for the development of object selection services in SNMP. Finally, we hope that our effort in GetRows development can contribute to the Internet Engineering Task Force (IETF) for a newer version of SNMP. REFERENCES 1 Hunt R. SNMP, SMNPv2 and CMIP: the technologies for multivendor network management. Computer Communications 1997; 20: 73 88. 2 Case J, Fedor M, Schoffstall M, Davin J. Simple Network Management Protocol. IETF STD 15, RFC 1157, http://www.ietf.org/rfc/rfc1157.txt, May 1990. 3 Rose M, McCloghrie K. Structure and identification of management information for TCP/IP-based internets. IETF STD 16, RFC 1155, http://www.ietf.org/rfc/rfc1155.txt, May 1990. 4 Case J, McCloghrie K, Rose M, Waldbusser S. Protocol operations for Version 2 of the Simple Network Management Protocol (SNMPv2). IETF, RFC 1905, http://www.ietf.org/rfc/rfc1905.txt, January 1996. 5 Case J, Mundy R, Partain D, Stewart B. Introduction and applicability statements for Internet-Standard Management Framework. IETF, RFC 3410, http://www.ietf.org/rfc/rfc3410.txt, December 2002. 6 Rose M, McCloghrie K. Management information base for network management of TCP/IP-based internets, MIB II. IETF, RFC 1213, http://www.ietf.org/rfc/rfc1213.txt, March 1991. 7 Sprenkels R, Philippe J, Flatin M. Bulk transfers of MIB data. Simple Times 1999; 7(1): 1 7. 8 Chandragiri S. Efficient transfer of bulk SNMP data. Evolution of SNMP (EOS) Working Group, Internet draft, http://ietf.cnri.reston.va.us/proceedings/02mar/i-d/draft-ietf-eos-snmpbulk-00.txt, April 2001. [8 March 2006] 9 Rose M, McCloghrie K, Devin J. Bulk table retrieval with SNMP. IETF, RFC 1187, http://www.ietf.org/ rfc/rfc1187.txt, October 1990. 10 Heintz L. SNMP row operations extensions. Internet draft, http://ietf.cnri.reston.va.us/proceedings/02mar/i- D/draft-ietf-eos-snmp-rowops-01.txt, June 2001 [15 February 2006]. 11 Marek Malowidzki. GetBulk worth fixing. Simple Times 2002; 10(1): 3 6. 12 Breitgand D, Raz D, Shavitt Y. SNMP GetPrev: an efficient way to browse large MIB tables. IEEE Journal on Selected Areas in Communication 2002; 20(4): 656 668. 13 Park SH, Park MS. An efficient transmission for large MIB tables in polling-based SNMP. In Proceedings of the 10th International Conference on Telecommunications, Vol. 1, March 2003; 246 252. 14 Gavalas D, Greenwood D, Ghanbari M, O Mahony M. Advanced network monitoring applications based on mobile/intelligent agent technology. Computer Communications 2000; 28(8): 720 730. 15 Hardaker W. Object Oriented Protocol operations for the SNMP Protocol. Evolution of SNMP (EOS) Working Group, Internet draft, http://www3.ietf.org/proceedings/03mar/i-d/draft-ietf-eos-oops.00.txt, Feb. 2003. [8 March 2006] 16 Information processing systems. Open Systems Interconnection, Specification of Abstract Syntax Notation One (ASN.1). International Organization for Standardization, International Standard 8824, December 1987. 17 Presuhn R, Case J. Version 2 of the protocol operations for the Simple Network Management Protocol (SNMP). IETF, RFC 3416, December 2002.

SNMP GetRows 67 18 AdventNet. AdventNet SNMP API 4. http://snmp.adventnet.com/, 2005 [15 February 2006]. 19 TWAREN. TaiWan Advanced Research and Education Network, National Center For High-Performance Computing. http://211.79.61.6/english/, 2005. [8 March 2006] AUTHORS BIOGRAPHIES Yen-Cheng Chen received the Ph.D. degree in computer science from the National Tsing Hua University, Taiwan, in 1992. He was an associative researcher of the ChungHwa Telecom Labs. from 1992 to 1998. From 1998 to 2001, he was an assistant professor of the Department of Information Management, Ming Chuan University, Taiwan. Since August 2001, he has been an assistant professor of the Department of Information Management, National Chi Nan University, Taiwan. His current research interests are network management, wireless networks, and security. Io-Kuan Chan received a Master s degree in Information Management in 2005 from National Chi Nan University (NCNU), Taiwan. She was a researcher in the Computing & Network Communication Laboratory of NCNU during 2002-2005. Since 2006, she works as an IT System Specialist for Venetian Macau Limited, a Hotel Casio in Macau Cotai. Her research interests are network management and Java programming.