%x73
subidKeyword = %x73 %x75 %x62 %x69 %x64
objectKeyword = %x6F %x62 %x6A %x65 %x63 %x74
notificationKeyword = %x6E %x6F %x74 %x69 %x66 %x69 %x63 %x61 %x74
%x69 %x6F %x6E
signalsKeyword = %x73 %x69 %x67 %x6E %x61 %x6C %x73
oidKeyword = %x6F %x69 %x64
groupKeyword = %x67 %x72 %x6F %x75 %x70
complianceKeyword = %x63 %x6F %x6D %x70 %x6C %x69 %x61 %x6E %x63
%x65
impliedKeyword = %x69 %x6D %x70 %x6C %x69 %x65 %x64
indexKeyword = %x69 %x6E %x64 %x65 %x78
augmentsKeyword = %x61 %x75 %x67 %x6D %x65 %x6E %x74 %x73
reordersKeyword = %x72 %x65 %x6F %x72 %x64 %x65 %x72 %x73
extendsKeyword = %x65 %x78 %x74 %x65 %x6E %x64 %x73
expandsKeyword = %x65 %x78 %x70 %x61 %x6E %x64 %x73
createKeyword = %x63 %x72 %x65 %x61 %x74 %x65
membersKeyword = %x6D %x65 %x6D %x62 %x65 %x72 %x73
mandatoryKeyword = %x6D %x61 %x6E %x64 %x61 %x74 %x6F %x72 %x79
optionalKeyword = %x6F %x70 %x74 %x69 %x6F %x6E %x61 %x6C
refineKeyword = %x72 %x65 %x66 %x69 %x6E %x65
writetypeKeyword = %x77 %x72 %x69 %x74 %x65 %x74 %x79 %x70 %x65
;; End of ABNF
";
};
//
//
//
snmp {
node ccitt { oid 0; };
node zeroDotZero {
oid 0.0;
description "A null value used for pointers.";
};
node iso { oid 1; };
node org { oid iso.3; };
node dod { oid org.6; };
node internet { oid dod.1; };
node directory { oid internet.1; };
node mgmt { oid internet.2; };
node mib-2 { oid mgmt.1; };
node transmission { oid mib-2.10; };
node experimental { oid internet.3; };
node private { oid internet.4; };
node enterprises { oid private.1; };
node security { oid internet.5; };
node snmpV2 { oid internet.6; };
node snmpDomains { oid snmpV2.1; };
node snmpProxys { oid snmpV2.2; };
node snmpModules { oid snmpV2.3; };
node joint-iso-ccitt { oid 2; };
status current;
description
"This set of nodes defines the core object
identifier hierarchy";
reference
"RFC 2578, Section 2.";
};
};
6. NMRG-SMING-SNMP
The module NMRG-SMING-SNMP specified below defines derived types that
are specific to the SNMP mapping.
module NMRG-SMING-SNMP {
organization "IRTF Network Management Research Group (NMRG)";
contact "IRTF Network Management Research Group (NMRG)
http://www.ibr.cs.tu-bs.de/projects/nmrg/
Frank Strauss
TU Braunschweig
Muehlenpfordtstrasse 23
38106 Braunschweig
Germany
Phone: +49 531 391 3266
EMail: strauss@ibr.cs.tu-bs.de
Juergen Schoenwaelder
International University Bremen
P.O. Box 750 561
28725 Bremen
Germany
Phone: +49 421 200 3587
EMail: j.schoenwaelder@iu-bremen.de";
description "Core type definitions for the SMIng SNMP mapping.
These definitions are based on RFC 2579 definitions
that are specific to the SNMP protocol and its
naming system.
Copyright (C) The Internet Society (2004).
All Rights Reserved.
This version of this module is part of
RFC 3781, see the RFC itself for full
legal notices.";
revision {
date "2003-12-16";
description "Initial version, published as RFC 3781.";
};
typedef TestAndIncr {
type Integer32 (0..2147483647);
description
"Represents integer-valued information used for atomic
operations. When the management protocol is used to
specify that an object instance having this type is to
be modified, the new value supplied via the management
protocol must precisely match the value presently held by
the instance. If not, the management protocol set
operation fails with an error of `inconsistentValue’.
Otherwise, if the current value is the maximum value of
2^31-1 (2147483647 decimal), then the value held by the
instance is wrapped to zero; otherwise, the value held by
the instance is incremented by one. (Note that
regardless of whether the management protocol set
operation succeeds, the variable-binding in the request
and response PDUs are identical.)
The value of the SNMP access clause for objects having
this type has to be `readwrite’. When an instance of a
columnar object having this type is created, any value
may be supplied via the management protocol.
When the network management portion of the system is re-
initialized, the value of every object instance having
this type must either be incremented from its value prior
to the re-initialization, or (if the value prior to the
re-initialization is unknown) be set to a
pseudo-randomly generated value."; };
typedef AutonomousType {
type Pointer;
description
"Represents an independently extensible type
identification value. It may, for example, indicate a
particular OID sub-tree with further MIB definitions, or
define a particular type of protocol or hardware.";
};
typedef VariablePointer {
type Pointer;
description
"A pointer to a specific object instance. For example,
sysContact.0 or ifInOctets.3.";
};
typedef RowPointer {
type Pointer;
description
"Represents a pointer to a conceptual row. The value is
the name of the instance of the first accessible columnar
object in the conceptual row.
For example, ifIndex.3 would point to the 3rd row in the
ifTable (note that if ifIndex were not-accessible, then
ifDescr.3 would be used instead).";
};
typedef RowStatus {
type Enumeration (active(1), notInService(2),
notReady(3), createAndGo(4),
createAndWait(5), destroy(6));
description
"The RowStatus type is used to manage the creation and
deletion of conceptual rows, and is used as the type for the
row status column of a conceptual row.
The status column has six defined values:
- `active’, which indicates that the conceptual row is
available for use by the managed device;
- `notInService’, which indicates that the conceptual
row exists in the agent, but is unavailable for use by
the managed device (see NOTE below);
- `notReady’, which indicates that the conceptual row
exists in the agent, but is missing information
necessary in order to be available for use by the
managed device;
- `createAndGo’, which is supplied by a management
station wishing to create a new instance of a
conceptual row and to have its status automatically set
to active, making it available for use by the managed
device;
- `createAndWait’, which is supplied by a management
station wishing to create a new instance of a
conceptual row (but not make it available for use by
the managed device); and,
- `destroy’, which is supplied by a management station
wishing to delete all of the instances associated with
an existing conceptual row.
Whereas five of the six values (all except `notReady’) may
be specified in a management protocol set operation, only
three values will be returned in response to a management
protocol retrieval operation: `notReady’, `notInService’ or
`active’. That is, when queried, an existing conceptual row
has only three states: it is either available for use by the
managed device (the status column has value `active’); it is
not available for use by the managed device, though the
agent has sufficient information to make it so (the status
column has value `notInService’); or, it is not available
for use by the managed device, and an attempt to make it so
would fail because the agent has insufficient information
(the state column has value `notReady’).
NOTE WELL
This textual convention may be used for a MIB table,
irrespective of whether the values of that table’s
conceptual rows are able to be modified while it is
active, or whether its conceptual rows must be taken
out of service in order to be modified. That is, it is
the responsibility of the DESCRIPTION clause of the
status column to specify whether the status column must
not be `active’ in order for the value of some other
column of the same conceptual row to be modified. If
such a specification is made, affected columns may be
changed by an SNMP set PDU if the RowStatus would not
be equal to `active’ either immediately before or after
processing the PDU. In other words, if the PDU also
contained a varbind that would change the RowStatus
value, the column in question may be changed if the
RowStatus was not equal to `active’ as the PDU was
received, or if the varbind sets the status to a value
other than ’active’.
Also note that whenever any elements of a row exist, the
RowStatus column must also exist.
To summarize the effect of having a conceptual row with a
column having a type of RowStatus, consider the following
state diagram:
STATE
+--------------+-----------+-------------+-------------
| A | B | C | D
| |status col.|status column|
|status column | is | is |status column
ACTION |does not exist| notReady | notInService| is active
--------------+--------------+-----------+-------------+-------------
set status |noError ->D|inconsist- |inconsistent-|inconsistent-
column to | or | entValue| Value| Value
createAndGo |inconsistent- | | |
| Value| | |
--------------+--------------+-----------+-------------+-------------
set status |noError see 1|inconsist- |inconsistent-|inconsistent-
column to | or | entValue| Value| Value
createAndWait |wrongValue | | |
--------------+--------------+-----------+-------------+-------------
set status |inconsistent- |inconsist- |noError |noError
column to | Value| entValue| |
active | | | |
| | or | |
| | | |
| |see 2 ->D|see 8 ->D| ->D
--------------+--------------+-----------+-------------+-------------
set status |inconsistent- |inconsist- |noError |noError ->C
column to | Value| entValue| |
notInService | | | |
| | or | | or
| | | |
| |see 3 ->C| ->C|see 6
--------------+--------------+-----------+-------------+-------------
set status |noError |noError |noError |noError ->A
column to | | | | or
destroy | ->A| ->A| ->A|see 7
--------------+--------------+-----------+-------------+-------------
set any other |see 4 |noError |noError |see 5
column to some| | | |
value | | see 1| ->C| ->D
--------------+--------------+-----------+-------------+-------------
(1) go to B or C, depending on information available to the
agent.
(2) if other variable bindings included in the same PDU,
provide values for all columns which are missing but
required, then return noError and goto D.
(3) if other variable bindings included in the same PDU,
provide values for all columns which are missing but
required, then return noError and goto C.
(4) at the discretion of the agent, the return value may be
either:
inconsistentName: because the agent does not choose to
create such an instance when the corresponding
RowStatus instance does not exist, or
inconsistentValue: if the supplied value is
inconsistent with the state of some other MIB object’s
value, or
noError: because the agent chooses to create the
instance.
If noError is returned, then the instance of the status
column must also be created, and the new state is B or C,
depending on the information available to the agent. If
inconsistentName or inconsistentValue is returned, the row
remains in state A.
(5) depending on the MIB definition for the column/table,
either noError or inconsistentValue may be returned.
(6) the return value can indicate one of the following
errors:
wrongValue: because the agent does not support
createAndWait, or
inconsistentValue: because the agent is unable to take
the row out of service at this time, perhaps because it
is in use and cannot be de-activated.
(7) the return value can indicate the following error:
inconsistentValue: because the agent is unable to
remove the row at this time, perhaps because it is in
use and cannot be de-activated.
NOTE: Other processing of the set request may result in a
response other than noError being returned, e.g.,
wrongValue, noCreation, etc.
Conceptual Row Creation
There are four potential interactions when creating a
conceptual row: selecting an instance-identifier which is
not in use; creating the conceptual row; initializing any
objects for which the agent does not supply a default; and,
making the conceptual row available for use by the managed
device.
Interaction 1: Selecting an Instance-Identifier
The algorithm used to select an instance-identifier varies
for each conceptual row. In some cases, the instance-
identifier is semantically significant, e.g., the
destination address of a route, and a management station
selects the instance-identifier according to the semantics.
In other cases, the instance-identifier is used solely to
distinguish conceptual rows, and a management station
without specific knowledge of the conceptual row might
examine the instances present in order to determine an
unused instance-identifier. (This approach may be used, but
it is often highly sub-optimal; however, it is also a
questionable practice for a naive management station to
attempt conceptual row creation.)
Alternately, the MIB module which defines the conceptual row
might provide one or more objects which provide assistance
in determining an unused instance-identifier. For example,
if the conceptual row is indexed by an integer-value, then
an object having an integer-valued SYNTAX clause might be
defined for such a purpose, allowing a management station to
issue a management protocol retrieval operation. In order
to avoid unnecessary collisions between competing management
stations, `adjacent’ retrievals of this object should be
different.
Finally, the management station could select a pseudo-random
number to use as the index. In the event that this index
was already in use and an inconsistentValue was returned in
response to the management protocol set operation, the
management station should simply select a new pseudo-random
number and retry the operation.