RMON2-MIB

Counter32

The total number of frames that were received by the probe and therefore not accounted for in the *StatsDropEvents, but that the probe chose not to count for this entry for whatever reason. Most often, this event occurs when the probe is out of some resources and decides to shed load from this collection. This count does not include packets that were not counted because they had MAC-layer errors. Note that, unlike the dropEvents counter, this number is the exact number of frames dropped.

LastCreateTimeThis TC describes an object that stores the value of the sysUpTime object at the last time its entry was created. This can be used for polling applications to determine that an entry has been deleted and re-created between polls, causing an otherwise undetectable discontinuity in the data. If sysUpTime is reset to zero as a result of a re- initialization of the network management (sub)system, then the values of all LastCreateTime objects are also reset. However, after approximately 497 days without a re- initialization, the sysUpTime object will reach 2^^32-1 and then increment to zero; in this case, existing values of TimeStamp objects do not change. This can lead to ambiguities in the value of TimeStamp objects. · TimeTicks

The value of sysUpTime when this control entry was last activated. This can be used by the management station to ensure that the table has not been deleted and recreated between polls.

Counter32

The total number of frames that were received by the probe and therefore not accounted for in the *StatsDropEvents, but that the probe chose not to count for this entry for whatever reason. Most often, this event occurs when the probe is out of some resources and decides to shed load from this collection. This count does not include packets that were not counted because they had MAC-layer errors. Note that, unlike the dropEvents counter, this number is the exact number of frames dropped.

LastCreateTimeThis TC describes an object that stores the value of the sysUpTime object at the last time its entry was created. This can be used for polling applications to determine that an entry has been deleted and re-created between polls, causing an otherwise undetectable discontinuity in the data. If sysUpTime is reset to zero as a result of a re- initialization of the network management (sub)system, then the values of all LastCreateTime objects are also reset. However, after approximately 497 days without a re- initialization, the sysUpTime object will reach 2^^32-1 and then increment to zero; in this case, existing values of TimeStamp objects do not change. This can lead to ambiguities in the value of TimeStamp objects. · TimeTicks

The value of sysUpTime when this control entry was last activated. This can be used by the management station to ensure that the table has not been deleted and recreated between polls.

Counter32

The total number of frames that were received by the probe and therefore not accounted for in the *StatsDropEvents, but that the probe chose not to count for this entry for whatever reason. Most often, this event occurs when the probe is out of some resources and decides to shed load from this collection. This count does not include packets that were not counted because they had MAC-layer errors. Note that, unlike the dropEvents counter, this number is the exact number of frames dropped.

LastCreateTimeThis TC describes an object that stores the value of the sysUpTime object at the last time its entry was created. This can be used for polling applications to determine that an entry has been deleted and re-created between polls, causing an otherwise undetectable discontinuity in the data. If sysUpTime is reset to zero as a result of a re- initialization of the network management (sub)system, then the values of all LastCreateTime objects are also reset. However, after approximately 497 days without a re- initialization, the sysUpTime object will reach 2^^32-1 and then increment to zero; in this case, existing values of TimeStamp objects do not change. This can lead to ambiguities in the value of TimeStamp objects. · TimeTicks

The value of sysUpTime when this control entry was last activated. This can be used by the management station to ensure that the table has not been deleted and recreated between polls.

Counter32

The total number of frames that were received by the probe and therefore not accounted for in the *StatsDropEvents, but that the probe chose not to count for this entry for whatever reason. Most often, this event occurs when the probe is out of some resources and decides to shed load from this collection. This count does not include packets that were not counted because they had MAC-layer errors. Note that, unlike the dropEvents counter, this number is the exact number of frames dropped.

Counter32

The total number of frames that were received by the probe and therefore not accounted for in the *StatsDropEvents, but that the probe chose not to count for this entry for whatever reason. Most often, this event occurs when the probe is out of some resources and decides to shed load from this collection. This count does not include packets that were not counted because they had MAC-layer errors. Note that, unlike the dropEvents counter, this number is the exact number of frames dropped.

LastCreateTimeThis TC describes an object that stores the value of the sysUpTime object at the last time its entry was created. This can be used for polling applications to determine that an entry has been deleted and re-created between polls, causing an otherwise undetectable discontinuity in the data. If sysUpTime is reset to zero as a result of a re- initialization of the network management (sub)system, then the values of all LastCreateTime objects are also reset. However, after approximately 497 days without a re- initialization, the sysUpTime object will reach 2^^32-1 and then increment to zero; in this case, existing values of TimeStamp objects do not change. This can lead to ambiguities in the value of TimeStamp objects. · TimeTicks

The value of sysUpTime when this control entry was last activated. This can be used by the management station to ensure that the table has not been deleted and recreated between polls.

Counter32

The total number of frames that were received by the probe and therefore not accounted for in the *StatsDropEvents, but that the probe chose not to count for this entry for whatever reason. Most often, this event occurs when the probe is out of some resources and decides to shed load from this collection. This count does not include packets that were not counted because they had MAC-layer errors. Note that, unlike the dropEvents counter, this number is the exact number of frames dropped.

LastCreateTimeThis TC describes an object that stores the value of the sysUpTime object at the last time its entry was created. This can be used for polling applications to determine that an entry has been deleted and re-created between polls, causing an otherwise undetectable discontinuity in the data. If sysUpTime is reset to zero as a result of a re- initialization of the network management (sub)system, then the values of all LastCreateTime objects are also reset. However, after approximately 497 days without a re- initialization, the sysUpTime object will reach 2^^32-1 and then increment to zero; in this case, existing values of TimeStamp objects do not change. This can lead to ambiguities in the value of TimeStamp objects. · TimeTicks

The value of sysUpTime when this control entry was last activated. This can be used by the management station to ensure that the table has not been deleted and recreated between polls.

Counter32

The total number of frames that were received by the probe and therefore not accounted for in the *StatsDropEvents, but that the probe chose not to count for this entry for whatever reason. Most often, this event occurs when the probe is out of some resources and decides to shed load from this collection. This count does not include packets that were not counted because they had MAC-layer errors. Note that, unlike the dropEvents counter, this number is the exact number of frames dropped.

LastCreateTimeThis TC describes an object that stores the value of the sysUpTime object at the last time its entry was created. This can be used for polling applications to determine that an entry has been deleted and re-created between polls, causing an otherwise undetectable discontinuity in the data. If sysUpTime is reset to zero as a result of a re- initialization of the network management (sub)system, then the values of all LastCreateTime objects are also reset. However, after approximately 497 days without a re- initialization, the sysUpTime object will reach 2^^32-1 and then increment to zero; in this case, existing values of TimeStamp objects do not change. This can lead to ambiguities in the value of TimeStamp objects. · TimeTicks

The value of sysUpTime when this control entry was last activated. This can be used by the management station to ensure that the table has not been deleted and recreated between polls.

Integer32 (0..2147483647)

When this object is set to a non-zero value, the filter that it is associated with performs the following operations on every packet: 1) If the packet doesn't match the protocol directory entry identified by this object, discard the packet and exit (i.e., discard the packet if it is not of the identified protocol). 2) If the associated filterProtocolDirLocalIndex is non-zero and the packet doesn't match the protocol directory entry identified by that object, discard the packet and exit. 3) If the packet matches, perform the regular filter algorithm as if the beginning of this named protocol is the beginning of the packet, potentially applying the filterOffset value to move further into the packet.

Integer32 (0..2147483647)

When this object is set to a non-zero value, the filter that it is associated with will discard the packet if the packet doesn't match this protocol directory entry.

Counter32

The total number of frames that were received by the probe and therefore not accounted for in the *StatsDropEvents, but that the probe chose not to count for this entry for whatever reason. Most often, this event occurs when the probe is out of some resources and decides to shed load from this collection. This count does not include packets that were not counted because they had MAC-layer errors. Note that, unlike the dropEvents counter, this number is the exact number of frames dropped.

LastCreateTimeThis TC describes an object that stores the value of the sysUpTime object at the last time its entry was created. This can be used for polling applications to determine that an entry has been deleted and re-created between polls, causing an otherwise undetectable discontinuity in the data. If sysUpTime is reset to zero as a result of a re- initialization of the network management (sub)system, then the values of all LastCreateTime objects are also reset. However, after approximately 497 days without a re- initialization, the sysUpTime object will reach 2^^32-1 and then increment to zero; in this case, existing values of TimeStamp objects do not change. This can lead to ambiguities in the value of TimeStamp objects. · TimeTicks

The value of sysUpTime when this control entry was last activated. This can be used by the management station to ensure that the table has not been deleted and recreated between polls.

Counter32

The total number of frames that were received by the probe and therefore not accounted for in the *StatsDropEvents, but that the probe chose not to count for this entry for whatever reason. Most often, this event occurs when the probe is out of some resources and decides to shed load from this collection. This count does not include packets that were not counted because they had MAC-layer errors. Note that, unlike the dropEvents counter, this number is the exact number of frames dropped.

LastCreateTimeThis TC describes an object that stores the value of the sysUpTime object at the last time its entry was created. This can be used for polling applications to determine that an entry has been deleted and re-created between polls, causing an otherwise undetectable discontinuity in the data. If sysUpTime is reset to zero as a result of a re- initialization of the network management (sub)system, then the values of all LastCreateTime objects are also reset. However, after approximately 497 days without a re- initialization, the sysUpTime object will reach 2^^32-1 and then increment to zero; in this case, existing values of TimeStamp objects do not change. This can lead to ambiguities in the value of TimeStamp objects. · TimeTicks

The value of sysUpTime when this control entry was last activated. This can be used by the management station to ensure that the table has not been deleted and recreated between polls.

OCTET STRING SIZE (4..128)

A unique identifier for a particular protocol. Standard identifiers will be defined in such a manner that they can often be used as specifications for new protocols - i.e., a tree-structured assignment mechanism that matches the protocol encapsulation 'tree' and that has algorithmic assignment mechanisms for certain subtrees. See RFC 2074 for more details. Despite the algorithmic mechanism, the probe will only place entries in here for those protocols it chooses to collect. In other words, it need not populate this table with all possible ethernet protocol types, nor need it create them on the fly when it sees them. Whether it does these things is a matter of product definition (cost/benefit, usability) and is up to the designer of the product. If an entry is written to this table with a protocolDirID that the agent doesn't understand, either directly or algorithmically, the SET request will be rejected with an inconsistentName or badValue (for SNMPv1) error.

OCTET STRING SIZE (1..32)

A set of parameters for the associated protocolDirID. See the associated RMON2 Protocol Identifiers document for a description of the possible parameters. There will be one octet in this string for each sub-identifier in the protocolDirID, and the parameters will appear here in the same order as the associated sub-identifiers appear in the protocolDirID. Every node in the protocolDirID tree has a different, optional set of parameters defined (that is, the definition of parameters for a node is optional). The proper parameter value for each node is included in this string. Note that the inclusion of a parameter value in this string for each node is not optional. What is optional is that a node may have no parameters defined, in which case the parameter field for that node will be zero.

Integer32 (1..2147483647)

The locally arbitrary but unique identifier associated with this protocolDir entry. The value for each supported protocol must remain constant at least from one re-initialization of the entity's network management system to the next re-initialization, except that if a protocol is deleted and re-created, it must be re-created with a new value that has not been used since the last re-initialization. The specific value is meaningful only within a given SNMP entity. A protocolDirLocalIndex must not be re-used until the next agent restart in the event that the protocol directory entry is deleted.

DisplayStringRepresents textual information taken from the NVT ASCII character set, as defined in pages 4, 10-11 of RFC 854. To summarize RFC 854, the NVT ASCII repertoire specifies: - the use of character codes 0-127 (decimal) - the graphics characters (32-126) are interpreted as US ASCII - NUL, LF, CR, BEL, BS, HT, VT and FF have the special meanings specified in RFC 854 - the other 25 codes have no standard interpretation - the sequence 'CR LF' means newline - the sequence 'CR NUL' means carriage-return - an 'LF' not preceded by a 'CR' means moving to the same column on the next line. - the sequence 'CR x' for any x other than LF or NUL is illegal. (Note that this also means that a string may end with either 'CR LF' or 'CR NUL', but not with CR.) Any object defined using this syntax may not exceed 255 characters in length. SIZE (1..64) · OCTET STRING · hint 255a

A textual description of the protocol encapsulation. A probe may choose to describe only a subset of the entire encapsulation (e.g., only the highest layer). This object is intended for human consumption only. This object may not be modified if the associated protocolDirStatus object is equal to active(1).

BITS

This object describes 2 attributes of this protocol directory entry. The presence or absence of the 'extensible' bit describes whether this protocol directory entry can be extended by the user by creating protocol directory entries that are children of this protocol. An example of an entry that will often allow extensibility is 'ip.udp'. The probe may automatically populate some children of this node, such as 'ip.udp.snmp' and 'ip.udp.dns'. A probe administrator or user may also populate additional children via remote SNMP requests that create entries in this table. When a child node is added for a protocol for which the probe has no built-in support extending a parent node (for which the probe does have built-in support), that child node is not extendable. This is termed 'limited extensibility'. When a child node is added through this extensibility mechanism, the values of protocolDirLocalIndex and protocolDirType shall be assigned by the agent. The other objects in the entry will be assigned by the manager who is creating the new entry. This object also describes whether this agent can recognize addresses for this protocol, should it be a network-level protocol. That is, while a probe may be able to recognize packets of a particular network-layer protocol and count them, it takes additional logic to be able to recognize the addresses in this protocol and to populate network-layer or application-layer tables with the addresses in this protocol. If this bit is set, the agent will recognize network-layer addresses for this protocol and populate the network- and application-layer host and matrix tables with these protocols. Note that when an entry is created, the agent will supply values for the bits that match the capabilities of the agent with respect to this protocol. Note that since row creations usually exercise the limited extensibility feature, these bits will usually be set to zero.

INTEGER1 = notSupported2 = supportedOff3 = supportedOn · Integer32

This object describes and configures the probe's support for address mapping for this protocol. When the probe creates entries in this table for all protocols that it understands, it will set the entry to notSupported(1) if it doesn't have the capability to perform address mapping for the protocol or if this protocol is not a network-layer protocol. When an entry is created in this table by a management operation as part of the limited extensibility feature, the probe must set this value to notSupported(1), because limited extensibility of the protocolDirTable does not extend to interpreting addresses of the extended protocols. If the value of this object is notSupported(1), the probe will not perform address mapping for this protocol and shall not allow this object to be changed to any other value. If the value of this object is supportedOn(3), the probe supports address mapping for this protocol and is configured to perform address mapping for this protocol for all addressMappingControlEntries and all interfaces. If the value of this object is supportedOff(2), the probe supports address mapping for this protocol but is configured to not perform address mapping for this protocol for any addressMappingControlEntries and all interfaces. Whenever this value changes from supportedOn(3) to supportedOff(2), the probe shall delete all related entries in the addressMappingTable.

INTEGER1 = notSupported2 = supportedOff3 = supportedOn · Integer32

This object describes and configures the probe's support for the network-layer and application-layer host tables for this protocol. When the probe creates entries in this table for all protocols that it understands, it will set the entry to notSupported(1) if it doesn't have the capability to track the nlHostTable for this protocol or if the alHostTable is implemented but doesn't have the capability to track this protocol. Note that if the alHostTable is implemented, the probe may only support a protocol if it is supported in both the nlHostTable and the alHostTable. If the associated protocolDirType object has the addressRecognitionCapable bit set, then this is a network- layer protocol for which the probe recognizes addresses, and thus the probe will populate the nlHostTable and alHostTable with addresses it discovers for this protocol. If the value of this object is notSupported(1), the probe will not track the nlHostTable or alHostTable for this protocol and shall not allow this object to be changed to any other value. If the value of this object is supportedOn(3), the probe supports tracking of the nlHostTable and alHostTable for this protocol and is configured to track both tables for this protocol for all control entries and all interfaces. If the value of this object is supportedOff(2), the probe supports tracking of the nlHostTable and alHostTable for this protocol but is configured to not track these tables for any control entries or interfaces. Whenever this value changes from supportedOn(3) to supportedOff(2), the probe shall delete all related entries in the nlHostTable and alHostTable. Note that since each alHostEntry references 2 protocol directory entries, one for the network address and one for the type of the highest protocol recognized, an entry will only be created in that table if this value is supportedOn(3) for both protocols.

INTEGER1 = notSupported2 = supportedOff3 = supportedOn · Integer32

This object describes and configures the probe's support for the network-layer and application-layer matrix tables for this protocol. When the probe creates entries in this table for all protocols that it understands, it will set the entry to notSupported(1) if it doesn't have the capability to track the nlMatrixTables for this protocol or if the alMatrixTables are implemented but don't have the capability to track this protocol. Note that if the alMatrix tables are implemented, the probe may only support a protocol if it is supported in both of the nlMatrixTables and both of the alMatrixTables. If the associated protocolDirType object has the addressRecognitionCapable bit set, then this is a network- layer protocol for which the probe recognizes addresses, and thus the probe will populate both of the nlMatrixTables and both of the alMatrixTables with addresses it discovers for this protocol. If the value of this object is notSupported(1), the probe will not track either of the nlMatrixTables or the alMatrixTables for this protocol and shall not allow this object to be changed to any other value. If the value of this object is supportedOn(3), the probe supports tracking of both of the nlMatrixTables and (if implemented) both of the alMatrixTables for this protocol and is configured to track these tables for this protocol for all control entries and all interfaces. If the value of this object is supportedOff(2), the probe supports tracking of both of the nlMatrixTables and (if implemented) both of the alMatrixTables for this protocol but is configured to not track these tables for this protocol for any control entries or interfaces. Whenever this value changes from supportedOn(3) to supportedOff(2), the probe shall delete all related entries in the nlMatrixTables and the alMatrixTables. Note that since each alMatrixEntry references 2 protocol directory entries, one for the network address and one for the type of the highest protocol recognized, an entry will only be created in that table if this value is supportedOn(3) for both protocols.

OwnerStringThis data type is used to model an administratively assigned name of the owner of a resource. Implementations must accept values composed of well-formed NVT ASCII sequences. In addition, implementations should accept values composed of well-formed UTF-8 sequences. It is suggested that this name contain one or more of the following: IP address, management station name, network manager's name, location, or phone number. In some cases the agent itself will be the owner of an entry. In these cases, this string shall be set to a string starting with 'monitor'. SNMP access control is articulated entirely in terms of the contents of MIB views; access to a particular SNMP object instance depends only upon its presence or absence in a particular MIB view and never upon its value or the value of related object instances. Thus, objects of this type afford resolution of resource contention only among cooperating managers; they realize no access control function with respect to uncooperative parties. SIZE (0..127) · OCTET STRING

The entity that configured this entry and is therefore using the resources assigned to it.

