[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
draft-kalbfleisch-eos-select-00.txt
ID Editor,
Please post the attached as a personal submission internet draft.
Carl
--
Carl W. Kalbfleisch
NTT/VERIO
www.nttverio.com
Internet Draft C. Kalbfleisch
NTT/VERIO
25 September 2002
Select PDU for SNMPv3
<draft-kalbfleisch-eos-select-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."
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.
<could insert more background here>
4.0 Examples
Consider some examples of data retrieval that can benefit from a
C. Kalbfleisch Expires Mar 2003 [Page 3]
INTERNET DRAFT SNMP SELECT PDU Sep 2002
SELECT criteria.
4.1 Interface statistics
It is common to collect interface statistics so that they can be used
for at least the following purposes:
o graphing utlization
o usage based billing
o calculating performance based SLA's
However, it is also common to only do this when ifAdminStatus is
"up". Currently, the data must be acquired from the device along with
ifAdminStatus. Then a comparison to ifAdminStatus must be performed
by the management application. Data that does not meet the criteria
is thrown out while the remainder of the processing continues for the
data that meets the criteria. In this model ifAdminStatus was queried
for the sole purpose of doing the "select" in the manager.
If a SELECT PDU could be sent to the agent it could request:
select <statistics> from ifEntry where ifAdminStatus='up'
In this case <statistics> represents the arbitrary set of attributes
that would be gathered from the SNMP entity. This likely includes
ifInOctets, ifOutOctets as well as potentially their high-speed
counterparts depending on the interface type.
4.2 Application Performance
Many Internet Service Providers are now moving towards management of
applications as managed services. When managing an application it is
desireable to have access to MIBs like SYSAPPL, APPL and WWW-MIB.
However some of these newer MIBs are not as widely deployed as the
Host Resources MIB. Let's say we want to report utilization of memory
and cpu for each of the "apache" processes running on a server.
Something like the following select would work:
select hrSWRunPerfCPU, hrSWRunPerfMem from hrSWRunPerf
where hrSWRunName LIKE "*apache*"
4.3 Selection of interfaces based on multiple criteria
It may be useful for a management application to select based on
multiple selection criteria. For example:
C. Kalbfleisch Expires Mar 2003 [Page 4]
INTERNET DRAFT SNMP SELECT PDU Sep 2002
select ifSpeed, ifPhysAddr, ifMtu from ifTable where
ifType like *Ethernet*" abd ifOperStatus = "up"
4.4 Selection of BGP route table entries based on AS
On large routers the BGP routing tables are huge. Retrieving the
table with SNMP may be impractical. However, if one wanted to
determine which routes were for some range of AS numbers then:
select bgpPeerIdentifier from bgpPeerTable where
(bgpPeerRemoteAs > 1000) and (bgpPeerRemoteAs < 2000)
5.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.
<need a better, real example>
The other problem is that the join is both operationally complex
(against the S in SNMP) and is memory intensive.
Therefore although this would be a useful operation, it is suggested
that this type of operation is broken into two queries. The first
would select the necessary results from the first table. Then the
indexes from the first query are used to select data from the second
table. The manager is then responsible for combining the data.
5.4 Definition
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 <value> 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]