-- MIB created 10/09/96 17:50:16, by -- SMICng version 2.0.10(PRO)(MS-DOS32), October 9, 1996. -- version 1.1, modified 09/04/98 SNMPv2-TC-v1 DEFINITIONS ::= BEGIN -- From file: "rfc1903.sm2" -- Compile options "G A" IMPORTS TimeTicks FROM RFC1155-SMI; --?? No macro TEXTUAL-CONVENTION in SNMPv1 DisplayString ::= OCTET STRING(SIZE(0..255)) -- TEXTUAL-CONVENTION -- DspHint -- 255a -- Status -- mandatory -- Descr -- Represents 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. PhysAddress ::= OCTET STRING -- TEXTUAL-CONVENTION -- DspHint -- 1x: -- Status -- mandatory -- Descr -- Represents media- or physical-level addresses. MacAddress ::= OCTET STRING(SIZE(6)) -- TEXTUAL-CONVENTION -- DspHint -- 1x: -- Status -- mandatory -- Descr -- Represents an 802 MAC address represented in the -- `canonical' order defined by IEEE 802.1a, i.e., as if it -- were transmitted least significant bit first, even though -- 802.5 (in contrast to other 802.x protocols) requires MAC -- addresses to be transmitted most significant bit first. TruthValue ::= INTEGER { true(1), false(2) } -- TEXTUAL-CONVENTION -- Status -- mandatory -- Descr -- Represents a boolean value. TestAndIncr ::= INTEGER(0..2147483647) -- TEXTUAL-CONVENTION -- Status -- mandatory -- Descr -- Represents integer-valued information used for atomic -- operations. When the management protocol is used to specify -- that an object instance having this syntax is to be -- modified, the new value supplied via the management protocol -- must precisely match the value presently held by the -- instance. If not, the management protocol set operation -- fails with an error of `inconsistentValue'. Otherwise, if -- the current value is the maximum value of 2^31-1 (2147483647 -- decimal), then the value held by the instance is wrapped to -- zero; otherwise, the value held by the instance is -- incremented by one. (Note that regardless of whether the -- management protocol set operation succeeds, the variable- -- binding in the request and response PDUs are identical.) -- -- The value of the ACCESS clause for objects having this -- syntax is either `read-write' or `read-create'. When an -- instance of a columnar object having this syntax is created, -- any value may be supplied via the management protocol. -- -- When the network management portion of the system is re- -- initialized, the value of every object instance having this -- syntax must either be incremented from its value prior to -- the re-initialization, or (if the value prior to the re- -- initialization is unknown) be set to a pseudo-randomly -- generated value. AutonomousType ::= OBJECT IDENTIFIER -- TEXTUAL-CONVENTION -- Status -- mandatory -- Descr -- Represents an independently extensible type identification -- value. It may, for example, indicate a particular sub-tree -- with further MIB definitions, or define a particular type of -- protocol or hardware. InstancePointer ::= OBJECT IDENTIFIER -- TEXTUAL-CONVENTION -- Status -- obsolete -- Descr -- A pointer to either a specific instance of a MIB object or -- a conceptual row of a MIB table in the managed device. In -- the latter case, by convention, it is the name of the -- particular instance of the first accessible columnar object -- in the conceptual row. -- -- The two uses of this textual convention are replaced by -- VariablePointer and RowPointer, respectively. VariablePointer ::= OBJECT IDENTIFIER -- TEXTUAL-CONVENTION -- Status -- mandatory -- Descr -- A pointer to a specific object instance. For example, -- sysContact.0 or ifInOctets.3. RowPointer ::= OBJECT IDENTIFIER -- TEXTUAL-CONVENTION -- Status -- mandatory -- Descr -- Represents a pointer to a conceptual row. The value is the -- name of the instance of the first accessible columnar object -- in the conceptual row. -- -- For example, ifIndex.3 would point to the 3rd row in the -- ifTable (note that if ifIndex were not-accessible, then -- ifDescr.3 would be used instead). RowStatus ::= INTEGER { active(1), notInService(2), notReady(3), createAndGo(4), createAndWait(5), destroy(6) } -- TEXTUAL-CONVENTION -- Status -- mandatory -- Descr -- The 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); -- -- - `notReady', which indicates that the conceptual row -- exists in the agent, but is missing information -- necessary in order to be available for use by the -- managed device; -- -- - `createAndGo', which is supplied by a management -- station wishing to create a new instance of a -- conceptual row and to have its status automatically set -- to active, making it available for use by the managed -- device; -- -- - `createAndWait', which is supplied by a management -- station wishing to create a new instance of a -- conceptual row (but not make it available for use by -- the managed device); and, -- -- - `destroy', which is supplied by a management station -- wishing to delete all of the instances associated with -- an existing conceptual row. -- -- Whereas five of the six values (all except `notReady') may -- be specified in a management protocol set operation, only -- three values will be returned in response to a management -- protocol retrieval operation: `notReady', `notInService' or -- `active'. That is, when queried, an existing conceptual row -- has only three states: it is either available for use by -- the managed device (the status column has value `active'); -- it is not available for use by the managed device, though -- the agent has sufficient information to make it so (the -- status column has value `notInService'); or, it is not -- available for use by the managed device, and an attempt to -- make it so would fail because the agent has insufficient -- information (the state column has value `notReady'). -- -- NOTE WELL -- -- This textual convention may be used for a MIB table, -- irrespective of whether the values of that table's -- conceptual rows are able to be modified while it is -- active, or whether its conceptual rows must be taken -- out of service in order to be modified. That is, it is -- the responsibility of the DESCRIPTION clause of the -- status column to specify whether the status column must -- not be `active' in order for the value of some other -- column of the same conceptual row to be modified. If -- such a specification is made, affected columns may be -- changed by an SNMP set PDU if the RowStatus would not -- be equal to `active' either immediately before or after -- processing the PDU. In other words, if the PDU also -- contained a varbind that would change the RowStatus -- value, the column in question may be changed if the -- RowStatus was not equal to `active' as the PDU was -- received, or if the varbind sets the status to a value -- other than 'active'. -- -- -- Also note that whenever any elements of a row exist, the -- RowStatus column must also exist. -- -- To summarize the effect of having a conceptual row with a -- 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| ->D| ->D -- ==============+==============+===========+=============+============= -- set status |inconsistent- |inconsist- |noError |noError ->C -- column to | Value| entValue| | -- notInService | | | | -- | | or | | or -- | | | | -- | |see 3 ->C| ->C|wrongValue -- ==============+==============+===========+=============+============= -- set status |noError |noError |noError |noError -- column to | | | | -- destroy | ->A| ->A| ->A| ->A -- ==============+==============+===========+=============+============= -- 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, then return noError and goto D. -- -- (3) if other variable bindings included in the same PDU, -- provide values for all columns which are missing but -- required, then return noError and goto C. -- -- (4) at the discretion of the agent, the return value may be -- either: -- -- inconsistentName: because the agent does not choose to -- create such an instance when the corresponding -- RowStatus instance does not exist, or -- -- inconsistentValue: if the supplied value is -- inconsistent with the state of some other MIB object's -- value, or -- -- noError: because the agent chooses to create the -- instance. -- -- If noError is returned, then the instance of the status -- column must also be created, and the new state is B or C, -- depending on the information available to the agent. If -- inconsistentName or inconsistentValue is returned, the row -- remains in state A. -- -- (5) depending on the MIB definition for the column/table, -- either noError or inconsistentValue may be returned. -- -- NOTE: Other processing of the set request may result in a -- response other than noError being returned, e.g., -- wrongValue, noCreation, etc. -- -- -- Conceptual Row Creation -- -- There are four potential interactions when creating a -- conceptual row: selecting an instance-identifier which is -- not in use; creating the conceptual row; initializing any -- objects for which the agent does not supply a default; and, -- making the conceptual row available for use by the managed -- device. -- -- Interaction 1: Selecting an Instance-Identifier -- -- The algorithm used to select an instance-identifier varies -- for each conceptual row. In some cases, the instance- -- identifier is semantically significant, e.g., the -- destination address of a route, and a management station -- selects the instance-identifier according to the semantics. -- -- In other cases, the instance-identifier is used solely to -- distinguish conceptual rows, and a management station -- without specific knowledge of the conceptual row might -- examine the instances present in order to determine an -- unused instance-identifier. (This approach may be used, but -- it is often highly sub-optimal; however, it is also a -- questionable practice for a naive management station to -- attempt conceptual row creation.) -- -- Alternately, the MIB module which defines the conceptual row -- might provide one or more objects which provide assistance -- in determining an unused instance-identifier. For example, -- if the conceptual row is indexed by an integer-value, then -- an object having an integer-valued SYNTAX clause might be -- defined for such a purpose, allowing a management station to -- issue a management protocol retrieval operation. In order -- to avoid unnecessary collisions between competing management -- stations, `adjacent' retrievals of this object should be -- different. -- -- Finally, the management station could select a pseudo-random -- number to use as the index. In the event that this index -- was already in use and an inconsistentValue was returned in -- response to the management protocol set operation, the -- management station should simply select a new pseudo-random -- number and retry the operation. -- -- 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 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 absense 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'. 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. TimeStamp ::= TimeTicks -- TEXTUAL-CONVENTION -- Status -- mandatory -- Descr -- The 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. TimeInterval ::= INTEGER(0..2147483647) -- TEXTUAL-CONVENTION -- Status -- mandatory -- Descr -- A period of time, measured in units of 0.01 seconds. DateAndTime ::= OCTET STRING(SIZE(11)) -- TEXTUAL-CONVENTION -- DspHint -- 2d-1d-1d,1d:1d:1d.1d,1a1d:1d -- Status -- mandatory -- Descr -- A date-time specification. -- -- field octets contents range -- ===== ====== ======== ===== -- 1 1-2 year 0..65536 -- 2 3 month 1..12 -- 3 4 day 1..31 -- 4 5 hour 0..23 -- 5 6 minutes 0..59 -- 6 7 seconds 0..60 -- (use 60 for leap-second) -- 7 8 deci-seconds 0..9 -- 8 9 direction from UTC '+' / '-' -- 9 10 hours from UTC 0..11 -- 10 11 minutes from UTC 0..59 -- -- For example, Tuesday May 26, 1992 at 1:30:15 PM EDT would be -- displayed as: -- -- 1992-5-26,13:30:15.0,-4:0 -- -- Note that if only local time is known, then timezone -- information (fields 8-10) is not present. StorageType ::= INTEGER { other(1), volatile(2), nonVolatile(3), permanent(4), readOnly(5) } -- TEXTUAL-CONVENTION -- Status -- mandatory -- Descr -- Describes the memory realization of a conceptual row. A -- row which is volatile(2) is lost upon reboot. A row which -- is either nonVolatile(3), permanent(4) or readOnly(5), is -- backed up by stable storage. A row which is permanent(4) -- can be changed but not deleted. A row which is readOnly(5) -- cannot be changed nor deleted. -- -- If the value of an object with this syntax is either -- permanent(4) or readOnly(5), it cannot be modified. -- Conversely, if the value is either other(1), volatile(2) or -- nonVolatile(3), it cannot be modified to be permanent(4) or -- readOnly(5). -- -- Every usage of this textual convention is required to -- specify the columnar objects which a permanent(4) row must -- at a minimum allow to be writable. TDomain ::= OBJECT IDENTIFIER -- TEXTUAL-CONVENTION -- Status -- mandatory -- Descr -- Denotes a kind of transport service. -- -- Some possible values, such as snmpUDPDomain, are defined in -- 'Transport Mappings for Version 2 of the Simple Network -- Management Protocol (SNMPv2)'. TAddress ::= OCTET STRING(SIZE(1..255)) -- TEXTUAL-CONVENTION -- Status -- mandatory -- Descr -- Denotes a transport service address. -- -- For snmpUDPDomain, a TAddress is 6 octets long, the initial 4 -- octets containing the IP-address in network-byte order and the -- last 2 containing the UDP port in network-byte order. Consult -- 'Transport Mappings for Version 2 of the Simple Network -- Management Protocol (SNMPv2)' for further information on -- snmpUDPDomain. END