RowStatus1 = active2 = notInService3 = notReady4 = createAndGo5 = createAndWait6 = destroyThe RowStatus textual convention is used to manage the creation and deletion of conceptual rows, and is used as the value of the SYNTAX clause for the status column of a conceptual row (as described in Section 7.7.1 of [2].) 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); 'notInService' has no implication regarding the internal consistency of the row, availability of resources, or consistency with the current state of the managed device; - `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 (i.e., one or more required columns in the conceptual row have not been instanciated); - `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 attempt 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 status column having a SYNTAX clause value 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) goto 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, and all columns have acceptable values, then return noError and goto D. (3) if other variable bindings included in the same PDU, provide legal 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 notInService (e.g., an agent which 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. (8) the transition to D can fail, e.g., if the values of the conceptual row are inconsistent, then the error code would be inconsistentValue. NOTE: Other processing of (this and other varbinds 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. A MIB designer should choose between the two latter algorithms based on the size of the table (and therefore the efficiency of each algorithm). For tables in which a large number of entries are expected, it is recommended that a MIB object be defined that returns an acceptable index for creation. For tables with small numbers of entries, it is recommended that the latter pseudo-random index mechanism be used. Interaction 2: Creating the Conceptual Row Once an unused instance-identifier has been selected, the management station determines if it wishes to create and activate the conceptual row in one transaction or in a negotiated set of interactions. Interaction 2a: Creating and Activating the Conceptual Row The management station must first determine the column requirements, i.e., it must determine those columns for which it must or must not provide values. Depending on the complexity of the table and the management station's knowledge of the agent's capabilities, this determination can be made locally by the management station. Alternately, the management station issues a management protocol get operation to examine all columns in the conceptual row that it wishes to create. In response, for each column, there are three possible outcomes: - a value is returned, indicating that some other management station has already created this conceptual row. We return to interaction 1. - the exception `noSuchInstance' is returned, indicating that the agent implements the object-type associated with this column, and that this column in at least one conceptual row would be accessible in the MIB view used by the retrieval were it to exist. For those columns to which the agent provides read-create access, the `noSuchInstance' exception tells the management station that it should supply a value for this column when the conceptual row is to be created. - the exception `noSuchObject' is returned, indicating that the agent does not implement the object-type associated with this column or that there is no conceptual row for which this column would be accessible in the MIB view used by the retrieval. As such, the management station can not issue any management protocol set operations to create an instance of this column. Once the column requirements have been determined, a management protocol set operation is accordingly issued. This operation also sets the new instance of the status column to `createAndGo'. When the agent processes the set operation, it verifies that it has sufficient information to make the conceptual row available for use by the managed device. The information available to the agent is provided by two sources: the management protocol set operation which creates the conceptual row, and, implementation-specific defaults supplied by the agent (note that an agent must provide implementation-specific defaults for at least those objects which it implements as read-only). If there is sufficient information available, then the conceptual row is created, a `noError' response is returned, the status column is set to `active', and no further interactions are necessary (i.e., interactions 3 and 4 are skipped). If there is insufficient information, then the conceptual row is not created, and the set operation fails with an error of `inconsistentValue'. On this error, the management station can issue a management protocol retrieval operation to determine if this was because it failed to specify a value for a required column, or, because the selected instance of the status column already existed. In the latter case, we return to interaction 1. In the former case, the management station can re-issue the set operation with the additional information, or begin interaction 2 again using `createAndWait' in order to negotiate creation of the conceptual row. NOTE WELL Regardless of the method used to determine the column requirements, it is possible that the management station might deem a column necessary when, in fact, the agent will not allow that particular columnar instance to be created or written. In this case, the management protocol set operation will fail with an error such as `noCreation' or `notWritable'. In this case, the management station decides whether it needs to be able to set a value for that particular columnar instance. If not, the management station re-issues the management protocol set operation, but without setting a value for that particular columnar instance; otherwise, the management station aborts the row creation algorithm. Interaction 2b: Negotiating the Creation of the Conceptual Row The management station issues a management protocol set operation which sets the desired instance of the status column to `createAndWait'. If the agent is unwilling to process a request of this sort, the set operation fails with an error of `wrongValue'. (As a consequence, such an agent must be prepared to accept a single management protocol set operation, i.e., interaction 2a above, containing all of the columns indicated by its column requirements.) Otherwise, the conceptual row is created, a `noError' response is returned, and the status column is immediately set to either `notInService' or `notReady', depending on whether it has sufficient information to (attempt to) make the conceptual row available for use by the managed device. If there is sufficient information available, then the status column is set to `notInService'; otherwise, if there is insufficient information, then the status column is set to `notReady'. Regardless, we proceed to interaction 3. Interaction 3: Initializing non-defaulted Objects The management station must now determine the column requirements. It issues a management protocol get operation to examine all columns in the created conceptual row. In the response, for each column, there are three possible outcomes: - a value is returned, indicating that the agent implements the object-type associated with this column and had sufficient information to provide a value. For those columns to which the agent provides read-create access (and for which the agent allows their values to be changed after their creation), a value return tells the management station that it may issue additional management protocol set operations, if it desires, in order to change the value associated with this column. - the exception `noSuchInstance' is returned, indicating that the agent implements the object-type associated with this column, and that this column in at least one conceptual row would be accessible in the MIB view used by the retrieval were it to exist. However, the agent does not have sufficient information to provide a value, and until a value is provided, the conceptual row may not be made available for use by the managed device. For those columns to which the agent provides read-create access, the `noSuchInstance' exception tells the management station that it must issue additional management protocol set operations, in order to provide a value associated with this column. - the exception `noSuchObject' is returned, indicating that the agent does not implement the object-type associated with this column or that there is no conceptual row for which this column would be accessible in the MIB view used by the retrieval. As such, the management station can not issue any management protocol set operations to create an instance of this column. If the value associated with the status column is `notReady', then the management station must first deal with all `noSuchInstance' columns, if any. Having done so, the value of the status column becomes `notInService', and we proceed to interaction 4. Interaction 4: Making the Conceptual Row Available Once the management station is satisfied with the values associated with the columns of the conceptual row, it issues a management protocol set operation to set the status column to `active'. If the agent has sufficient information to make the conceptual row available for use by the managed device, the management protocol set operation succeeds (a `noError' response is returned). Otherwise, the management protocol set operation fails with an error of `inconsistentValue'. NOTE WELL A conceptual row having a status column with value `notInService' or `notReady' is unavailable to the managed device. As such, it is possible for the managed device to create its own instances during the time between the management protocol set operation which sets the status column to `createAndWait' and the management protocol set operation which sets the status column to `active'. In this case, when the management protocol set operation is issued to set the status column to `active', the values held in the agent supersede those used by the managed device. If the management station is prevented from setting the status column to `active' (e.g., due to management station or network failure) the conceptual row will be left in the `notInService' or `notReady' state, consuming resources indefinitely. The agent must detect conceptual rows that have been in either state for an abnormally long period of time and remove them. It is the responsibility of the DESCRIPTION clause of the status column to indicate what an abnormally long period of time would be. This period of time should be long enough to allow for human response time (including `think time') between the creation of the conceptual row and the setting of the status to `active'. In the absence of such information in the DESCRIPTION clause, it is suggested that this period be approximately 5 minutes in length. This removal action applies not only to newly-created rows, but also to previously active rows which are set to, and left in, the notInService state for a prolonged period exceeding that which is considered normal for such a conceptual row. Conceptual Row Suspension When a conceptual row is `active', the management station may issue a management protocol set operation which sets the instance of the status column to `notInService'. If the agent is unwilling to do so, the set operation fails with an error of `wrongValue' or `inconsistentValue'. Otherwise, the conceptual row is taken out of service, and a `noError' response is returned. It is the responsibility of the DESCRIPTION clause of the status column to indicate under what circumstances the status column should be taken out of service (e.g., in order for the value of some other column of the same conceptual row to be modified). Conceptual Row Deletion For deletion of conceptual rows, a management protocol set operation is issued which sets the instance of the status column to `destroy'. This request may be made regardless of the current value of the status column (e.g., it is possible to delete conceptual rows which are either `notReady', `notInService' or `active'.) If the operation succeeds, then all instances associated with the conceptual row are immediately removed. · Integer32

The status of this protocol directory entry. An entry may not exist in the active state unless all objects in the entry have an appropriate value. If this object is not equal to active(1), all associated entries in the nlHostTable, nlMatrixSDTable, nlMatrixDSTable, alHostTable, alMatrixSDTable, and alMatrixDSTable shall be deleted.

Integer32 (1..65535)

A unique index for this protocolDistControlEntry.

DataSourceIdentifies the source of the data that the associated function is configured to analyze. This source can be any interface on this device. In order to identify a particular interface, this object shall identify the instance of the ifIndex object, defined in [RFC2863], for the desired interface. For example, if an entry were to receive data from interface #1, this object would be set to ifIndex.1. · OBJECT IDENTIFIER

The source of data for the this protocol distribution. The statistics in this group reflect all packets on the local network segment attached to the identified interface. This object may not be modified if the associated protocolDistControlStatus object is equal to active(1).

Counter32

The total number of frames that were received by the probe and therefore not accounted for in the *StatsDropEvents, but that the probe chose not to count for this entry for whatever reason. Most often, this event occurs when the probe is out of some resources and decides to shed load from this collection. This count does not include packets that were not counted because they had MAC-layer errors. Note that, unlike the dropEvents counter, this number is the exact number of frames dropped.

LastCreateTimeThis TC describes an object that stores the value of the sysUpTime object at the last time its entry was created. This can be used for polling applications to determine that an entry has been deleted and re-created between polls, causing an otherwise undetectable discontinuity in the data. If sysUpTime is reset to zero as a result of a re- initialization of the network management (sub)system, then the values of all LastCreateTime objects are also reset. However, after approximately 497 days without a re- initialization, the sysUpTime object will reach 2^^32-1 and then increment to zero; in this case, existing values of TimeStamp objects do not change. This can lead to ambiguities in the value of TimeStamp objects. · TimeTicks

The value of sysUpTime when this control entry was last activated. This can be used by the management station to ensure that the table has not been deleted and recreated between polls.

OwnerStringThis data type is used to model an administratively assigned name of the owner of a resource. Implementations must accept values composed of well-formed NVT ASCII sequences. In addition, implementations should accept values composed of well-formed UTF-8 sequences. It is suggested that this name contain one or more of the following: IP address, management station name, network manager's name, location, or phone number. In some cases the agent itself will be the owner of an entry. In these cases, this string shall be set to a string starting with 'monitor'. SNMP access control is articulated entirely in terms of the contents of MIB views; access to a particular SNMP object instance depends only upon its presence or absence in a particular MIB view and never upon its value or the value of related object instances. Thus, objects of this type afford resolution of resource contention only among cooperating managers; they realize no access control function with respect to uncooperative parties. SIZE (0..127) · OCTET STRING

The entity that configured this entry and is therefore using the resources assigned to it.

RowStatus1 = active2 = notInService3 = notReady4 = createAndGo5 = createAndWait6 = destroyThe RowStatus textual convention is used to manage the creation and deletion of conceptual rows, and is used as the value of the SYNTAX clause for the status column of a conceptual row (as described in Section 7.7.1 of [2].) 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); 'notInService' has no implication regarding the internal consistency of the row, availability of resources, or consistency with the current state of the managed device; - `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 (i.e., one or more required columns in the conceptual row have not been instanciated); - `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 attempt 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 status column having a SYNTAX clause value 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) goto 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, and all columns have acceptable values, then return noError and goto D. (3) if other variable bindings included in the same PDU, provide legal 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 notInService (e.g., an agent which 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. (8) the transition to D can fail, e.g., if the values of the conceptual row are inconsistent, then the error code would be inconsistentValue. NOTE: Other processing of (this and other varbinds 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. A MIB designer should choose between the two latter algorithms based on the size of the table (and therefore the efficiency of each algorithm). For tables in which a large number of entries are expected, it is recommended that a MIB object be defined that returns an acceptable index for creation. For tables with small numbers of entries, it is recommended that the latter pseudo-random index mechanism be used. Interaction 2: Creating the Conceptual Row Once an unused instance-identifier has been selected, the management station determines if it wishes to create and activate the conceptual row in one transaction or in a negotiated set of interactions. Interaction 2a: Creating and Activating the Conceptual Row The management station must first determine the column requirements, i.e., it must determine those columns for which it must or must not provide values. Depending on the complexity of the table and the management station's knowledge of the agent's capabilities, this determination can be made locally by the management station. Alternately, the management station issues a management protocol get operation to examine all columns in the conceptual row that it wishes to create. In response, for each column, there are three possible outcomes: - a value is returned, indicating that some other management station has already created this conceptual row. We return to interaction 1. - the exception `noSuchInstance' is returned, indicating that the agent implements the object-type associated with this column, and that this column in at least one conceptual row would be accessible in the MIB view used by the retrieval were it to exist. For those columns to which the agent provides read-create access, the `noSuchInstance' exception tells the management station that it should supply a value for this column when the conceptual row is to be created. - the exception `noSuchObject' is returned, indicating that the agent does not implement the object-type associated with this column or that there is no conceptual row for which this column would be accessible in the MIB view used by the retrieval. As such, the management station can not issue any management protocol set operations to create an instance of this column. Once the column requirements have been determined, a management protocol set operation is accordingly issued. This operation also sets the new instance of the status column to `createAndGo'. When the agent processes the set operation, it verifies that it has sufficient information to make the conceptual row available for use by the managed device. The information available to the agent is provided by two sources: the management protocol set operation which creates the conceptual row, and, implementation-specific defaults supplied by the agent (note that an agent must provide implementation-specific defaults for at least those objects which it implements as read-only). If there is sufficient information available, then the conceptual row is created, a `noError' response is returned, the status column is set to `active', and no further interactions are necessary (i.e., interactions 3 and 4 are skipped). If there is insufficient information, then the conceptual row is not created, and the set operation fails with an error of `inconsistentValue'. On this error, the management station can issue a management protocol retrieval operation to determine if this was because it failed to specify a value for a required column, or, because the selected instance of the status column already existed. In the latter case, we return to interaction 1. In the former case, the management station can re-issue the set operation with the additional information, or begin interaction 2 again using `createAndWait' in order to negotiate creation of the conceptual row. NOTE WELL Regardless of the method used to determine the column requirements, it is possible that the management station might deem a column necessary when, in fact, the agent will not allow that particular columnar instance to be created or written. In this case, the management protocol set operation will fail with an error such as `noCreation' or `notWritable'. In this case, the management station decides whether it needs to be able to set a value for that particular columnar instance. If not, the management station re-issues the management protocol set operation, but without setting a value for that particular columnar instance; otherwise, the management station aborts the row creation algorithm. Interaction 2b: Negotiating the Creation of the Conceptual Row The management station issues a management protocol set operation which sets the desired instance of the status column to `createAndWait'. If the agent is unwilling to process a request of this sort, the set operation fails with an error of `wrongValue'. (As a consequence, such an agent must be prepared to accept a single management protocol set operation, i.e., interaction 2a above, containing all of the columns indicated by its column requirements.) Otherwise, the conceptual row is created, a `noError' response is returned, and the status column is immediately set to either `notInService' or `notReady', depending on whether it has sufficient information to (attempt to) make the conceptual row available for use by the managed device. If there is sufficient information available, then the status column is set to `notInService'; otherwise, if there is insufficient information, then the status column is set to `notReady'. Regardless, we proceed to interaction 3. Interaction 3: Initializing non-defaulted Objects The management station must now determine the column requirements. It issues a management protocol get operation to examine all columns in the created conceptual row. In the response, for each column, there are three possible outcomes: - a value is returned, indicating that the agent implements the object-type associated with this column and had sufficient information to provide a value. For those columns to which the agent provides read-create access (and for which the agent allows their values to be changed after their creation), a value return tells the management station that it may issue additional management protocol set operations, if it desires, in order to change the value associated with this column. - the exception `noSuchInstance' is returned, indicating that the agent implements the object-type associated with this column, and that this column in at least one conceptual row would be accessible in the MIB view used by the retrieval were it to exist. However, the agent does not have sufficient information to provide a value, and until a value is provided, the conceptual row may not be made available for use by the managed device. For those columns to which the agent provides read-create access, the `noSuchInstance' exception tells the management station that it must issue additional management protocol set operations, in order to provide a value associated with this column. - the exception `noSuchObject' is returned, indicating that the agent does not implement the object-type associated with this column or that there is no conceptual row for which this column would be accessible in the MIB view used by the retrieval. As such, the management station can not issue any management protocol set operations to create an instance of this column. If the value associated with the status column is `notReady', then the management station must first deal with all `noSuchInstance' columns, if any. Having done so, the value of the status column becomes `notInService', and we proceed to interaction 4. Interaction 4: Making the Conceptual Row Available Once the management station is satisfied with the values associated with the columns of the conceptual row, it issues a management protocol set operation to set the status column to `active'. If the agent has sufficient information to make the conceptual row available for use by the managed device, the management protocol set operation succeeds (a `noError' response is returned). Otherwise, the management protocol set operation fails with an error of `inconsistentValue'. NOTE WELL A conceptual row having a status column with value `notInService' or `notReady' is unavailable to the managed device. As such, it is possible for the managed device to create its own instances during the time between the management protocol set operation which sets the status column to `createAndWait' and the management protocol set operation which sets the status column to `active'. In this case, when the management protocol set operation is issued to set the status column to `active', the values held in the agent supersede those used by the managed device. If the management station is prevented from setting the status column to `active' (e.g., due to management station or network failure) the conceptual row will be left in the `notInService' or `notReady' state, consuming resources indefinitely. The agent must detect conceptual rows that have been in either state for an abnormally long period of time and remove them. It is the responsibility of the DESCRIPTION clause of the status column to indicate what an abnormally long period of time would be. This period of time should be long enough to allow for human response time (including `think time') between the creation of the conceptual row and the setting of the status to `active'. In the absence of such information in the DESCRIPTION clause, it is suggested that this period be approximately 5 minutes in length. This removal action applies not only to newly-created rows, but also to previously active rows which are set to, and left in, the notInService state for a prolonged period exceeding that which is considered normal for such a conceptual row. Conceptual Row Suspension When a conceptual row is `active', the management station may issue a management protocol set operation which sets the instance of the status column to `notInService'. If the agent is unwilling to do so, the set operation fails with an error of `wrongValue' or `inconsistentValue'. Otherwise, the conceptual row is taken out of service, and a `noError' response is returned. It is the responsibility of the DESCRIPTION clause of the status column to indicate under what circumstances the status column should be taken out of service (e.g., in order for the value of some other column of the same conceptual row to be modified). Conceptual Row Deletion For deletion of conceptual rows, a management protocol set operation is issued which sets the instance of the status column to `destroy'. This request may be made regardless of the current value of the status column (e.g., it is possible to delete conceptual rows which are either `notReady', `notInService' or `active'.) If the operation succeeds, then all instances associated with the conceptual row are immediately removed. · Integer32

The status of this row. An entry may not exist in the active state unless all objects in the entry have an appropriate value. If this object is not equal to active(1), all associated entries in the protocolDistStatsTable shall be deleted.

ZeroBasedCounter32This TC describes an object that counts events with the following semantics: objects of this type will be set to zero(0) on creation and will thereafter count appropriate events, wrapping back to zero(0) when the value 2^32 is reached. Provided that an application discovers the new object within the minimum time to wrap, it can use the initial value as a delta since it last polled the table of which this object is part. It is important for a management station to be aware of this minimum time and the actual time between polls, and to discard data if the actual time is too long or there is no defined minimum time. Typically, this TC is used in tables where the INDEX space is constantly changing and/or the TimeFilter mechanism is in use. · Gauge32

The number of packets of this protocol type received without errors. Note that this is the number of link-layer packets, so if a single network-layer packet is fragmented into several link-layer frames, this counter is incremented several times.

ZeroBasedCounter32This TC describes an object that counts events with the following semantics: objects of this type will be set to zero(0) on creation and will thereafter count appropriate events, wrapping back to zero(0) when the value 2^32 is reached. Provided that an application discovers the new object within the minimum time to wrap, it can use the initial value as a delta since it last polled the table of which this object is part. It is important for a management station to be aware of this minimum time and the actual time between polls, and to discard data if the actual time is too long or there is no defined minimum time. Typically, this TC is used in tables where the INDEX space is constantly changing and/or the TimeFilter mechanism is in use. · Gauge32

The number of octets in packets of this protocol type received since it was added to the protocolDistStatsTable (excluding framing bits, but including FCS octets), except for those octets in packets that contained errors. Note that this doesn't count just those octets in the particular protocol frames but includes the entire packet that contained the protocol.

Integer32 (1..65535)

A unique index for this entry in the addressMapControlTable.

DataSourceIdentifies the source of the data that the associated function is configured to analyze. This source can be any interface on this device. In order to identify a particular interface, this object shall identify the instance of the ifIndex object, defined in [RFC2863], for the desired interface. For example, if an entry were to receive data from interface #1, this object would be set to ifIndex.1. · OBJECT IDENTIFIER

The source of data for this addressMapControlEntry.

Counter32

The total number of frames that were received by the probe and therefore not accounted for in the *StatsDropEvents, but that the probe chose not to count for this entry for whatever reason. Most often, this event occurs when the probe is out of some resources and decides to shed load from this collection. This count does not include packets that were not counted because they had MAC-layer errors. Note that, unlike the dropEvents counter, this number is the exact number of frames dropped.

OwnerStringThis data type is used to model an administratively assigned name of the owner of a resource. Implementations must accept values composed of well-formed NVT ASCII sequences. In addition, implementations should accept values composed of well-formed UTF-8 sequences. It is suggested that this name contain one or more of the following: IP address, management station name, network manager's name, location, or phone number. In some cases the agent itself will be the owner of an entry. In these cases, this string shall be set to a string starting with 'monitor'. SNMP access control is articulated entirely in terms of the contents of MIB views; access to a particular SNMP object instance depends only upon its presence or absence in a particular MIB view and never upon its value or the value of related object instances. Thus, objects of this type afford resolution of resource contention only among cooperating managers; they realize no access control function with respect to uncooperative parties. SIZE (0..127) · OCTET STRING

The entity that configured this entry and is therefore using the resources assigned to it.

RowStatus1 = active2 = notInService3 = notReady4 = createAndGo5 = createAndWait6 = destroyThe RowStatus textual convention is used to manage the creation and deletion of conceptual rows, and is used as the value of the SYNTAX clause for the status column of a conceptual row (as described in Section 7.7.1 of [2].) 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); 'notInService' has no implication regarding the internal consistency of the row, availability of resources, or consistency with the current state of the managed device; - `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 (i.e., one or more required columns in the conceptual row have not been instanciated); - `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 attempt 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 status column having a SYNTAX clause value 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) goto 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, and all columns have acceptable values, then return noError and goto D. (3) if other variable bindings included in the same PDU, provide legal 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 notInService (e.g., an agent which 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. (8) the transition to D can fail, e.g., if the values of the conceptual row are inconsistent, then the error code would be inconsistentValue. NOTE: Other processing of (this and other varbinds 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. A MIB designer should choose between the two latter algorithms based on the size of the table (and therefore the efficiency of each algorithm). For tables in which a large number of entries are expected, it is recommended that a MIB object be defined that returns an acceptable index for creation. For tables with small numbers of entries, it is recommended that the latter pseudo-random index mechanism be used. Interaction 2: Creating the Conceptual Row Once an unused instance-identifier has been selected, the management station determines if it wishes to create and activate the conceptual row in one transaction or in a negotiated set of interactions. Interaction 2a: Creating and Activating the Conceptual Row The management station must first determine the column requirements, i.e., it must determine those columns for which it must or must not provide values. Depending on the complexity of the table and the management station's knowledge of the agent's capabilities, this determination can be made locally by the management station. Alternately, the management station issues a management protocol get operation to examine all columns in the conceptual row that it wishes to create. In response, for each column, there are three possible outcomes: - a value is returned, indicating that some other management station has already created this conceptual row. We return to interaction 1. - the exception `noSuchInstance' is returned, indicating that the agent implements the object-type associated with this column, and that this column in at least one conceptual row would be accessible in the MIB view used by the retrieval were it to exist. For those columns to which the agent provides read-create access, the `noSuchInstance' exception tells the management station that it should supply a value for this column when the conceptual row is to be created. - the exception `noSuchObject' is returned, indicating that the agent does not implement the object-type associated with this column or that there is no conceptual row for which this column would be accessible in the MIB view used by the retrieval. As such, the management station can not issue any management protocol set operations to create an instance of this column. Once the column requirements have been determined, a management protocol set operation is accordingly issued. This operation also sets the new instance of the status column to `createAndGo'. When the agent processes the set operation, it verifies that it has sufficient information to make the conceptual row available for use by the managed device. The information available to the agent is provided by two sources: the management protocol set operation which creates the conceptual row, and, implementation-specific defaults supplied by the agent (note that an agent must provide implementation-specific defaults for at least those objects which it implements as read-only). If there is sufficient information available, then the conceptual row is created, a `noError' response is returned, the status column is set to `active', and no further interactions are necessary (i.e., interactions 3 and 4 are skipped). If there is insufficient information, then the conceptual row is not created, and the set operation fails with an error of `inconsistentValue'. On this error, the management station can issue a management protocol retrieval operation to determine if this was because it failed to specify a value for a required column, or, because the selected instance of the status column already existed. In the latter case, we return to interaction 1. In the former case, the management station can re-issue the set operation with the additional information, or begin interaction 2 again using `createAndWait' in order to negotiate creation of the conceptual row. NOTE WELL Regardless of the method used to determine the column requirements, it is possible that the management station might deem a column necessary when, in fact, the agent will not allow that particular columnar instance to be created or written. In this case, the management protocol set operation will fail with an error such as `noCreation' or `notWritable'. In this case, the management station decides whether it needs to be able to set a value for that particular columnar instance. If not, the management station re-issues the management protocol set operation, but without setting a value for that particular columnar instance; otherwise, the management station aborts the row creation algorithm. Interaction 2b: Negotiating the Creation of the Conceptual Row The management station issues a management protocol set operation which sets the desired instance of the status column to `createAndWait'. If the agent is unwilling to process a request of this sort, the set operation fails with an error of `wrongValue'. (As a consequence, such an agent must be prepared to accept a single management protocol set operation, i.e., interaction 2a above, containing all of the columns indicated by its column requirements.) Otherwise, the conceptual row is created, a `noError' response is returned, and the status column is immediately set to either `notInService' or `notReady', depending on whether it has sufficient information to (attempt to) make the conceptual row available for use by the managed device. If there is sufficient information available, then the status column is set to `notInService'; otherwise, if there is insufficient information, then the status column is set to `notReady'. Regardless, we proceed to interaction 3. Interaction 3: Initializing non-defaulted Objects The management station must now determine the column requirements. It issues a management protocol get operation to examine all columns in the created conceptual row. In the response, for each column, there are three possible outcomes: - a value is returned, indicating that the agent implements the object-type associated with this column and had sufficient information to provide a value. For those columns to which the agent provides read-create access (and for which the agent allows their values to be changed after their creation), a value return tells the management station that it may issue additional management protocol set operations, if it desires, in order to change the value associated with this column. - the exception `noSuchInstance' is returned, indicating that the agent implements the object-type associated with this column, and that this column in at least one conceptual row would be accessible in the MIB view used by the retrieval were it to exist. However, the agent does not have sufficient information to provide a value, and until a value is provided, the conceptual row may not be made available for use by the managed device. For those columns to which the agent provides read-create access, the `noSuchInstance' exception tells the management station that it must issue additional management protocol set operations, in order to provide a value associated with this column. - the exception `noSuchObject' is returned, indicating that the agent does not implement the object-type associated with this column or that there is no conceptual row for which this column would be accessible in the MIB view used by the retrieval. As such, the management station can not issue any management protocol set operations to create an instance of this column. If the value associated with the status column is `notReady', then the management station must first deal with all `noSuchInstance' columns, if any. Having done so, the value of the status column becomes `notInService', and we proceed to interaction 4. Interaction 4: Making the Conceptual Row Available Once the management station is satisfied with the values associated with the columns of the conceptual row, it issues a management protocol set operation to set the status column to `active'. If the agent has sufficient information to make the conceptual row available for use by the managed device, the management protocol set operation succeeds (a `noError' response is returned). Otherwise, the management protocol set operation fails with an error of `inconsistentValue'. NOTE WELL A conceptual row having a status column with value `notInService' or `notReady' is unavailable to the managed device. As such, it is possible for the managed device to create its own instances during the time between the management protocol set operation which sets the status column to `createAndWait' and the management protocol set operation which sets the status column to `active'. In this case, when the management protocol set operation is issued to set the status column to `active', the values held in the agent supersede those used by the managed device. If the management station is prevented from setting the status column to `active' (e.g., due to management station or network failure) the conceptual row will be left in the `notInService' or `notReady' state, consuming resources indefinitely. The agent must detect conceptual rows that have been in either state for an abnormally long period of time and remove them. It is the responsibility of the DESCRIPTION clause of the status column to indicate what an abnormally long period of time would be. This period of time should be long enough to allow for human response time (including `think time') between the creation of the conceptual row and the setting of the status to `active'. In the absence of such information in the DESCRIPTION clause, it is suggested that this period be approximately 5 minutes in length. This removal action applies not only to newly-created rows, but also to previously active rows which are set to, and left in, the notInService state for a prolonged period exceeding that which is considered normal for such a conceptual row. Conceptual Row Suspension When a conceptual row is `active', the management station may issue a management protocol set operation which sets the instance of the status column to `notInService'. If the agent is unwilling to do so, the set operation fails with an error of `wrongValue' or `inconsistentValue'. Otherwise, the conceptual row is taken out of service, and a `noError' response is returned. It is the responsibility of the DESCRIPTION clause of the status column to indicate under what circumstances the status column should be taken out of service (e.g., in order for the value of some other column of the same conceptual row to be modified). Conceptual Row Deletion For deletion of conceptual rows, a management protocol set operation is issued which sets the instance of the status column to `destroy'. This request may be made regardless of the current value of the status column (e.g., it is possible to delete conceptual rows which are either `notReady', `notInService' or `active'.) If the operation succeeds, then all instances associated with the conceptual row are immediately removed. · Integer32

The status of this addressMap control entry. An entry may not exist in the active state unless all objects in the entry have an appropriate value. If this object is not equal to active(1), all associated entries in the addressMapTable shall be deleted.

TimeFilterTo be used for the index to a table. Allows an application to download only those rows changed since a particular time. Note that this is not a history mechanism. Only current values of underlying objects are returned; saved instance values associated with particular values of sysUpTime are not. An entry is considered changed if the value of any object in the entry changes, if the row is created, or if any object in the entry is created or deleted. Note that deleted entries cannot be detected or downloaded. A time-filtered conceptual table is created by inserting a single object of SYNTAX TimeFilter as the first INDEX component in a copy of an existing basic conceptual table (i.e., any SEQUENCE without a TimeFilter INDEX component). Thus, for each conceptual entry 'I' in the basic table, there exists N conceptual entries in the time-filtered version, indexed N.I, where 'N' is equal to the value of sysUpTime. When an application retrieves conceptual instances from a time-filtered table, and an INDEX value is provided for the TimeFilter INDEX component 'N', the agent will only consider returning basic conceptual entries (e.g., 'fooColumn.N.I') if any column within the basic conceptual entry has changed since sysUpTime 'N'. If not, the basic conceptual entry will be ignored for the particular retrieval operation. When sysUpTime is equal to zero, this table shall be empty. One conceptual entry exists for each past value of sysUpTime, except that the whole table is purged should sysUpTime wrap. As an entry in a time-filtered table is updated (i.e., one of the columns in the basic conceptual table is changed), new conceptual entries are also created in the time-filtered version (which still shares the now updated object values with all other instances). The number of unique time-filtered instances that are created is determined by the value of sysUpTime at which the basic entry was last updated. One unique instance will exist for each value of sysUpTime at the last update time for the row. However, a new TimeFilter index instance is created for each new sysUpTime value. The TimeFilter index values not associated with entry updates are called duplicate time-filtered instances. After some deployment experience, it has been determined that a time-filtered table is more efficient if the agent stops a MIB walk operation by skipping over rows with a TimeFilter index value higher than the value in the received GetNext/GetBulk request. That is, instead of incrementing a TimeFilter index value, the agent will continue to the next object or table. As a consequence, GetNext or GetBulk operations will provide only one pass through a time-filtered table. It is suggested that an agent implement a time-filtered table in this manner to improve performance and avoid a MIB walk getting stuck in time-filtered tables. It is, however, still acceptable for an agent to implement a time-filtered table in the traditional manner (i.e., every conceptual time-filtered instance is returned in GetNext and GetBulk PDU responses), and management applications must be able to deal with such traditional implementations. See the appendix for further discussion of this textual convention. The following example is provided to demonstrate TimeFilter behavior: Consider the following basic conceptual table, basicFooTable. (Note that the basic version of a time-filtered table may not actually be defined.) basicFooTable: basicFooTable ... INDEX { fooIndex } BasicFooEntry { fooIndex Integer32, fooCounts Counter32 } For this example, the basicFooTable contains two static conceptual entries (fooIndex equals '1' and '2'), created at time zero. It also contains one dynamic conceptual entry (fooIndex equals '3'), which is created at time '3' and deleted at time '7'. The time-filtered version of the basicFooTable could be defined as follows: FooTable: fooTable ... INDEX { fooTimeMark, fooIndex } FooEntry { fooTimeMark TimeFilter, fooIndex Integer32, fooCounts Counter32 } Note that entries exist in the time-filtered conceptual table only if they actually exist in the underlying (basic) table. For this example, the fooTable will have three underlying basic entries (fooIndex == 1, 2, and 3), with the following activity (for sysUpTime equal 0 to 9): - fooEntry.N.1 is created at time '0' and most recently updated at time '6' to the value '5'. - fooEntry.N.2 is created at time '0' and most recently updated at time '8' to the value '9'. - fooEntry.N.3 is created at time '3', updated at time '5' to the value '17', and deleted at time '7'. The following tables show the values that would be returned for MIB walk operations with various TimeFilter values, done at different times. An application issues a retrieval request at time 'T', with a TimeFilter value, 'N' (typically set to a lower value, such as the value of sysUpTime at the last polling cycle). The following values would be returned in a MIB walk of fooCounts.N if T equals '0' and N equals '0': fooCounts.N.I Value ========================== fooCounts.0.1 0 fooCounts.0.2 0 Note that nothing is returned for fooCounts.0.3, since that entry does not exist at sysUpTime equals '0'. The following values would be returned in a full (traditional) MIB walk of fooCounts.N if T equals '3' and N equals '0': fooCounts.N.I Value ======================= fooCounts.0.1 0 fooCounts.0.2 0 fooCounts.0.3 0 fooCounts.1.3 0 fooCounts.2.3 0 fooCounts.3.3 0 Note that there are no instances for T equals 1 or 2 for the first two values of N, as these entries did not change since they were created at time '0'. Note that the current value for 'fooCounts.N.3' is returned here, even for values of N less than '3' (when the entry was created). The agent only considers the current existence of an entry in the TimeFilter algorithm, not the time when the entry was created. Note that the instances 'fooCounts.0.3', 'fooCounts.1.3', and 'fooCounts.2.3' are duplicates and can be suppressed by the agent in a MIB walk. The following values would be returned in a full (traditional) MIB walk of fooCounts.N if T equals '6' and N equals '3': fooCounts.N.I Value ======================= fooCounts.3.1 5 fooCounts.3.3 17 fooCounts.4.1 5 fooCounts.4.3 17 fooCounts.5.1 5 fooCounts.5.3 17 fooCounts.6.1 5 Note that no instances for entry 'fooCounts.N.2' are returned, since it has not changed since time '3'. Note that all instances except 'fooCounts.5.3' and 'fooCounts.6.1' are duplicates and can be suppressed by the agent in a MIB walk. The following values would be returned in a full (traditional) MIB walk of fooCounts.N if T equals '9' and N equals '6': fooCounts.N.I Value ======================= fooCounts.6.1 5 fooCounts.6.2 9 fooCounts.7.2 9 fooCounts.8.2 9 Note that no instances for entry 'fooCounts.N.3' are returned, since it was deleted at time '7'. Note that instances 'fooCounts.6.2' and 'fooCounts.7.2' are duplicates and can be suppressed by the agent in a MIB walk. · TimeTicks

A TimeFilter for this entry. See the TimeFilter textual convention to see how this works.

OCTET STRING SIZE (1..255)

The network address for this relation. This is represented as an octet string with specific semantics and length as identified by the protocolDirLocalIndex component of the index. For example, if the protocolDirLocalIndex indicates an encapsulation of ip, this object is encoded as a length octet of 4, followed by the 4 octets of the IP address, in network byte order.

OBJECT IDENTIFIER

The interface or port on which the associated network address was most recently seen. If this address mapping was discovered on an interface, this object shall identify the instance of the ifIndex object, defined in [RFC2863], for the desired interface. For example, if an entry were to receive data from interface #1, this object would be set to ifIndex.1. If this address mapping was discovered on a port, this object shall identify the instance of the rptrGroupPortIndex object, defined in [RFC2108], for the desired port. For example, if an entry were to receive data from group #1, port #1, this object would be set to rptrGroupPortIndex.1.1. Note that while the dataSource associated with this entry may only point to index objects, this object may at times point to repeater port objects. This situation occurs when the dataSource points to an interface that is a locally attached repeater and the agent has additional information about the source port of traffic seen on that repeater.

OCTET STRING

The last source physical address on which the associated network address was seen. If the protocol of the associated network address was encapsulated inside of a network-level or higher protocol, this will be the address of the next-lower protocol with the addressRecognitionCapable bit enabled and will be formatted as specified for that protocol.

TimeStampThe value of the sysUpTime object at which a specific occurrence happened. The specific occurrence must be defined in the description of any object defined using this type. If sysUpTime is reset to zero as a result of a re- initialization of the network management (sub)system, then the values of all TimeStamp objects are also reset. However, after approximately 497 days without a re- initialization, the sysUpTime object will reach 2^^32-1 and then increment around to zero; in this case, existing values of TimeStamp objects do not change. This can lead to ambiguities in the value of TimeStamp objects. · TimeTicks

The value of sysUpTime at the time this entry was last created or the values of the physical address changed. This can be used to help detect duplicate address problems, in which case this object will be updated frequently.

Integer32 (1..65535)

An index that uniquely identifies an entry in the hlHostControlTable. Each such entry defines a function that discovers hosts on a particular interface and places statistics about them in the nlHostTable, and optionally in the alHostTable, on behalf of this hlHostControlEntry.

DataSourceIdentifies the source of the data that the associated function is configured to analyze. This source can be any interface on this device. In order to identify a particular interface, this object shall identify the instance of the ifIndex object, defined in [RFC2863], for the desired interface. For example, if an entry were to receive data from interface #1, this object would be set to ifIndex.1. · OBJECT IDENTIFIER

The source of data for the associated host tables. The statistics in this group reflect all packets on the local network segment attached to the identified interface. This object may not be modified if the associated hlHostControlStatus object is equal to active(1).

Counter32

The total number of frames that were received by the probe and therefore not accounted for in the *StatsDropEvents, but that the probe chose not to count for the associated nlHost entries for whatever reason. Most often, this event occurs when the probe is out of some resources and decides to shed load from this collection. This count does not include packets that were not counted because they had MAC-layer errors. Note that if the nlHostTable is inactive because no protocols are enabled in the protocol directory, this value should be 0. Note that, unlike the dropEvents counter, this number is the exact number of frames dropped.

Counter32

The number of times an nlHost entry has been inserted into the nlHost table. If an entry is inserted, then deleted, and then inserted, this counter will be incremented by 2. To allow for efficient implementation strategies, agents may delay updating this object for short periods of time. For example, an implementation strategy may allow internal data structures to differ from those visible via SNMP for short periods of time. This counter may reflect the internal data structures for those short periods of time. Note that the table size can be determined by subtracting hlHostControlNlDeletes from hlHostControlNlInserts.

Counter32

The number of times an nlHost entry has been deleted from the nlHost table (for any reason). If an entry is deleted, then inserted, and then deleted, this counter will be incremented by 2. To allow for efficient implementation strategies, agents may delay updating this object for short periods of time. For example, an implementation strategy may allow internal data structures to differ from those visible via SNMP for short periods of time. This counter may reflect the internal data structures for those short periods of time. Note that the table size can be determined by subtracting hlHostControlNlDeletes from hlHostControlNlInserts.

Integer32 (-1..2147483647)

The maximum number of entries that are desired in the nlHostTable on behalf of this control entry. The probe will not create more than this number of associated entries in the table but may choose to create fewer entries in this table for any reason, including the lack of resources. If this object is set to a value less than the current number of entries, enough entries are chosen in an implementation-dependent manner and deleted so that the number of entries in the table equals the value of this object. If this value is set to -1, the probe may create any number of entries in this table. If the associated hlHostControlStatus object is equal to 'active', this object may not be modified. This object may be used to control how resources are allocated on the probe for the various RMON functions.

Counter32

The total number of frames that were received by the probe and therefore not accounted for in the *StatsDropEvents, but that the probe chose not to count for the associated alHost entries for whatever reason. Most often, this event occurs when the probe is out of some resources and decides to shed load from this collection. This count does not include packets that were not counted because they had MAC-layer errors. Note that if the alHostTable is not implemented or is inactive because no protocols are enabled in the protocol directory, this value should be 0. Note that, unlike the dropEvents counter, this number is the exact number of frames dropped.

Counter32

The number of times an alHost entry has been inserted into the alHost table. If an entry is inserted, then deleted, and then inserted, this counter will be incremented by 2. To allow for efficient implementation strategies, agents may delay updating this object for short periods of time. For example, an implementation strategy may allow internal data structures to differ from those visible via SNMP for short periods of time. This counter may reflect the internal data structures for those short periods of time. Note that the table size can be determined by subtracting hlHostControlAlDeletes from hlHostControlAlInserts.

Counter32

The number of times an alHost entry has been deleted from the alHost table (for any reason). If an entry is deleted, then inserted, and then deleted, this counter will be incremented by 2. To allow for efficient implementation strategies, agents may delay updating this object for short periods of time. For example, an implementation strategy may allow internal data structures to differ from those visible via SNMP for short periods of time. This counter may reflect the internal data structures for those short periods of time. Note that the table size can be determined by subtracting hlHostControlAlDeletes from hlHostControlAlInserts.

Integer32 (-1..2147483647)

The maximum number of entries that are desired in the alHost table on behalf of this control entry. The probe will not create more than this number of associated entries in the table but may choose to create fewer entries in this table for any reason, including the lack of resources. If this object is set to a value less than the current number of entries, enough entries are chosen in an implementation-dependent manner and deleted so that the number of entries in the table equals the value of this object. If this value is set to -1, the probe may create any number of entries in this table. If the associated hlHostControlStatus object is equal to 'active', this object may not be modified. This object may be used to control how resources are allocated on the probe for the various RMON functions.

OwnerStringThis data type is used to model an administratively assigned name of the owner of a resource. Implementations must accept values composed of well-formed NVT ASCII sequences. In addition, implementations should accept values composed of well-formed UTF-8 sequences. It is suggested that this name contain one or more of the following: IP address, management station name, network manager's name, location, or phone number. In some cases the agent itself will be the owner of an entry. In these cases, this string shall be set to a string starting with 'monitor'. SNMP access control is articulated entirely in terms of the contents of MIB views; access to a particular SNMP object instance depends only upon its presence or absence in a particular MIB view and never upon its value or the value of related object instances. Thus, objects of this type afford resolution of resource contention only among cooperating managers; they realize no access control function with respect to uncooperative parties. SIZE (0..127) · OCTET STRING

The entity that configured this entry and is therefore using the resources assigned to it.

RowStatus1 = active2 = notInService3 = notReady4 = createAndGo5 = createAndWait6 = destroyThe RowStatus textual convention is used to manage the creation and deletion of conceptual rows, and is used as the value of the SYNTAX clause for the status column of a conceptual row (as described in Section 7.7.1 of [2].) 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); 'notInService' has no implication regarding the internal consistency of the row, availability of resources, or consistency with the current state of the managed device; - `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 (i.e., one or more required columns in the conceptual row have not been instanciated); - `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 attempt 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 status column having a SYNTAX clause value 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) goto 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, and all columns have acceptable values, then return noError and goto D. (3) if other variable bindings included in the same PDU, provide legal 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 notInService (e.g., an agent which 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. (8) the transition to D can fail, e.g., if the values of the conceptual row are inconsistent, then the error code would be inconsistentValue. NOTE: Other processing of (this and other varbinds 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. A MIB designer should choose between the two latter algorithms based on the size of the table (and therefore the efficiency of each algorithm). For tables in which a large number of entries are expected, it is recommended that a MIB object be defined that returns an acceptable index for creation. For tables with small numbers of entries, it is recommended that the latter pseudo-random index mechanism be used. Interaction 2: Creating the Conceptual Row Once an unused instance-identifier has been selected, the management station determines if it wishes to create and activate the conceptual row in one transaction or in a negotiated set of interactions. Interaction 2a: Creating and Activating the Conceptual Row The management station must first determine the column requirements, i.e., it must determine those columns for which it must or must not provide values. Depending on the complexity of the table and the management station's knowledge of the agent's capabilities, this determination can be made locally by the management station. Alternately, the management station issues a management protocol get operation to examine all columns in the conceptual row that it wishes to create. In response, for each column, there are three possible outcomes: - a value is returned, indicating that some other management station has already created this conceptual row. We return to interaction 1. - the exception `noSuchInstance' is returned, indicating that the agent implements the object-type associated with this column, and that this column in at least one conceptual row would be accessible in the MIB view used by the retrieval were it to exist. For those columns to which the agent provides read-create access, the `noSuchInstance' exception tells the management station that it should supply a value for this column when the conceptual row is to be created. - the exception `noSuchObject' is returned, indicating that the agent does not implement the object-type associated with this column or that there is no conceptual row for which this column would be accessible in the MIB view used by the retrieval. As such, the management station can not issue any management protocol set operations to create an instance of this column. Once the column requirements have been determined, a management protocol set operation is accordingly issued. This operation also sets the new instance of the status column to `createAndGo'. When the agent processes the set operation, it verifies that it has sufficient information to make the conceptual row available for use by the managed device. The information available to the agent is provided by two sources: the management protocol set operation which creates the conceptual row, and, implementation-specific defaults supplied by the agent (note that an agent must provide implementation-specific defaults for at least those objects which it implements as read-only). If there is sufficient information available, then the conceptual row is created, a `noError' response is returned, the status column is set to `active', and no further interactions are necessary (i.e., interactions 3 and 4 are skipped). If there is insufficient information, then the conceptual row is not created, and the set operation fails with an error of `inconsistentValue'. On this error, the management station can issue a management protocol retrieval operation to determine if this was because it failed to specify a value for a required column, or, because the selected instance of the status column already existed. In the latter case, we return to interaction 1. In the former case, the management station can re-issue the set operation with the additional information, or begin interaction 2 again using `createAndWait' in order to negotiate creation of the conceptual row. NOTE WELL Regardless of the method used to determine the column requirements, it is possible that the management station might deem a column necessary when, in fact, the agent will not allow that particular columnar instance to be created or written. In this case, the management protocol set operation will fail with an error such as `noCreation' or `notWritable'. In this case, the management station decides whether it needs to be able to set a value for that particular columnar instance. If not, the management station re-issues the management protocol set operation, but without setting a value for that particular columnar instance; otherwise, the management station aborts the row creation algorithm. Interaction 2b: Negotiating the Creation of the Conceptual Row The management station issues a management protocol set operation which sets the desired instance of the status column to `createAndWait'. If the agent is unwilling to process a request of this sort, the set operation fails with an error of `wrongValue'. (As a consequence, such an agent must be prepared to accept a single management protocol set operation, i.e., interaction 2a above, containing all of the columns indicated by its column requirements.) Otherwise, the conceptual row is created, a `noError' response is returned, and the status column is immediately set to either `notInService' or `notReady', depending on whether it has sufficient information to (attempt to) make the conceptual row available for use by the managed device. If there is sufficient information available, then the status column is set to `notInService'; otherwise, if there is insufficient information, then the status column is set to `notReady'. Regardless, we proceed to interaction 3. Interaction 3: Initializing non-defaulted Objects The management station must now determine the column requirements. It issues a management protocol get operation to examine all columns in the created conceptual row. In the response, for each column, there are three possible outcomes: - a value is returned, indicating that the agent implements the object-type associated with this column and had sufficient information to provide a value. For those columns to which the agent provides read-create access (and for which the agent allows their values to be changed after their creation), a value return tells the management station that it may issue additional management protocol set operations, if it desires, in order to change the value associated with this column. - the exception `noSuchInstance' is returned, indicating that the agent implements the object-type associated with this column, and that this column in at least one conceptual row would be accessible in the MIB view used by the retrieval were it to exist. However, the agent does not have sufficient information to provide a value, and until a value is provided, the conceptual row may not be made available for use by the managed device. For those columns to which the agent provides read-create access, the `noSuchInstance' exception tells the management station that it must issue additional management protocol set operations, in order to provide a value associated with this column. - the exception `noSuchObject' is returned, indicating that the agent does not implement the object-type associated with this column or that there is no conceptual row for which this column would be accessible in the MIB view used by the retrieval. As such, the management station can not issue any management protocol set operations to create an instance of this column. If the value associated with the status column is `notReady', then the management station must first deal with all `noSuchInstance' columns, if any. Having done so, the value of the status column becomes `notInService', and we proceed to interaction 4. Interaction 4: Making the Conceptual Row Available Once the management station is satisfied with the values associated with the columns of the conceptual row, it issues a management protocol set operation to set the status column to `active'. If the agent has sufficient information to make the conceptual row available for use by the managed device, the management protocol set operation succeeds (a `noError' response is returned). Otherwise, the management protocol set operation fails with an error of `inconsistentValue'. NOTE WELL A conceptual row having a status column with value `notInService' or `notReady' is unavailable to the managed device. As such, it is possible for the managed device to create its own instances during the time between the management protocol set operation which sets the status column to `createAndWait' and the management protocol set operation which sets the status column to `active'. In this case, when the management protocol set operation is issued to set the status column to `active', the values held in the agent supersede those used by the managed device. If the management station is prevented from setting the status column to `active' (e.g., due to management station or network failure) the conceptual row will be left in the `notInService' or `notReady' state, consuming resources indefinitely. The agent must detect conceptual rows that have been in either state for an abnormally long period of time and remove them. It is the responsibility of the DESCRIPTION clause of the status column to indicate what an abnormally long period of time would be. This period of time should be long enough to allow for human response time (including `think time') between the creation of the conceptual row and the setting of the status to `active'. In the absence of such information in the DESCRIPTION clause, it is suggested that this period be approximately 5 minutes in length. This removal action applies not only to newly-created rows, but also to previously active rows which are set to, and left in, the notInService state for a prolonged period exceeding that which is considered normal for such a conceptual row. Conceptual Row Suspension When a conceptual row is `active', the management station may issue a management protocol set operation which sets the instance of the status column to `notInService'. If the agent is unwilling to do so, the set operation fails with an error of `wrongValue' or `inconsistentValue'. Otherwise, the conceptual row is taken out of service, and a `noError' response is returned. It is the responsibility of the DESCRIPTION clause of the status column to indicate under what circumstances the status column should be taken out of service (e.g., in order for the value of some other column of the same conceptual row to be modified). Conceptual Row Deletion For deletion of conceptual rows, a management protocol set operation is issued which sets the instance of the status column to `destroy'. This request may be made regardless of the current value of the status column (e.g., it is possible to delete conceptual rows which are either `notReady', `notInService' or `active'.) If the operation succeeds, then all instances associated with the conceptual row are immediately removed. · Integer32

The status of this hlHostControlEntry. An entry may not exist in the active state unless all objects in the entry have an appropriate value. If this object is not equal to active(1), all associated entries in the nlHostTable and alHostTable shall be deleted.

TimeFilterTo be used for the index to a table. Allows an application to download only those rows changed since a particular time. Note that this is not a history mechanism. Only current values of underlying objects are returned; saved instance values associated with particular values of sysUpTime are not. An entry is considered changed if the value of any object in the entry changes, if the row is created, or if any object in the entry is created or deleted. Note that deleted entries cannot be detected or downloaded. A time-filtered conceptual table is created by inserting a single object of SYNTAX TimeFilter as the first INDEX component in a copy of an existing basic conceptual table (i.e., any SEQUENCE without a TimeFilter INDEX component). Thus, for each conceptual entry 'I' in the basic table, there exists N conceptual entries in the time-filtered version, indexed N.I, where 'N' is equal to the value of sysUpTime. When an application retrieves conceptual instances from a time-filtered table, and an INDEX value is provided for the TimeFilter INDEX component 'N', the agent will only consider returning basic conceptual entries (e.g., 'fooColumn.N.I') if any column within the basic conceptual entry has changed since sysUpTime 'N'. If not, the basic conceptual entry will be ignored for the particular retrieval operation. When sysUpTime is equal to zero, this table shall be empty. One conceptual entry exists for each past value of sysUpTime, except that the whole table is purged should sysUpTime wrap. As an entry in a time-filtered table is updated (i.e., one of the columns in the basic conceptual table is changed), new conceptual entries are also created in the time-filtered version (which still shares the now updated object values with all other instances). The number of unique time-filtered instances that are created is determined by the value of sysUpTime at which the basic entry was last updated. One unique instance will exist for each value of sysUpTime at the last update time for the row. However, a new TimeFilter index instance is created for each new sysUpTime value. The TimeFilter index values not associated with entry updates are called duplicate time-filtered instances. After some deployment experience, it has been determined that a time-filtered table is more efficient if the agent stops a MIB walk operation by skipping over rows with a TimeFilter index value higher than the value in the received GetNext/GetBulk request. That is, instead of incrementing a TimeFilter index value, the agent will continue to the next object or table. As a consequence, GetNext or GetBulk operations will provide only one pass through a time-filtered table. It is suggested that an agent implement a time-filtered table in this manner to improve performance and avoid a MIB walk getting stuck in time-filtered tables. It is, however, still acceptable for an agent to implement a time-filtered table in the traditional manner (i.e., every conceptual time-filtered instance is returned in GetNext and GetBulk PDU responses), and management applications must be able to deal with such traditional implementations. See the appendix for further discussion of this textual convention. The following example is provided to demonstrate TimeFilter behavior: Consider the following basic conceptual table, basicFooTable. (Note that the basic version of a time-filtered table may not actually be defined.) basicFooTable: basicFooTable ... INDEX { fooIndex } BasicFooEntry { fooIndex Integer32, fooCounts Counter32 } For this example, the basicFooTable contains two static conceptual entries (fooIndex equals '1' and '2'), created at time zero. It also contains one dynamic conceptual entry (fooIndex equals '3'), which is created at time '3' and deleted at time '7'. The time-filtered version of the basicFooTable could be defined as follows: FooTable: fooTable ... INDEX { fooTimeMark, fooIndex } FooEntry { fooTimeMark TimeFilter, fooIndex Integer32, fooCounts Counter32 } Note that entries exist in the time-filtered conceptual table only if they actually exist in the underlying (basic) table. For this example, the fooTable will have three underlying basic entries (fooIndex == 1, 2, and 3), with the following activity (for sysUpTime equal 0 to 9): - fooEntry.N.1 is created at time '0' and most recently updated at time '6' to the value '5'. - fooEntry.N.2 is created at time '0' and most recently updated at time '8' to the value '9'. - fooEntry.N.3 is created at time '3', updated at time '5' to the value '17', and deleted at time '7'. The following tables show the values that would be returned for MIB walk operations with various TimeFilter values, done at different times. An application issues a retrieval request at time 'T', with a TimeFilter value, 'N' (typically set to a lower value, such as the value of sysUpTime at the last polling cycle). The following values would be returned in a MIB walk of fooCounts.N if T equals '0' and N equals '0': fooCounts.N.I Value ========================== fooCounts.0.1 0 fooCounts.0.2 0 Note that nothing is returned for fooCounts.0.3, since that entry does not exist at sysUpTime equals '0'. The following values would be returned in a full (traditional) MIB walk of fooCounts.N if T equals '3' and N equals '0': fooCounts.N.I Value ======================= fooCounts.0.1 0 fooCounts.0.2 0 fooCounts.0.3 0 fooCounts.1.3 0 fooCounts.2.3 0 fooCounts.3.3 0 Note that there are no instances for T equals 1 or 2 for the first two values of N, as these entries did not change since they were created at time '0'. Note that the current value for 'fooCounts.N.3' is returned here, even for values of N less than '3' (when the entry was created). The agent only considers the current existence of an entry in the TimeFilter algorithm, not the time when the entry was created. Note that the instances 'fooCounts.0.3', 'fooCounts.1.3', and 'fooCounts.2.3' are duplicates and can be suppressed by the agent in a MIB walk. The following values would be returned in a full (traditional) MIB walk of fooCounts.N if T equals '6' and N equals '3': fooCounts.N.I Value ======================= fooCounts.3.1 5 fooCounts.3.3 17 fooCounts.4.1 5 fooCounts.4.3 17 fooCounts.5.1 5 fooCounts.5.3 17 fooCounts.6.1 5 Note that no instances for entry 'fooCounts.N.2' are returned, since it has not changed since time '3'. Note that all instances except 'fooCounts.5.3' and 'fooCounts.6.1' are duplicates and can be suppressed by the agent in a MIB walk. The following values would be returned in a full (traditional) MIB walk of fooCounts.N if T equals '9' and N equals '6': fooCounts.N.I Value ======================= fooCounts.6.1 5 fooCounts.6.2 9 fooCounts.7.2 9 fooCounts.8.2 9 Note that no instances for entry 'fooCounts.N.3' are returned, since it was deleted at time '7'. Note that instances 'fooCounts.6.2' and 'fooCounts.7.2' are duplicates and can be suppressed by the agent in a MIB walk. · TimeTicks

A TimeFilter for this entry. See the TimeFilter textual convention to see how this works.

OCTET STRING SIZE (1..255)

The network address for this nlHostEntry. This is represented as an octet string with specific semantics and length as identified by the protocolDirLocalIndex component of the index. For example, if the protocolDirLocalIndex indicates an encapsulation of IP, this object is encoded as a length octet of 4, followed by the 4 octets of the IP address, in network byte order.

ZeroBasedCounter32This TC describes an object that counts events with the following semantics: objects of this type will be set to zero(0) on creation and will thereafter count appropriate events, wrapping back to zero(0) when the value 2^32 is reached. Provided that an application discovers the new object within the minimum time to wrap, it can use the initial value as a delta since it last polled the table of which this object is part. It is important for a management station to be aware of this minimum time and the actual time between polls, and to discard data if the actual time is too long or there is no defined minimum time. Typically, this TC is used in tables where the INDEX space is constantly changing and/or the TimeFilter mechanism is in use. · Gauge32

The number of packets without errors transmitted to this address since it was added to the nlHostTable. Note that this is the number of link-layer packets, so if a single network-layer packet is fragmented into several link-layer frames, this counter is incremented several times.

ZeroBasedCounter32This TC describes an object that counts events with the following semantics: objects of this type will be set to zero(0) on creation and will thereafter count appropriate events, wrapping back to zero(0) when the value 2^32 is reached. Provided that an application discovers the new object within the minimum time to wrap, it can use the initial value as a delta since it last polled the table of which this object is part. It is important for a management station to be aware of this minimum time and the actual time between polls, and to discard data if the actual time is too long or there is no defined minimum time. Typically, this TC is used in tables where the INDEX space is constantly changing and/or the TimeFilter mechanism is in use. · Gauge32

The number of packets without errors transmitted by this address since it was added to the nlHostTable. Note that this is the number of link-layer packets, so if a single network-layer packet is fragmented into several link-layer frames, this counter is incremented several times.

ZeroBasedCounter32This TC describes an object that counts events with the following semantics: objects of this type will be set to zero(0) on creation and will thereafter count appropriate events, wrapping back to zero(0) when the value 2^32 is reached. Provided that an application discovers the new object within the minimum time to wrap, it can use the initial value as a delta since it last polled the table of which this object is part. It is important for a management station to be aware of this minimum time and the actual time between polls, and to discard data if the actual time is too long or there is no defined minimum time. Typically, this TC is used in tables where the INDEX space is constantly changing and/or the TimeFilter mechanism is in use. · Gauge32

The number of octets transmitted to this address since it was added to the nlHostTable (excluding framing bits, but including FCS octets), excluding octets in packets that contained errors. Note that this doesn't count just those octets in the particular protocol frames but includes the entire packet that contained the protocol.

ZeroBasedCounter32This TC describes an object that counts events with the following semantics: objects of this type will be set to zero(0) on creation and will thereafter count appropriate events, wrapping back to zero(0) when the value 2^32 is reached. Provided that an application discovers the new object within the minimum time to wrap, it can use the initial value as a delta since it last polled the table of which this object is part. It is important for a management station to be aware of this minimum time and the actual time between polls, and to discard data if the actual time is too long or there is no defined minimum time. Typically, this TC is used in tables where the INDEX space is constantly changing and/or the TimeFilter mechanism is in use. · Gauge32

The number of octets transmitted by this address since it was added to the nlHostTable (excluding framing bits, but including FCS octets), excluding octets in packets that contained errors. Note that this doesn't count just those octets in the particular protocol frames but includes the entire packet that contained the protocol.

ZeroBasedCounter32This TC describes an object that counts events with the following semantics: objects of this type will be set to zero(0) on creation and will thereafter count appropriate events, wrapping back to zero(0) when the value 2^32 is reached. Provided that an application discovers the new object within the minimum time to wrap, it can use the initial value as a delta since it last polled the table of which this object is part. It is important for a management station to be aware of this minimum time and the actual time between polls, and to discard data if the actual time is too long or there is no defined minimum time. Typically, this TC is used in tables where the INDEX space is constantly changing and/or the TimeFilter mechanism is in use. · Gauge32

The number of packets without errors transmitted by this address that were directed to any MAC broadcast addresses or to any MAC multicast addresses since this host was added to the nlHostTable. Note that this is the number of link-layer packets, so if a single network-layer packet is fragmented into several link-layer frames, this counter is incremented several times.

LastCreateTimeThis TC describes an object that stores the value of the sysUpTime object at the last time its entry was created. This can be used for polling applications to determine that an entry has been deleted and re-created between polls, causing an otherwise undetectable discontinuity in the data. If sysUpTime is reset to zero as a result of a re- initialization of the network management (sub)system, then the values of all LastCreateTime objects are also reset. However, after approximately 497 days without a re- initialization, the sysUpTime object will reach 2^^32-1 and then increment to zero; in this case, existing values of TimeStamp objects do not change. This can lead to ambiguities in the value of TimeStamp objects. · TimeTicks

The value of sysUpTime when this entry was last activated. This can be used by the management station to ensure that the entry has not been deleted and recreated between polls.

Integer32 (1..65535)

An index that uniquely identifies an entry in the hlMatrixControlTable. Each such entry defines a function that discovers conversations on a particular interface and places statistics about them in the nlMatrixSDTable and the nlMatrixDSTable, and optionally the alMatrixSDTable and alMatrixDSTable, on behalf of this hlMatrixControlEntry.

DataSourceIdentifies the source of the data that the associated function is configured to analyze. This source can be any interface on this device. In order to identify a particular interface, this object shall identify the instance of the ifIndex object, defined in [RFC2863], for the desired interface. For example, if an entry were to receive data from interface #1, this object would be set to ifIndex.1. · OBJECT IDENTIFIER

The source of the data for the associated matrix tables. The statistics in this group reflect all packets on the local network segment attached to the identified interface. This object may not be modified if the associated hlMatrixControlStatus object is equal to active(1).

Counter32

The total number of frames that were received by the probe and therefore not accounted for in the *StatsDropEvents, but that the probe chose not to count for this entry for whatever reason. Most often, this event occurs when the probe is out of some resources and decides to shed load from this collection. This count does not include packets that were not counted because they had MAC-layer errors. Note that if the nlMatrixTables are inactive because no protocols are enabled in the protocol directory, this value should be 0. Note that, unlike the dropEvents counter, this number is the exact number of frames dropped.

Counter32

The number of times an nlMatrix entry has been inserted into the nlMatrix tables. If an entry is inserted, then deleted, and then inserted, this counter will be incremented by 2. The addition of a conversation into both the nlMatrixSDTable and nlMatrixDSTable shall be counted as two insertions (even though every addition into one table must be accompanied by an insertion into the other). To allow for efficient implementation strategies, agents may delay updating this object for short periods of time. For example, an implementation strategy may allow internal data structures to differ from those visible via SNMP for short periods of time. This counter may reflect the internal data structures for those short periods of time. Note that the sum of then nlMatrixSDTable and nlMatrixDSTable sizes can be determined by subtracting hlMatrixControlNlDeletes from hlMatrixControlNlInserts.

Counter32

The number of times an nlMatrix entry has been deleted from the nlMatrix tables (for any reason). If an entry is deleted, then inserted, and then deleted, this counter will be incremented by 2. The deletion of a conversation from both the nlMatrixSDTable and nlMatrixDSTable shall be counted as two deletions (even though every deletion from one table must be accompanied by a deletion from the other). To allow for efficient implementation strategies, agents may delay updating this object for short periods of time. For example, an implementation strategy may allow internal data structures to differ from those visible via SNMP for short periods of time. This counter may reflect the internal data structures for those short periods of time. Note that the table size can be determined by subtracting hlMatrixControlNlDeletes from hlMatrixControlNlInserts.

Integer32 (-1..2147483647)

The maximum number of entries that are desired in the nlMatrix tables on behalf of this control entry. The probe will not create more than this number of associated entries in the table but may choose to create fewer entries in this table for any reason, including the lack of resources. If this object is set to a value less than the current number of entries, enough entries are chosen in an implementation-dependent manner and deleted so that the number of entries in the table equals the value of this object. If this value is set to -1, the probe may create any number of entries in this table. If the associated hlMatrixControlStatus object is equal to 'active', this object may not be modified. This object may be used to control how resources are allocated on the probe for the various RMON functions.

Counter32

The total number of frames that were received by the probe and therefore not accounted for in the *StatsDropEvents, but that the probe chose not to count for this entry for whatever reason. Most often, this event occurs when the probe is out of some resources and decides to shed load from this collection. This count does not include packets that were not counted because they had MAC-layer errors. Note that if the alMatrixTables are not implemented or are inactive because no protocols are enabled in the protocol directory, this value should be 0. Note that, unlike the dropEvents counter, this number is the exact number of frames dropped.

Counter32

The number of times an alMatrix entry has been inserted into the alMatrix tables. If an entry is inserted, then deleted, and then inserted, this counter will be incremented by 2. The addition of a conversation into both the alMatrixSDTable and alMatrixDSTable shall be counted as two insertions (even though every addition into one table must be accompanied by an insertion into the other). To allow for efficient implementation strategies, agents may delay updating this object for short periods of time. For example, an implementation strategy may allow internal data structures to differ from those visible via SNMP for short periods of time. This counter may reflect the internal data structures for those short periods of time. Note that the table size can be determined by subtracting hlMatrixControlAlDeletes from hlMatrixControlAlInserts.

Counter32

The number of times an alMatrix entry has been deleted from the alMatrix tables. If an entry is deleted, then inserted, and then deleted, this counter will be incremented by 2. The deletion of a conversation from both the alMatrixSDTable and alMatrixDSTable shall be counted as two deletions (even though every deletion from one table must be accompanied by a deletion from the other). To allow for efficient implementation strategies, agents may delay updating this object for short periods of time. For example, an implementation strategy may allow internal data structures to differ from those visible via SNMP for short periods of time. This counter may reflect the internal data structures for those short periods of time. Note that the table size can be determined by subtracting hlMatrixControlAlDeletes from hlMatrixControlAlInserts.

Integer32 (-1..2147483647)

The maximum number of entries that are desired in the alMatrix tables on behalf of this control entry. The probe will not create more than this number of associated entries in the table but may choose to create fewer entries in this table for any reason, including the lack of resources. If this object is set to a value less than the current number of entries, enough entries are chosen in an implementation-dependent manner and deleted so that the number of entries in the table equals the value of this object. If this value is set to -1, the probe may create any number of entries in this table. If the associated hlMatrixControlStatus object is equal to 'active', this object may not be modified. This object may be used to control how resources are allocated on the probe for the various RMON functions.

OwnerStringThis data type is used to model an administratively assigned name of the owner of a resource. Implementations must accept values composed of well-formed NVT ASCII sequences. In addition, implementations should accept values composed of well-formed UTF-8 sequences. It is suggested that this name contain one or more of the following: IP address, management station name, network manager's name, location, or phone number. In some cases the agent itself will be the owner of an entry. In these cases, this string shall be set to a string starting with 'monitor'. SNMP access control is articulated entirely in terms of the contents of MIB views; access to a particular SNMP object instance depends only upon its presence or absence in a particular MIB view and never upon its value or the value of related object instances. Thus, objects of this type afford resolution of resource contention only among cooperating managers; they realize no access control function with respect to uncooperative parties. SIZE (0..127) · OCTET STRING

The entity that configured this entry and is therefore using the resources assigned to it.

RowStatus1 = active2 = notInService3 = notReady4 = createAndGo5 = createAndWait6 = destroyThe RowStatus textual convention is used to manage the creation and deletion of conceptual rows, and is used as the value of the SYNTAX clause for the status column of a conceptual row (as described in Section 7.7.1 of [2].) 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); 'notInService' has no implication regarding the internal consistency of the row, availability of resources, or consistency with the current state of the managed device; - `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 (i.e., one or more required columns in the conceptual row have not been instanciated); - `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 attempt 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 status column having a SYNTAX clause value 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) goto 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, and all columns have acceptable values, then return noError and goto D. (3) if other variable bindings included in the same PDU, provide legal 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 notInService (e.g., an agent which 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. (8) the transition to D can fail, e.g., if the values of the conceptual row are inconsistent, then the error code would be inconsistentValue. NOTE: Other processing of (this and other varbinds 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. A MIB designer should choose between the two latter algorithms based on the size of the table (and therefore the efficiency of each algorithm). For tables in which a large number of entries are expected, it is recommended that a MIB object be defined that returns an acceptable index for creation. For tables with small numbers of entries, it is recommended that the latter pseudo-random index mechanism be used. Interaction 2: Creating the Conceptual Row Once an unused instance-identifier has been selected, the management station determines if it wishes to create and activate the conceptual row in one transaction or in a negotiated set of interactions. Interaction 2a: Creating and Activating the Conceptual Row The management station must first determine the column requirements, i.e., it must determine those columns for which it must or must not provide values. Depending on the complexity of the table and the management station's knowledge of the agent's capabilities, this determination can be made locally by the management station. Alternately, the management station issues a management protocol get operation to examine all columns in the conceptual row that it wishes to create. In response, for each column, there are three possible outcomes: - a value is returned, indicating that some other management station has already created this conceptual row. We return to interaction 1. - the exception `noSuchInstance' is returned, indicating that the agent implements the object-type associated with this column, and that this column in at least one conceptual row would be accessible in the MIB view used by the retrieval were it to exist. For those columns to which the agent provides read-create access, the `noSuchInstance' exception tells the management station that it should supply a value for this column when the conceptual row is to be created. - the exception `noSuchObject' is returned, indicating that the agent does not implement the object-type associated with this column or that there is no conceptual row for which this column would be accessible in the MIB view used by the retrieval. As such, the management station can not issue any management protocol set operations to create an instance of this column. Once the column requirements have been determined, a management protocol set operation is accordingly issued. This operation also sets the new instance of the status column to `createAndGo'. When the agent processes the set operation, it verifies that it has sufficient information to make the conceptual row available for use by the managed device. The information available to the agent is provided by two sources: the management protocol set operation which creates the conceptual row, and, implementation-specific defaults supplied by the agent (note that an agent must provide implementation-specific defaults for at least those objects which it implements as read-only). If there is sufficient information available, then the conceptual row is created, a `noError' response is returned, the status column is set to `active', and no further interactions are necessary (i.e., interactions 3 and 4 are skipped). If there is insufficient information, then the conceptual row is not created, and the set operation fails with an error of `inconsistentValue'. On this error, the management station can issue a management protocol retrieval operation to determine if this was because it failed to specify a value for a required column, or, because the selected instance of the status column already existed. In the latter case, we return to interaction 1. In the former case, the management station can re-issue the set operation with the additional information, or begin interaction 2 again using `createAndWait' in order to negotiate creation of the conceptual row. NOTE WELL Regardless of the method used to determine the column requirements, it is possible that the management station might deem a column necessary when, in fact, the agent will not allow that particular columnar instance to be created or written. In this case, the management protocol set operation will fail with an error such as `noCreation' or `notWritable'. In this case, the management station decides whether it needs to be able to set a value for that particular columnar instance. If not, the management station re-issues the management protocol set operation, but without setting a value for that particular columnar instance; otherwise, the management station aborts the row creation algorithm. Interaction 2b: Negotiating the Creation of the Conceptual Row The management station issues a management protocol set operation which sets the desired instance of the status column to `createAndWait'. If the agent is unwilling to process a request of this sort, the set operation fails with an error of `wrongValue'. (As a consequence, such an agent must be prepared to accept a single management protocol set operation, i.e., interaction 2a above, containing all of the columns indicated by its column requirements.) Otherwise, the conceptual row is created, a `noError' response is returned, and the status column is immediately set to either `notInService' or `notReady', depending on whether it has sufficient information to (attempt to) make the conceptual row available for use by the managed device. If there is sufficient information available, then the status column is set to `notInService'; otherwise, if there is insufficient information, then the status column is set to `notReady'. Regardless, we proceed to interaction 3. Interaction 3: Initializing non-defaulted Objects The management station must now determine the column requirements. It issues a management protocol get operation to examine all columns in the created conceptual row. In the response, for each column, there are three possible outcomes: - a value is returned, indicating that the agent implements the object-type associated with this column and had sufficient information to provide a value. For those columns to which the agent provides read-create access (and for which the agent allows their values to be changed after their creation), a value return tells the management station that it may issue additional management protocol set operations, if it desires, in order to change the value associated with this column. - the exception `noSuchInstance' is returned, indicating that the agent implements the object-type associated with this column, and that this column in at least one conceptual row would be accessible in the MIB view used by the retrieval were it to exist. However, the agent does not have sufficient information to provide a value, and until a value is provided, the conceptual row may not be made available for use by the managed device. For those columns to which the agent provides read-create access, the `noSuchInstance' exception tells the management station that it must issue additional management protocol set operations, in order to provide a value associated with this column. - the exception `noSuchObject' is returned, indicating that the agent does not implement the object-type associated with this column or that there is no conceptual row for which this column would be accessible in the MIB view used by the retrieval. As such, the management station can not issue any management protocol set operations to create an instance of this column. If the value associated with the status column is `notReady', then the management station must first deal with all `noSuchInstance' columns, if any. Having done so, the value of the status column becomes `notInService', and we proceed to interaction 4. Interaction 4: Making the Conceptual Row Available Once the management station is satisfied with the values associated with the columns of the conceptual row, it issues a management protocol set operation to set the status column to `active'. If the agent has sufficient information to make the conceptual row available for use by the managed device, the management protocol set operation succeeds (a `noError' response is returned). Otherwise, the management protocol set operation fails with an error of `inconsistentValue'. NOTE WELL A conceptual row having a status column with value `notInService' or `notReady' is unavailable to the managed device. As such, it is possible for the managed device to create its own instances during the time between the management protocol set operation which sets the status column to `createAndWait' and the management protocol set operation which sets the status column to `active'. In this case, when the management protocol set operation is issued to set the status column to `active', the values held in the agent supersede those used by the managed device. If the management station is prevented from setting the status column to `active' (e.g., due to management station or network failure) the conceptual row will be left in the `notInService' or `notReady' state, consuming resources indefinitely. The agent must detect conceptual rows that have been in either state for an abnormally long period of time and remove them. It is the responsibility of the DESCRIPTION clause of the status column to indicate what an abnormally long period of time would be. This period of time should be long enough to allow for human response time (including `think time') between the creation of the conceptual row and the setting of the status to `active'. In the absence of such information in the DESCRIPTION clause, it is suggested that this period be approximately 5 minutes in length. This removal action applies not only to newly-created rows, but also to previously active rows which are set to, and left in, the notInService state for a prolonged period exceeding that which is considered normal for such a conceptual row. Conceptual Row Suspension When a conceptual row is `active', the management station may issue a management protocol set operation which sets the instance of the status column to `notInService'. If the agent is unwilling to do so, the set operation fails with an error of `wrongValue' or `inconsistentValue'. Otherwise, the conceptual row is taken out of service, and a `noError' response is returned. It is the responsibility of the DESCRIPTION clause of the status column to indicate under what circumstances the status column should be taken out of service (e.g., in order for the value of some other column of the same conceptual row to be modified). Conceptual Row Deletion For deletion of conceptual rows, a management protocol set operation is issued which sets the instance of the status column to `destroy'. This request may be made regardless of the current value of the status column (e.g., it is possible to delete conceptual rows which are either `notReady', `notInService' or `active'.) If the operation succeeds, then all instances associated with the conceptual row are immediately removed. · Integer32

The status of this hlMatrixControlEntry. An entry may not exist in the active state unless all objects in the entry have an appropriate value. If this object is not equal to active(1), all associated entries in the nlMatrixSDTable, nlMatrixDSTable, alMatrixSDTable, and alMatrixDSTable shall be deleted by the agent.

TimeFilterTo be used for the index to a table. Allows an application to download only those rows changed since a particular time. Note that this is not a history mechanism. Only current values of underlying objects are returned; saved instance values associated with particular values of sysUpTime are not. An entry is considered changed if the value of any object in the entry changes, if the row is created, or if any object in the entry is created or deleted. Note that deleted entries cannot be detected or downloaded. A time-filtered conceptual table is created by inserting a single object of SYNTAX TimeFilter as the first INDEX component in a copy of an existing basic conceptual table (i.e., any SEQUENCE without a TimeFilter INDEX component). Thus, for each conceptual entry 'I' in the basic table, there exists N conceptual entries in the time-filtered version, indexed N.I, where 'N' is equal to the value of sysUpTime. When an application retrieves conceptual instances from a time-filtered table, and an INDEX value is provided for the TimeFilter INDEX component 'N', the agent will only consider returning basic conceptual entries (e.g., 'fooColumn.N.I') if any column within the basic conceptual entry has changed since sysUpTime 'N'. If not, the basic conceptual entry will be ignored for the particular retrieval operation. When sysUpTime is equal to zero, this table shall be empty. One conceptual entry exists for each past value of sysUpTime, except that the whole table is purged should sysUpTime wrap. As an entry in a time-filtered table is updated (i.e., one of the columns in the basic conceptual table is changed), new conceptual entries are also created in the time-filtered version (which still shares the now updated object values with all other instances). The number of unique time-filtered instances that are created is determined by the value of sysUpTime at which the basic entry was last updated. One unique instance will exist for each value of sysUpTime at the last update time for the row. However, a new TimeFilter index instance is created for each new sysUpTime value. The TimeFilter index values not associated with entry updates are called duplicate time-filtered instances. After some deployment experience, it has been determined that a time-filtered table is more efficient if the agent stops a MIB walk operation by skipping over rows with a TimeFilter index value higher than the value in the received GetNext/GetBulk request. That is, instead of incrementing a TimeFilter index value, the agent will continue to the next object or table. As a consequence, GetNext or GetBulk operations will provide only one pass through a time-filtered table. It is suggested that an agent implement a time-filtered table in this manner to improve performance and avoid a MIB walk getting stuck in time-filtered tables. It is, however, still acceptable for an agent to implement a time-filtered table in the traditional manner (i.e., every conceptual time-filtered instance is returned in GetNext and GetBulk PDU responses), and management applications must be able to deal with such traditional implementations. See the appendix for further discussion of this textual convention. The following example is provided to demonstrate TimeFilter behavior: Consider the following basic conceptual table, basicFooTable. (Note that the basic version of a time-filtered table may not actually be defined.) basicFooTable: basicFooTable ... INDEX { fooIndex } BasicFooEntry { fooIndex Integer32, fooCounts Counter32 } For this example, the basicFooTable contains two static conceptual entries (fooIndex equals '1' and '2'), created at time zero. It also contains one dynamic conceptual entry (fooIndex equals '3'), which is created at time '3' and deleted at time '7'. The time-filtered version of the basicFooTable could be defined as follows: FooTable: fooTable ... INDEX { fooTimeMark, fooIndex } FooEntry { fooTimeMark TimeFilter, fooIndex Integer32, fooCounts Counter32 } Note that entries exist in the time-filtered conceptual table only if they actually exist in the underlying (basic) table. For this example, the fooTable will have three underlying basic entries (fooIndex == 1, 2, and 3), with the following activity (for sysUpTime equal 0 to 9): - fooEntry.N.1 is created at time '0' and most recently updated at time '6' to the value '5'. - fooEntry.N.2 is created at time '0' and most recently updated at time '8' to the value '9'. - fooEntry.N.3 is created at time '3', updated at time '5' to the value '17', and deleted at time '7'. The following tables show the values that would be returned for MIB walk operations with various TimeFilter values, done at different times. An application issues a retrieval request at time 'T', with a TimeFilter value, 'N' (typically set to a lower value, such as the value of sysUpTime at the last polling cycle). The following values would be returned in a MIB walk of fooCounts.N if T equals '0' and N equals '0': fooCounts.N.I Value ========================== fooCounts.0.1 0 fooCounts.0.2 0 Note that nothing is returned for fooCounts.0.3, since that entry does not exist at sysUpTime equals '0'. The following values would be returned in a full (traditional) MIB walk of fooCounts.N if T equals '3' and N equals '0': fooCounts.N.I Value ======================= fooCounts.0.1 0 fooCounts.0.2 0 fooCounts.0.3 0 fooCounts.1.3 0 fooCounts.2.3 0 fooCounts.3.3 0 Note that there are no instances for T equals 1 or 2 for the first two values of N, as these entries did not change since they were created at time '0'. Note that the current value for 'fooCounts.N.3' is returned here, even for values of N less than '3' (when the entry was created). The agent only considers the current existence of an entry in the TimeFilter algorithm, not the time when the entry was created. Note that the instances 'fooCounts.0.3', 'fooCounts.1.3', and 'fooCounts.2.3' are duplicates and can be suppressed by the agent in a MIB walk. The following values would be returned in a full (traditional) MIB walk of fooCounts.N if T equals '6' and N equals '3': fooCounts.N.I Value ======================= fooCounts.3.1 5 fooCounts.3.3 17 fooCounts.4.1 5 fooCounts.4.3 17 fooCounts.5.1 5 fooCounts.5.3 17 fooCounts.6.1 5 Note that no instances for entry 'fooCounts.N.2' are returned, since it has not changed since time '3'. Note that all instances except 'fooCounts.5.3' and 'fooCounts.6.1' are duplicates and can be suppressed by the agent in a MIB walk. The following values would be returned in a full (traditional) MIB walk of fooCounts.N if T equals '9' and N equals '6': fooCounts.N.I Value ======================= fooCounts.6.1 5 fooCounts.6.2 9 fooCounts.7.2 9 fooCounts.8.2 9 Note that no instances for entry 'fooCounts.N.3' are returned, since it was deleted at time '7'. Note that instances 'fooCounts.6.2' and 'fooCounts.7.2' are duplicates and can be suppressed by the agent in a MIB walk. · TimeTicks

A TimeFilter for this entry. See the TimeFilter textual convention to see how this works.

OCTET STRING SIZE (1..255)

The network source address for this nlMatrixSDEntry. This is represented as an octet string with specific semantics and length as identified by the protocolDirLocalIndex component of the index. For example, if the protocolDirLocalIndex indicates an encapsulation of IP, this object is encoded as a length octet of 4, followed by the 4 octets of the IP address, in network byte order.

OCTET STRING SIZE (1..255)

The network destination address for this nlMatrixSDEntry. This is represented as an octet string with specific semantics and length as identified by the protocolDirLocalIndex component of the index. For example, if the protocolDirLocalIndex indicates an encapsulation of IP, this object is encoded as a length octet of 4, followed by the 4 octets of the IP address, in network byte order.

ZeroBasedCounter32This TC describes an object that counts events with the following semantics: objects of this type will be set to zero(0) on creation and will thereafter count appropriate events, wrapping back to zero(0) when the value 2^32 is reached. Provided that an application discovers the new object within the minimum time to wrap, it can use the initial value as a delta since it last polled the table of which this object is part. It is important for a management station to be aware of this minimum time and the actual time between polls, and to discard data if the actual time is too long or there is no defined minimum time. Typically, this TC is used in tables where the INDEX space is constantly changing and/or the TimeFilter mechanism is in use. · Gauge32

The number of packets without errors transmitted from the source address to the destination address since this entry was added to the nlMatrixSDTable. Note that this is the number of link-layer packets, so if a single network-layer packet is fragmented into several link-layer frames, this counter is incremented several times.

ZeroBasedCounter32This TC describes an object that counts events with the following semantics: objects of this type will be set to zero(0) on creation and will thereafter count appropriate events, wrapping back to zero(0) when the value 2^32 is reached. Provided that an application discovers the new object within the minimum time to wrap, it can use the initial value as a delta since it last polled the table of which this object is part. It is important for a management station to be aware of this minimum time and the actual time between polls, and to discard data if the actual time is too long or there is no defined minimum time. Typically, this TC is used in tables where the INDEX space is constantly changing and/or the TimeFilter mechanism is in use. · Gauge32

The number of octets transmitted from the source address to the destination address since this entry was added to the nlMatrixSDTable (excluding framing bits, but including FCS octets), excluding octets in packets that contained errors. Note that this doesn't count just those octets in the particular protocol frames but includes the entire packet that contained the protocol.

LastCreateTimeThis TC describes an object that stores the value of the sysUpTime object at the last time its entry was created. This can be used for polling applications to determine that an entry has been deleted and re-created between polls, causing an otherwise undetectable discontinuity in the data. If sysUpTime is reset to zero as a result of a re- initialization of the network management (sub)system, then the values of all LastCreateTime objects are also reset. However, after approximately 497 days without a re- initialization, the sysUpTime object will reach 2^^32-1 and then increment to zero; in this case, existing values of TimeStamp objects do not change. This can lead to ambiguities in the value of TimeStamp objects. · TimeTicks

The value of sysUpTime when this entry was last activated. This can be used by the management station to ensure that the entry has not been deleted and recreated between polls.

TimeFilterTo be used for the index to a table. Allows an application to download only those rows changed since a particular time. Note that this is not a history mechanism. Only current values of underlying objects are returned; saved instance values associated with particular values of sysUpTime are not. An entry is considered changed if the value of any object in the entry changes, if the row is created, or if any object in the entry is created or deleted. Note that deleted entries cannot be detected or downloaded. A time-filtered conceptual table is created by inserting a single object of SYNTAX TimeFilter as the first INDEX component in a copy of an existing basic conceptual table (i.e., any SEQUENCE without a TimeFilter INDEX component). Thus, for each conceptual entry 'I' in the basic table, there exists N conceptual entries in the time-filtered version, indexed N.I, where 'N' is equal to the value of sysUpTime. When an application retrieves conceptual instances from a time-filtered table, and an INDEX value is provided for the TimeFilter INDEX component 'N', the agent will only consider returning basic conceptual entries (e.g., 'fooColumn.N.I') if any column within the basic conceptual entry has changed since sysUpTime 'N'. If not, the basic conceptual entry will be ignored for the particular retrieval operation. When sysUpTime is equal to zero, this table shall be empty. One conceptual entry exists for each past value of sysUpTime, except that the whole table is purged should sysUpTime wrap. As an entry in a time-filtered table is updated (i.e., one of the columns in the basic conceptual table is changed), new conceptual entries are also created in the time-filtered version (which still shares the now updated object values with all other instances). The number of unique time-filtered instances that are created is determined by the value of sysUpTime at which the basic entry was last updated. One unique instance will exist for each value of sysUpTime at the last update time for the row. However, a new TimeFilter index instance is created for each new sysUpTime value. The TimeFilter index values not associated with entry updates are called duplicate time-filtered instances. After some deployment experience, it has been determined that a time-filtered table is more efficient if the agent stops a MIB walk operation by skipping over rows with a TimeFilter index value higher than the value in the received GetNext/GetBulk request. That is, instead of incrementing a TimeFilter index value, the agent will continue to the next object or table. As a consequence, GetNext or GetBulk operations will provide only one pass through a time-filtered table. It is suggested that an agent implement a time-filtered table in this manner to improve performance and avoid a MIB walk getting stuck in time-filtered tables. It is, however, still acceptable for an agent to implement a time-filtered table in the traditional manner (i.e., every conceptual time-filtered instance is returned in GetNext and GetBulk PDU responses), and management applications must be able to deal with such traditional implementations. See the appendix for further discussion of this textual convention. The following example is provided to demonstrate TimeFilter behavior: Consider the following basic conceptual table, basicFooTable. (Note that the basic version of a time-filtered table may not actually be defined.) basicFooTable: basicFooTable ... INDEX { fooIndex } BasicFooEntry { fooIndex Integer32, fooCounts Counter32 } For this example, the basicFooTable contains two static conceptual entries (fooIndex equals '1' and '2'), created at time zero. It also contains one dynamic conceptual entry (fooIndex equals '3'), which is created at time '3' and deleted at time '7'. The time-filtered version of the basicFooTable could be defined as follows: FooTable: fooTable ... INDEX { fooTimeMark, fooIndex } FooEntry { fooTimeMark TimeFilter, fooIndex Integer32, fooCounts Counter32 } Note that entries exist in the time-filtered conceptual table only if they actually exist in the underlying (basic) table. For this example, the fooTable will have three underlying basic entries (fooIndex == 1, 2, and 3), with the following activity (for sysUpTime equal 0 to 9): - fooEntry.N.1 is created at time '0' and most recently updated at time '6' to the value '5'. - fooEntry.N.2 is created at time '0' and most recently updated at time '8' to the value '9'. - fooEntry.N.3 is created at time '3', updated at time '5' to the value '17', and deleted at time '7'. The following tables show the values that would be returned for MIB walk operations with various TimeFilter values, done at different times. An application issues a retrieval request at time 'T', with a TimeFilter value, 'N' (typically set to a lower value, such as the value of sysUpTime at the last polling cycle). The following values would be returned in a MIB walk of fooCounts.N if T equals '0' and N equals '0': fooCounts.N.I Value ========================== fooCounts.0.1 0 fooCounts.0.2 0 Note that nothing is returned for fooCounts.0.3, since that entry does not exist at sysUpTime equals '0'. The following values would be returned in a full (traditional) MIB walk of fooCounts.N if T equals '3' and N equals '0': fooCounts.N.I Value ======================= fooCounts.0.1 0 fooCounts.0.2 0 fooCounts.0.3 0 fooCounts.1.3 0 fooCounts.2.3 0 fooCounts.3.3 0 Note that there are no instances for T equals 1 or 2 for the first two values of N, as these entries did not change since they were created at time '0'. Note that the current value for 'fooCounts.N.3' is returned here, even for values of N less than '3' (when the entry was created). The agent only considers the current existence of an entry in the TimeFilter algorithm, not the time when the entry was created. Note that the instances 'fooCounts.0.3', 'fooCounts.1.3', and 'fooCounts.2.3' are duplicates and can be suppressed by the agent in a MIB walk. The following values would be returned in a full (traditional) MIB walk of fooCounts.N if T equals '6' and N equals '3': fooCounts.N.I Value ======================= fooCounts.3.1 5 fooCounts.3.3 17 fooCounts.4.1 5 fooCounts.4.3 17 fooCounts.5.1 5 fooCounts.5.3 17 fooCounts.6.1 5 Note that no instances for entry 'fooCounts.N.2' are returned, since it has not changed since time '3'. Note that all instances except 'fooCounts.5.3' and 'fooCounts.6.1' are duplicates and can be suppressed by the agent in a MIB walk. The following values would be returned in a full (traditional) MIB walk of fooCounts.N if T equals '9' and N equals '6': fooCounts.N.I Value ======================= fooCounts.6.1 5 fooCounts.6.2 9 fooCounts.7.2 9 fooCounts.8.2 9 Note that no instances for entry 'fooCounts.N.3' are returned, since it was deleted at time '7'. Note that instances 'fooCounts.6.2' and 'fooCounts.7.2' are duplicates and can be suppressed by the agent in a MIB walk. · TimeTicks

A TimeFilter for this entry. See the TimeFilter textual convention to see how this works.

OCTET STRING SIZE (1..255)

The network source address for this nlMatrixDSEntry. This is represented as an octet string with specific semantics and length as identified by the protocolDirLocalIndex component of the index. For example, if the protocolDirLocalIndex indicates an encapsulation of IP, this object is encoded as a length octet of 4, followed by the 4 octets of the IP address, in network byte order.

OCTET STRING SIZE (1..255)

The network destination address for this nlMatrixDSEntry. This is represented as an octet string with specific semantics and length as identified by the protocolDirLocalIndex component of the index. For example, if the protocolDirLocalIndex indicates an encapsulation of IP, this object is encoded as a length octet of 4, followed by the 4 octets of the IP address, in network byte order.

ZeroBasedCounter32This TC describes an object that counts events with the following semantics: objects of this type will be set to zero(0) on creation and will thereafter count appropriate events, wrapping back to zero(0) when the value 2^32 is reached. Provided that an application discovers the new object within the minimum time to wrap, it can use the initial value as a delta since it last polled the table of which this object is part. It is important for a management station to be aware of this minimum time and the actual time between polls, and to discard data if the actual time is too long or there is no defined minimum time. Typically, this TC is used in tables where the INDEX space is constantly changing and/or the TimeFilter mechanism is in use. · Gauge32

The number of packets without errors transmitted from the source address to the destination address since this entry was added to the nlMatrixDSTable. Note that this is the number of link-layer packets, so if a single network-layer packet is fragmented into several link-layer frames, this counter is incremented several times.

ZeroBasedCounter32This TC describes an object that counts events with the following semantics: objects of this type will be set to zero(0) on creation and will thereafter count appropriate events, wrapping back to zero(0) when the value 2^32 is reached. Provided that an application discovers the new object within the minimum time to wrap, it can use the initial value as a delta since it last polled the table of which this object is part. It is important for a management station to be aware of this minimum time and the actual time between polls, and to discard data if the actual time is too long or there is no defined minimum time. Typically, this TC is used in tables where the INDEX space is constantly changing and/or the TimeFilter mechanism is in use. · Gauge32

The number of octets transmitted from the source address to the destination address since this entry was added to the nlMatrixDSTable (excluding framing bits, but including FCS octets), excluding octets in packets that contained errors. Note that this doesn't count just those octets in the particular protocol frames but includes the entire packet that contained the protocol.

LastCreateTimeThis TC describes an object that stores the value of the sysUpTime object at the last time its entry was created. This can be used for polling applications to determine that an entry has been deleted and re-created between polls, causing an otherwise undetectable discontinuity in the data. If sysUpTime is reset to zero as a result of a re- initialization of the network management (sub)system, then the values of all LastCreateTime objects are also reset. However, after approximately 497 days without a re- initialization, the sysUpTime object will reach 2^^32-1 and then increment to zero; in this case, existing values of TimeStamp objects do not change. This can lead to ambiguities in the value of TimeStamp objects. · TimeTicks

The value of sysUpTime when this entry was last activated. This can be used by the management station to ensure that the entry has not been deleted and recreated between polls.

Integer32 (1..65535)

An index that uniquely identifies an entry in the nlMatrixTopNControlTable. Each such entry defines one topN report prepared for one interface.

Integer32 (1..65535)

The nlMatrix[SD/DS] table for which a topN report will be prepared on behalf of this entry. The nlMatrix[SD/DS] table is identified by the value of the hlMatrixControlIndex for that table - that value is used here to identify the particular table. This object may not be modified if the associated nlMatrixTopNControlStatus object is equal to active(1).

INTEGER1 = nlMatrixTopNPkts2 = nlMatrixTopNOctets3 = nlMatrixTopNHighCapacityPkts4 = nlMatrixTopNHighCapacityOctets · Integer32

The variable for each nlMatrix[SD/DS] entry that the nlMatrixTopNEntries are sorted by, as well as a control for the table that the results will be reported in. This object may not be modified if the associated nlMatrixTopNControlStatus object is equal to active(1). If this value is less than or equal to 2, when the report is prepared, entries are created in the nlMatrixTopNTable associated with this object. If this value is greater than or equal to 3, when the report is prepared, entries are created in the nlMatrixTopNHighCapacityTable associated with this object.

Integer32 (0..2147483647)

The number of seconds left in the report currently being collected. When this object is modified by the management station, a new collection is started, possibly aborting a currently running report. The new value is used as the requested duration of this report and is immediately loaded into the associated nlMatrixTopNControlDuration object. When the report finishes, the probe will automatically start another collection with the same initial value of nlMatrixTopNControlTimeRemaining. Thus, the management station may simply read the resulting reports repeatedly, checking the startTime and duration each time to ensure that a report was not missed or that the report parameters were not changed. While the value of this object is non-zero, it decrements by one per second until it reaches zero. At the time that this object decrements to zero, the report is made accessible in the nlMatrixTopNTable, overwriting any report that may be there. When this object is modified by the management station, any associated entries in the nlMatrixTopNTable shall be deleted. (Note that this is a different algorithm than the one used in the hostTopNTable).

Counter32

The number of reports that have been generated by this entry.

Integer32

The number of seconds that this report has collected during the last sampling interval. When the associated nlMatrixTopNControlTimeRemaining object is set, this object shall be set by the probe to the same value and shall not be modified until the next time the nlMatrixTopNControlTimeRemaining is set. This value shall be zero if no reports have been requested for this nlMatrixTopNControlEntry.

Integer32 (0..2147483647)

The maximum number of matrix entries requested for this report. When this object is created or modified, the probe should set nlMatrixTopNControlGrantedSize as closely to this object as possible for the particular probe implementation and available resources.

Integer32 (0..2147483647)

The maximum number of matrix entries in this report. When the associated nlMatrixTopNControlRequestedSize object is created or modified, the probe should set this object as closely to the requested value as possible for the particular implementation and available resources. The probe must not lower this value except as a side-effect of a set to the associated nlMatrixTopNControlRequestedSize object. If the value of nlMatrixTopNControlRateBase is equal to nlMatrixTopNPkts, when the next topN report is generated, matrix entries with the highest value of nlMatrixTopNPktRate shall be placed in this table in decreasing order of this rate until there is no more room or until there are no more matrix entries. If the value of nlMatrixTopNControlRateBase is equal to nlMatrixTopNOctets, when the next topN report is generated, matrix entries with the highest value of nlMatrixTopNOctetRate shall be placed in this table in decreasing order of this rate until there is no more room or until there are no more matrix entries. It is an implementation-specific matter how entries with the same value of nlMatrixTopNPktRate or nlMatrixTopNOctetRate are sorted. It is also an implementation-specific matter as to whether zero-valued entries are available.

TimeStampThe value of the sysUpTime object at which a specific occurrence happened. The specific occurrence must be defined in the description of any object defined using this type. If sysUpTime is reset to zero as a result of a re- initialization of the network management (sub)system, then the values of all TimeStamp objects are also reset. However, after approximately 497 days without a re- initialization, the sysUpTime object will reach 2^^32-1 and then increment around to zero; in this case, existing values of TimeStamp objects do not change. This can lead to ambiguities in the value of TimeStamp objects. · TimeTicks

The value of sysUpTime when this topN report was last started. In other words, this is the time that the associated nlMatrixTopNControlTimeRemaining object was modified to start the requested report or the time the report was last automatically (re)started. This object may be used by the management station to determine whether a report was missed.

OwnerStringThis data type is used to model an administratively assigned name of the owner of a resource. Implementations must accept values composed of well-formed NVT ASCII sequences. In addition, implementations should accept values composed of well-formed UTF-8 sequences. It is suggested that this name contain one or more of the following: IP address, management station name, network manager's name, location, or phone number. In some cases the agent itself will be the owner of an entry. In these cases, this string shall be set to a string starting with 'monitor'. SNMP access control is articulated entirely in terms of the contents of MIB views; access to a particular SNMP object instance depends only upon its presence or absence in a particular MIB view and never upon its value or the value of related object instances. Thus, objects of this type afford resolution of resource contention only among cooperating managers; they realize no access control function with respect to uncooperative parties. SIZE (0..127) · OCTET STRING

The entity that configured this entry and is therefore using the resources assigned to it.

RowStatus1 = active2 = notInService3 = notReady4 = createAndGo5 = createAndWait6 = destroyThe RowStatus textual convention is used to manage the creation and deletion of conceptual rows, and is used as the value of the SYNTAX clause for the status column of a conceptual row (as described in Section 7.7.1 of [2].) 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); 'notInService' has no implication regarding the internal consistency of the row, availability of resources, or consistency with the current state of the managed device; - `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 (i.e., one or more required columns in the conceptual row have not been instanciated); - `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 attempt 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 status column having a SYNTAX clause value 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) goto 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, and all columns have acceptable values, then return noError and goto D. (3) if other variable bindings included in the same PDU, provide legal 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 notInService (e.g., an agent which 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. (8) the transition to D can fail, e.g., if the values of the conceptual row are inconsistent, then the error code would be inconsistentValue. NOTE: Other processing of (this and other varbinds 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. A MIB designer should choose between the two latter algorithms based on the size of the table (and therefore the efficiency of each algorithm). For tables in which a large number of entries are expected, it is recommended that a MIB object be defined that returns an acceptable index for creation. For tables with small numbers of entries, it is recommended that the latter pseudo-random index mechanism be used. Interaction 2: Creating the Conceptual Row Once an unused instance-identifier has been selected, the management station determines if it wishes to create and activate the conceptual row in one transaction or in a negotiated set of interactions. Interaction 2a: Creating and Activating the Conceptual Row The management station must first determine the column requirements, i.e., it must determine those columns for which it must or must not provide values. Depending on the complexity of the table and the management station's knowledge of the agent's capabilities, this determination can be made locally by the management station. Alternately, the management station issues a management protocol get operation to examine all columns in the conceptual row that it wishes to create. In response, for each column, there are three possible outcomes: - a value is returned, indicating that some other management station has already created this conceptual row. We return to interaction 1. - the exception `noSuchInstance' is returned, indicating that the agent implements the object-type associated with this column, and that this column in at least one conceptual row would be accessible in the MIB view used by the retrieval were it to exist. For those columns to which the agent provides read-create access, the `noSuchInstance' exception tells the management station that it should supply a value for this column when the conceptual row is to be created. - the exception `noSuchObject' is returned, indicating that the agent does not implement the object-type associated with this column or that there is no conceptual row for which this column would be accessible in the MIB view used by the retrieval. As such, the management station can not issue any management protocol set operations to create an instance of this column. Once the column requirements have been determined, a management protocol set operation is accordingly issued. This operation also sets the new instance of the status column to `createAndGo'. When the agent processes the set operation, it verifies that it has sufficient information to make the conceptual row available for use by the managed device. The information available to the agent is provided by two sources: the management protocol set operation which creates the conceptual row, and, implementation-specific defaults supplied by the agent (note that an agent must provide implementation-specific defaults for at least those objects which it implements as read-only). If there is sufficient information available, then the conceptual row is created, a `noError' response is returned, the status column is set to `active', and no further interactions are necessary (i.e., interactions 3 and 4 are skipped). If there is insufficient information, then the conceptual row is not created, and the set operation fails with an error of `inconsistentValue'. On this error, the management station can issue a management protocol retrieval operation to determine if this was because it failed to specify a value for a required column, or, because the selected instance of the status column already existed. In the latter case, we return to interaction 1. In the former case, the management station can re-issue the set operation with the additional information, or begin interaction 2 again using `createAndWait' in order to negotiate creation of the conceptual row. NOTE WELL Regardless of the method used to determine the column requirements, it is possible that the management station might deem a column necessary when, in fact, the agent will not allow that particular columnar instance to be created or written. In this case, the management protocol set operation will fail with an error such as `noCreation' or `notWritable'. In this case, the management station decides whether it needs to be able to set a value for that particular columnar instance. If not, the management station re-issues the management protocol set operation, but without setting a value for that particular columnar instance; otherwise, the management station aborts the row creation algorithm. Interaction 2b: Negotiating the Creation of the Conceptual Row The management station issues a management protocol set operation which sets the desired instance of the status column to `createAndWait'. If the agent is unwilling to process a request of this sort, the set operation fails with an error of `wrongValue'. (As a consequence, such an agent must be prepared to accept a single management protocol set operation, i.e., interaction 2a above, containing all of the columns indicated by its column requirements.) Otherwise, the conceptual row is created, a `noError' response is returned, and the status column is immediately set to either `notInService' or `notReady', depending on whether it has sufficient information to (attempt to) make the conceptual row available for use by the managed device. If there is sufficient information available, then the status column is set to `notInService'; otherwise, if there is insufficient information, then the status column is set to `notReady'. Regardless, we proceed to interaction 3. Interaction 3: Initializing non-defaulted Objects The management station must now determine the column requirements. It issues a management protocol get operation to examine all columns in the created conceptual row. In the response, for each column, there are three possible outcomes: - a value is returned, indicating that the agent implements the object-type associated with this column and had sufficient information to provide a value. For those columns to which the agent provides read-create access (and for which the agent allows their values to be changed after their creation), a value return tells the management station that it may issue additional management protocol set operations, if it desires, in order to change the value associated with this column. - the exception `noSuchInstance' is returned, indicating that the agent implements the object-type associated with this column, and that this column in at least one conceptual row would be accessible in the MIB view used by the retrieval were it to exist. However, the agent does not have sufficient information to provide a value, and until a value is provided, the conceptual row may not be made available for use by the managed device. For those columns to which the agent provides read-create access, the `noSuchInstance' exception tells the management station that it must issue additional management protocol set operations, in order to provide a value associated with this column. - the exception `noSuchObject' is returned, indicating that the agent does not implement the object-type associated with this column or that there is no conceptual row for which this column would be accessible in the MIB view used by the retrieval. As such, the management station can not issue any management protocol set operations to create an instance of this column. If the value associated with the status column is `notReady', then the management station must first deal with all `noSuchInstance' columns, if any. Having done so, the value of the status column becomes `notInService', and we proceed to interaction 4. Interaction 4: Making the Conceptual Row Available Once the management station is satisfied with the values associated with the columns of the conceptual row, it issues a management protocol set operation to set the status column to `active'. If the agent has sufficient information to make the conceptual row available for use by the managed device, the management protocol set operation succeeds (a `noError' response is returned). Otherwise, the management protocol set operation fails with an error of `inconsistentValue'. NOTE WELL A conceptual row having a status column with value `notInService' or `notReady' is unavailable to the managed device. As such, it is possible for the managed device to create its own instances during the time between the management protocol set operation which sets the status column to `createAndWait' and the management protocol set operation which sets the status column to `active'. In this case, when the management protocol set operation is issued to set the status column to `active', the values held in the agent supersede those used by the managed device. If the management station is prevented from setting the status column to `active' (e.g., due to management station or network failure) the conceptual row will be left in the `notInService' or `notReady' state, consuming resources indefinitely. The agent must detect conceptual rows that have been in either state for an abnormally long period of time and remove them. It is the responsibility of the DESCRIPTION clause of the status column to indicate what an abnormally long period of time would be. This period of time should be long enough to allow for human response time (including `think time') between the creation of the conceptual row and the setting of the status to `active'. In the absence of such information in the DESCRIPTION clause, it is suggested that this period be approximately 5 minutes in length. This removal action applies not only to newly-created rows, but also to previously active rows which are set to, and left in, the notInService state for a prolonged period exceeding that which is considered normal for such a conceptual row. Conceptual Row Suspension When a conceptual row is `active', the management station may issue a management protocol set operation which sets the instance of the status column to `notInService'. If the agent is unwilling to do so, the set operation fails with an error of `wrongValue' or `inconsistentValue'. Otherwise, the conceptual row is taken out of service, and a `noError' response is returned. It is the responsibility of the DESCRIPTION clause of the status column to indicate under what circumstances the status column should be taken out of service (e.g., in order for the value of some other column of the same conceptual row to be modified). Conceptual Row Deletion For deletion of conceptual rows, a management protocol set operation is issued which sets the instance of the status column to `destroy'. This request may be made regardless of the current value of the status column (e.g., it is possible to delete conceptual rows which are either `notReady', `notInService' or `active'.) If the operation succeeds, then all instances associated with the conceptual row are immediately removed. · Integer32

The status of this nlMatrixTopNControlEntry. An entry may not exist in the active state unless all objects in the entry have an appropriate value. If this object is not equal to active(1), all associated entries in the nlMatrixTopNTable shall be deleted by the agent.

Integer32 (1..65535)

An index that uniquely identifies an entry in the nlMatrixTopNTable among those in the same report. This index is between 1 and N, where N is the number of entries in this report. If the value of nlMatrixTopNControlRateBase is equal to nlMatrixTopNPkts, increasing values of nlMatrixTopNIndex shall be assigned to entries with decreasing values of nlMatrixTopNPktRate until index N is assigned or there are no more nlMatrixTopNEntries. If the value of nlMatrixTopNControlRateBase is equal to nlMatrixTopNOctets, increasing values of nlMatrixTopNIndex shall be assigned to entries with decreasing values of nlMatrixTopNOctetRate until index N is assigned or there are no more nlMatrixTopNEntries.

Integer32 (1..2147483647)

The protocolDirLocalIndex of the network-layer protocol of this entry's network address.

OCTET STRING SIZE (1..255)

The network-layer address of the source host in this conversation. This is represented as an octet string with specific semantics and length as identified by the associated nlMatrixTopNProtocolDirLocalIndex. For example, if the protocolDirLocalIndex indicates an encapsulation of IP, this object is encoded as a length octet of 4, followed by the 4 octets of the IP address, in network byte order.

OCTET STRING SIZE (1..255)

The network-layer address of the destination host in this conversation. This is represented as an octet string with specific semantics and length as identified by the associated nlMatrixTopNProtocolDirLocalIndex. For example, if the nlMatrixTopNProtocolDirLocalIndex indicates an encapsulation of IP, this object is encoded as a length octet of 4, followed by the 4 octets of the IP address, in network byte order.

Gauge32

The number of packets seen from the source host to the destination host during this sampling interval, counted using the rules for counting the nlMatrixSDPkts object. If the value of nlMatrixTopNControlRateBase is nlMatrixTopNPkts, this variable will be used to sort this report.

Gauge32

The number of packets seen from the destination host to the source host during this sampling interval, counted using the rules for counting the nlMatrixSDPkts object. (Note that the corresponding nlMatrixSDPkts object selected is the one whose source address is equal to nlMatrixTopNDestAddress and whose destination address is equal to nlMatrixTopNSourceAddress.) Note that if the value of nlMatrixTopNControlRateBase is equal to nlMatrixTopNPkts, the sort of topN entries is based entirely on nlMatrixTopNPktRate, and not on the value of this object.

Gauge32

The number of octets seen from the source host to the destination host during this sampling interval, counted using the rules for counting the nlMatrixSDOctets object. If the value of nlMatrixTopNControlRateBase is nlMatrixTopNOctets, this variable will be used to sort this report.

Gauge32

The number of octets seen from the destination host to the source host during this sampling interval, counted using the rules for counting the nlMatrixDSOctets object. (Note that the corresponding nlMatrixSDOctets object selected is the one whose source address is equal to nlMatrixTopNDestAddress and whose destination address is equal to nlMatrixTopNSourceAddress.) Note that if the value of nlMatrixTopNControlRateBase is equal to nlMatrixTopNOctets, the sort of topN entries is based entirely on nlMatrixTopNOctetRate, and not on the value of this object.

TimeFilterTo be used for the index to a table. Allows an application to download only those rows changed since a particular time. Note that this is not a history mechanism. Only current values of underlying objects are returned; saved instance values associated with particular values of sysUpTime are not. An entry is considered changed if the value of any object in the entry changes, if the row is created, or if any object in the entry is created or deleted. Note that deleted entries cannot be detected or downloaded. A time-filtered conceptual table is created by inserting a single object of SYNTAX TimeFilter as the first INDEX component in a copy of an existing basic conceptual table (i.e., any SEQUENCE without a TimeFilter INDEX component). Thus, for each conceptual entry 'I' in the basic table, there exists N conceptual entries in the time-filtered version, indexed N.I, where 'N' is equal to the value of sysUpTime. When an application retrieves conceptual instances from a time-filtered table, and an INDEX value is provided for the TimeFilter INDEX component 'N', the agent will only consider returning basic conceptual entries (e.g., 'fooColumn.N.I') if any column within the basic conceptual entry has changed since sysUpTime 'N'. If not, the basic conceptual entry will be ignored for the particular retrieval operation. When sysUpTime is equal to zero, this table shall be empty. One conceptual entry exists for each past value of sysUpTime, except that the whole table is purged should sysUpTime wrap. As an entry in a time-filtered table is updated (i.e., one of the columns in the basic conceptual table is changed), new conceptual entries are also created in the time-filtered version (which still shares the now updated object values with all other instances). The number of unique time-filtered instances that are created is determined by the value of sysUpTime at which the basic entry was last updated. One unique instance will exist for each value of sysUpTime at the last update time for the row. However, a new TimeFilter index instance is created for each new sysUpTime value. The TimeFilter index values not associated with entry updates are called duplicate time-filtered instances. After some deployment experience, it has been determined that a time-filtered table is more efficient if the agent stops a MIB walk operation by skipping over rows with a TimeFilter index value higher than the value in the received GetNext/GetBulk request. That is, instead of incrementing a TimeFilter index value, the agent will continue to the next object or table. As a consequence, GetNext or GetBulk operations will provide only one pass through a time-filtered table. It is suggested that an agent implement a time-filtered table in this manner to improve performance and avoid a MIB walk getting stuck in time-filtered tables. It is, however, still acceptable for an agent to implement a time-filtered table in the traditional manner (i.e., every conceptual time-filtered instance is returned in GetNext and GetBulk PDU responses), and management applications must be able to deal with such traditional implementations. See the appendix for further discussion of this textual convention. The following example is provided to demonstrate TimeFilter behavior: Consider the following basic conceptual table, basicFooTable. (Note that the basic version of a time-filtered table may not actually be defined.) basicFooTable: basicFooTable ... INDEX { fooIndex } BasicFooEntry { fooIndex Integer32, fooCounts Counter32 } For this example, the basicFooTable contains two static conceptual entries (fooIndex equals '1' and '2'), created at time zero. It also contains one dynamic conceptual entry (fooIndex equals '3'), which is created at time '3' and deleted at time '7'. The time-filtered version of the basicFooTable could be defined as follows: FooTable: fooTable ... INDEX { fooTimeMark, fooIndex } FooEntry { fooTimeMark TimeFilter, fooIndex Integer32, fooCounts Counter32 } Note that entries exist in the time-filtered conceptual table only if they actually exist in the underlying (basic) table. For this example, the fooTable will have three underlying basic entries (fooIndex == 1, 2, and 3), with the following activity (for sysUpTime equal 0 to 9): - fooEntry.N.1 is created at time '0' and most recently updated at time '6' to the value '5'. - fooEntry.N.2 is created at time '0' and most recently updated at time '8' to the value '9'. - fooEntry.N.3 is created at time '3', updated at time '5' to the value '17', and deleted at time '7'. The following tables show the values that would be returned for MIB walk operations with various TimeFilter values, done at different times. An application issues a retrieval request at time 'T', with a TimeFilter value, 'N' (typically set to a lower value, such as the value of sysUpTime at the last polling cycle). The following values would be returned in a MIB walk of fooCounts.N if T equals '0' and N equals '0': fooCounts.N.I Value ========================== fooCounts.0.1 0 fooCounts.0.2 0 Note that nothing is returned for fooCounts.0.3, since that entry does not exist at sysUpTime equals '0'. The following values would be returned in a full (traditional) MIB walk of fooCounts.N if T equals '3' and N equals '0': fooCounts.N.I Value ======================= fooCounts.0.1 0 fooCounts.0.2 0 fooCounts.0.3 0 fooCounts.1.3 0 fooCounts.2.3 0 fooCounts.3.3 0 Note that there are no instances for T equals 1 or 2 for the first two values of N, as these entries did not change since they were created at time '0'. Note that the current value for 'fooCounts.N.3' is returned here, even for values of N less than '3' (when the entry was created). The agent only considers the current existence of an entry in the TimeFilter algorithm, not the time when the entry was created. Note that the instances 'fooCounts.0.3', 'fooCounts.1.3', and 'fooCounts.2.3' are duplicates and can be suppressed by the agent in a MIB walk. The following values would be returned in a full (traditional) MIB walk of fooCounts.N if T equals '6' and N equals '3': fooCounts.N.I Value ======================= fooCounts.3.1 5 fooCounts.3.3 17 fooCounts.4.1 5 fooCounts.4.3 17 fooCounts.5.1 5 fooCounts.5.3 17 fooCounts.6.1 5 Note that no instances for entry 'fooCounts.N.2' are returned, since it has not changed since time '3'. Note that all instances except 'fooCounts.5.3' and 'fooCounts.6.1' are duplicates and can be suppressed by the agent in a MIB walk. The following values would be returned in a full (traditional) MIB walk of fooCounts.N if T equals '9' and N equals '6': fooCounts.N.I Value ======================= fooCounts.6.1 5 fooCounts.6.2 9 fooCounts.7.2 9 fooCounts.8.2 9 Note that no instances for entry 'fooCounts.N.3' are returned, since it was deleted at time '7'. Note that instances 'fooCounts.6.2' and 'fooCounts.7.2' are duplicates and can be suppressed by the agent in a MIB walk. · TimeTicks

A TimeFilter for this entry. See the TimeFilter textual convention to see how this works.

ZeroBasedCounter32This TC describes an object that counts events with the following semantics: objects of this type will be set to zero(0) on creation and will thereafter count appropriate events, wrapping back to zero(0) when the value 2^32 is reached. Provided that an application discovers the new object within the minimum time to wrap, it can use the initial value as a delta since it last polled the table of which this object is part. It is important for a management station to be aware of this minimum time and the actual time between polls, and to discard data if the actual time is too long or there is no defined minimum time. Typically, this TC is used in tables where the INDEX space is constantly changing and/or the TimeFilter mechanism is in use. · Gauge32

The number of packets of this protocol type without errors transmitted to this address since it was added to the alHostTable. Note that this is the number of link-layer packets, so if a single network-layer packet is fragmented into several link-layer frames, this counter is incremented several times.

ZeroBasedCounter32This TC describes an object that counts events with the following semantics: objects of this type will be set to zero(0) on creation and will thereafter count appropriate events, wrapping back to zero(0) when the value 2^32 is reached. Provided that an application discovers the new object within the minimum time to wrap, it can use the initial value as a delta since it last polled the table of which this object is part. It is important for a management station to be aware of this minimum time and the actual time between polls, and to discard data if the actual time is too long or there is no defined minimum time. Typically, this TC is used in tables where the INDEX space is constantly changing and/or the TimeFilter mechanism is in use. · Gauge32

The number of packets of this protocol type without errors transmitted by this address since it was added to the alHostTable. Note that this is the number of link-layer packets, so if a single network-layer packet is fragmented into several link-layer frames, this counter is incremented several times.

ZeroBasedCounter32This TC describes an object that counts events with the following semantics: objects of this type will be set to zero(0) on creation and will thereafter count appropriate events, wrapping back to zero(0) when the value 2^32 is reached. Provided that an application discovers the new object within the minimum time to wrap, it can use the initial value as a delta since it last polled the table of which this object is part. It is important for a management station to be aware of this minimum time and the actual time between polls, and to discard data if the actual time is too long or there is no defined minimum time. Typically, this TC is used in tables where the INDEX space is constantly changing and/or the TimeFilter mechanism is in use. · Gauge32

The number of octets transmitted to this address of this protocol type since it was added to the alHostTable (excluding framing bits, but including FCS octets), excluding octets in packets that contained errors. Note that this doesn't count just those octets in the particular protocol frames but includes the entire packet that contained the protocol.

ZeroBasedCounter32This TC describes an object that counts events with the following semantics: objects of this type will be set to zero(0) on creation and will thereafter count appropriate events, wrapping back to zero(0) when the value 2^32 is reached. Provided that an application discovers the new object within the minimum time to wrap, it can use the initial value as a delta since it last polled the table of which this object is part. It is important for a management station to be aware of this minimum time and the actual time between polls, and to discard data if the actual time is too long or there is no defined minimum time. Typically, this TC is used in tables where the INDEX space is constantly changing and/or the TimeFilter mechanism is in use. · Gauge32

The number of octets transmitted by this address of this protocol type since it was added to the alHostTable (excluding framing bits, but including FCS octets), excluding octets in packets that contained errors. Note that this doesn't count just those octets in the particular protocol frames but includes the entire packet that contained the protocol.

LastCreateTimeThis TC describes an object that stores the value of the sysUpTime object at the last time its entry was created. This can be used for polling applications to determine that an entry has been deleted and re-created between polls, causing an otherwise undetectable discontinuity in the data. If sysUpTime is reset to zero as a result of a re- initialization of the network management (sub)system, then the values of all LastCreateTime objects are also reset. However, after approximately 497 days without a re- initialization, the sysUpTime object will reach 2^^32-1 and then increment to zero; in this case, existing values of TimeStamp objects do not change. This can lead to ambiguities in the value of TimeStamp objects. · TimeTicks

The value of sysUpTime when this entry was last activated. This can be used by the management station to ensure that the entry has not been deleted and recreated between polls.

TimeFilterTo be used for the index to a table. Allows an application to download only those rows changed since a particular time. Note that this is not a history mechanism. Only current values of underlying objects are returned; saved instance values associated with particular values of sysUpTime are not. An entry is considered changed if the value of any object in the entry changes, if the row is created, or if any object in the entry is created or deleted. Note that deleted entries cannot be detected or downloaded. A time-filtered conceptual table is created by inserting a single object of SYNTAX TimeFilter as the first INDEX component in a copy of an existing basic conceptual table (i.e., any SEQUENCE without a TimeFilter INDEX component). Thus, for each conceptual entry 'I' in the basic table, there exists N conceptual entries in the time-filtered version, indexed N.I, where 'N' is equal to the value of sysUpTime. When an application retrieves conceptual instances from a time-filtered table, and an INDEX value is provided for the TimeFilter INDEX component 'N', the agent will only consider returning basic conceptual entries (e.g., 'fooColumn.N.I') if any column within the basic conceptual entry has changed since sysUpTime 'N'. If not, the basic conceptual entry will be ignored for the particular retrieval operation. When sysUpTime is equal to zero, this table shall be empty. One conceptual entry exists for each past value of sysUpTime, except that the whole table is purged should sysUpTime wrap. As an entry in a time-filtered table is updated (i.e., one of the columns in the basic conceptual table is changed), new conceptual entries are also created in the time-filtered version (which still shares the now updated object values with all other instances). The number of unique time-filtered instances that are created is determined by the value of sysUpTime at which the basic entry was last updated. One unique instance will exist for each value of sysUpTime at the last update time for the row. However, a new TimeFilter index instance is created for each new sysUpTime value. The TimeFilter index values not associated with entry updates are called duplicate time-filtered instances. After some deployment experience, it has been determined that a time-filtered table is more efficient if the agent stops a MIB walk operation by skipping over rows with a TimeFilter index value higher than the value in the received GetNext/GetBulk request. That is, instead of incrementing a TimeFilter index value, the agent will continue to the next object or table. As a consequence, GetNext or GetBulk operations will provide only one pass through a time-filtered table. It is suggested that an agent implement a time-filtered table in this manner to improve performance and avoid a MIB walk getting stuck in time-filtered tables. It is, however, still acceptable for an agent to implement a time-filtered table in the traditional manner (i.e., every conceptual time-filtered instance is returned in GetNext and GetBulk PDU responses), and management applications must be able to deal with such traditional implementations. See the appendix for further discussion of this textual convention. The following example is provided to demonstrate TimeFilter behavior: Consider the following basic conceptual table, basicFooTable. (Note that the basic version of a time-filtered table may not actually be defined.) basicFooTable: basicFooTable ... INDEX { fooIndex } BasicFooEntry { fooIndex Integer32, fooCounts Counter32 } For this example, the basicFooTable contains two static conceptual entries (fooIndex equals '1' and '2'), created at time zero. It also contains one dynamic conceptual entry (fooIndex equals '3'), which is created at time '3' and deleted at time '7'. The time-filtered version of the basicFooTable could be defined as follows: FooTable: fooTable ... INDEX { fooTimeMark, fooIndex } FooEntry { fooTimeMark TimeFilter, fooIndex Integer32, fooCounts Counter32 } Note that entries exist in the time-filtered conceptual table only if they actually exist in the underlying (basic) table. For this example, the fooTable will have three underlying basic entries (fooIndex == 1, 2, and 3), with the following activity (for sysUpTime equal 0 to 9): - fooEntry.N.1 is created at time '0' and most recently updated at time '6' to the value '5'. - fooEntry.N.2 is created at time '0' and most recently updated at time '8' to the value '9'. - fooEntry.N.3 is created at time '3', updated at time '5' to the value '17', and deleted at time '7'. The following tables show the values that would be returned for MIB walk operations with various TimeFilter values, done at different times. An application issues a retrieval request at time 'T', with a TimeFilter value, 'N' (typically set to a lower value, such as the value of sysUpTime at the last polling cycle). The following values would be returned in a MIB walk of fooCounts.N if T equals '0' and N equals '0': fooCounts.N.I Value ========================== fooCounts.0.1 0 fooCounts.0.2 0 Note that nothing is returned for fooCounts.0.3, since that entry does not exist at sysUpTime equals '0'. The following values would be returned in a full (traditional) MIB walk of fooCounts.N if T equals '3' and N equals '0': fooCounts.N.I Value ======================= fooCounts.0.1 0 fooCounts.0.2 0 fooCounts.0.3 0 fooCounts.1.3 0 fooCounts.2.3 0 fooCounts.3.3 0 Note that there are no instances for T equals 1 or 2 for the first two values of N, as these entries did not change since they were created at time '0'. Note that the current value for 'fooCounts.N.3' is returned here, even for values of N less than '3' (when the entry was created). The agent only considers the current existence of an entry in the TimeFilter algorithm, not the time when the entry was created. Note that the instances 'fooCounts.0.3', 'fooCounts.1.3', and 'fooCounts.2.3' are duplicates and can be suppressed by the agent in a MIB walk. The following values would be returned in a full (traditional) MIB walk of fooCounts.N if T equals '6' and N equals '3': fooCounts.N.I Value ======================= fooCounts.3.1 5 fooCounts.3.3 17 fooCounts.4.1 5 fooCounts.4.3 17 fooCounts.5.1 5 fooCounts.5.3 17 fooCounts.6.1 5 Note that no instances for entry 'fooCounts.N.2' are returned, since it has not changed since time '3'. Note that all instances except 'fooCounts.5.3' and 'fooCounts.6.1' are duplicates and can be suppressed by the agent in a MIB walk. The following values would be returned in a full (traditional) MIB walk of fooCounts.N if T equals '9' and N equals '6': fooCounts.N.I Value ======================= fooCounts.6.1 5 fooCounts.6.2 9 fooCounts.7.2 9 fooCounts.8.2 9 Note that no instances for entry 'fooCounts.N.3' are returned, since it was deleted at time '7'. Note that instances 'fooCounts.6.2' and 'fooCounts.7.2' are duplicates and can be suppressed by the agent in a MIB walk. · TimeTicks

A TimeFilter for this entry. See the TimeFilter textual convention to see how this works.

ZeroBasedCounter32This TC describes an object that counts events with the following semantics: objects of this type will be set to zero(0) on creation and will thereafter count appropriate events, wrapping back to zero(0) when the value 2^32 is reached. Provided that an application discovers the new object within the minimum time to wrap, it can use the initial value as a delta since it last polled the table of which this object is part. It is important for a management station to be aware of this minimum time and the actual time between polls, and to discard data if the actual time is too long or there is no defined minimum time. Typically, this TC is used in tables where the INDEX space is constantly changing and/or the TimeFilter mechanism is in use. · Gauge32

The number of packets of this protocol type without errors transmitted from the source address to the destination address since this entry was added to the alMatrixSDTable. Note that this is the number of link-layer packets, so if a single network-layer packet is fragmented into several link-layer frames, this counter is incremented several times.

ZeroBasedCounter32This TC describes an object that counts events with the following semantics: objects of this type will be set to zero(0) on creation and will thereafter count appropriate events, wrapping back to zero(0) when the value 2^32 is reached. Provided that an application discovers the new object within the minimum time to wrap, it can use the initial value as a delta since it last polled the table of which this object is part. It is important for a management station to be aware of this minimum time and the actual time between polls, and to discard data if the actual time is too long or there is no defined minimum time. Typically, this TC is used in tables where the INDEX space is constantly changing and/or the TimeFilter mechanism is in use. · Gauge32

The number of octets in packets of this protocol type transmitted from the source address to the destination address since this entry was added to the alMatrixSDTable (excluding framing bits, but including FCS octets), excluding octets in packets that contained errors. Note that this doesn't count just those octets in the particular protocol frames but includes the entire packet that contained the protocol.

LastCreateTimeThis TC describes an object that stores the value of the sysUpTime object at the last time its entry was created. This can be used for polling applications to determine that an entry has been deleted and re-created between polls, causing an otherwise undetectable discontinuity in the data. If sysUpTime is reset to zero as a result of a re- initialization of the network management (sub)system, then the values of all LastCreateTime objects are also reset. However, after approximately 497 days without a re- initialization, the sysUpTime object will reach 2^^32-1 and then increment to zero; in this case, existing values of TimeStamp objects do not change. This can lead to ambiguities in the value of TimeStamp objects. · TimeTicks

The value of sysUpTime when this entry was last activated. This can be used by the management station to ensure that the entry has not been deleted and recreated between polls.

TimeFilterTo be used for the index to a table. Allows an application to download only those rows changed since a particular time. Note that this is not a history mechanism. Only current values of underlying objects are returned; saved instance values associated with particular values of sysUpTime are not. An entry is considered changed if the value of any object in the entry changes, if the row is created, or if any object in the entry is created or deleted. Note that deleted entries cannot be detected or downloaded. A time-filtered conceptual table is created by inserting a single object of SYNTAX TimeFilter as the first INDEX component in a copy of an existing basic conceptual table (i.e., any SEQUENCE without a TimeFilter INDEX component). Thus, for each conceptual entry 'I' in the basic table, there exists N conceptual entries in the time-filtered version, indexed N.I, where 'N' is equal to the value of sysUpTime. When an application retrieves conceptual instances from a time-filtered table, and an INDEX value is provided for the TimeFilter INDEX component 'N', the agent will only consider returning basic conceptual entries (e.g., 'fooColumn.N.I') if any column within the basic conceptual entry has changed since sysUpTime 'N'. If not, the basic conceptual entry will be ignored for the particular retrieval operation. When sysUpTime is equal to zero, this table shall be empty. One conceptual entry exists for each past value of sysUpTime, except that the whole table is purged should sysUpTime wrap. As an entry in a time-filtered table is updated (i.e., one of the columns in the basic conceptual table is changed), new conceptual entries are also created in the time-filtered version (which still shares the now updated object values with all other instances). The number of unique time-filtered instances that are created is determined by the value of sysUpTime at which the basic entry was last updated. One unique instance will exist for each value of sysUpTime at the last update time for the row. However, a new TimeFilter index instance is created for each new sysUpTime value. The TimeFilter index values not associated with entry updates are called duplicate time-filtered instances. After some deployment experience, it has been determined that a time-filtered table is more efficient if the agent stops a MIB walk operation by skipping over rows with a TimeFilter index value higher than the value in the received GetNext/GetBulk request. That is, instead of incrementing a TimeFilter index value, the agent will continue to the next object or table. As a consequence, GetNext or GetBulk operations will provide only one pass through a time-filtered table. It is suggested that an agent implement a time-filtered table in this manner to improve performance and avoid a MIB walk getting stuck in time-filtered tables. It is, however, still acceptable for an agent to implement a time-filtered table in the traditional manner (i.e., every conceptual time-filtered instance is returned in GetNext and GetBulk PDU responses), and management applications must be able to deal with such traditional implementations. See the appendix for further discussion of this textual convention. The following example is provided to demonstrate TimeFilter behavior: Consider the following basic conceptual table, basicFooTable. (Note that the basic version of a time-filtered table may not actually be defined.) basicFooTable: basicFooTable ... INDEX { fooIndex } BasicFooEntry { fooIndex Integer32, fooCounts Counter32 } For this example, the basicFooTable contains two static conceptual entries (fooIndex equals '1' and '2'), created at time zero. It also contains one dynamic conceptual entry (fooIndex equals '3'), which is created at time '3' and deleted at time '7'. The time-filtered version of the basicFooTable could be defined as follows: FooTable: fooTable ... INDEX { fooTimeMark, fooIndex } FooEntry { fooTimeMark TimeFilter, fooIndex Integer32, fooCounts Counter32 } Note that entries exist in the time-filtered conceptual table only if they actually exist in the underlying (basic) table. For this example, the fooTable will have three underlying basic entries (fooIndex == 1, 2, and 3), with the following activity (for sysUpTime equal 0 to 9): - fooEntry.N.1 is created at time '0' and most recently updated at time '6' to the value '5'. - fooEntry.N.2 is created at time '0' and most recently updated at time '8' to the value '9'. - fooEntry.N.3 is created at time '3', updated at time '5' to the value '17', and deleted at time '7'. The following tables show the values that would be returned for MIB walk operations with various TimeFilter values, done at different times. An application issues a retrieval request at time 'T', with a TimeFilter value, 'N' (typically set to a lower value, such as the value of sysUpTime at the last polling cycle). The following values would be returned in a MIB walk of fooCounts.N if T equals '0' and N equals '0': fooCounts.N.I Value ========================== fooCounts.0.1 0 fooCounts.0.2 0 Note that nothing is returned for fooCounts.0.3, since that entry does not exist at sysUpTime equals '0'. The following values would be returned in a full (traditional) MIB walk of fooCounts.N if T equals '3' and N equals '0': fooCounts.N.I Value ======================= fooCounts.0.1 0 fooCounts.0.2 0 fooCounts.0.3 0 fooCounts.1.3 0 fooCounts.2.3 0 fooCounts.3.3 0 Note that there are no instances for T equals 1 or 2 for the first two values of N, as these entries did not change since they were created at time '0'. Note that the current value for 'fooCounts.N.3' is returned here, even for values of N less than '3' (when the entry was created). The agent only considers the current existence of an entry in the TimeFilter algorithm, not the time when the entry was created. Note that the instances 'fooCounts.0.3', 'fooCounts.1.3', and 'fooCounts.2.3' are duplicates and can be suppressed by the agent in a MIB walk. The following values would be returned in a full (traditional) MIB walk of fooCounts.N if T equals '6' and N equals '3': fooCounts.N.I Value ======================= fooCounts.3.1 5 fooCounts.3.3 17 fooCounts.4.1 5 fooCounts.4.3 17 fooCounts.5.1 5 fooCounts.5.3 17 fooCounts.6.1 5 Note that no instances for entry 'fooCounts.N.2' are returned, since it has not changed since time '3'. Note that all instances except 'fooCounts.5.3' and 'fooCounts.6.1' are duplicates and can be suppressed by the agent in a MIB walk. The following values would be returned in a full (traditional) MIB walk of fooCounts.N if T equals '9' and N equals '6': fooCounts.N.I Value ======================= fooCounts.6.1 5 fooCounts.6.2 9 fooCounts.7.2 9 fooCounts.8.2 9 Note that no instances for entry 'fooCounts.N.3' are returned, since it was deleted at time '7'. Note that instances 'fooCounts.6.2' and 'fooCounts.7.2' are duplicates and can be suppressed by the agent in a MIB walk. · TimeTicks

A TimeFilter for this entry. See the TimeFilter textual convention to see how this works.

ZeroBasedCounter32This TC describes an object that counts events with the following semantics: objects of this type will be set to zero(0) on creation and will thereafter count appropriate events, wrapping back to zero(0) when the value 2^32 is reached. Provided that an application discovers the new object within the minimum time to wrap, it can use the initial value as a delta since it last polled the table of which this object is part. It is important for a management station to be aware of this minimum time and the actual time between polls, and to discard data if the actual time is too long or there is no defined minimum time. Typically, this TC is used in tables where the INDEX space is constantly changing and/or the TimeFilter mechanism is in use. · Gauge32

The number of packets of this protocol type without errors transmitted from the source address to the destination address since this entry was added to the alMatrixDSTable. Note that this is the number of link-layer packets, so if a single network-layer packet is fragmented into several link-layer frames, this counter is incremented several times.

ZeroBasedCounter32This TC describes an object that counts events with the following semantics: objects of this type will be set to zero(0) on creation and will thereafter count appropriate events, wrapping back to zero(0) when the value 2^32 is reached. Provided that an application discovers the new object within the minimum time to wrap, it can use the initial value as a delta since it last polled the table of which this object is part. It is important for a management station to be aware of this minimum time and the actual time between polls, and to discard data if the actual time is too long or there is no defined minimum time. Typically, this TC is used in tables where the INDEX space is constantly changing and/or the TimeFilter mechanism is in use. · Gauge32

The number of octets in packets of this protocol type transmitted from the source address to the destination address since this entry was added to the alMatrixDSTable (excluding framing bits, but including FCS octets), excluding octets in packets that contained errors. Note that this doesn't count just those octets in the particular protocol frames but includes the entire packet that contained the protocol.

LastCreateTimeThis TC describes an object that stores the value of the sysUpTime object at the last time its entry was created. This can be used for polling applications to determine that an entry has been deleted and re-created between polls, causing an otherwise undetectable discontinuity in the data. If sysUpTime is reset to zero as a result of a re- initialization of the network management (sub)system, then the values of all LastCreateTime objects are also reset. However, after approximately 497 days without a re- initialization, the sysUpTime object will reach 2^^32-1 and then increment to zero; in this case, existing values of TimeStamp objects do not change. This can lead to ambiguities in the value of TimeStamp objects. · TimeTicks

The value of sysUpTime when this entry was last activated. This can be used by the management station to ensure that the entry has not been deleted and recreated between polls.

Integer32 (1..65535)

An index that uniquely identifies an entry in the alMatrixTopNControlTable. Each such entry defines one topN report prepared for one interface.

Integer32 (1..65535)

The alMatrix[SD/DS] table for which a topN report will be prepared on behalf of this entry. The alMatrix[SD/DS] table is identified by the value of the hlMatrixControlIndex for that table - that value is used here to identify the particular table. This object may not be modified if the associated alMatrixTopNControlStatus object is equal to active(1).

INTEGER1 = alMatrixTopNTerminalsPkts2 = alMatrixTopNTerminalsOctets3 = alMatrixTopNAllPkts4 = alMatrixTopNAllOctets5 = alMatrixTopNTerminalsHighCapacityPkts6 = alMatrixTopNTerminalsHighCapacityOctets7 = alMatrixTopNAllHighCapacityPkts8 = alMatrixTopNAllHighCapacityOctets · Integer32

This object controls which alMatrix[SD/DS] entry that the alMatrixTopNEntries are sorted by, which view of the matrix table that will be used, as well as which table the results will be reported in. The values alMatrixTopNTerminalsPkts, alMatrixTopNTerminalsOctets, alMatrixTopNTerminalsHighCapacityPkts, and alMatrixTopNTerminalsHighCapacityOctets cause collection only from protocols that have no child protocols that are counted. The values alMatrixTopNAllPkts, alMatrixTopNAllOctets, alMatrixTopNAllHighCapacityPkts, and alMatrixTopNAllHighCapacityOctets cause collection from all alMatrix entries. This object may not be modified if the associated alMatrixTopNControlStatus object is equal to active(1).

Integer32 (0..2147483647)

The number of seconds left in the report currently being collected. When this object is modified by the management station, a new collection is started, possibly aborting a currently running report. The new value is used as the requested duration of this report and is immediately loaded into the associated alMatrixTopNControlDuration object. When the report finishes, the probe will automatically start another collection with the same initial value of alMatrixTopNControlTimeRemaining. Thus, the management station may simply read the resulting reports repeatedly, checking the startTime and duration each time to ensure that a report was not missed or that the report parameters were not changed. While the value of this object is non-zero, it decrements by one per second until it reaches zero. At the time that this object decrements to zero, the report is made accessible in the alMatrixTopNTable, overwriting any report that may be there. When this object is modified by the management station, any associated entries in the alMatrixTopNTable shall be deleted. (Note that this is a different algorithm than the one used in the hostTopNTable).

Counter32

The number of reports that have been generated by this entry.

Integer32

The number of seconds that this report has collected during the last sampling interval. When the associated alMatrixTopNControlTimeRemaining object is set, this object shall be set by the probe to the same value and shall not be modified until the next time the alMatrixTopNControlTimeRemaining is set. This value shall be zero if no reports have been requested for this alMatrixTopNControlEntry.

Integer32 (0..2147483647)

The maximum number of matrix entries requested for this report. When this object is created or modified, the probe should set alMatrixTopNControlGrantedSize as closely to this object as possible for the particular probe implementation and available resources.

Integer32 (0..2147483647)

The maximum number of matrix entries in this report. When the associated alMatrixTopNControlRequestedSize object is created or modified, the probe should set this object as closely to the requested value as possible for the particular implementation and available resources. The probe must not lower this value except as a side-effect of a set to the associated alMatrixTopNControlRequestedSize object. If the value of alMatrixTopNControlRateBase is equal to alMatrixTopNTerminalsPkts or alMatrixTopNAllPkts, when the next topN report is generated, matrix entries with the highest value of alMatrixTopNPktRate shall be placed in this table in decreasing order of this rate until there is no more room or until there are no more matrix entries. If the value of alMatrixTopNControlRateBase is equal to alMatrixTopNTerminalsOctets or alMatrixTopNAllOctets, when the next topN report is generated, matrix entries with the highest value of alMatrixTopNOctetRate shall be placed in this table in decreasing order of this rate until there is no more room or until there are no more matrix entries. It is an implementation-specific matter how entries with the same value of alMatrixTopNPktRate or alMatrixTopNOctetRate are sorted. It is also an implementation-specific matter as to whether zero-valued entries are available.

TimeStampThe value of the sysUpTime object at which a specific occurrence happened. The specific occurrence must be defined in the description of any object defined using this type. If sysUpTime is reset to zero as a result of a re- initialization of the network management (sub)system, then the values of all TimeStamp objects are also reset. However, after approximately 497 days without a re- initialization, the sysUpTime object will reach 2^^32-1 and then increment around to zero; in this case, existing values of TimeStamp objects do not change. This can lead to ambiguities in the value of TimeStamp objects. · TimeTicks

The value of sysUpTime when this topN report was last started. In other words, this is the time that the associated alMatrixTopNControlTimeRemaining object was modified to start the requested report or the time the report was last automatically (re)started. This object may be used by the management station to determine whether a report was missed.

OwnerStringThis data type is used to model an administratively assigned name of the owner of a resource. Implementations must accept values composed of well-formed NVT ASCII sequences. In addition, implementations should accept values composed of well-formed UTF-8 sequences. It is suggested that this name contain one or more of the following: IP address, management station name, network manager's name, location, or phone number. In some cases the agent itself will be the owner of an entry. In these cases, this string shall be set to a string starting with 'monitor'. SNMP access control is articulated entirely in terms of the contents of MIB views; access to a particular SNMP object instance depends only upon its presence or absence in a particular MIB view and never upon its value or the value of related object instances. Thus, objects of this type afford resolution of resource contention only among cooperating managers; they realize no access control function with respect to uncooperative parties. SIZE (0..127) · OCTET STRING

The entity that configured this entry and is therefore using the resources assigned to it.

RowStatus1 = active2 = notInService3 = notReady4 = createAndGo5 = createAndWait6 = destroyThe RowStatus textual convention is used to manage the creation and deletion of conceptual rows, and is used as the value of the SYNTAX clause for the status column of a conceptual row (as described in Section 7.7.1 of [2].) 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); 'notInService' has no implication regarding the internal consistency of the row, availability of resources, or consistency with the current state of the managed device; - `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 (i.e., one or more required columns in the conceptual row have not been instanciated); - `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 attempt 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 status column having a SYNTAX clause value 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) goto 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, and all columns have acceptable values, then return noError and goto D. (3) if other variable bindings included in the same PDU, provide legal 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 notInService (e.g., an agent which 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. (8) the transition to D can fail, e.g., if the values of the conceptual row are inconsistent, then the error code would be inconsistentValue. NOTE: Other processing of (this and other varbinds 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. A MIB designer should choose between the two latter algorithms based on the size of the table (and therefore the efficiency of each algorithm). For tables in which a large number of entries are expected, it is recommended that a MIB object be defined that returns an acceptable index for creation. For tables with small numbers of entries, it is recommended that the latter pseudo-random index mechanism be used. Interaction 2: Creating the Conceptual Row Once an unused instance-identifier has been selected, the management station determines if it wishes to create and activate the conceptual row in one transaction or in a negotiated set of interactions. Interaction 2a: Creating and Activating the Conceptual Row The management station must first determine the column requirements, i.e., it must determine those columns for which it must or must not provide values. Depending on the complexity of the table and the management station's knowledge of the agent's capabilities, this determination can be made locally by the management station. Alternately, the management station issues a management protocol get operation to examine all columns in the conceptual row that it wishes to create. In response, for each column, there are three possible outcomes: - a value is returned, indicating that some other management station has already created this conceptual row. We return to interaction 1. - the exception `noSuchInstance' is returned, indicating that the agent implements the object-type associated with this column, and that this column in at least one conceptual row would be accessible in the MIB view used by the retrieval were it to exist. For those columns to which the agent provides read-create access, the `noSuchInstance' exception tells the management station that it should supply a value for this column when the conceptual row is to be created. - the exception `noSuchObject' is returned, indicating that the agent does not implement the object-type associated with this column or that there is no conceptual row for which this column would be accessible in the MIB view used by the retrieval. As such, the management station can not issue any management protocol set operations to create an instance of this column. Once the column requirements have been determined, a management protocol set operation is accordingly issued. This operation also sets the new instance of the status column to `createAndGo'. When the agent processes the set operation, it verifies that it has sufficient information to make the conceptual row available for use by the managed device. The information available to the agent is provided by two sources: the management protocol set operation which creates the conceptual row, and, implementation-specific defaults supplied by the agent (note that an agent must provide implementation-specific defaults for at least those objects which it implements as read-only). If there is sufficient information available, then the conceptual row is created, a `noError' response is returned, the status column is set to `active', and no further interactions are necessary (i.e., interactions 3 and 4 are skipped). If there is insufficient information, then the conceptual row is not created, and the set operation fails with an error of `inconsistentValue'. On this error, the management station can issue a management protocol retrieval operation to determine if this was because it failed to specify a value for a required column, or, because the selected instance of the status column already existed. In the latter case, we return to interaction 1. In the former case, the management station can re-issue the set operation with the additional information, or begin interaction 2 again using `createAndWait' in order to negotiate creation of the conceptual row. NOTE WELL Regardless of the method used to determine the column requirements, it is possible that the management station might deem a column necessary when, in fact, the agent will not allow that particular columnar instance to be created or written. In this case, the management protocol set operation will fail with an error such as `noCreation' or `notWritable'. In this case, the management station decides whether it needs to be able to set a value for that particular columnar instance. If not, the management station re-issues the management protocol set operation, but without setting a value for that particular columnar instance; otherwise, the management station aborts the row creation algorithm. Interaction 2b: Negotiating the Creation of the Conceptual Row The management station issues a management protocol set operation which sets the desired instance of the status column to `createAndWait'. If the agent is unwilling to process a request of this sort, the set operation fails with an error of `wrongValue'. (As a consequence, such an agent must be prepared to accept a single management protocol set operation, i.e., interaction 2a above, containing all of the columns indicated by its column requirements.) Otherwise, the conceptual row is created, a `noError' response is returned, and the status column is immediately set to either `notInService' or `notReady', depending on whether it has sufficient information to (attempt to) make the conceptual row available for use by the managed device. If there is sufficient information available, then the status column is set to `notInService'; otherwise, if there is insufficient information, then the status column is set to `notReady'. Regardless, we proceed to interaction 3. Interaction 3: Initializing non-defaulted Objects The management station must now determine the column requirements. It issues a management protocol get operation to examine all columns in the created conceptual row. In the response, for each column, there are three possible outcomes: - a value is returned, indicating that the agent implements the object-type associated with this column and had sufficient information to provide a value. For those columns to which the agent provides read-create access (and for which the agent allows their values to be changed after their creation), a value return tells the management station that it may issue additional management protocol set operations, if it desires, in order to change the value associated with this column. - the exception `noSuchInstance' is returned, indicating that the agent implements the object-type associated with this column, and that this column in at least one conceptual row would be accessible in the MIB view used by the retrieval were it to exist. However, the agent does not have sufficient information to provide a value, and until a value is provided, the conceptual row may not be made available for use by the managed device. For those columns to which the agent provides read-create access, the `noSuchInstance' exception tells the management station that it must issue additional management protocol set operations, in order to provide a value associated with this column. - the exception `noSuchObject' is returned, indicating that the agent does not implement the object-type associated with this column or that there is no conceptual row for which this column would be accessible in the MIB view used by the retrieval. As such, the management station can not issue any management protocol set operations to create an instance of this column. If the value associated with the status column is `notReady', then the management station must first deal with all `noSuchInstance' columns, if any. Having done so, the value of the status column becomes `notInService', and we proceed to interaction 4. Interaction 4: Making the Conceptual Row Available Once the management station is satisfied with the values associated with the columns of the conceptual row, it issues a management protocol set operation to set the status column to `active'. If the agent has sufficient information to make the conceptual row available for use by the managed device, the management protocol set operation succeeds (a `noError' response is returned). Otherwise, the management protocol set operation fails with an error of `inconsistentValue'. NOTE WELL A conceptual row having a status column with value `notInService' or `notReady' is unavailable to the managed device. As such, it is possible for the managed device to create its own instances during the time between the management protocol set operation which sets the status column to `createAndWait' and the management protocol set operation which sets the status column to `active'. In this case, when the management protocol set operation is issued to set the status column to `active', the values held in the agent supersede those used by the managed device. If the management station is prevented from setting the status column to `active' (e.g., due to management station or network failure) the conceptual row will be left in the `notInService' or `notReady' state, consuming resources indefinitely. The agent must detect conceptual rows that have been in either state for an abnormally long period of time and remove them. It is the responsibility of the DESCRIPTION clause of the status column to indicate what an abnormally long period of time would be. This period of time should be long enough to allow for human response time (including `think time') between the creation of the conceptual row and the setting of the status to `active'. In the absence of such information in the DESCRIPTION clause, it is suggested that this period be approximately 5 minutes in length. This removal action applies not only to newly-created rows, but also to previously active rows which are set to, and left in, the notInService state for a prolonged period exceeding that which is considered normal for such a conceptual row. Conceptual Row Suspension When a conceptual row is `active', the management station may issue a management protocol set operation which sets the instance of the status column to `notInService'. If the agent is unwilling to do so, the set operation fails with an error of `wrongValue' or `inconsistentValue'. Otherwise, the conceptual row is taken out of service, and a `noError' response is returned. It is the responsibility of the DESCRIPTION clause of the status column to indicate under what circumstances the status column should be taken out of service (e.g., in order for the value of some other column of the same conceptual row to be modified). Conceptual Row Deletion For deletion of conceptual rows, a management protocol set operation is issued which sets the instance of the status column to `destroy'. This request may be made regardless of the current value of the status column (e.g., it is possible to delete conceptual rows which are either `notReady', `notInService' or `active'.) If the operation succeeds, then all instances associated with the conceptual row are immediately removed. · Integer32

The status of this alMatrixTopNControlEntry. An entry may not exist in the active state unless all objects in the entry have an appropriate value. If this object is not equal to active(1), all associated entries in the alMatrixTopNTable shall be deleted by the agent.

Integer32 (1..65535)

An index that uniquely identifies an entry in the alMatrixTopNTable among those in the same report. This index is between 1 and N, where N is the number of entries in this report. If the value of alMatrixTopNControlRateBase is equal to alMatrixTopNTerminalsPkts or alMatrixTopNAllPkts, increasing values of alMatrixTopNIndex shall be assigned to entries with decreasing values of alMatrixTopNPktRate until index N is assigned or there are no more alMatrixTopNEntries. If the value of alMatrixTopNControlRateBase is equal to alMatrixTopNTerminalsOctets or alMatrixTopNAllOctets, increasing values of alMatrixTopNIndex shall be assigned to entries with decreasing values of alMatrixTopNOctetRate until index N is assigned or there are no more alMatrixTopNEntries.

Integer32 (1..2147483647)

The protocolDirLocalIndex of the network-layer protocol of this entry's network address.

OCTET STRING SIZE (1..255)

The network-layer address of the source host in this conversation. This is represented as an octet string with specific semantics and length as identified by the associated alMatrixTopNProtocolDirLocalIndex. For example, if the alMatrixTopNProtocolDirLocalIndex indicates an encapsulation of IP, this object is encoded as a length octet of 4, followed by the 4 octets of the IP address, in network byte order.

OCTET STRING SIZE (1..255)

The network-layer address of the destination host in this conversation. This is represented as an octet string with specific semantics and length as identified by the associated alMatrixTopNProtocolDirLocalIndex. For example, if the alMatrixTopNProtocolDirLocalIndex indicates an encapsulation of IP, this object is encoded as a length octet of 4, followed by the 4 octets of the IP address, in network byte order.

Integer32 (1..2147483647)

The type of the protocol counted by this matrix entry.

Gauge32

The number of packets seen of this protocol from the source host to the destination host during this sampling interval, counted using the rules for counting the alMatrixSDPkts object. If the value of alMatrixTopNControlRateBase is alMatrixTopNTerminalsPkts or alMatrixTopNAllPkts, this variable will be used to sort this report.

Gauge32

The number of packets seen of this protocol from the destination host to the source host during this sampling interval, counted using the rules for counting the alMatrixDSPkts object. (Note that the corresponding alMatrixSDPkts object selected is the one whose source address is equal to alMatrixTopNDestAddress and whose destination address is equal to alMatrixTopNSourceAddress.) Note that if the value of alMatrixTopNControlRateBase is equal to alMatrixTopNTerminalsPkts or alMatrixTopNAllPkts, the sort of topN entries is based entirely on alMatrixTopNPktRate, and not on the value of this object.

Gauge32

The number of octets seen of this protocol from the source host to the destination host during this sampling interval, counted using the rules for counting the alMatrixSDOctets object. If the value of alMatrixTopNControlRateBase is alMatrixTopNTerminalsOctets or alMatrixTopNAllOctets, this variable will be used to sort this report.

Gauge32

The number of octets seen of this protocol from the destination host to the source host during this sampling interval, counted using the rules for counting the alMatrixDSOctets object. (Note that the corresponding alMatrixSDOctets object selected is the one whose source address is equal to alMatrixTopNDestAddress and whose destination address is equal to alMatrixTopNSourceAddress.) Note that if the value of alMatrixTopNControlRateBase is equal to alMatrixTopNTerminalsOctets or alMatrixTopNAllOctets, the sort of topN entries is based entirely on alMatrixTopNOctetRate, and not on the value of this object.

Integer32 (1..65535)

An index that uniquely identifies an entry in the usrHistoryControlTable. Each such entry defines a set of samples at a particular interval for a specified set of MIB instances available from the managed system.

Integer32 (1..65535)

The number of MIB objects to be collected in the portion of usrHistoryTable associated with this usrHistoryControlEntry. This object may not be modified if the associated instance of usrHistoryControlStatus is equal to active(1).

Integer32 (1..65535)

The requested number of discrete time intervals over which data is to be saved in the part of the usrHistoryTable associated with this usrHistoryControlEntry. When this object is created or modified, the probe should set usrHistoryControlBucketsGranted as closely to this object as possible for the particular probe implementation and available resources.

Integer32 (1..65535)

The number of discrete sampling intervals over which data shall be saved in the part of the usrHistoryTable associated with this usrHistoryControlEntry. When the associated usrHistoryControlBucketsRequested object is created or modified, the probe should set this object as closely to the requested value as possible for the particular probe implementation and available resources. The probe must not lower this value except as a result of a modification to the associated usrHistoryControlBucketsRequested object. The associated usrHistoryControlBucketsRequested object should be set before or at the same time as this object to allow the probe to accurately estimate the resources required for this usrHistoryControlEntry. There will be times when the actual number of buckets associated with this entry is less than the value of this object. In this case, at the end of each sampling interval, a new bucket will be added to the usrHistoryTable. When the number of buckets reaches the value of this object and a new bucket is to be added to the usrHistoryTable, the oldest bucket associated with this usrHistoryControlEntry shall be deleted by the agent so that the new bucket can be added. When the value of this object changes to a value less than the current value, entries are deleted from the usrHistoryTable associated with this usrHistoryControlEntry. Enough of the oldest of these entries shall be deleted by the agent so that their number remains less than or equal to the new value of this object. When the value of this object changes to a value greater than the current value, the number of associated usrHistory entries may be allowed to grow.

Integer32 (1..2147483647)

The interval in seconds over which the data is sampled for each bucket in the part of the usrHistory table associated with this usrHistoryControlEntry. Because the counters in a bucket may overflow at their maximum value with no indication, a prudent manager will take into account the possibility of overflow in any of the associated counters. It is important to consider the minimum time in which any counter could overflow on a particular media type and to set the usrHistoryControlInterval object to a value less than this interval. This object may not be modified if the associated usrHistoryControlStatus object is equal to active(1).

OwnerStringThis data type is used to model an administratively assigned name of the owner of a resource. Implementations must accept values composed of well-formed NVT ASCII sequences. In addition, implementations should accept values composed of well-formed UTF-8 sequences. It is suggested that this name contain one or more of the following: IP address, management station name, network manager's name, location, or phone number. In some cases the agent itself will be the owner of an entry. In these cases, this string shall be set to a string starting with 'monitor'. SNMP access control is articulated entirely in terms of the contents of MIB views; access to a particular SNMP object instance depends only upon its presence or absence in a particular MIB view and never upon its value or the value of related object instances. Thus, objects of this type afford resolution of resource contention only among cooperating managers; they realize no access control function with respect to uncooperative parties. SIZE (0..127) · OCTET STRING

The entity that configured this entry and is therefore using the resources assigned to it.

RowStatus1 = active2 = notInService3 = notReady4 = createAndGo5 = createAndWait6 = destroyThe RowStatus textual convention is used to manage the creation and deletion of conceptual rows, and is used as the value of the SYNTAX clause for the status column of a conceptual row (as described in Section 7.7.1 of [2].) 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); 'notInService' has no implication regarding the internal consistency of the row, availability of resources, or consistency with the current state of the managed device; - `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 (i.e., one or more required columns in the conceptual row have not been instanciated); - `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 attempt 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 status column having a SYNTAX clause value 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) goto 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, and all columns have acceptable values, then return noError and goto D. (3) if other variable bindings included in the same PDU, provide legal 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 notInService (e.g., an agent which 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. (8) the transition to D can fail, e.g., if the values of the conceptual row are inconsistent, then the error code would be inconsistentValue. NOTE: Other processing of (this and other varbinds 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. A MIB designer should choose between the two latter algorithms based on the size of the table (and therefore the efficiency of each algorithm). For tables in which a large number of entries are expected, it is recommended that a MIB object be defined that returns an acceptable index for creation. For tables with small numbers of entries, it is recommended that the latter pseudo-random index mechanism be used. Interaction 2: Creating the Conceptual Row Once an unused instance-identifier has been selected, the management station determines if it wishes to create and activate the conceptual row in one transaction or in a negotiated set of interactions. Interaction 2a: Creating and Activating the Conceptual Row The management station must first determine the column requirements, i.e., it must determine those columns for which it must or must not provide values. Depending on the complexity of the table and the management station's knowledge of the agent's capabilities, this determination can be made locally by the management station. Alternately, the management station issues a management protocol get operation to examine all columns in the conceptual row that it wishes to create. In response, for each column, there are three possible outcomes: - a value is returned, indicating that some other management station has already created this conceptual row. We return to interaction 1. - the exception `noSuchInstance' is returned, indicating that the agent implements the object-type associated with this column, and that this column in at least one conceptual row would be accessible in the MIB view used by the retrieval were it to exist. For those columns to which the agent provides read-create access, the `noSuchInstance' exception tells the management station that it should supply a value for this column when the conceptual row is to be created. - the exception `noSuchObject' is returned, indicating that the agent does not implement the object-type associated with this column or that there is no conceptual row for which this column would be accessible in the MIB view used by the retrieval. As such, the management station can not issue any management protocol set operations to create an instance of this column. Once the column requirements have been determined, a management protocol set operation is accordingly issued. This operation also sets the new instance of the status column to `createAndGo'. When the agent processes the set operation, it verifies that it has sufficient information to make the conceptual row available for use by the managed device. The information available to the agent is provided by two sources: the management protocol set operation which creates the conceptual row, and, implementation-specific defaults supplied by the agent (note that an agent must provide implementation-specific defaults for at least those objects which it implements as read-only). If there is sufficient information available, then the conceptual row is created, a `noError' response is returned, the status column is set to `active', and no further interactions are necessary (i.e., interactions 3 and 4 are skipped). If there is insufficient information, then the conceptual row is not created, and the set operation fails with an error of `inconsistentValue'. On this error, the management station can issue a management protocol retrieval operation to determine if this was because it failed to specify a value for a required column, or, because the selected instance of the status column already existed. In the latter case, we return to interaction 1. In the former case, the management station can re-issue the set operation with the additional information, or begin interaction 2 again using `createAndWait' in order to negotiate creation of the conceptual row. NOTE WELL Regardless of the method used to determine the column requirements, it is possible that the management station might deem a column necessary when, in fact, the agent will not allow that particular columnar instance to be created or written. In this case, the management protocol set operation will fail with an error such as `noCreation' or `notWritable'. In this case, the management station decides whether it needs to be able to set a value for that particular columnar instance. If not, the management station re-issues the management protocol set operation, but without setting a value for that particular columnar instance; otherwise, the management station aborts the row creation algorithm. Interaction 2b: Negotiating the Creation of the Conceptual Row The management station issues a management protocol set operation which sets the desired instance of the status column to `createAndWait'. If the agent is unwilling to process a request of this sort, the set operation fails with an error of `wrongValue'. (As a consequence, such an agent must be prepared to accept a single management protocol set operation, i.e., interaction 2a above, containing all of the columns indicated by its column requirements.) Otherwise, the conceptual row is created, a `noError' response is returned, and the status column is immediately set to either `notInService' or `notReady', depending on whether it has sufficient information to (attempt to) make the conceptual row available for use by the managed device. If there is sufficient information available, then the status column is set to `notInService'; otherwise, if there is insufficient information, then the status column is set to `notReady'. Regardless, we proceed to interaction 3. Interaction 3: Initializing non-defaulted Objects The management station must now determine the column requirements. It issues a management protocol get operation to examine all columns in the created conceptual row. In the response, for each column, there are three possible outcomes: - a value is returned, indicating that the agent implements the object-type associated with this column and had sufficient information to provide a value. For those columns to which the agent provides read-create access (and for which the agent allows their values to be changed after their creation), a value return tells the management station that it may issue additional management protocol set operations, if it desires, in order to change the value associated with this column. - the exception `noSuchInstance' is returned, indicating that the agent implements the object-type associated with this column, and that this column in at least one conceptual row would be accessible in the MIB view used by the retrieval were it to exist. However, the agent does not have sufficient information to provide a value, and until a value is provided, the conceptual row may not be made available for use by the managed device. For those columns to which the agent provides read-create access, the `noSuchInstance' exception tells the management station that it must issue additional management protocol set operations, in order to provide a value associated with this column. - the exception `noSuchObject' is returned, indicating that the agent does not implement the object-type associated with this column or that there is no conceptual row for which this column would be accessible in the MIB view used by the retrieval. As such, the management station can not issue any management protocol set operations to create an instance of this column. If the value associated with the status column is `notReady', then the management station must first deal with all `noSuchInstance' columns, if any. Having done so, the value of the status column becomes `notInService', and we proceed to interaction 4. Interaction 4: Making the Conceptual Row Available Once the management station is satisfied with the values associated with the columns of the conceptual row, it issues a management protocol set operation to set the status column to `active'. If the agent has sufficient information to make the conceptual row available for use by the managed device, the management protocol set operation succeeds (a `noError' response is returned). Otherwise, the management protocol set operation fails with an error of `inconsistentValue'. NOTE WELL A conceptual row having a status column with value `notInService' or `notReady' is unavailable to the managed device. As such, it is possible for the managed device to create its own instances during the time between the management protocol set operation which sets the status column to `createAndWait' and the management protocol set operation which sets the status column to `active'. In this case, when the management protocol set operation is issued to set the status column to `active', the values held in the agent supersede those used by the managed device. If the management station is prevented from setting the status column to `active' (e.g., due to management station or network failure) the conceptual row will be left in the `notInService' or `notReady' state, consuming resources indefinitely. The agent must detect conceptual rows that have been in either state for an abnormally long period of time and remove them. It is the responsibility of the DESCRIPTION clause of the status column to indicate what an abnormally long period of time would be. This period of time should be long enough to allow for human response time (including `think time') between the creation of the conceptual row and the setting of the status to `active'. In the absence of such information in the DESCRIPTION clause, it is suggested that this period be approximately 5 minutes in length. This removal action applies not only to newly-created rows, but also to previously active rows which are set to, and left in, the notInService state for a prolonged period exceeding that which is considered normal for such a conceptual row. Conceptual Row Suspension When a conceptual row is `active', the management station may issue a management protocol set operation which sets the instance of the status column to `notInService'. If the agent is unwilling to do so, the set operation fails with an error of `wrongValue' or `inconsistentValue'. Otherwise, the conceptual row is taken out of service, and a `noError' response is returned. It is the responsibility of the DESCRIPTION clause of the status column to indicate under what circumstances the status column should be taken out of service (e.g., in order for the value of some other column of the same conceptual row to be modified). Conceptual Row Deletion For deletion of conceptual rows, a management protocol set operation is issued which sets the instance of the status column to `destroy'. This request may be made regardless of the current value of the status column (e.g., it is possible to delete conceptual rows which are either `notReady', `notInService' or `active'.) If the operation succeeds, then all instances associated with the conceptual row are immediately removed. · Integer32

The status of this variable history control entry. An entry may not exist in the active state unless all objects in the entry have an appropriate value. If this object is not equal to active(1), all associated entries in the usrHistoryTable shall be deleted.

Integer32 (1..65535)

An index used to uniquely identify an entry in the usrHistoryObject table. Each such entry defines a MIB instance to be collected periodically.

OBJECT IDENTIFIER

The object identifier of the particular variable to be sampled. Only variables that resolve to an ASN.1 primitive type of Integer32 (Integer32, Counter, Gauge, or TimeTicks) may be sampled. Because SNMP access control is articulated entirely in terms of the contents of MIB views, no access control mechanism exists that can restrict the value of this object to identify only those objects that exist in a particular MIB view. Because there is thus no acceptable means of restricting the read access that could be obtained through the user history mechanism, the probe must only grant write access to this object in those views that have read access to all objects on the probe. See USM [RFC3414] and VACM [RFC3415] for more information. During a set operation, if the supplied variable name is not available in the selected MIB view, a badValue error must be returned. This object may not be modified if the associated usrHistoryControlStatus object is equal to active(1).

INTEGER1 = absoluteValue2 = deltaValue · Integer32

The method of sampling the selected variable for storage in the usrHistoryTable. If the value of this object is absoluteValue(1), the value of the selected variable will be copied directly into the history bucket. If the value of this object is deltaValue(2), the value of the selected variable at the last sample will be subtracted from the current value, and the difference will be stored in the history bucket. If the associated usrHistoryObjectVariable instance could not be obtained at the previous sample interval, then a delta sample is not possible, and the value of the associated usrHistoryValStatus object for this interval will be valueNotAvailable(1). This object may not be modified if the associated usrHistoryControlStatus object is equal to active(1).

Integer32 (1..2147483647)

An index that uniquely identifies the particular sample this entry represents among all samples associated with the same usrHistoryControlEntry. This index starts at 1 and increases by one as each new sample is taken.

TimeStampThe value of the sysUpTime object at which a specific occurrence happened. The specific occurrence must be defined in the description of any object defined using this type. If sysUpTime is reset to zero as a result of a re- initialization of the network management (sub)system, then the values of all TimeStamp objects are also reset. However, after approximately 497 days without a re- initialization, the sysUpTime object will reach 2^^32-1 and then increment around to zero; in this case, existing values of TimeStamp objects do not change. This can lead to ambiguities in the value of TimeStamp objects. · TimeTicks

The value of sysUpTime at the start of the interval over which this sample was measured. If the probe keeps track of the time of day, it should start the first sample of the history at a time such that when the next hour of the day begins, a sample is started at that instant. Note that following this rule may require that the probe delay collecting the first sample of the history, as each sample must be of the same interval. Also note that the sample that is currently being collected is not accessible in this table until the end of its interval.

TimeStampThe value of the sysUpTime object at which a specific occurrence happened. The specific occurrence must be defined in the description of any object defined using this type. If sysUpTime is reset to zero as a result of a re- initialization of the network management (sub)system, then the values of all TimeStamp objects are also reset. However, after approximately 497 days without a re- initialization, the sysUpTime object will reach 2^^32-1 and then increment around to zero; in this case, existing values of TimeStamp objects do not change. This can lead to ambiguities in the value of TimeStamp objects. · TimeTicks

The value of sysUpTime at the end of the interval over which this sample was measured.

Gauge32

The absolute value (i.e., unsigned value) of the user-specified statistic during the last sampling period. The value during the current sampling period is not made available until the period is completed. To obtain the true value for this sampling interval, the associated instance of usrHistoryValStatus must be checked, and usrHistoryAbsValue adjusted as necessary. If the MIB instance could not be accessed during the sampling interval, then this object will have a value of zero, and the associated instance of usrHistoryValStatus will be set to 'valueNotAvailable(1)'. The access control check prescribed in the definition of usrHistoryObjectVariable SHOULD be checked for each sampling interval. If this check determines that access should not be allowed, then this object will have a value of zero, and the associated instance of usrHistoryValStatus will be set to 'valueNotAvailable(1)'.

INTEGER1 = valueNotAvailable2 = valuePositive3 = valueNegative · Integer32

This object indicates the validity and sign of the data in the associated instance of usrHistoryAbsValue. If the MIB instance could not be accessed during the sampling interval, then 'valueNotAvailable(1)' will be returned. If the sample is valid and the actual value of the sample is greater than or equal to zero, then 'valuePositive(2)' is returned. If the sample is valid and the actual value of the sample is less than zero, 'valueNegative(3)' will be returned. The associated instance of usrHistoryAbsValue should be multiplied by -1 to obtain the true sample value.

INTEGER1 = direct2 = modem · Integer32

The type of incoming connection to be expected on this serial interface.

INTEGER1 = other2 = slip3 = ppp · Integer32

The type of data link encapsulation to be used on this serial interface.

Integer32 (1..65535)

This timeout value is used when the Management Station has initiated the conversation over the serial link. This variable represents the number of seconds of inactivity allowed before terminating the connection on this serial interface. Use the serialDialoutTimeout in the case where the probe has initiated the connection for the purpose of sending a trap.

ControlStringThis data type is used to communicate with a modem or a serial data switch. A ControlString contains embedded commands to control how the device will interact with the remote device through the serial interface. Commands are represented as two-character sequences beginning with the '^' character. The following commands are recognized by the device (note that command characters are case sensitive): ^s Send string that follows, which is terminated by the next command or the end of string. ^c Delay for the number of seconds that follows. Toss out any data received rather than store it in a buffer for parsing. ^t Set timeout to the value represented by the decimal digits that follow. The default timeout is 20 seconds. Note that this timeout may be overridden by a smaller serialTimeout configured for the associated serial interface (see serialConfigTable). ^w Wait for the reply string that follows, which is terminated by the next command or the end of string. Partial and case-insensitive matching is applied, i.e., if the reply string (any case combination) is found anywhere in the received string, then the a match is found. If the current timeout elapses without a match, then the remaining control string is ignored. ^! The ^ character. ^d Delay the number of seconds specified by the decimal digits that follow. ^b Send break for the number of milliseconds specified by the decimal digits that follow. If no digits follow, break will be enforced for 250 milliseconds by default. The following ASCII control characters may be inserted into the '^s' send string or the '^w' reply string: ^@ 0x00 ^A 0x01 .. ^M 0x0D .. ^Z 0x1A ^[ 0x1B ^ 0x1C ^] 0x1D ^^ 0x1E ^_ 0x1F Binary data may also be inserted into the data stream. The control sequence for each byte of binary data is ^0x##, where ## is the hexadecimal representation of the data byte. Two ASCII characters (0-9, a-f, A-F) must follow the '^0x' control prefix. For example, '^0x0D^0x0A' is interpreted as a carriage return followed by a line feed. SIZE (0..255) · OCTET STRING

A control string that controls how a modem attached to this serial interface should be initialized. The initialization is performed once during startup and again after each connection is terminated if the associated serialMode has the value of modem(2). A control string that is appropriate for a wide variety of modems is: '^s^MATE0Q0V1X4 S0=1 S2=43^M'.

ControlStringThis data type is used to communicate with a modem or a serial data switch. A ControlString contains embedded commands to control how the device will interact with the remote device through the serial interface. Commands are represented as two-character sequences beginning with the '^' character. The following commands are recognized by the device (note that command characters are case sensitive): ^s Send string that follows, which is terminated by the next command or the end of string. ^c Delay for the number of seconds that follows. Toss out any data received rather than store it in a buffer for parsing. ^t Set timeout to the value represented by the decimal digits that follow. The default timeout is 20 seconds. Note that this timeout may be overridden by a smaller serialTimeout configured for the associated serial interface (see serialConfigTable). ^w Wait for the reply string that follows, which is terminated by the next command or the end of string. Partial and case-insensitive matching is applied, i.e., if the reply string (any case combination) is found anywhere in the received string, then the a match is found. If the current timeout elapses without a match, then the remaining control string is ignored. ^! The ^ character. ^d Delay the number of seconds specified by the decimal digits that follow. ^b Send break for the number of milliseconds specified by the decimal digits that follow. If no digits follow, break will be enforced for 250 milliseconds by default. The following ASCII control characters may be inserted into the '^s' send string or the '^w' reply string: ^@ 0x00 ^A 0x01 .. ^M 0x0D .. ^Z 0x1A ^[ 0x1B ^ 0x1C ^] 0x1D ^^ 0x1E ^_ 0x1F Binary data may also be inserted into the data stream. The control sequence for each byte of binary data is ^0x##, where ## is the hexadecimal representation of the data byte. Two ASCII characters (0-9, a-f, A-F) must follow the '^0x' control prefix. For example, '^0x0D^0x0A' is interpreted as a carriage return followed by a line feed. SIZE (0..255) · OCTET STRING

A control string that specifies how to disconnect a modem connection on this serial interface. This object is only meaningful if the associated serialMode has the value of modem(2). A control string that is appropriate for a wide variety of modems is: '^d2^s+++^d2^sATH0^M^d2'.

DisplayStringRepresents textual information taken from the NVT ASCII character set, as defined in pages 4, 10-11 of RFC 854. To summarize RFC 854, the NVT ASCII repertoire specifies: - the use of character codes 0-127 (decimal) - the graphics characters (32-126) are interpreted as US ASCII - NUL, LF, CR, BEL, BS, HT, VT and FF have the special meanings specified in RFC 854 - the other 25 codes have no standard interpretation - the sequence 'CR LF' means newline - the sequence 'CR NUL' means carriage-return - an 'LF' not preceded by a 'CR' means moving to the same column on the next line. - the sequence 'CR x' for any x other than LF or NUL is illegal. (Note that this also means that a string may end with either 'CR LF' or 'CR NUL', but not with CR.) Any object defined using this syntax may not exceed 255 characters in length. SIZE (0..255) · OCTET STRING · hint 255a

An ASCII string containing substrings that describe the expected modem connection response code and associated bps rate. The substrings are delimited by the first character in the string, for example: /CONNECT/300/CONNECT 1200/1200/CONNECT 2400/2400/ CONNECT 4800/4800/CONNECT 9600/9600 will be interpreted as: response code bps rate CONNECT 300 CONNECT 1200 1200 CONNECT 2400 2400 CONNECT 4800 4800 CONNECT 9600 9600 The agent will use the information in this string to adjust the bps rate of this serial interface once a modem connection is established. A value that is appropriate for a wide variety of modems is: '/CONNECT/300/CONNECT 1200/1200/CONNECT 2400/2400/ CONNECT 4800/4800/CONNECT 9600/9600/CONNECT 14400/14400/ CONNECT 19200/19200/CONNECT 38400/38400/'.

DisplayStringRepresents textual information taken from the NVT ASCII character set, as defined in pages 4, 10-11 of RFC 854. To summarize RFC 854, the NVT ASCII repertoire specifies: - the use of character codes 0-127 (decimal) - the graphics characters (32-126) are interpreted as US ASCII - NUL, LF, CR, BEL, BS, HT, VT and FF have the special meanings specified in RFC 854 - the other 25 codes have no standard interpretation - the sequence 'CR LF' means newline - the sequence 'CR NUL' means carriage-return - an 'LF' not preceded by a 'CR' means moving to the same column on the next line. - the sequence 'CR x' for any x other than LF or NUL is illegal. (Note that this also means that a string may end with either 'CR LF' or 'CR NUL', but not with CR.) Any object defined using this syntax may not exceed 255 characters in length. SIZE (0..255) · OCTET STRING · hint 255a

An ASCII string containing response codes that may be generated by a modem to report the reason why a connection attempt has failed. The response codes are delimited by the first character in the string, for example: /NO CARRIER/BUSY/NO DIALTONE/NO ANSWER/ERROR/ If one of these response codes is received via this serial interface while attempting to make a modem connection, the agent will issue the hang up command as specified by serialModemHangUpString. A value that is appropriate for a wide variety of modems is: '/NO CARRIER/BUSY/NO DIALTONE/NO ANSWER/ERROR/'.

Integer32 (1..65535)

This timeout value is used when the probe initiates the serial connection with the intention of contacting a management station. This variable represents the number of seconds of inactivity allowed before terminating the connection on this serial interface.

RowStatus1 = active2 = notInService3 = notReady4 = createAndGo5 = createAndWait6 = destroyThe RowStatus textual convention is used to manage the creation and deletion of conceptual rows, and is used as the value of the SYNTAX clause for the status column of a conceptual row (as described in Section 7.7.1 of [2].) 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); 'notInService' has no implication regarding the internal consistency of the row, availability of resources, or consistency with the current state of the managed device; - `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 (i.e., one or more required columns in the conceptual row have not been instanciated); - `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 attempt 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 status column having a SYNTAX clause value 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) goto 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, and all columns have acceptable values, then return noError and goto D. (3) if other variable bindings included in the same PDU, provide legal 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 notInService (e.g., an agent which 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. (8) the transition to D can fail, e.g., if the values of the conceptual row are inconsistent, then the error code would be inconsistentValue. NOTE: Other processing of (this and other varbinds 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. A MIB designer should choose between the two latter algorithms based on the size of the table (and therefore the efficiency of each algorithm). For tables in which a large number of entries are expected, it is recommended that a MIB object be defined that returns an acceptable index for creation. For tables with small numbers of entries, it is recommended that the latter pseudo-random index mechanism be used. Interaction 2: Creating the Conceptual Row Once an unused instance-identifier has been selected, the management station determines if it wishes to create and activate the conceptual row in one transaction or in a negotiated set of interactions. Interaction 2a: Creating and Activating the Conceptual Row The management station must first determine the column requirements, i.e., it must determine those columns for which it must or must not provide values. Depending on the complexity of the table and the management station's knowledge of the agent's capabilities, this determination can be made locally by the management station. Alternately, the management station issues a management protocol get operation to examine all columns in the conceptual row that it wishes to create. In response, for each column, there are three possible outcomes: - a value is returned, indicating that some other management station has already created this conceptual row. We return to interaction 1. - the exception `noSuchInstance' is returned, indicating that the agent implements the object-type associated with this column, and that this column in at least one conceptual row would be accessible in the MIB view used by the retrieval were it to exist. For those columns to which the agent provides read-create access, the `noSuchInstance' exception tells the management station that it should supply a value for this column when the conceptual row is to be created. - the exception `noSuchObject' is returned, indicating that the agent does not implement the object-type associated with this column or that there is no conceptual row for which this column would be accessible in the MIB view used by the retrieval. As such, the management station can not issue any management protocol set operations to create an instance of this column. Once the column requirements have been determined, a management protocol set operation is accordingly issued. This operation also sets the new instance of the status column to `createAndGo'. When the agent processes the set operation, it verifies that it has sufficient information to make the conceptual row available for use by the managed device. The information available to the agent is provided by two sources: the management protocol set operation which creates the conceptual row, and, implementation-specific defaults supplied by the agent (note that an agent must provide implementation-specific defaults for at least those objects which it implements as read-only). If there is sufficient information available, then the conceptual row is created, a `noError' response is returned, the status column is set to `active', and no further interactions are necessary (i.e., interactions 3 and 4 are skipped). If there is insufficient information, then the conceptual row is not created, and the set operation fails with an error of `inconsistentValue'. On this error, the management station can issue a management protocol retrieval operation to determine if this was because it failed to specify a value for a required column, or, because the selected instance of the status column already existed. In the latter case, we return to interaction 1. In the former case, the management station can re-issue the set operation with the additional information, or begin interaction 2 again using `createAndWait' in order to negotiate creation of the conceptual row. NOTE WELL Regardless of the method used to determine the column requirements, it is possible that the management station might deem a column necessary when, in fact, the agent will not allow that particular columnar instance to be created or written. In this case, the management protocol set operation will fail with an error such as `noCreation' or `notWritable'. In this case, the management station decides whether it needs to be able to set a value for that particular columnar instance. If not, the management station re-issues the management protocol set operation, but without setting a value for that particular columnar instance; otherwise, the management station aborts the row creation algorithm. Interaction 2b: Negotiating the Creation of the Conceptual Row The management station issues a management protocol set operation which sets the desired instance of the status column to `createAndWait'. If the agent is unwilling to process a request of this sort, the set operation fails with an error of `wrongValue'. (As a consequence, such an agent must be prepared to accept a single management protocol set operation, i.e., interaction 2a above, containing all of the columns indicated by its column requirements.) Otherwise, the conceptual row is created, a `noError' response is returned, and the status column is immediately set to either `notInService' or `notReady', depending on whether it has sufficient information to (attempt to) make the conceptual row available for use by the managed device. If there is sufficient information available, then the status column is set to `notInService'; otherwise, if there is insufficient information, then the status column is set to `notReady'. Regardless, we proceed to interaction 3. Interaction 3: Initializing non-defaulted Objects The management station must now determine the column requirements. It issues a management protocol get operation to examine all columns in the created conceptual row. In the response, for each column, there are three possible outcomes: - a value is returned, indicating that the agent implements the object-type associated with this column and had sufficient information to provide a value. For those columns to which the agent provides read-create access (and for which the agent allows their values to be changed after their creation), a value return tells the management station that it may issue additional management protocol set operations, if it desires, in order to change the value associated with this column. - the exception `noSuchInstance' is returned, indicating that the agent implements the object-type associated with this column, and that this column in at least one conceptual row would be accessible in the MIB view used by the retrieval were it to exist. However, the agent does not have sufficient information to provide a value, and until a value is provided, the conceptual row may not be made available for use by the managed device. For those columns to which the agent provides read-create access, the `noSuchInstance' exception tells the management station that it must issue additional management protocol set operations, in order to provide a value associated with this column. - the exception `noSuchObject' is returned, indicating that the agent does not implement the object-type associated with this column or that there is no conceptual row for which this column would be accessible in the MIB view used by the retrieval. As such, the management station can not issue any management protocol set operations to create an instance of this column. If the value associated with the status column is `notReady', then the management station must first deal with all `noSuchInstance' columns, if any. Having done so, the value of the status column becomes `notInService', and we proceed to interaction 4. Interaction 4: Making the Conceptual Row Available Once the management station is satisfied with the values associated with the columns of the conceptual row, it issues a management protocol set operation to set the status column to `active'. If the agent has sufficient information to make the conceptual row available for use by the managed device, the management protocol set operation succeeds (a `noError' response is returned). Otherwise, the management protocol set operation fails with an error of `inconsistentValue'. NOTE WELL A conceptual row having a status column with value `notInService' or `notReady' is unavailable to the managed device. As such, it is possible for the managed device to create its own instances during the time between the management protocol set operation which sets the status column to `createAndWait' and the management protocol set operation which sets the status column to `active'. In this case, when the management protocol set operation is issued to set the status column to `active', the values held in the agent supersede those used by the managed device. If the management station is prevented from setting the status column to `active' (e.g., due to management station or network failure) the conceptual row will be left in the `notInService' or `notReady' state, consuming resources indefinitely. The agent must detect conceptual rows that have been in either state for an abnormally long period of time and remove them. It is the responsibility of the DESCRIPTION clause of the status column to indicate what an abnormally long period of time would be. This period of time should be long enough to allow for human response time (including `think time') between the creation of the conceptual row and the setting of the status to `active'. In the absence of such information in the DESCRIPTION clause, it is suggested that this period be approximately 5 minutes in length. This removal action applies not only to newly-created rows, but also to previously active rows which are set to, and left in, the notInService state for a prolonged period exceeding that which is considered normal for such a conceptual row. Conceptual Row Suspension When a conceptual row is `active', the management station may issue a management protocol set operation which sets the instance of the status column to `notInService'. If the agent is unwilling to do so, the set operation fails with an error of `wrongValue' or `inconsistentValue'. Otherwise, the conceptual row is taken out of service, and a `noError' response is returned. It is the responsibility of the DESCRIPTION clause of the status column to indicate under what circumstances the status column should be taken out of service (e.g., in order for the value of some other column of the same conceptual row to be modified). Conceptual Row Deletion For deletion of conceptual rows, a management protocol set operation is issued which sets the instance of the status column to `destroy'. This request may be made regardless of the current value of the status column (e.g., it is possible to delete conceptual rows which are either `notReady', `notInService' or `active'.) If the operation succeeds, then all instances associated with the conceptual row are immediately removed. · Integer32

The status of this serialConfigEntry. An entry may not exist in the active state unless all objects in the entry have an appropriate value.

IpAddress SIZE (4)

The IP address of this Net interface. The default value for this object is 0.0.0.0. If either the netConfigIPAddress or netConfigSubnetMask is 0.0.0.0, then when the device boots, it may use BOOTP to try to figure out what these values should be. If BOOTP fails before the device can talk on the network, this value must be configured (e.g., through a terminal attached to the device). If BOOTP is used, care should be taken to not send BOOTP broadcasts too frequently and to eventually send them very infrequently if no replies are received.

IpAddress SIZE (4)

The subnet mask of this Net interface. The default value for this object is 0.0.0.0. If either the netConfigIPAddress or netConfigSubnetMask is 0.0.0.0, then when the device boots, it may use BOOTP to try to figure out what these values should be. If BOOTP fails before the device can talk on the network, this value must be configured (e.g., through a terminal attached to the device). If BOOTP is used, care should be taken to not send BOOTP broadcasts too frequently and to eventually send them very infrequently if no replies are received.

RowStatus1 = active2 = notInService3 = notReady4 = createAndGo5 = createAndWait6 = destroyThe RowStatus textual convention is used to manage the creation and deletion of conceptual rows, and is used as the value of the SYNTAX clause for the status column of a conceptual row (as described in Section 7.7.1 of [2].) 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); 'notInService' has no implication regarding the internal consistency of the row, availability of resources, or consistency with the current state of the managed device; - `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 (i.e., one or more required columns in the conceptual row have not been instanciated); - `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 attempt 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 status column having a SYNTAX clause value 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) goto 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, and all columns have acceptable values, then return noError and goto D. (3) if other variable bindings included in the same PDU, provide legal 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 notInService (e.g., an agent which 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. (8) the transition to D can fail, e.g., if the values of the conceptual row are inconsistent, then the error code would be inconsistentValue. NOTE: Other processing of (this and other varbinds 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. A MIB designer should choose between the two latter algorithms based on the size of the table (and therefore the efficiency of each algorithm). For tables in which a large number of entries are expected, it is recommended that a MIB object be defined that returns an acceptable index for creation. For tables with small numbers of entries, it is recommended that the latter pseudo-random index mechanism be used. Interaction 2: Creating the Conceptual Row Once an unused instance-identifier has been selected, the management station determines if it wishes to create and activate the conceptual row in one transaction or in a negotiated set of interactions. Interaction 2a: Creating and Activating the Conceptual Row The management station must first determine the column requirements, i.e., it must determine those columns for which it must or must not provide values. Depending on the complexity of the table and the management station's knowledge of the agent's capabilities, this determination can be made locally by the management station. Alternately, the management station issues a management protocol get operation to examine all columns in the conceptual row that it wishes to create. In response, for each column, there are three possible outcomes: - a value is returned, indicating that some other management station has already created this conceptual row. We return to interaction 1. - the exception `noSuchInstance' is returned, indicating that the agent implements the object-type associated with this column, and that this column in at least one conceptual row would be accessible in the MIB view used by the retrieval were it to exist. For those columns to which the agent provides read-create access, the `noSuchInstance' exception tells the management station that it should supply a value for this column when the conceptual row is to be created. - the exception `noSuchObject' is returned, indicating that the agent does not implement the object-type associated with this column or that there is no conceptual row for which this column would be accessible in the MIB view used by the retrieval. As such, the management station can not issue any management protocol set operations to create an instance of this column. Once the column requirements have been determined, a management protocol set operation is accordingly issued. This operation also sets the new instance of the status column to `createAndGo'. When the agent processes the set operation, it verifies that it has sufficient information to make the conceptual row available for use by the managed device. The information available to the agent is provided by two sources: the management protocol set operation which creates the conceptual row, and, implementation-specific defaults supplied by the agent (note that an agent must provide implementation-specific defaults for at least those objects which it implements as read-only). If there is sufficient information available, then the conceptual row is created, a `noError' response is returned, the status column is set to `active', and no further interactions are necessary (i.e., interactions 3 and 4 are skipped). If there is insufficient information, then the conceptual row is not created, and the set operation fails with an error of `inconsistentValue'. On this error, the management station can issue a management protocol retrieval operation to determine if this was because it failed to specify a value for a required column, or, because the selected instance of the status column already existed. In the latter case, we return to interaction 1. In the former case, the management station can re-issue the set operation with the additional information, or begin interaction 2 again using `createAndWait' in order to negotiate creation of the conceptual row. NOTE WELL Regardless of the method used to determine the column requirements, it is possible that the management station might deem a column necessary when, in fact, the agent will not allow that particular columnar instance to be created or written. In this case, the management protocol set operation will fail with an error such as `noCreation' or `notWritable'. In this case, the management station decides whether it needs to be able to set a value for that particular columnar instance. If not, the management station re-issues the management protocol set operation, but without setting a value for that particular columnar instance; otherwise, the management station aborts the row creation algorithm. Interaction 2b: Negotiating the Creation of the Conceptual Row The management station issues a management protocol set operation which sets the desired instance of the status column to `createAndWait'. If the agent is unwilling to process a request of this sort, the set operation fails with an error of `wrongValue'. (As a consequence, such an agent must be prepared to accept a single management protocol set operation, i.e., interaction 2a above, containing all of the columns indicated by its column requirements.) Otherwise, the conceptual row is created, a `noError' response is returned, and the status column is immediately set to either `notInService' or `notReady', depending on whether it has sufficient information to (attempt to) make the conceptual row available for use by the managed device. If there is sufficient information available, then the status column is set to `notInService'; otherwise, if there is insufficient information, then the status column is set to `notReady'. Regardless, we proceed to interaction 3. Interaction 3: Initializing non-defaulted Objects The management station must now determine the column requirements. It issues a management protocol get operation to examine all columns in the created conceptual row. In the response, for each column, there are three possible outcomes: - a value is returned, indicating that the agent implements the object-type associated with this column and had sufficient information to provide a value. For those columns to which the agent provides read-create access (and for which the agent allows their values to be changed after their creation), a value return tells the management station that it may issue additional management protocol set operations, if it desires, in order to change the value associated with this column. - the exception `noSuchInstance' is returned, indicating that the agent implements the object-type associated with this column, and that this column in at least one conceptual row would be accessible in the MIB view used by the retrieval were it to exist. However, the agent does not have sufficient information to provide a value, and until a value is provided, the conceptual row may not be made available for use by the managed device. For those columns to which the agent provides read-create access, the `noSuchInstance' exception tells the management station that it must issue additional management protocol set operations, in order to provide a value associated with this column. - the exception `noSuchObject' is returned, indicating that the agent does not implement the object-type associated with this column or that there is no conceptual row for which this column would be accessible in the MIB view used by the retrieval. As such, the management station can not issue any management protocol set operations to create an instance of this column. If the value associated with the status column is `notReady', then the management station must first deal with all `noSuchInstance' columns, if any. Having done so, the value of the status column becomes `notInService', and we proceed to interaction 4. Interaction 4: Making the Conceptual Row Available Once the management station is satisfied with the values associated with the columns of the conceptual row, it issues a management protocol set operation to set the status column to `active'. If the agent has sufficient information to make the conceptual row available for use by the managed device, the management protocol set operation succeeds (a `noError' response is returned). Otherwise, the management protocol set operation fails with an error of `inconsistentValue'. NOTE WELL A conceptual row having a status column with value `notInService' or `notReady' is unavailable to the managed device. As such, it is possible for the managed device to create its own instances during the time between the management protocol set operation which sets the status column to `createAndWait' and the management protocol set operation which sets the status column to `active'. In this case, when the management protocol set operation is issued to set the status column to `active', the values held in the agent supersede those used by the managed device. If the management station is prevented from setting the status column to `active' (e.g., due to management station or network failure) the conceptual row will be left in the `notInService' or `notReady' state, consuming resources indefinitely. The agent must detect conceptual rows that have been in either state for an abnormally long period of time and remove them. It is the responsibility of the DESCRIPTION clause of the status column to indicate what an abnormally long period of time would be. This period of time should be long enough to allow for human response time (including `think time') between the creation of the conceptual row and the setting of the status to `active'. In the absence of such information in the DESCRIPTION clause, it is suggested that this period be approximately 5 minutes in length. This removal action applies not only to newly-created rows, but also to previously active rows which are set to, and left in, the notInService state for a prolonged period exceeding that which is considered normal for such a conceptual row. Conceptual Row Suspension When a conceptual row is `active', the management station may issue a management protocol set operation which sets the instance of the status column to `notInService'. If the agent is unwilling to do so, the set operation fails with an error of `wrongValue' or `inconsistentValue'. Otherwise, the conceptual row is taken out of service, and a `noError' response is returned. It is the responsibility of the DESCRIPTION clause of the status column to indicate under what circumstances the status column should be taken out of service (e.g., in order for the value of some other column of the same conceptual row to be modified). Conceptual Row Deletion For deletion of conceptual rows, a management protocol set operation is issued which sets the instance of the status column to `destroy'. This request may be made regardless of the current value of the status column (e.g., it is possible to delete conceptual rows which are either `notReady', `notInService' or `active'.) If the operation succeeds, then all instances associated with the conceptual row are immediately removed. · Integer32

The status of this netConfigEntry. An entry may not exist in the active state unless all objects in the entry have an appropriate value.

Integer32 (1..65535)

A value that uniquely identifies this trapDestEntry.

OCTET STRING SIZE (0..127)

A community to which this destination address belongs. This entry is associated with any eventEntries in the RMON MIB whose value of eventCommunity is equal to the value of this object. Every time an associated event entry sends a trap due to an event, that trap will be sent to each address in the trapDestTable with a trapDestCommunity equal to eventCommunity, as long as no access control mechanism precludes it (e.g., VACM). This object may not be modified if the associated trapDestStatus object is equal to active(1).

INTEGER1 = ip2 = ipx · Integer32

The protocol with which this trap is to be sent.

OCTET STRING

The destination address for traps on behalf of this entry. If the associated trapDestProtocol object is equal to ip(1), the encoding of this object is the same as the snmpUDPAddress textual convention in RFC 3417, 'Transport Mappings for the Simple Network Management Protocol (SNMP)' [RFC3417]: -- for a SnmpUDPAddress of length 6: -- -- octets contents encoding -- 1-4 IP-address network-byte order -- 5-6 UDP-port network-byte order If the associated trapDestProtocol object is equal to ipx(2), the encoding of this object is the same as the snmpIPXAddress textual convention in RFC 3417, 'Transport Mappings for the Simple Network Management Protocol (SNMP)' [RFC3417]: -- for a SnmpIPXAddress of length 12: -- -- octets contents encoding -- 1-4 network-number network-byte order -- 5-10 physical-address network-byte order -- 11-12 socket-number network-byte order This object may not be modified if the associated trapDestStatus object is equal to active(1).

OwnerStringThis data type is used to model an administratively assigned name of the owner of a resource. Implementations must accept values composed of well-formed NVT ASCII sequences. In addition, implementations should accept values composed of well-formed UTF-8 sequences. It is suggested that this name contain one or more of the following: IP address, management station name, network manager's name, location, or phone number. In some cases the agent itself will be the owner of an entry. In these cases, this string shall be set to a string starting with 'monitor'. SNMP access control is articulated entirely in terms of the contents of MIB views; access to a particular SNMP object instance depends only upon its presence or absence in a particular MIB view and never upon its value or the value of related object instances. Thus, objects of this type afford resolution of resource contention only among cooperating managers; they realize no access control function with respect to uncooperative parties. SIZE (0..127) · OCTET STRING

The entity that configured this entry and is therefore using the resources assigned to it.

RowStatus1 = active2 = notInService3 = notReady4 = createAndGo5 = createAndWait6 = destroyThe RowStatus textual convention is used to manage the creation and deletion of conceptual rows, and is used as the value of the SYNTAX clause for the status column of a conceptual row (as described in Section 7.7.1 of [2].) 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); 'notInService' has no implication regarding the internal consistency of the row, availability of resources, or consistency with the current state of the managed device; - `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 (i.e., one or more required columns in the conceptual row have not been instanciated); - `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 attempt 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 status column having a SYNTAX clause value 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) goto 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, and all columns have acceptable values, then return noError and goto D. (3) if other variable bindings included in the same PDU, provide legal 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 notInService (e.g., an agent which 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. (8) the transition to D can fail, e.g., if the values of the conceptual row are inconsistent, then the error code would be inconsistentValue. NOTE: Other processing of (this and other varbinds 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. A MIB designer should choose between the two latter algorithms based on the size of the table (and therefore the efficiency of each algorithm). For tables in which a large number of entries are expected, it is recommended that a MIB object be defined that returns an acceptable index for creation. For tables with small numbers of entries, it is recommended that the latter pseudo-random index mechanism be used. Interaction 2: Creating the Conceptual Row Once an unused instance-identifier has been selected, the management station determines if it wishes to create and activate the conceptual row in one transaction or in a negotiated set of interactions. Interaction 2a: Creating and Activating the Conceptual Row The management station must first determine the column requirements, i.e., it must determine those columns for which it must or must not provide values. Depending on the complexity of the table and the management station's knowledge of the agent's capabilities, this determination can be made locally by the management station. Alternately, the management station issues a management protocol get operation to examine all columns in the conceptual row that it wishes to create. In response, for each column, there are three possible outcomes: - a value is returned, indicating that some other management station has already created this conceptual row. We return to interaction 1. - the exception `noSuchInstance' is returned, indicating that the agent implements the object-type associated with this column, and that this column in at least one conceptual row would be accessible in the MIB view used by the retrieval were it to exist. For those columns to which the agent provides read-create access, the `noSuchInstance' exception tells the management station that it should supply a value for this column when the conceptual row is to be created. - the exception `noSuchObject' is returned, indicating that the agent does not implement the object-type associated with this column or that there is no conceptual row for which this column would be accessible in the MIB view used by the retrieval. As such, the management station can not issue any management protocol set operations to create an instance of this column. Once the column requirements have been determined, a management protocol set operation is accordingly issued. This operation also sets the new instance of the status column to `createAndGo'. When the agent processes the set operation, it verifies that it has sufficient information to make the conceptual row available for use by the managed device. The information available to the agent is provided by two sources: the management protocol set operation which creates the conceptual row, and, implementation-specific defaults supplied by the agent (note that an agent must provide implementation-specific defaults for at least those objects which it implements as read-only). If there is sufficient information available, then the conceptual row is created, a `noError' response is returned, the status column is set to `active', and no further interactions are necessary (i.e., interactions 3 and 4 are skipped). If there is insufficient information, then the conceptual row is not created, and the set operation fails with an error of `inconsistentValue'. On this error, the management station can issue a management protocol retrieval operation to determine if this was because it failed to specify a value for a required column, or, because the selected instance of the status column already existed. In the latter case, we return to interaction 1. In the former case, the management station can re-issue the set operation with the additional information, or begin interaction 2 again using `createAndWait' in order to negotiate creation of the conceptual row. NOTE WELL Regardless of the method used to determine the column requirements, it is possible that the management station might deem a column necessary when, in fact, the agent will not allow that particular columnar instance to be created or written. In this case, the management protocol set operation will fail with an error such as `noCreation' or `notWritable'. In this case, the management station decides whether it needs to be able to set a value for that particular columnar instance. If not, the management station re-issues the management protocol set operation, but without setting a value for that particular columnar instance; otherwise, the management station aborts the row creation algorithm. Interaction 2b: Negotiating the Creation of the Conceptual Row The management station issues a management protocol set operation which sets the desired instance of the status column to `createAndWait'. If the agent is unwilling to process a request of this sort, the set operation fails with an error of `wrongValue'. (As a consequence, such an agent must be prepared to accept a single management protocol set operation, i.e., interaction 2a above, containing all of the columns indicated by its column requirements.) Otherwise, the conceptual row is created, a `noError' response is returned, and the status column is immediately set to either `notInService' or `notReady', depending on whether it has sufficient information to (attempt to) make the conceptual row available for use by the managed device. If there is sufficient information available, then the status column is set to `notInService'; otherwise, if there is insufficient information, then the status column is set to `notReady'. Regardless, we proceed to interaction 3. Interaction 3: Initializing non-defaulted Objects The management station must now determine the column requirements. It issues a management protocol get operation to examine all columns in the created conceptual row. In the response, for each column, there are three possible outcomes: - a value is returned, indicating that the agent implements the object-type associated with this column and had sufficient information to provide a value. For those columns to which the agent provides read-create access (and for which the agent allows their values to be changed after their creation), a value return tells the management station that it may issue additional management protocol set operations, if it desires, in order to change the value associated with this column. - the exception `noSuchInstance' is returned, indicating that the agent implements the object-type associated with this column, and that this column in at least one conceptual row would be accessible in the MIB view used by the retrieval were it to exist. However, the agent does not have sufficient information to provide a value, and until a value is provided, the conceptual row may not be made available for use by the managed device. For those columns to which the agent provides read-create access, the `noSuchInstance' exception tells the management station that it must issue additional management protocol set operations, in order to provide a value associated with this column. - the exception `noSuchObject' is returned, indicating that the agent does not implement the object-type associated with this column or that there is no conceptual row for which this column would be accessible in the MIB view used by the retrieval. As such, the management station can not issue any management protocol set operations to create an instance of this column. If the value associated with the status column is `notReady', then the management station must first deal with all `noSuchInstance' columns, if any. Having done so, the value of the status column becomes `notInService', and we proceed to interaction 4. Interaction 4: Making the Conceptual Row Available Once the management station is satisfied with the values associated with the columns of the conceptual row, it issues a management protocol set operation to set the status column to `active'. If the agent has sufficient information to make the conceptual row available for use by the managed device, the management protocol set operation succeeds (a `noError' response is returned). Otherwise, the management protocol set operation fails with an error of `inconsistentValue'. NOTE WELL A conceptual row having a status column with value `notInService' or `notReady' is unavailable to the managed device. As such, it is possible for the managed device to create its own instances during the time between the management protocol set operation which sets the status column to `createAndWait' and the management protocol set operation which sets the status column to `active'. In this case, when the management protocol set operation is issued to set the status column to `active', the values held in the agent supersede those used by the managed device. If the management station is prevented from setting the status column to `active' (e.g., due to management station or network failure) the conceptual row will be left in the `notInService' or `notReady' state, consuming resources indefinitely. The agent must detect conceptual rows that have been in either state for an abnormally long period of time and remove them. It is the responsibility of the DESCRIPTION clause of the status column to indicate what an abnormally long period of time would be. This period of time should be long enough to allow for human response time (including `think time') between the creation of the conceptual row and the setting of the status to `active'. In the absence of such information in the DESCRIPTION clause, it is suggested that this period be approximately 5 minutes in length. This removal action applies not only to newly-created rows, but also to previously active rows which are set to, and left in, the notInService state for a prolonged period exceeding that which is considered normal for such a conceptual row. Conceptual Row Suspension When a conceptual row is `active', the management station may issue a management protocol set operation which sets the instance of the status column to `notInService'. If the agent is unwilling to do so, the set operation fails with an error of `wrongValue' or `inconsistentValue'. Otherwise, the conceptual row is taken out of service, and a `noError' response is returned. It is the responsibility of the DESCRIPTION clause of the status column to indicate under what circumstances the status column should be taken out of service (e.g., in order for the value of some other column of the same conceptual row to be modified). Conceptual Row Deletion For deletion of conceptual rows, a management protocol set operation is issued which sets the instance of the status column to `destroy'. This request may be made regardless of the current value of the status column (e.g., it is possible to delete conceptual rows which are either `notReady', `notInService' or `active'.) If the operation succeeds, then all instances associated with the conceptual row are immediately removed. · Integer32

The status of this trap destination entry. An entry may not exist in the active state unless all objects in the entry have an appropriate value.

Integer32 (1..65535)

A value that uniquely identifies this serialConnection entry.

IpAddress SIZE (4)

The IP Address that can be reached at the other end of this serial connection. This object may not be modified if the associated serialConnectStatus object is equal to active(1).

INTEGER1 = direct2 = modem3 = switch4 = modemSwitch · Integer32

The type of outgoing connection to be made. If this object has the value direct(1), then a direct serial connection is assumed. If this object has the value modem(2), then serialConnectDialString will be used to make a modem connection. If this object has the value switch(3), then serialConnectSwitchConnectSeq will be used to establish the connection over a serial data switch, and serialConnectSwitchDisconnectSeq will be used to terminate the connection. If this object has the value modem-switch(4), then a modem connection will be made first, followed by the switch connection. This object may not be modified if the associated serialConnectStatus object is equal to active(1).

ControlStringThis data type is used to communicate with a modem or a serial data switch. A ControlString contains embedded commands to control how the device will interact with the remote device through the serial interface. Commands are represented as two-character sequences beginning with the '^' character. The following commands are recognized by the device (note that command characters are case sensitive): ^s Send string that follows, which is terminated by the next command or the end of string. ^c Delay for the number of seconds that follows. Toss out any data received rather than store it in a buffer for parsing. ^t Set timeout to the value represented by the decimal digits that follow. The default timeout is 20 seconds. Note that this timeout may be overridden by a smaller serialTimeout configured for the associated serial interface (see serialConfigTable). ^w Wait for the reply string that follows, which is terminated by the next command or the end of string. Partial and case-insensitive matching is applied, i.e., if the reply string (any case combination) is found anywhere in the received string, then the a match is found. If the current timeout elapses without a match, then the remaining control string is ignored. ^! The ^ character. ^d Delay the number of seconds specified by the decimal digits that follow. ^b Send break for the number of milliseconds specified by the decimal digits that follow. If no digits follow, break will be enforced for 250 milliseconds by default. The following ASCII control characters may be inserted into the '^s' send string or the '^w' reply string: ^@ 0x00 ^A 0x01 .. ^M 0x0D .. ^Z 0x1A ^[ 0x1B ^ 0x1C ^] 0x1D ^^ 0x1E ^_ 0x1F Binary data may also be inserted into the data stream. The control sequence for each byte of binary data is ^0x##, where ## is the hexadecimal representation of the data byte. Two ASCII characters (0-9, a-f, A-F) must follow the '^0x' control prefix. For example, '^0x0D^0x0A' is interpreted as a carriage return followed by a line feed. SIZE (0..255) · OCTET STRING

A control string that specifies how to dial the phone number in order to establish a modem connection. The string should include the dialing prefix and suffix. For example: '^s^MATD9,888-1234^M' will instruct the Probe to send a carriage return, followed by the dialing prefix 'ATD', the phone number '9,888-1234', and a carriage return as the dialing suffix. This object may not be modified if the associated serialConnectStatus object is equal to active(1).

ControlStringThis data type is used to communicate with a modem or a serial data switch. A ControlString contains embedded commands to control how the device will interact with the remote device through the serial interface. Commands are represented as two-character sequences beginning with the '^' character. The following commands are recognized by the device (note that command characters are case sensitive): ^s Send string that follows, which is terminated by the next command or the end of string. ^c Delay for the number of seconds that follows. Toss out any data received rather than store it in a buffer for parsing. ^t Set timeout to the value represented by the decimal digits that follow. The default timeout is 20 seconds. Note that this timeout may be overridden by a smaller serialTimeout configured for the associated serial interface (see serialConfigTable). ^w Wait for the reply string that follows, which is terminated by the next command or the end of string. Partial and case-insensitive matching is applied, i.e., if the reply string (any case combination) is found anywhere in the received string, then the a match is found. If the current timeout elapses without a match, then the remaining control string is ignored. ^! The ^ character. ^d Delay the number of seconds specified by the decimal digits that follow. ^b Send break for the number of milliseconds specified by the decimal digits that follow. If no digits follow, break will be enforced for 250 milliseconds by default. The following ASCII control characters may be inserted into the '^s' send string or the '^w' reply string: ^@ 0x00 ^A 0x01 .. ^M 0x0D .. ^Z 0x1A ^[ 0x1B ^ 0x1C ^] 0x1D ^^ 0x1E ^_ 0x1F Binary data may also be inserted into the data stream. The control sequence for each byte of binary data is ^0x##, where ## is the hexadecimal representation of the data byte. Two ASCII characters (0-9, a-f, A-F) must follow the '^0x' control prefix. For example, '^0x0D^0x0A' is interpreted as a carriage return followed by a line feed. SIZE (0..255) · OCTET STRING

A control string that specifies how to establish a data switch connection. This object may not be modified if the associated serialConnectStatus object is equal to active(1).

ControlStringThis data type is used to communicate with a modem or a serial data switch. A ControlString contains embedded commands to control how the device will interact with the remote device through the serial interface. Commands are represented as two-character sequences beginning with the '^' character. The following commands are recognized by the device (note that command characters are case sensitive): ^s Send string that follows, which is terminated by the next command or the end of string. ^c Delay for the number of seconds that follows. Toss out any data received rather than store it in a buffer for parsing. ^t Set timeout to the value represented by the decimal digits that follow. The default timeout is 20 seconds. Note that this timeout may be overridden by a smaller serialTimeout configured for the associated serial interface (see serialConfigTable). ^w Wait for the reply string that follows, which is terminated by the next command or the end of string. Partial and case-insensitive matching is applied, i.e., if the reply string (any case combination) is found anywhere in the received string, then the a match is found. If the current timeout elapses without a match, then the remaining control string is ignored. ^! The ^ character. ^d Delay the number of seconds specified by the decimal digits that follow. ^b Send break for the number of milliseconds specified by the decimal digits that follow. If no digits follow, break will be enforced for 250 milliseconds by default. The following ASCII control characters may be inserted into the '^s' send string or the '^w' reply string: ^@ 0x00 ^A 0x01 .. ^M 0x0D .. ^Z 0x1A ^[ 0x1B ^ 0x1C ^] 0x1D ^^ 0x1E ^_ 0x1F Binary data may also be inserted into the data stream. The control sequence for each byte of binary data is ^0x##, where ## is the hexadecimal representation of the data byte. Two ASCII characters (0-9, a-f, A-F) must follow the '^0x' control prefix. For example, '^0x0D^0x0A' is interpreted as a carriage return followed by a line feed. SIZE (0..255) · OCTET STRING

A control string that specifies how to terminate a data switch connection. This object may not be modified if the associated serialConnectStatus object is equal to active(1).

ControlStringThis data type is used to communicate with a modem or a serial data switch. A ControlString contains embedded commands to control how the device will interact with the remote device through the serial interface. Commands are represented as two-character sequences beginning with the '^' character. The following commands are recognized by the device (note that command characters are case sensitive): ^s Send string that follows, which is terminated by the next command or the end of string. ^c Delay for the number of seconds that follows. Toss out any data received rather than store it in a buffer for parsing. ^t Set timeout to the value represented by the decimal digits that follow. The default timeout is 20 seconds. Note that this timeout may be overridden by a smaller serialTimeout configured for the associated serial interface (see serialConfigTable). ^w Wait for the reply string that follows, which is terminated by the next command or the end of string. Partial and case-insensitive matching is applied, i.e., if the reply string (any case combination) is found anywhere in the received string, then the a match is found. If the current timeout elapses without a match, then the remaining control string is ignored. ^! The ^ character. ^d Delay the number of seconds specified by the decimal digits that follow. ^b Send break for the number of milliseconds specified by the decimal digits that follow. If no digits follow, break will be enforced for 250 milliseconds by default. The following ASCII control characters may be inserted into the '^s' send string or the '^w' reply string: ^@ 0x00 ^A 0x01 .. ^M 0x0D .. ^Z 0x1A ^[ 0x1B ^ 0x1C ^] 0x1D ^^ 0x1E ^_ 0x1F Binary data may also be inserted into the data stream. The control sequence for each byte of binary data is ^0x##, where ## is the hexadecimal representation of the data byte. Two ASCII characters (0-9, a-f, A-F) must follow the '^0x' control prefix. For example, '^0x0D^0x0A' is interpreted as a carriage return followed by a line feed. SIZE (0..255) · OCTET STRING

A control string that specifies how to reset a data switch in the event of a timeout. This object may not be modified if the associated serialConnectStatus object is equal to active(1).

OwnerStringThis data type is used to model an administratively assigned name of the owner of a resource. Implementations must accept values composed of well-formed NVT ASCII sequences. In addition, implementations should accept values composed of well-formed UTF-8 sequences. It is suggested that this name contain one or more of the following: IP address, management station name, network manager's name, location, or phone number. In some cases the agent itself will be the owner of an entry. In these cases, this string shall be set to a string starting with 'monitor'. SNMP access control is articulated entirely in terms of the contents of MIB views; access to a particular SNMP object instance depends only upon its presence or absence in a particular MIB view and never upon its value or the value of related object instances. Thus, objects of this type afford resolution of resource contention only among cooperating managers; they realize no access control function with respect to uncooperative parties. SIZE (0..127) · OCTET STRING

The entity that configured this entry and is therefore using the resources assigned to it.

RowStatus1 = active2 = notInService3 = notReady4 = createAndGo5 = createAndWait6 = destroyThe RowStatus textual convention is used to manage the creation and deletion of conceptual rows, and is used as the value of the SYNTAX clause for the status column of a conceptual row (as described in Section 7.7.1 of [2].) 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); 'notInService' has no implication regarding the internal consistency of the row, availability of resources, or consistency with the current state of the managed device; - `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 (i.e., one or more required columns in the conceptual row have not been instanciated); - `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 attempt 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 status column having a SYNTAX clause value 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) goto 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, and all columns have acceptable values, then return noError and goto D. (3) if other variable bindings included in the same PDU, provide legal 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 notInService (e.g., an agent which 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. (8) the transition to D can fail, e.g., if the values of the conceptual row are inconsistent, then the error code would be inconsistentValue. NOTE: Other processing of (this and other varbinds 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. A MIB designer should choose between the two latter algorithms based on the size of the table (and therefore the efficiency of each algorithm). For tables in which a large number of entries are expected, it is recommended that a MIB object be defined that returns an acceptable index for creation. For tables with small numbers of entries, it is recommended that the latter pseudo-random index mechanism be used. Interaction 2: Creating the Conceptual Row Once an unused instance-identifier has been selected, the management station determines if it wishes to create and activate the conceptual row in one transaction or in a negotiated set of interactions. Interaction 2a: Creating and Activating the Conceptual Row The management station must first determine the column requirements, i.e., it must determine those columns for which it must or must not provide values. Depending on the complexity of the table and the management station's knowledge of the agent's capabilities, this determination can be made locally by the management station. Alternately, the management station issues a management protocol get operation to examine all columns in the conceptual row that it wishes to create. In response, for each column, there are three possible outcomes: - a value is returned, indicating that some other management station has already created this conceptual row. We return to interaction 1. - the exception `noSuchInstance' is returned, indicating that the agent implements the object-type associated with this column, and that this column in at least one conceptual row would be accessible in the MIB view used by the retrieval were it to exist. For those columns to which the agent provides read-create access, the `noSuchInstance' exception tells the management station that it should supply a value for this column when the conceptual row is to be created. - the exception `noSuchObject' is returned, indicating that the agent does not implement the object-type associated with this column or that there is no conceptual row for which this column would be accessible in the MIB view used by the retrieval. As such, the management station can not issue any management protocol set operations to create an instance of this column. Once the column requirements have been determined, a management protocol set operation is accordingly issued. This operation also sets the new instance of the status column to `createAndGo'. When the agent processes the set operation, it verifies that it has sufficient information to make the conceptual row available for use by the managed device. The information available to the agent is provided by two sources: the management protocol set operation which creates the conceptual row, and, implementation-specific defaults supplied by the agent (note that an agent must provide implementation-specific defaults for at least those objects which it implements as read-only). If there is sufficient information available, then the conceptual row is created, a `noError' response is returned, the status column is set to `active', and no further interactions are necessary (i.e., interactions 3 and 4 are skipped). If there is insufficient information, then the conceptual row is not created, and the set operation fails with an error of `inconsistentValue'. On this error, the management station can issue a management protocol retrieval operation to determine if this was because it failed to specify a value for a required column, or, because the selected instance of the status column already existed. In the latter case, we return to interaction 1. In the former case, the management station can re-issue the set operation with the additional information, or begin interaction 2 again using `createAndWait' in order to negotiate creation of the conceptual row. NOTE WELL Regardless of the method used to determine the column requirements, it is possible that the management station might deem a column necessary when, in fact, the agent will not allow that particular columnar instance to be created or written. In this case, the management protocol set operation will fail with an error such as `noCreation' or `notWritable'. In this case, the management station decides whether it needs to be able to set a value for that particular columnar instance. If not, the management station re-issues the management protocol set operation, but without setting a value for that particular columnar instance; otherwise, the management station aborts the row creation algorithm. Interaction 2b: Negotiating the Creation of the Conceptual Row The management station issues a management protocol set operation which sets the desired instance of the status column to `createAndWait'. If the agent is unwilling to process a request of this sort, the set operation fails with an error of `wrongValue'. (As a consequence, such an agent must be prepared to accept a single management protocol set operation, i.e., interaction 2a above, containing all of the columns indicated by its column requirements.) Otherwise, the conceptual row is created, a `noError' response is returned, and the status column is immediately set to either `notInService' or `notReady', depending on whether it has sufficient information to (attempt to) make the conceptual row available for use by the managed device. If there is sufficient information available, then the status column is set to `notInService'; otherwise, if there is insufficient information, then the status column is set to `notReady'. Regardless, we proceed to interaction 3. Interaction 3: Initializing non-defaulted Objects The management station must now determine the column requirements. It issues a management protocol get operation to examine all columns in the created conceptual row. In the response, for each column, there are three possible outcomes: - a value is returned, indicating that the agent implements the object-type associated with this column and had sufficient information to provide a value. For those columns to which the agent provides read-create access (and for which the agent allows their values to be changed after their creation), a value return tells the management station that it may issue additional management protocol set operations, if it desires, in order to change the value associated with this column. - the exception `noSuchInstance' is returned, indicating that the agent implements the object-type associated with this column, and that this column in at least one conceptual row would be accessible in the MIB view used by the retrieval were it to exist. However, the agent does not have sufficient information to provide a value, and until a value is provided, the conceptual row may not be made available for use by the managed device. For those columns to which the agent provides read-create access, the `noSuchInstance' exception tells the management station that it must issue additional management protocol set operations, in order to provide a value associated with this column. - the exception `noSuchObject' is returned, indicating that the agent does not implement the object-type associated with this column or that there is no conceptual row for which this column would be accessible in the MIB view used by the retrieval. As such, the management station can not issue any management protocol set operations to create an instance of this column. If the value associated with the status column is `notReady', then the management station must first deal with all `noSuchInstance' columns, if any. Having done so, the value of the status column becomes `notInService', and we proceed to interaction 4. Interaction 4: Making the Conceptual Row Available Once the management station is satisfied with the values associated with the columns of the conceptual row, it issues a management protocol set operation to set the status column to `active'. If the agent has sufficient information to make the conceptual row available for use by the managed device, the management protocol set operation succeeds (a `noError' response is returned). Otherwise, the management protocol set operation fails with an error of `inconsistentValue'. NOTE WELL A conceptual row having a status column with value `notInService' or `notReady' is unavailable to the managed device. As such, it is possible for the managed device to create its own instances during the time between the management protocol set operation which sets the status column to `createAndWait' and the management protocol set operation which sets the status column to `active'. In this case, when the management protocol set operation is issued to set the status column to `active', the values held in the agent supersede those used by the managed device. If the management station is prevented from setting the status column to `active' (e.g., due to management station or network failure) the conceptual row will be left in the `notInService' or `notReady' state, consuming resources indefinitely. The agent must detect conceptual rows that have been in either state for an abnormally long period of time and remove them. It is the responsibility of the DESCRIPTION clause of the status column to indicate what an abnormally long period of time would be. This period of time should be long enough to allow for human response time (including `think time') between the creation of the conceptual row and the setting of the status to `active'. In the absence of such information in the DESCRIPTION clause, it is suggested that this period be approximately 5 minutes in length. This removal action applies not only to newly-created rows, but also to previously active rows which are set to, and left in, the notInService state for a prolonged period exceeding that which is considered normal for such a conceptual row. Conceptual Row Suspension When a conceptual row is `active', the management station may issue a management protocol set operation which sets the instance of the status column to `notInService'. If the agent is unwilling to do so, the set operation fails with an error of `wrongValue' or `inconsistentValue'. Otherwise, the conceptual row is taken out of service, and a `noError' response is returned. It is the responsibility of the DESCRIPTION clause of the status column to indicate under what circumstances the status column should be taken out of service (e.g., in order for the value of some other column of the same conceptual row to be modified). Conceptual Row Deletion For deletion of conceptual rows, a management protocol set operation is issued which sets the instance of the status column to `destroy'. This request may be made regardless of the current value of the status column (e.g., it is possible to delete conceptual rows which are either `notReady', `notInService' or `active'.) If the operation succeeds, then all instances associated with the conceptual row are immediately removed. · Integer32

The status of this serialConnectionEntry. If the manager attempts to set this object to active(1) when the serialConnectType is set to modem(2) or modem-switch(4) and the serialConnectDialString is a zero-length string or cannot be correctly parsed as a ConnectString, the set request will be rejected with badValue(3). If the manager attempts to set this object to active(1) when the serialConnectType is set to switch(3) or modem-switch(4) and the serialConnectSwitchConnectSeq, the serialConnectSwitchDisconnectSeq, or the serialConnectSwitchResetSeq is a zero-length string or cannot be correctly parsed as a ConnectString, the set request will be rejected with badValue(3). An entry may not exist in the active state unless all objects in the entry have an appropriate value.