[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
draft-ietf-eos-snmp-rowops-00.txt
- To: "EOS WG (E-mail)" <eos@ops.ietf.org>
- Subject: draft-ietf-eos-snmp-rowops-00.txt
- From: Lauren Heintz <lheintz@cisco.com>
- Date: Mon, 16 Apr 2001 14:35:51 -0700
- Delivery-date: Mon, 16 Apr 2001 14:36:11 -0700
- Envelope-to: eos-data@psg.com
Hi,
Attached is a sneak peek at the rowOps doc (work-in-progress).
Please take a look and provide comments (even simple yeah's and
nay's of support) to the list.
In sum, the described approach provides: new RowState TC
to replace RowStatus, and 5 new Request types (CreateRow,
DeleteRow, EditRow, GetRow, GetNextRow). The appendix
hints at some alternatives to instead consider.
The TBDs (and grammar/spell errors, and murky text, etc) will
get fixed after some measure of agreement on the overall approach
is apparent.
Thanks, Lauren
INTERNET-DRAFT L. Heintz
Cisco Systems, Inc.
16 April 2001
SNMP Row Operations Extensions
<draft-ietf-eos-snmp-rowops-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 (2001). All Rights Reserved.
Abstract
This document describes a set of extensions (protocol operations and
textual conventions) to the existing SNMP framework architecture as
defined in RFC2571. These extensions provide mechanisms for
efficient creation, modification, deletion and retrieval of table
rows.
Table of Contents
1. The SNMP Network Management Framework ....................... 3
2. Overview .................................................... 4
2.1. Terms ..................................................... 4
2.2. Motivations for the Extensions ............................ 4
2.3. Design Goals .............................................. 5
EOS Working Group Expires September 2001 [Page 1]
Internet Draft SNMP Row Operations Extensions 16 April 2001
3. The Extensions .............................................. 6
3.1. RowState .................................................. 6
3.2. Row Operations ............................................ 8
3.2.1. The rowIdentifier ....................................... 9
3.2.2. The operands ............................................ 12
3.2.3. Distinguishing rowIdentifiers from operands ............. 13
3.2.4. RowState and RowStatus Considerations ................... 13
3.2.5. Granularity of Success/Fail ............................. 14
4. Elements of Procedure ....................................... 14
4.1. CreateRow Request Processing .............................. 14
4.2. DeleteRow Request Processing .............................. 14
4.3. EditRow Request Processing ................................ 14
4.4. GetRow Request Processing ................................. 14
4.5. GetNextRow Request Processing ............................. 14
4.6. Entities not supporting SetRow or RetrieveRow. ........... 14
5. Protocol Operations Definitions ............................. 15
6. Managed Object Definitions .................................. 15
7. IANA Considerations ......................................... 16
8. Intellectual Property ....................................... 16
9. Acknowledgements ............................................ 17
10. Security Considerations .................................... 17
11. References ................................................. 17
12. Editor's Addresses ......................................... 20
A. Impact to Other Protocols ................................... 21
B. Alternative Approaches ...................................... 21
C. Examples of Row Operations .................................. 21
C.1. CreateRow with RowStatus .................................. 22
C.2. CreateRow with RowState ................................... 22
C.3. DeleteRow ................................................. 23
C.4. GetRow and GetNextRow ..................................... 24
D. Known issues ................................................ 26
E. Full Copyright Statement .................................... 26
EOS Working Group Expires September 2001 [Page 2]
Internet Draft SNMP Row Operations Extensions 16 April 2001
1. The SNMP Network Management Framework
The SNMP Management Framework presently consists of five major
components:
- An overall architecture, described in RFC 2571 [RFC2571].
- 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 [RFC1155], RFC 1212 [RFC1212] and RFC 1215 [RFC1215].
The second version, called SMIv2, is described in RFC 2578
[RFC2578], RFC 2579 [RFC2579] and RFC 2580 [RFC2580].
- Message protocols for transferring management information. The
first version of the SNMP message protocol is called SNMPv1 and
described in RFC 1157 [RFC1157]. A second version of the SNMP
message protocol, which is not an Internet standards track
protocol, is called SNMPv2c and described in RFC 1901 [RFC1901]
and RFC 1906 [RFC1906]. The third version of the message
protocol is called SNMPv3 and described in RFC 1906 [RFC1906],
RFC 2572 [RFC2572] and RFC 2574 [RFC2574].
- Protocol operations for accessing management information. The
first set of protocol operations and associated PDU formats is
described in RFC 1157 [RFC1157]. A second set of protocol
operations and associated PDU formats is described in RFC 1905
[RFC1905].
- A set of fundamental applications described in RFC 2573
[RFC2573] and the view-based access control mechanism described
in RFC 2575 [RFC2575].
A more detailed introduction to the current SNMP Management Framework
can be found in RFC 2570 [RFC2570].
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
EOS Working Group Expires September 2001 [Page 3]
Internet Draft SNMP Row Operations Extensions 16 April 2001
MIB.
2. Overview
This document describes a set of SNMP extensions to current protocol
operations [RFC1905] to provide for efficient row operations (i.e.
creating, modifying, deleting and retrieving table rows). In
addition, a new textual convention, RowState, is defined to replace
RowStatus in future MIBs. RowState maintains the ability to report
the state of a row, but does not attempt to provide a mechanism to
create or delete a row.
APPENDIX A discusses some of the known impacts that these extensions
may cause to current frameworks or protocols (e.g. AgentX).
It is recognized that any one of several other approaches exist that
could have been used to meet the design goals of this document. As
such, a few of these approaches are briefly discussed in APPENDIX B.
2.1. Terms
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].
Terminology such as "leftmost" or "left" indicates a PDU component
that is transmitted on the wire prior to other components. Thus,
terms such as "rightmost" imply components that have similar, but
opposite semantics.
It is important to understand the difference between the concepts of
protocol operation and row operation and the term rowOp. Protocol
operation refers to a high-level request, such as a SetRequest or
GetRequest (or one of the five new requests defined within this
document). Row operation refers to one logical operation that
affects one specific table row. A protocol operation may contain one
or more row operations. The term rowOp refers to the component parts
of a protocol operation that comprise a single row operation.
2.2. Motivations for the Extensions
Experience with SNMP has shown that there are certain problems and
inefficiencies when using current protocol operations and management
structures to effect configuration changes within managed devices and
when retrieving information. The extensions described in this
EOS Working Group Expires September 2001 [Page 4]
Internet Draft SNMP Row Operations Extensions 16 April 2001
document are specifically designed to minimize, or provide
opportunities to minimize the following problems:
- Requests that contains multiple varbinds that affect only one
row of a table may contain significant redundancy of
information. This is because each varbind contains an object
name (i.e. Object Identifier or OID), and these OIDs may differ
only in the single subid that designates a specific column. In
cases where strings are used as instance identifiers, for
example, UDP maximum-message-size constraints may force
multiple SetRequests to be used to construct a new, or modify
an existing row in a table. Requests containing redundant data
are also more costly to encrypt and decrypt.
- SetRequests may contain multiple varbinds that actually refer
to the same MIB object. For example, varbind one may be
attempting to set the object, foo, to the value 1, while
varbind two may be attempting to set the same object, foo, to
the value 2. In such cases, the SNMP protocol indicates that
implementations may make independant decisions as to which
varbind will effectively be used and which will be ignored.
- SetRequests do not impose any ordering requirements on the
varbinds within a single request, even if they affect different
objects in the same row of a table. This can cause added
complexity in SetRequest processing.
- The RowStatus textual convention [RFC1903] provides a mechanism
for row management. RowStatus most often requires the
implementation of a rather complicated state machine, many of
whose transitions are optional and whose target states are at
times ambiguous. RowStatus also confuses the notion of row
status with the notion of row fate, which also tends to
complicate both the MIB design and the implementation.
2.3. Design Goals
Several goals were identified when considering the kinds of
extensions that were needed:
- allow separate row operations (hereafter referred to as rowOps)
to be performed in a single protocol operation.
- minimize redundant information in a protocol operation. The
extensions should at least make use of OID suppression
techniques to meet this goal. Note that OID suppression
(largely an issue of how data is stored within a PDU) is not
EOS Working Group Expires September 2001 [Page 5]
Internet Draft SNMP Row Operations Extensions 16 April 2001
equivalent to OID compression (data compression algorithms).
Issues of OID compression are considered out of scope for this
document.
- eliminate the need for special MIB objects (e.g. RowStatus)
that control the creation and deletion of rows.
- minimize the impact on existing network management and subagent
protocols such as AgentX, and applications.
- interoperate with legacy MIBs as well as future MIBs.
- operate in existing SNMP networks and not disrupt legacy SNMP-
capable devices.
3. The Extensions
Five new conceptual protocol operations are described in this
document: CreateRowRequest-PDU (aka CreateRow), DeleteRowRequest-PDU
(aka DeleteRow), EditRowRequest-PDU (aka EditRow), GetRowRequest-PDU
(aka GetRow), and GetNextRowRequest-PDU (aka GetNextRow). Each of
these request types are based on the same PDU structure as originally
defined in [RFC1905].
For purposes of discussion, the three requests, CreateRow, DeleteRow
and EditRow are more generically referred to as SetRow class
requests, while GetRow and GetNextRow are referred to as RetrieveRow
class requests.
In addition, a RowState textual convention is defined, which is
intended to replace RowStatus in all future MIB designs. Although
RowState is not a protocol operation, it does serve to reestablish a
distinction between SNMP data types and SNMP operations -- a line
which is blurred in the current RowStatus definition.
3.1. RowState
As mentioned earlier, this document defines a proposed textual
convention, RowState, whose purpose is to replace RowStatus in future
MIBs. This convention provides several important improvements over
RowStatus:
- RowState relaxes some of the row timeout rules that RowStatus
suffers from. Such rules inhibit the usefulness of RowStatus as
a means of temporarily placing system resources (i.e. table
rows) out of service. For example, if an SNMP manager changes
EOS Working Group Expires September 2001 [Page 6]
Internet Draft SNMP Row Operations Extensions 16 April 2001
a given instance of snmpNotifyRowStatus from Active to
NotInService as a means of temporarily disabling one or more
notifications, an unintended side-effect of this action on some
implementations may be that the row is automatically deleted
after some short amount of time has elapsed (typically, a few
minutes).
- More importantly, RowState separates the notion of reporting
row status and the notion of managing row fate (i.e. creation &
deletion). Specifically, the purpose of RowState is to enable
reporting of row state, while matters of creating and deleting
rows are better served by protocol operations.
RowState provides three states: NotReady, NotInService and Active,
which are very similar to the corresponding RowStatus definitions.
Unlike RowStatus, RowState does not provide CreatAndWait, CreateAndGo
or Destroy.
Any entity providing a RowState column in a table must instantiate an
instance of RowState when one or more other column objects in the
same row have been created or instantiated (by whatever means). Using
the new protocol operations defined in this document, it is
unnecessary to directly set or reference a RowState instance in order
to create and activate a new row. The initial state of RowState is
determined at the moment of initial row creation according to the
semantics specified by the MIB designer (as provided within the
Description clause of the RowState object, and much in the same way
that RowStatus descriptions customize the semantics of those
objects). At the time of row creation, the row creator may explicitly
set the RowState object to a desired initial value, but the
processing entity refers to this as a kind of "hint" since the final
decision as to the initial value can only be determined after the
complete row contents within the creation operation has been
evaluated.
One of the other differences between RowState and RowStatus is that
RowState objects can never be automatically deleted from the entity
as a result of timeouts when their states are either NotInService or
Active. This provides the ability to use RowState objects to
indefinitely take a row out of service without the fear of it being
automatically deleted. When, and whether, rows containing RowState
objects are added to, or removed from, non-volatile storage are not
addressed by RowState. Such behavior must be specified by other
means, which is out of scope for this document.
In addition, unlike RowStatus, it is permissible to explicitly set
RowState objects to the NotReady state as a crude means of allowing
traditional SetRequests to delete the row. In this case, deletion
EOS Working Group Expires September 2001 [Page 7]
Internet Draft SNMP Row Operations Extensions 16 April 2001
occurs as a side effect of a row timeout.
The CreateRow request introduces the ability to set either RowStatus
or RowState objects without the need to explicitly include a varbind
in the request. A CreateRow request by convention contains an
implicit operand (i.e. varbind) to set a corresponding RowState
object (if any) to the Active value. This implicit varbind can be
overridden by the inclusion of an actual RowState varbind. For
example, the following two CreateRow requests are logically
identical, as both will attempt to create a newly active fooEntry,
whose index is 1, and whose fooInt object equals 2:
CreateRow (fooEntry.1, fooInt=2);
CreateRow (fooEntry.1, fooInt=2, fooRowState=Active);
These two requests are NOT logically identical:
CreateRow (fooEntry.1, fooInt=2);
CreateRow (fooEntry.1, fooInt=2, fooRowState=NotInService);
Implementations are not required, however, to support such implicit
operands within CreateRow requests for RowStatus objects. This is
intended to maximize the set of possible transition solutions for
vendors of SNMP technology.
The RowState textual convention provides full details of its use and
operation and is provided in section 6.
3.2. Row Operations
The new protocol operations are designed to "fit" in the existing PDU
structure as originally defined in [RFC1905]. One of the alternative
approaches discussed in the Appendix is the possibility of defining a
new PDU structure that allows an even more efficient OID suppression
strategy than the one described herein. However, the initial approach
offered in intended to "look and feel" as close to the current
framework as possible. As will be shown, the current PDU structure is
quite sufficient to obtain significant (but not optimal) OID
suppression benefits.
Formal definitions of the new protocol operations are provided in
section 5. [RFC1905] provides the PDU definition which these new
operations are based on.
Although the old PDU structure is maintained for now, this document
specifies an evolutionary approach in the way that the new protocol
operations are encoded or contained within the PDU. As such, the new
EOS Working Group Expires September 2001 [Page 8]
Internet Draft SNMP Row Operations Extensions 16 April 2001
requests capitalize on OID suppression techniques to minimize
information redundancy and minimize PDU size. Note that the
traditional SNMP protocol operations as defined in [RFC1905] are not
being changed, either in their semantics, the way they are encoded
within a PDU, or the way they are processed.
The following general discussion centers on how the varbinds of the
new protocol operations are formed or constructed. Other components
of the PDU (e.g. error-index) are treated similarly to the current
framework. The elements of procedure, section 4, formally describes
how the new requests are processed. APPENDIX C provides some high-
level examples of the use of these operations.
The varbinds in a PDU form one or more independant row operations
(rowOps). This allows a single CreateRow request, for example, to
create one or more new rows in a single protocol operation. Each
rowOp corresponds to one attempt to create a row, in this case, or
corresponds to one attempt to delete a row in the case of DeleteRow,
and so forth.
Note that the three layers in the diagram below do not describe
different sections of the PDU, rather, they each represent the same
information and structure (at different levels of abstraction).
<CreateRow.............>
<rowOp1><rowOp2><rowOp3>
<vb><vb><vb><vb><vb><vb>
Although the above diagram shows a CreateRow request logically
containing three rowOps (i.e. create three rows) with two consecutive
varbinds per rowOp, in reality, these requests may contain one, two,
or more than two rowOps, each of which may may be comprised of a
differing number of varbinds (i.e. one, two, or more than two). In
addition, the above example (and the ones that follow) could have
substituted a RetrieveRow class request instead of CreateRow,
The varbinds allocatted to a single rowOp serve to function as either
a rowIdentifier or as operands. The next two sections describe these
basic rowOp components.
3.2.1. The rowIdentifier
The first varbind in each rowOp provides basic request parameters,
and is hereafter referred to as the rowIdentifier parameter of a
rowOp. The remaining varbinds in a given rowOp provide the
individual operands (i.e. the affected row objects), which are
hereafter referred to as operands. In the diagram above, the 1st, 3rd
EOS Working Group Expires September 2001 [Page 9]
Internet Draft SNMP Row Operations Extensions 16 April 2001
and 5th varbinds are therefore rowIdentifiers while the 2nd, 4th and
6th varbinds are operands.
The following diagram shows a GetRow request containing a single
rowOp that itself is composed of the required rowIdentifier and two
operands.
<GetRow.......................................>
<rowOp........................................>
<vb1-rowIdentifier><vb2-operand1><vb3-operand2>
In this case, the GetRow request is seeking to retrieve two specific
column objects from a specific row.
To understand how each rowIdentifier varbind is constructed and what
information is contained therein, it is useful to consider how OIDs
for table objects are formed.
An OID for a given object instance in a table can be broken up into
three logical components:
OID = <tableEntryPart><columnPart><instancePart>
If a traditional SetRequest contains two varbinds referring to two
different columns in the same row, it is evident that both OIDs
differ only in the integer value of the columnPart (a single subid).
The other two parts, tableEntryPart and instancePart, therefore, are
identical for each varbind present in a request affecting only a
single table.
A more meaningful representation for rowIdentifier is now possible:
rowIdentifier =
<vb.name=tableEntryPart, vb.type, vb.value=instancePart>
The vb.type MUST specify either OID or Unsigned32. This is because
the instancePart of an OID is actually comprised of one or more table
index values, depending on which table is affected and how many MIB
objects comprise the INDEX clause of that table. For example, for a
table whose INDEX is comprised of a single integer, instancePart will
be a single subid; and for a table whose INDEX is comprised of two or
more objects of any kind, the instancePart will be an OID (index1 +
index2 + ... + indexN) with each index component representing one or
more subids.
In the case where instancePart is a single subid then vb.type MUST be
specified as Unsigned32 and instancePart will be the integer value of
that single subid. Otherwise, vb.type MUST specify an OID as the
EOS Working Group Expires September 2001 [Page 10]
Internet Draft SNMP Row Operations Extensions 16 April 2001
type and the instancePart will be provided as an OID value.
The rowIdentifier of each rowOp in a SetRow or RetrieveRow request
specifies the exact row affected by the rowOp (but not which column
objects are affected in that row).
Consider the case of two or more rowOps in, say, a SetRow request
that affect different rows in the same table. In such cases,
tableEntryPart of all the related rowIdentifier varbinds will contain
identical values. Thus, in order to further minimize information
redundancy, the OID of 1.0 is permitted to be substituted into the
tableEntryPart of any rowIdentifier to indicate the correct
tableEntryPart value for that rowIdentifier is located in the most
recent (leftmost) rowIdentifier whose name was NOT 1.0.
Of course, this implies that rowOps that affect the same table SHOULD
be consecutively placed in the PDU varbind list, and also that the
first rowIdentifier in the PDU MUST NOT contain the value of 1.0.
In this example, a simplified notation is used to help illustrate how
a rowOp (the two middle ones in this case) uses the inheritance OID
(1.0) to minimize PDU size. This example shows four rowOps, each
comprised of one rowIdentifier and one operand (op):
[<foo><op>] [<1.0><op>] [<1.0><op>] [<fum><op>]
The following is logically identical to the preceding example (though
it forms a larger PDU):
[<foo><op>] [<foo><op>] [<foo><op>] [<fum><op>]
Each rowOp is fully independant of any other despite any inheritance
it may use.
Each rowOp MUST contain a single rowIdentifier varbind, which MUST be
the first varbind in each rowOp. The rowIdentifier MUST be fully
formed and cannot contain partial OIDs, as are possible in
traditional getNextRequests. This means that the tableEntryPart MUST
always exactly correspond to a legal table entry definition (if the
desired results are to be achieved). The motivation behind this is
that all rowOps are performed at the row level; therefore, each rowOp
within a given GetNextRow request, for example, MUST refer to a row
(existing or not) after which the next row (if any) is retrieved.
Also note that GetNextRow requests do not "jump" to the next table.
In other words, in the event a GetNextRow rowOp refers to the last
row in a given table, the appropriate exception is returned for that
rowOp even if other tables follow that contain retrievable rows. In
this sense, GetNextRow is limited to operate within the subtree of
EOS Working Group Expires September 2001 [Page 11]
Internet Draft SNMP Row Operations Extensions 16 April 2001
the targeted table(s).
3.2.2. The operands
The remaining varbinds for a given rowOp are referred to as its
operands, and are formed as standard SetRequest varbinds except that
the name of each varbind is an OID whose length is exactly two subids
long and whose first subid is always the value 0. The second subid is
always taken from the affected column descriptor value whose object
instance is affected. This means that each affected column object
within a rowOp is explicitly named. At the expense of wasting a few
octets of PDU size in the storage of subids that are always 0, this
helps avoid processing errors that are possible if an implicit means
of identifying column objects was instead used.
Each operand contained in the same rowOp will have a varbind name
such that varbind N MUST be lexicographically smaller than the name
of varbind N+1. In other words, there is a left to right ordering
relationship imposed on the rowOp operands to further provide
implementation optimization opportunities and to further guarantee
that multiple and possibly conflicting operands for the same column
object cannot be provided (further minimizes information redundancy
and processing ambiguity). For example, the operand with the name
of, 0.1, MUST be to the left of the operand with the name of, 0.2, if
they are operands of the same rowOp.
In cases of RetrieveRow class requests, each rowOp MAY contain zero
or more operands. If zero operands are provided, this implicitly
calls for the retrieval of all instantiated objects in the specified
row. Otherwise, only the specified row objects are retrieved (or
exceptions returned).
In cases of CreateRow, each rowOp MUST contain at least one operand
whose MAX-ACCESS value is read-create. Also, the rows MUST NOT
already exist (in whole or part).
In cases of EditRow, each rowOp contains an operand for each row
object whose value is being changed and whose MAX-ACCESS is either
read-create or read-write. The affected rows MUST already exist (in
whole or part), though the specific operands MAY refer to objects
that do not yet exist.
In cases of DeleteRow, each rowOp MUST NOT contain any operands.
EOS Working Group Expires September 2001 [Page 12]
Internet Draft SNMP Row Operations Extensions 16 April 2001
3.2.3. Distinguishing rowIdentifiers from operands
As described earlier, the varbinds in a rowOp function either as a
rowIdentifier (one per rowOp) or as an operand (zero or more per
rowOp). The first varbind in any SetRow or RetrieveRow request is a
rowIdentifier, because by definition the first varbind in each rowOp
MUST be a rowIdentifier. The varbind names of all rowIdentifiers are
guaranteed to be OIDs with a minimum of three subids (because current
SMIv2 rules and current IANA object registrations preclude the
possibility that table entry definitions can have shorter OIDs). One
exception to this, is that varbind names for rowIdentifiers may
contain the special OID value of, 1.0, which serves to indicate that
the varbind name in the previous rowIdentifier (whose name is not
equal to 1.0) is to be logically inherited or substituted in place of
the 1.0 value.
The varbind names of all operands, on the other hand, are OID values
with exactly two subids and whose first subid MUST be 0. Note that
0.0 is a legal varbind name for an operand (if the affected column
descriptor is equal to 0).
In summary, if a varbind name contains two subids, the first of which
equals 0, then the varbind in question functions as an operand.
Otherwise, the varbind functions as a rowIdentifier.
3.2.4. RowState and RowStatus Considerations
It is worthwhile to note that SetRow class requests allow new MIBs to
be created without requiring use of the RowStatus or RowState textual
conventions to allow for either incremental or "big-bang" style (i.e.
CreateAndWait or CreateAndGo, resp.) row creation or deletion.
RowState is useful only to report the current state of a row --
notwithstanding the slight anomaly that it also allows SetRequests
and EditRow requests to explicitly change the state of such objects
to NotReady, and thereby cause a row deletion timer to be
instantiated. Similarly, traditional SetRequests and SetRow requests
can both be used to manage MIBs that incoporate RowStatus columns.
For new MIB tables that do not require row state reporting objects,
but which do require creation and/or deletion semantics, it is
sufficient to omit RowState and RowStatus entirely and instead use a
MAX-ACCESS of read-create for all writable objects. Such tables can
elegantly support row creation through use of the CreateRow or
traditional SetRequest operations, and also support row deletion
through use of the DeleteRow operation.
EOS Working Group Expires September 2001 [Page 13]
Internet Draft SNMP Row Operations Extensions 16 April 2001
3.2.5. Granularity of Success/Fail
In the event a SetRow class request contains two or more rowOps that
affect the same row, the elements of procedure (below) indicate that
all rowOps in the SetRow request are to be rejected (i.e. all rowOps
fail and the entity remains in the state it was in prior to receiving
the SetRow request).
RetrieveRow class requests can succeed or fail individually or even
with each varbind.
4. Elements of Procedure
4.1. CreateRow Request Processing
TBD
4.2. DeleteRow Request Processing
TBD
4.3. EditRow Request Processing
TBD
4.4. GetRow Request Processing
TBD
4.5. GetNextRow Request Processing
TBD
4.6. Entities not supporting SetRow or RetrieveRow.
An essential requirement for these operations is that it must operate
seamlessly in existing networks and not disrupt legacy SNMP devices.
This is satisfied by the fact that the new protocol operations have
new and unique ASN.1 tags, which allow older implementations to
efficiently and silently drop these new PDU requests.
EOS Working Group Expires September 2001 [Page 14]
Internet Draft SNMP Row Operations Extensions 16 April 2001
Some entities may only support these operations for certain tables.
For example, different AgentX subagents may or may not support these
operations. This requires that the requests fail whenever a table is
targeted that cannot support the new operation. The elements of
procedure indictate the proper exceptions in these cases.
It is also possible that some table implementations may support only
some subset of the new operations, for example, the RetrieveRow
requests, but not the SetRow requests. It is herein RECOMMENDED that
SNMP entities that support at least one operation within a class
(i.e. SetRow or RequestRow) for a given table SHOULD support all
requests within the same class for that table. Also, it is further
RECOMMENDED that if the SetRow class of operations are supported for
a given table, then the entity SHOULD also support all the
RetrieveRow operations for that table. For any operation not
supported by a targeted table (which nevertheless supports other
operations), the elements of procedure indicate the proper exceptions
that apply.
5. Protocol Operations Definitions
TBD
6. Managed Object Definitions
SNMP-ROWOPS-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE,
OBJECT-IDENTITY,
snmpModules FROM SNMPv2-SMI
TEXTUAL-CONVENTION FROM SNMPv2-TC
MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF;
snmpRowopsMIB MODULE-IDENTITY
LAST-UPDATED "200104162050Z"
ORGANIZATION "EOS Working Group"
CONTACT-INFO "WG-EMail: eos@ops.ietf.org
Subscribe: eos-request@ops.ietf.org
Co-Chair: Dale Francisco
Cisco Systems, Inc.
postal:
USA
EMail: dfrancis@cisco.com
phone:
EOS Working Group Expires September 2001 [Page 15]
Internet Draft SNMP Row Operations Extensions 16 April 2001
Co-Chair: Glenn Waters
Nortel Networks
postal:
USA
EMail: gww@nortelnetworks.com
phone:
Co-editor: Lauren Heintz
Cisco Systems, Inc.
postal:
USA
EMail: lheintz@cisco.com
phone:
"
DESCRIPTION "The SNMP Row Operations Extensions MIB"
REVISION "200103280000Z"
DESCRIPTION "The initial version, published in
draft-ietf-eos-snmp-rowops.00.txt.
"
::= { snmpModules TBD }
-- Textual Conventions
RowState ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION "TBD"
SYNTAX INTEGER {TBD}
END
7. IANA Considerations
This document defines one number space administered by IANA for
providing a capability expression to allow command responders to
advertise their ability to support the extensions outlined in this
document. TBD
8. Intellectual Property
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
EOS Working Group Expires September 2001 [Page 16]
Internet Draft SNMP Row Operations Extensions 16 April 2001
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
9. Acknowledgements
This document is the result of the efforts of the Evolution Of SNMP
(EOS) Working Group. Some special thanks are in order to the
following EOS WG members:
Wiley Coyote (Acme)
10. Security Considerations
This is where security considerations will be.
11. References
[RFC1155] Rose, M. and K. McCloghrie, "Structure and
Identification of Management Information for TCP/IP-
based internets", STD 16, RFC 1155, May 1990.
[RFC1157] Case, J., M. Fedor, M. Schoffstall and J. Davin, "The
Simple Network Management Protocol", STD 15, RFC 1157,
May 1990.
[RFC1212] Rose, M. and K. McCloghrie, "Concise MIB Definitions",
STD 16, RFC 1212, March 1991.
[RFC1901] The SNMPv2 Working Group, Case, J., McCloghrie, K.,
Rose, M. and S. Waldbusser, "Introduction to
Community-based SNMPv2", RFC 1901, January 1996.
[RFC2571] Harrington, D., Presuhn, R., and B. Wijnen, "An
Architecture for Describing SNMP Management Frameworks",
RFC 2571, April 1999.
[RFC2578] McCloghrie, K., Perkins, D. and J. Schoenwaelder,
"Structure of Management Information Version 2 (SMIv2)",
STD 58, RFC 2578, April 1999.
EOS Working Group Expires September 2001 [Page 17]
Internet Draft SNMP Row Operations Extensions 16 April 2001
[RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder,
"Textual Conventions for SMIv2", STD 58, RFC 2579, April
1999.
[RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder,
"Conformance Statements for SMIv2", STD 58, RFC 2580,
April 1999.
[RFC-PROTO] Presuhn, R., Case, J., McCloghrie, K., Rose, M., and S.
Waldbusser, "Protocol Operations for the Simple Network
Management Protocol", <draft-ietf-snmpv3-update-proto-
05.txt>, April 2001.
[RFC-TMM] Presuhn, R., Case, J., McCloghrie, K., Rose, M., and S.
Waldbusser, "Transport Mappings for the Simple Network
Management Protocol", <draft-ietf-snmpv3-update-
transmap-05.txt>, April 2001.
[RFC-MIB] Presuhn, R., Case, J., McCloghrie, K., Rose, M. and S.
Waldbusser, "Management Information Base for the Simple
Network Management Protocol", <draft-ietf-snmpv3-
update-mib-05.txt>, April 2001.
[RFC-COEX] Frye, R., Levi, D., Routhier, S., and B. Wijnen,
"Coexistence between Version 1, Version 2, and Version 3
of the Internet-standard Network Management Framework",
<draft-ietf-snmpv3-coex-v2-00.txt>, April 2001.
[RFC1909] McCloghrie, K., Editor, "An Administrative
Infrastructure for SNMPv2", RFC 1909, February 1996.
[RFC1910] Waters, G., Editor, "User-based Security Model for
SNMPv2", RFC 1910, February 1996.
[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO
10646", RFC 2279, January, 1998.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[BCP-11] Hovey, R. and S. Bradner, "The Organizations Involved in
the IETF Standards Process", BCP 11, RFC 2028, October
1996.
[RFC2863] McCloghrie, K. and F. Kastenholz. "The Interfaces Group
MIB." RFC 2863, June 2000.
[SNMP-MPD] Case, J., Harrington, D., Presuhn, R. and B. Wijnen,
EOS Working Group Expires September 2001 [Page 18]
Internet Draft SNMP Row Operations Extensions 16 April 2001
"Message Processing and Dispatching for the Simple
Network Management Protocol (SNMP)", <draft-ietf-
snmpv3-mpd-v2-00.txt>, April 2001.
[SNMP-USM] Blumenthal, U. and B. Wijnen, "The User-Based Security
Model for Version 3 of the Simple Network Management
Protocol (SNMPv3)", <draft-ietf-snmpv3-usm-v2-00.txt>,
April 2001.
[SNMP-ACM] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based
Access Control Model for the Simple Network Management
Protocol (SNMP)", <draft-ietf-snmpv3-vacm-04.txt>,
February 1999. <draft-ietf-snmpv3-vacm-v2-00.txt>,
April 2001.
[RFC-APPL] Levi, D., Meyer, P. and B. Stewart, "SNMP
Applications", <draft-ietf-snmpv3-apps-v2-00.txt>, April
2001.
[RFC2570] Case, J., Mundy, R., Partain, D. and B. Stewart,
"Introduction to Version 3 of the Internet-standard
Network Management Framework", <draft-ietf-snmpv3-
intro-04.txt>, January 1999.
[RFC-COEX] Frye, R., Levi, D., Routhier, S., and B. Wijnen,
"Coexistence between Version 1, Version 2, and Version 3
of the Internet-standard Network Management Framework",
<draft-ietf-snmpv3-coex-v2-00.txt>, April 2001.
EOS Working Group Expires September 2001 [Page 19]
Internet Draft SNMP Row Operations Extensions 16 April 2001
12. Editor's Addresses
Lauren Heintz
Cisco Systems, Inc.
130 Baytech Drive
San Jose, Ca 95134
Phone: +1 408-615-7605
EMail: lheintz@cisco.com
EOS Working Group Expires September 2001 [Page 20]
Internet Draft SNMP Row Operations Extensions 16 April 2001
APPENDIXES
A. Impact to Other Protocols
TBD
B. Alternative Approaches
This section will be deleted before going standards track.
This document outlines one approach to achieving the design goals
stated earlier. Several other approaches also exist. Here are some
hints:
- Use the same approach described herein except define a new
"RowPDU" to further optimize OID suppression (i.e. get rid of
the 0.X column subid notation). This may require a new kind of
varbind list where each varbind is no longer an OID/value, but
instead it is an Integer/Value pair. Similarly, this new PDU
could contain one or more rowIdentifier items (one per rowOp).
- Instead of having five new request types, use only one instead
and perhaps have an operator with the request to indicate the
kind of operation. Also, the operator might be included within
each rowOp contained within the request so that one protocol
operation might contain mixed row operations (i.e. a createRow
and deleteRow might co-exist in the same protocol request).
- Maintain the same PDU structure, but re-define what a varbind
is (i.e. one varbind might actually be able to contain a
sequence of objects, all of which pertain to one row
operation). You'd still have to define where/how you designate
which row(s) and column(s) are affected.
- Nix the RowState idea, keep RowStatus, and simply provide
traditional protocol operations, perhaps with a way of
minimizing overhead.
- Some combination of the above, or other?
C. Examples of Row Operations
Each of the following examples assumes that the error-index and
error-status fields of the manager initiated request are set to 0 and
the request-id contains an appropriate value.
EOS Working Group Expires September 2001 [Page 21]
Internet Draft SNMP Row Operations Extensions 16 April 2001
C.1. CreateRow with RowStatus
This protocol exchange illustrates the use of the CreateRow request
to create two new rows in the snmpNotifyTable [RFC2573]. This table
uses RowStatus, so we choose to explicitly set its value for each
row, as desired (some impls may allow us to instead omit setting
RowStatus and rely on implicit support for it).
Note that the second rowOp inherits its table OID information from
the previous rowOp (because 1.0 instructs this).
CreateRow
(
-- rowOp 1
-- rowIdentifier (table and instance)
vb1.name = 1.3.6.1.6.3.13.1.1.1 -- snmpNotifyEntry
vb1.value(OID) = 114.111.119.49 -- "row1"
vb2.name = 0.2 -- snmpNotifyTag
vb2.value(SnmpTagValue) = "tag1"
vb3.name = 0.3 -- snmpNotifyType
vb3.value(INT) = 1 -- trap
-- skip snmpNotifyStorageType. Use DEFVAL
vb4.name = 0.5 -- snmpNotifyRowStatus
vb4.value(RowStatus) = createAndGo
-- rowOp 2
-- rowIdentifier (table and instance)
vb5.name = 1.0 -- inherit snmpNotifyEntry
vb5.value(OID) = 114.111.119.50 -- "row2"
vb8.name = 0.5 -- snmpNotifyRowStatus
vb8.value(RowStatus) = createAndWait
)
C.2. CreateRow with RowState
This protocol exchange illustrates the use of the CreateRow request
to create two new rows in the snmpNotifyTable [RFC2573] except that
we pretend here that RowState was used in the design of that table
instead of RowStatus.
EOS Working Group Expires September 2001 [Page 22]
Internet Draft SNMP Row Operations Extensions 16 April 2001
CreateRow
(
-- rowOp 1
-- rowIdentifier (table and instance)
vb1.name = 1.3.6.1.6.3.13.1.1.1 -- snmpNotifyEntry
vb1.value(OID) = 114.111.119.49 -- "row1"
vb2.name = 0.2 -- snmpNotifyTag
vb2.value(SnmpTagValue) = "tag1"
vb3.name = 0.3 -- snmpNotifyType
vb3.value(INT) = 1 -- trap
-- skip snmpNotifyStorageType. Use DEFVAL
-- By omitting a RowState varbind, it is the
-- same as setting RowState=Active.
-- rowOp 2
-- rowIdentifier (table and instance)
vb5.name = 1.0 -- inherit snmpNotifyEntry
vb5.value(OID) = 114.111.119.50 -- "row2"
-- Explicitly set RowState to an initial
-- value because we don't want to go
-- active just yet. Even though we hint
-- for an initial value of NotInService,
-- it's possible that the result might
-- show NotReady (if the row as defined
-- by CreateRow were not ready to go Active).
vb8.name = 0.5 -- snmpNotifyRowState
vb8.value(RowState) = NotInService
)
C.3. DeleteRow
This example illustrates how a DeleteRow request containing two row
operations is formed to delete the two rows created in either of the
two previous examples. Note that the rowIdentifier in the second
rowOp does not inherit the table OID from the first rowOp. Although
this is legal, it also increases the request PDU size unnecessarily.
DeleteRow
(
-- rowOp 1
EOS Working Group Expires September 2001 [Page 23]
Internet Draft SNMP Row Operations Extensions 16 April 2001
-- rowIdentifier (table and instance)
vb1.name = 1.3.6.1.6.3.13.1.1.1 -- snmpNotifyEntry
vb1.value(OID) = 114.111.119.49 -- "row1"
-- rowOp 2
-- rowIdentifier (table and instance)
vb1.name = 1.3.6.1.6.3.13.1.1.1 -- snmpNotifyEntry
vb1.value(OID) = 114.111.119.50 -- "row2"
)
C.4. GetRow and GetNextRow
This example illustrates how a GetRow request with three row
operations is used to retrieve row information. Note that rowOp1
retrieves only the snmpNotifyTag from row1, rowOp2 retrieves only the
RowStatus value from row2, and rowOp3 retrieves all values from row2.
rowOp2 additionally attempts to retrieve an object that does not
exist in the table row.
The Response PDU is also shown afterward.
GetNextRow performs very similarly to GetRow except that the Response
PDU will contain the object names and values from the next row in the
table (if any), or will contain exceptions as placeholders where the
requested objects do not exist.
GetRow
(
-- rowOp 1
-- rowIdentifier (table and instance)
vb1.name = 1.3.6.1.6.3.13.1.1.1 -- snmpNotifyEntry
vb1.value(OID) = 114.111.119.49 -- "row1"
vb2.name = 0.2 -- snmpNotifyTag
vb2.value = NULL
-- rowOp 2
-- rowIdentifier (table and instance)
vb3.name = 1.0 -- inherit snmpNotifyEntry
vb3.value(OID) = 114.111.119.50 -- "row2"
vb4.name = 0.5 -- snmpNotifyRowStatus
vb4.value = NULL
EOS Working Group Expires September 2001 [Page 24]
Internet Draft SNMP Row Operations Extensions 16 April 2001
vb5.name = 0.999 -- doesn't exist
vb5.value = NULL
-- rowOp 3
-- rowIdentifier (table and instance)
vb6.name = 1.0 -- inherit snmpNotifyEntry
vb6.value(OID) = 114.111.119.50 -- "row2"
-- omitting all operands indicates "get all" row objects.
)
ResponsePdu
(
-- rowOp 1
-- rowIdentifier (table and instance)
vb1.name = 1.3.6.1.6.3.13.1.1.1 -- snmpNotifyEntry
vb1.value(OID) = 114.111.119.49 -- "row1"
vb2.name = 0.2 -- snmpNotifyTag
vb2.value(snmpTagValue) = "tag1"
-- rowOp 2
-- rowIdentifier (table and instance)
vb3.name = 1.0 -- inherit snmpNotifyEntry
vb3.value(OID) = 114.111.119.50 -- "row2"
vb4.name = 0.5 -- snmpNotifyRowStatus
vb4.value(RowStatus) = NotInService
vb5.name = 0.999 -- doesn't exist
vb5.value(int) = NoSuchObject
-- rowOp 3
-- rowIdentifier (table and instance)
vb6.name = 1.0 -- inherit snmpNotifyEntry
vb5.value(OID) = 114.111.119.50 -- "row2"
vb7.name = 0.2 -- snmpNotifyTag
vb7.value(SnmpTagValue) = ""
vb8.name = 0.3 -- snmpNotifyType
vb8.value(INT) = 1 -- trap
vb9.name = 0.4 -- snmpNotifyStorageType
EOS Working Group Expires September 2001 [Page 25]
Internet Draft SNMP Row Operations Extensions 16 April 2001
vb9.value(StorageType) = nonVolatile
vb10.name = 0.5 -- snmpNotifyRowStatus
vb10.value(RowStatus) = NotInService
)
D. Known issues
This section will be deleted before becoming an RFC.
These are known issues that need to be resolved before going
standards track:
- The instancePart of the rowIdentifier is contained within the
value part of a varbind. Usually, only SetRequests contain
non-NULL value varbind components, so what impact do these new
requests (with these non-NULL value components) cause?
E. Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
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.
EOS Working Group Expires September 2001 [Page 26]
Internet Draft SNMP Row Operations Extensions 16 April 2001
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
EOS Working Group Expires September 2001 [Page 27]