DOCS-IF-MIB

Integer32 (0..255)

The Cable Modem Termination System identification of the downstream channel within this particular MAC interface. if the interface is down, the object returns the most current value. If the downstream channel ID is unknown, this object returns a value of 0.

Integer32 (0..1000000000) · hertz

The center of the downstream frequency associated with this channel. This object will return the current tuner frequency. If a CMTS provides IF output, this object will return 0, unless this CMTS is in control of the final downstream frequency. See the associated compliance object for a description of valid frequencies that may be written to this object. ⓘ

Integer32 (0..16000000) · hertz

The bandwidth of this downstream channel. Most implementations are expected to support a channel width of 6 MHz (North America) and/or 8 MHz (Europe). See the associated compliance object for a description of the valid channel widths for this object. ⓘ

INTEGER1 = unknown2 = other3 = qam644 = qam256 · Integer32

The modulation type associated with this downstream channel. If the interface is down, this object either returns the configured value (CMTS), the most current value (CM), or the value of unknown(1). See the associated conformance object for write conditions and limitations. See the reference for specifics on the modulation profiles implied by qam64 and qam256. ⓘ

INTEGER1 = unknown2 = other3 = taps8Increment164 = taps16Increment85 = taps32Increment46 = taps64Increment27 = taps128Increment18 = taps12increment17 · Integer32

The Forward Error Correction (FEC) interleaving used for this downstream channel. Values are defined as follows: taps8Increment16(3): protection 5.9/4.1 usec, latency .22/.15 msec taps16Increment8(4): protection 12/8.2 usec, latency .48/.33 msec taps32Increment4(5): protection 24/16 usec, latency .98/.68 msec taps64Increment2(6): protection 47/33 usec, latency 2/1.4 msec taps128Increment1(7): protection 95/66 usec, latency 4/2.8 msec taps12increment17(8): protection 18/14 usec, latency 0.43/0.32 msec The value 'taps12increment17' is supported by EuroDOCSIS cable systems only, and the others by DOCSIS cable systems. If the interface is down, this object either returns the configured value (CMTS), the most current value (CM), or the value of unknown(1). The value of other(2) is returned if the interleave is known but not defined in the above list. See the associated conformance object for write conditions and limitations. See the reference for the FEC configuration described by the setting of this object. ⓘ

TenthdBmVThis data type represents power levels that are normally expressed in dBmV. Units are in tenths of a dBmV; for example, 5.1 dBmV will be represented as 51. · Integer32 · hint d-1 · dBmV

At the CMTS, the operational transmit power. At the CM, the received power level. If the interface is down, this object either returns the configured value (CMTS), the most current value (CM) or the value of 0. See the associated conformance object for write conditions and limitations. See the reference for recommended and required power levels. ⓘ

INTEGER1 = unknown2 = other3 = annexA4 = annexB5 = annexC · Integer32

The value of this object indicates the conformance of the implementation to important regional cable standards. annexA : Annex A from ITU-T J.83 is used. (equivalent to EN 300 429) annexB : Annex B from ITU-T J.83 is used. annexC : Annex C from ITU-T J.83 is used. ⓘ

StorageType1 = other2 = volatile3 = nonVolatile4 = permanent5 = readOnlyDescribes 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 written. Conversely, if the value is either other(1), volatile(2) or nonVolatile(3), it cannot be modified to be permanent(4) or readOnly(5). (All illegal modifications result in a 'wrongValue' error.) 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. · Integer32

The storage type for this conceptual row. Entries with this object set to permanent(4) do not require write operations for read-write objects.

Integer32 (0..255)

The CMTS identification of the upstream channel.

Integer32 (0..1000000000) · hertz

The center of the frequency band associated with this upstream interface. This object returns 0 if the frequency is undefined or unknown. Minimum permitted upstream frequency is 5,000,000 Hz for current technology. See the associated conformance object for write conditions and limitations. ⓘ

Integer32 (0..64000000) · hertz

The bandwidth of this upstream interface. This object returns 0 if the interface width is undefined or unknown. Minimum permitted interface width is currently 200,000 Hz. See the associated conformance object for write conditions and limitations. ⓘ

Unsigned32

An entry identical to the docsIfModIndex in the docsIfCmtsModulationTable that describes this channel. This channel is further instantiated there by a grouping of interval usage codes (IUCs) that, together, fully describe the channel modulation. This object returns 0 if the docsIfCmtsModulationTable entry does not exist or is empty. See the associated conformance object for write conditions and limitations. Setting this object returns an 'inconsistentValue' error if the following conditions are not satisfied: 1. All the IUC entries in the selected modulation profile MUST have the same value of docsIfCmtsModChannelType. 2. All of the Modulation parameters in the selected modulation profile MUST be consistent with the other parameters in this docsIfUpstreamChannelEntry. ⓘ

Unsigned32 · ticks

Applicable to TDMA and ATDMA channel types only. The number of 6.25 microsecond ticks in each upstream mini-slot. Returns zero if the value is undefined or unknown or in case of an SCDMA channel. See the associated conformance object for write conditions and limitations. ⓘ

Unsigned32

At the CM, a measure of the current round trip time obtained from the ranging offset (initial ranging offset + ranging offset adjustments). At the CMTS, the maximum of timing offset, among all the CMs that are/were present on the channel, taking into account all ( initial + periodic ) timing offset corrections that were sent for each of the CMs. Generally, these measurements are positive, but if the measurements are negative, the value of this object is zero. Used for timing of CM upstream transmissions to ensure synchronized arrivals at the CMTS. Units are one 64th fraction of 6.25 microseconds. ⓘ

Integer32 (0..16)

The initial random backoff window to use when retrying Ranging Requests. Expressed as a power of 2. A value of 16 at the CMTS indicates that a proprietary adaptive retry mechanism is to be used. See the associated conformance object for write conditions and limitations. ⓘ

Integer32 (0..16)

The final random backoff window to use when retrying Ranging Requests. Expressed as a power of 2. A value of 16 at the CMTS indicates that a proprietary adaptive retry mechanism is to be used. See the associated conformance object for write conditions and limitations. ⓘ

Integer32 (0..16)

The initial random backoff window to use when retrying transmissions. Expressed as a power of 2. A value of 16 at the CMTS indicates that a proprietary adaptive retry mechanism is to be used. See the associated conformance object for write conditions and limitations. ⓘ

Integer32 (0..16)

The final random backoff window to use when retrying transmissions. Expressed as a power of 2. A value of 16 at the CMTS indicates that a proprietary adaptive retry mechanism is to be used. See the associated conformance object for write conditions and limitations. ⓘ

Unsigned32 (0 | 64..66 | 68..70 | 72 | 74..78 | 80..82 | 84..88 | 90..96 | 98..100 | 102 | 104..106 | 108 | 110..112 | 114..126 | 128)

Applicable for SCDMA channel types only. Number of active codes. Returns zero for Non-SCDMA channel types. Note that legal values from 64..128 MUST be non-prime. ⓘ

Integer32 (0 | 2..32) · codesperMinislots

Applicable for SCDMA channel types only. The number of SCDMA codes per mini-slot. Returns zero if the value is undefined or unknown or in case of a TDMA or ATDMA channel. ⓘ

Unsigned32 (0..32) · spreadIntervals

Applicable for SCDMA channel types only. SCDMA Frame size in units of spreading intervals. This value returns zero for non-SCDMA Profiles. ⓘ

Unsigned32 (0..32767)

Applicable for SCDMA channel types only. 15-bit seed used for code hopping sequence initialization. Returns zero for non-SCDMA channel types. Setting this value to a value different than zero for non-SCDMA channel types returns the error 'wrongValue'. ⓘ

DocsisUpstreamType0 = unknown1 = tdma2 = atdma3 = scdma4 = tdmaAndAtdmaIndicates the DOCSIS Upstream Channel Type. 'unknown' means information not available. 'tdma' is related to TDMA, Time Division Multiple Access; 'atdma' is related to A-TDMA, Advanced Time Division Multiple Access, 'scdma' is related to S-CDMA, Synchronous Code Division Multiple Access. 'tdmaAndAtdma is related to simultaneous support of TDMA and A-TDMA modes. · Integer32

Reflects the Upstream channel type. This object returns the value of docsIfCmtsModChannelType for the modulation profile selected in docsIfUpChannelModulationProfile for this row. ⓘ

InterfaceIndexOrZeroThis textual convention is an extension of the InterfaceIndex convention. The latter defines a greater than zero value used to identify an interface or interface sub-layer in the managed system. This extension permits the additional value of zero. the value zero is object-specific and must therefore be defined as part of the description of any object which uses this syntax. Examples of the usage of zero might include situations where interface was unknown, or when none or all interfaces need to be referenced. (0..2147483647) · Integer32 · hint d

This object contains the ifIndex value of the physical interface row entry whose parameters are to be adjusted. Upon setting this object to the ifIndex value of a physical interface, the following interface objects values are copied to this entry: docsIfUpChannelFrequency, docsIfUpChannelWidth, docsIfUpChannelModulationProfile, docsIfUpChannelSlotSize, docsIfUpChannelRangingBackoffStart, docsIfUpChannelRangingBackoffEnd, docsIfUpChannelTxBackoffStart, docsIfUpChannelTxBackoffEnd, docsIfUpChannelScdmaActiveCodes, docsIfUpChannelScdmaCodesPerSlot, docsIfUpChannelScdmaFrameSize, docsIfUpChannelScdmaHoppingSeed, docsIfUpChannelType, and docsIfUpChannelPreEqEnable Setting this object to the value of a non-existent or a temporary upstream interface returns the error 'wrongValue'. This object MUST contain a value of zero for physical interfaces entries. Setting this object in row entries that correspond to physical interfaces returns the error 'wrongValue'.

TruthValue1 = true2 = falseRepresents a boolean value. · Integer32

Used to perform the copy of adjusted parameters from the temporary interface entry to the physical interface indicated by the docsIfUpChannelCloneFrom object. The transfer is initiated through an SNMP SET to 'true' of this object. A SET to 'true' fails and returns error 'commitFailed' if docsIfUpChannelStatus value is 'notInService', which means that the interface parameters values are not compatible with each other or have not been validated yet. Reading this object always returns 'false'.

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

This object is only used for the creation of a temporary upstream row with the purpose of updating the parameters of a physical upstream channel entry. The following restrictions apply to this object: 1. This object is not writable for physical interfaces. 2. Temporary interface entries are only created by a SET of this object to createandWait(5). 3. ifAdminStatus from the Interface MIB RFC 2863 is used to take a physical upstream channel offline, to be consistent with DOCSIS 1.x operation, as indicated in RFC 2670. In addition, o ifAdminStatus 'down' is reflected in this object as 'notInService'. o ifOperStatus 'down' while ifAdminStatus 'up' is reflected in this object as 'notInservice'. 4. Temporary created rows MUST be set to 'active' with the purpose of validating upstream parameter consistency prior to transferring the parameters to the physical interface. Below is a mandatory procedure for adjusting the values of a physical interface: 1. Create a temporary interface entry through an SNMP SET using 'createAndWait'. At this point, the RowStatus reports 'notReady'. The Manager entity uses an ifIndex value outside the operational range of the physical interfaces for the creation of a temporary interface. 2. Set the docsIfUpChannelCloneFrom object to the ifIndex value of the physical row to update. Now docsIfUpChannelStatus reports 'notInService'. 3. Change the upstream parameters to the desired values in the temporary row. 4. Validate that all parameters are consistent by setting docsIfUpChannelStatus to 'active'. A failure to set the RowStatus to 'active' returns the error 'commitFailed', which means the parameters are not compatible with the target physical interface. 5. With docsIfUpChannelStatus 'active', transfer the parameters to the target physical interface by setting the object docsIfUpChannelUpdate to 'true'. 6. Delete the temporary row by setting docsIfUpChannelStatus to 'destroy'.

TruthValue1 = true2 = falseRepresents a boolean value. · Integer32

At the CMTS, this object is used to enable or disable pre-equalization on the upstream channel represented by this table instance. At the CM, this object is read-only and reflects the status of pre-equalization as represented in the RNG-RSP. Pre-equalization is considered enabled at the CM if a RNG-RSP with pre-equalization data has been received at least once since the last mac reinitialization.

Integer32 (1..16383)

The index value that uniquely identifies an entry in the docsIfQosProfileTable.

Integer32 (0..7)

A relative priority assigned to this service when allocating bandwidth. Zero indicates lowest priority and seven indicates highest priority. Interpretation of priority is device-specific. MUST NOT be changed while this row is active. ⓘ

Integer32 (0..100000000) · bits per second

The maximum upstream bandwidth, in bits per second, allowed for a service with this service class. Zero if there is no restriction of upstream bandwidth. MUST NOT be changed while this row is active. ⓘ

Integer32 (0..100000000) · bits per second

Minimum guaranteed upstream bandwidth, in bits per second, allowed for a service with this service class. MUST NOT be changed while this row is active. ⓘ

Integer32 (0..100000000) · bits per second

The maximum downstream bandwidth, in bits per second, allowed for a service with this service class. Zero if there is no restriction of downstream bandwidth. MUST NOT be changed while this row is active. ⓘ

Integer32 (0..255) · mini-slots

The maximum number of mini-slots that may be requested for a single upstream transmission. A value of zero means there is no limit. MUST NOT be changed while this row is active. This object has been deprecated and replaced by docsIfQosProfMaxTransmitBurst, to fix a mismatch of the units and value range with respect to the DOCSIS Maximum Upstream Channel Transmit Burst Configuration Setting. ⓘ

TruthValue1 = true2 = falseRepresents a boolean value. · Integer32

Indicates whether Baseline Privacy is enabled for this service class. MUST NOT be changed while this row is active.

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

This is object is used to create or delete rows in this table. This object MUST NOT be changed from active while the row is referenced by any entry in either docsIfCmServiceTable (on the CM) or docsIfCmtsServiceTable (on the CMTS).

Integer32 (0..65535) · bytes

The maximum number of bytes that may be requested for a single upstream transmission. A value of zero means there is no limit. Note: This value does not include any physical layer overhead. MUST NOT be changed while this row is active. ⓘ

StorageType1 = other2 = volatile3 = nonVolatile4 = permanent5 = readOnlyDescribes 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 written. Conversely, if the value is either other(1), volatile(2) or nonVolatile(3), it cannot be modified to be permanent(4) or readOnly(5). (All illegal modifications result in a 'wrongValue' error.) 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. · Integer32

The storage type for this conceptual row. Entries with this object set to permanent(4) do not require write operations for writable objects.

TruthValue1 = true2 = falseRepresents a boolean value. · Integer32

true(1) if this CMTS includes contention intervals in the counters in this table. Always false(2) for CMs. ⓘ

Counter32 · codewords

Codewords received on this channel without error. This includes all codewords, whether or not they were part of frames destined for this device. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex. ⓘ

Counter32 · codewords

Codewords received on this channel with correctable errors. This includes all codewords, whether or not they were part of frames destined for this device. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex. ⓘ

Counter32 · codewords

Codewords received on this channel with uncorrectable errors. This includes all codewords, whether or not they were part of frames destined for this device. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex. ⓘ

TenthdBThis data type represents power levels that are normally expressed in dB. Units are in tenths of a dB; for example, 5.1 dB will be represented as 51. · Integer32 · hint d-1 · TenthdB

Signal/Noise ratio as perceived for this channel. At the CM, this object describes the Signal/Noise of the downstream channel. At the CMTS, it describes the average Signal/Noise of the upstream channel. ⓘ

Integer32 (0..255) · -dBc

Microreflections, including in-channel response as perceived on this interface, measured in dBc below the signal level. This object is not assumed to return an absolutely accurate value, but it gives a rough indication of microreflections received on this interface. It is up to the implementer to provide information as accurately as possible. ⓘ

DocsEqualizerDataThis data type represents the equalizer data as measured at the receiver interface. The format of the equalizer follows the structure of the Transmit Equalization Adjust RNG-RSP TLV of DOCSIS RFI v2.0 : 1 byte Main tap location 1..(n + m) 1 byte Number of forward taps per symbol 1 byte Number of forward taps: n 1 byte Number of reverse taps: m Following are the equalizer coefficients: First, forward taps coefficients: 2 bytes F1 (real), 2 bytes F1 (imag) ... 2 bytes Fn (real), 2 bytes Fn (imag) Then, reverse taps coefficients: 2 bytes D1 (real), 2 bytes D1 (imag) ... 2 bytes Dm (real), 2 bytes Dm (imag) The equalizer coefficients are considered signed 16-bit integers in the range from -32768 (0x8000) to 32767 (0x7FFF). DOCSIS specifications require up to a maximum of 64 equalizer taps (n + m); therefore, this object size can get up 260 bytes (4 + 4x64). The minimum object size (other than zero) for a t-spaced tap with a minimum of 8 symbols will be 36 (4 + 4x8).Reference: Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I10-051209, Figure 8-23. SIZE (0 | 36..260) · OCTET STRING

At the CM, this object returns the equalization data for the downstream channel. At the CMTS, this object is not applicable and is not instantiated. Note that previous CMTS implementations may instantiate this object in two ways: - An equalization value indicating an equalization average for the upstream channel. Those values have vendor-dependent interpretations. - Return a zero-length OCTET STRING to indicate that the value is unknown or if there is no equalization data available or defined. ⓘ

Counter64 (0..18446744073709551615) · codewords

Codewords received on this channel without error. This includes all codewords, whether or not they were part of frames destined for this device. This is the 64-bit version of docsIfSigQUnerroreds. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex. ⓘ

Counter64 (0..18446744073709551615) · codewords

Codewords received on this channel with correctable errors. This includes all codewords, whether or not they were part of frames destined for this device. This is the 64-bit version of docsIfSigQCorrecteds. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex. ⓘ

Counter64 (0..18446744073709551615) · codewords

Codewords received on this channel with uncorrectable errors. This includes all codewords, whether or not they were part of frames destined for this device. This is the 64-bit version of docsIfSigQUncorrectables. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex. ⓘ

MacAddressRepresents 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. SIZE (6) · OCTET STRING · hint 1x:

Identifies the CMTS that is believed to control this MAC domain. At the CM, this will be the source address from SYNC, MAP, and other MAC-layer messages. If the CMTS is unknown, returns 00-00-00-00-00-00. ⓘ

BITS

Identifies the capabilities of the MAC implementation at this interface. Note that packet transmission is always supported. Therefore, there is no specific bit required to explicitly indicate this capability. Note that BITS objects are encoded most significant bit first. For example, if bit 1 is set, the value of this object is the octet string '40'H.

TimeTicks

Waiting time for a Ranging Response packet. This object has been obsoleted and replaced by docsIfCmRangingTimeout to correct the typing to TimeInterval. ⓘ

TimeIntervalA period of time, measured in units of 0.01 seconds. (0..2147483647) · Integer32 · HundredOfSeconds

Waiting time for a Ranging Response packet. This object MUST NOT persist at reinitialization of the managed system. ⓘ

INTEGER1 = other2 = notReady3 = notSynchronized4 = phySynchronized5 = usParametersAcquired6 = rangingComplete7 = ipComplete8 = todEstablished9 = securityEstablished10 = paramTransferComplete11 = registrationComplete12 = operational13 = accessDenied · Integer32

Current Cable Modem connectivity state, as specified in the RF Interface Specification. Interpretations for state values 1-12 are clearly outlined in the SP-RFI reference given below. The state value accessDenied(13) indicates the CMTS has sent a Registration Aborted message to the CM. The same state is reported as accessDenied(7) by the CMTS object docsIfCmtsCmStatusValue. ⓘ

OCTET STRING SIZE (0 | 5 | 6)

Status code for a Cable Modem as defined in the OSSI Specification. The status code consists of a single character indicating error groups, followed by a two- or three-digit number indicating the status condition, followed by a decimal. An example of a returned value could be 'T101.0'. The zero-length OCTET STRING indicates no status code yet registered. ⓘ

TenthdBmVThis data type represents power levels that are normally expressed in dBmV. Units are in tenths of a dBmV; for example, 5.1 dBmV will be represented as 51. · Integer32 · hint d-1 · TenthdBmV

The operational transmit power for the attached upstream channel. ⓘ

Counter32 · resets

Number of times the CM reset or initialized this interface. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex.

Counter32

Number of times the CM lost synchronization with the downstream channel. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex. ⓘ

Counter32 · maps

Number of times the CM received invalid MAP messages. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex. ⓘ

Counter32 · messages

Number of times the CM received invalid UCD messages. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex. ⓘ

Counter32 · messages

Number of times the CM received invalid ranging response messages. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex. ⓘ

Counter32 · messages

Number of times the CM received invalid registration response messages. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex. ⓘ

Counter32 · timeouts

Number of times counter T1 expired in the CM. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex. ⓘ

Counter32 · timeouts

Number of times counter T2 expired in the CM. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex. ⓘ

Counter32 · timeouts

Number of times counter T3 expired in the CM. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex. ⓘ

Counter32 · timeouts

Number of times counter T4 expired in the CM. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex. ⓘ

Counter32 · attempts

Number of times the ranging process was aborted by the CMTS. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex. ⓘ

DocsisQosVersion1 = docsis102 = docsis11Indicates the referenced quality-of-service level. 'docsis10 refers to DOCSIS 1.0 Class of Service queuing services, and 'docsis11' refers to DOCSIS 1.1 Quality of Service. · Integer32

Indication of whether the device has registered using 1.0 Class of Service or 1.1 Quality of Service. An unregistered CM SHOULD indicate 'docsis11' for a docsIfDocsisBaseCapability value of DOCSIS 1.1/2.0. An unregistered CM SHOULD indicate 'docsis10' for a docsIfDocsisBaseCapability value of DOCSIS 1.0. ⓘ

DocsisUpstreamType0 = unknown1 = tdma2 = atdma3 = scdma4 = tdmaAndAtdmaIndicates the DOCSIS Upstream Channel Type. 'unknown' means information not available. 'tdma' is related to TDMA, Time Division Multiple Access; 'atdma' is related to A-TDMA, Advanced Time Division Multiple Access, 'scdma' is related to S-CDMA, Synchronous Code Division Multiple Access. 'tdmaAndAtdma is related to simultaneous support of TDMA and A-TDMA modes. · Integer32

Indicates modulation type status currently used by the CM. Since this object specifically identifies PHY mode, the shared upstream channel type is not permitted. ⓘ

DocsEqualizerDataThis data type represents the equalizer data as measured at the receiver interface. The format of the equalizer follows the structure of the Transmit Equalization Adjust RNG-RSP TLV of DOCSIS RFI v2.0 : 1 byte Main tap location 1..(n + m) 1 byte Number of forward taps per symbol 1 byte Number of forward taps: n 1 byte Number of reverse taps: m Following are the equalizer coefficients: First, forward taps coefficients: 2 bytes F1 (real), 2 bytes F1 (imag) ... 2 bytes Fn (real), 2 bytes Fn (imag) Then, reverse taps coefficients: 2 bytes D1 (real), 2 bytes D1 (imag) ... 2 bytes Dm (real), 2 bytes Dm (imag) The equalizer coefficients are considered signed 16-bit integers in the range from -32768 (0x8000) to 32767 (0x7FFF). DOCSIS specifications require up to a maximum of 64 equalizer taps (n + m); therefore, this object size can get up 260 bytes (4 + 4x64). The minimum object size (other than zero) for a t-spaced tap with a minimum of 8 symbols will be 36 (4 + 4x8).Reference: Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I10-051209, Figure 8-23. SIZE (0 | 36..260) · OCTET STRING

Pre-equalization data for this CM after convolution with data indicated in the RNG-RSP. This data is valid when docsIfUpChannelPreEqEnable is set to true. ⓘ

Counter32 · attempts

The number of successful Upstream Channel Change transactions. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex.

Counter32 · attempts

The number of failed Upstream Channel Change transactions. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex.

Integer32 (1..16383)

Identifies a service queue for upstream bandwidth. The attributes of this service queue are shared between the CM and the CMTS. The CMTS allocates upstream bandwidth to this service queue based on requests from the CM and on the class of service associated with this queue.

Integer32 (0..16383)

The index in docsIfQosProfileTable describing the quality of service attributes associated with this particular service. If no associated entry in docsIfQosProfileTable exists, this object returns a value of zero.

Counter32 · mini-slots

The number of upstream mini-slots that have been used to transmit data PDUs in immediate (contention) mode. This includes only those PDUs that are presumed to have arrived at the head-end (i.e., those that were explicitly acknowledged). It does not include retransmission attempts or mini-slots used by requests. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex. ⓘ

Counter32 · mini-slots

The number of upstream mini-slots that have been used to transmit data PDUs in dedicated mode (i.e., as a result of a unicast Data Grant). Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex. ⓘ

Counter32 · attempts

The number of attempts to transmit data PDUs containing requests for acknowledgment that did not result in acknowledgment. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex. ⓘ

Counter32 · attempts

The number of data PDU transmission failures due to excessive retries without acknowledgment. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex. ⓘ

Counter32 · attempts

The number of attempts to transmit bandwidth requests that did not result in acknowledgment. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex. ⓘ

Counter32 · attempts

The number of requests for bandwidth that failed due to excessive retries without acknowledgment. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex. ⓘ

Counter64 (0..18446744073709551615) · mini-slots

The number of upstream mini-slots that have been used to transmit data PDUs in immediate (contention) mode. This includes only those PDUs that are presumed to have arrived at the head-end (i.e., those that were explicitly acknowledged). It does not include retransmission attempts or mini-slots used by requests. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex. ⓘ

Counter64 (0..18446744073709551615) · mini-slots

The number of upstream mini-slots that have been used to transmit data PDUs in dedicated mode (i.e., as a result of a unicast Data Grant). Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex. ⓘ

BITS

Identifies the capabilities of the CMTS MAC implementation at this interface. Note that packet transmission is always supported. Therefore, there is no specific bit required to explicitly indicate this capability. Note that BITS objects are encoded most significant bit first. For example, if bit 1 is set, the value of this object is the octet string '40'H.

Integer32 (1..200) · Milliseconds

The interval between CMTS transmission of successive SYNC messages at this interface. ⓘ

Integer32 (1..2000) · Milliseconds

The interval between CMTS transmission of successive Upstream Channel Descriptor messages for each upstream channel at this interface. ⓘ

Integer32 (1..16383) · SIDs

The maximum number of service IDs that may be simultaneously active.

TimeTicks

The amount of time to elapse between each broadcast initial maintenance grant. Broadcast initial maintenance grants are used to allow new cable modems to join the network. Zero indicates that a vendor-specific algorithm is used instead of a fixed time. The maximum amount of time permitted by the specification is 2 seconds. This object has been obsoleted and replaced by docsIfCmtsInsertInterval to fix a SYNTAX typing problem. ⓘ

Integer32 (0..1024) · attempts

The maximum number of attempts to make on invitations for ranging requests. A value of zero means the system SHOULD attempt to range forever. ⓘ

TimeIntervalA period of time, measured in units of 0.01 seconds. (0..2147483647) · Integer32 · HundredOfSeconds

The amount of time to elapse between each broadcast initial maintenance grant. Broadcast initial maintenance grants are used to allow new cable modems to join the network. Zero indicates that a vendor-specific algorithm is used instead of a fixed time. The maximum amount of time permitted by the specification is 2 seconds. ⓘ

StorageType1 = other2 = volatile3 = nonVolatile4 = permanent5 = readOnlyDescribes 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 written. Conversely, if the value is either other(1), volatile(2) or nonVolatile(3), it cannot be modified to be permanent(4) or readOnly(5). (All illegal modifications result in a 'wrongValue' error.) 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. · Integer32

The storage type for this conceptual row. Entries with this object set to permanent(4) do not require write operations for read-write objects.

Counter32 · messages

This object counts invalid RNG-REQ messages received on this interface. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex. ⓘ

Counter32 · attempts

This object counts ranging attempts that were explicitly aborted by the CMTS. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex. ⓘ

Counter32 · messages

This object counts invalid REG-REQ messages received on this interface; that is, syntax, out of range parameters, or erroneous requests. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex. ⓘ

Counter32 · attempts

This object counts failed registration attempts. Included are docsIfCmtsStatusInvalidRegReqs, authentication, and class of service failures. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex. ⓘ

Counter32 · messages

This object counts invalid data request messages received on this interface. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex.

Counter32 · timeouts

This object counts the number of times counter T5 expired on this interface. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex. ⓘ

Integer32 (1..2147483647)

Index value to uniquely identify an entry in this table. For an individual cable modem, this index value SHOULD NOT change during CMTS uptime.

MacAddressRepresents 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. SIZE (6) · OCTET STRING · hint 1x:

MAC address of the cable modem. If the cable modem has multiple MAC addresses, this is the MAC address associated with the Cable interface. ⓘ

IpAddress SIZE (4)

IP address of this cable modem. If the cable modem has no IP address assigned, or the IP address is unknown, this object returns a value of 0.0.0.0. If the cable modem has multiple IP addresses, this object returns the IP address associated with the Cable interface. This object has been deprecated and replaced by docsIfCmtsCmStatusInetAddressType and docsIfCmtsCmStatusInetAddress, to enable IPv6 addressing in the future.

InterfaceIndexOrZeroThis textual convention is an extension of the InterfaceIndex convention. The latter defines a greater than zero value used to identify an interface or interface sub-layer in the managed system. This extension permits the additional value of zero. the value zero is object-specific and must therefore be defined as part of the description of any object which uses this syntax. Examples of the usage of zero might include situations where interface was unknown, or when none or all interfaces need to be referenced. (0..2147483647) · Integer32 · hint d

IfIndex of the downstream channel that this CM is connected to. If the downstream channel is unknown, this object returns a value of zero.

InterfaceIndexOrZeroThis textual convention is an extension of the InterfaceIndex convention. The latter defines a greater than zero value used to identify an interface or interface sub-layer in the managed system. This extension permits the additional value of zero. the value zero is object-specific and must therefore be defined as part of the description of any object which uses this syntax. Examples of the usage of zero might include situations where interface was unknown, or when none or all interfaces need to be referenced. (0..2147483647) · Integer32 · hint d

For DOCSIS 2.0, indicates the ifIndex of the logical upstream channel (ifType 205) this CM is connected to. For DOCSIS 1.x, indicates the ifIndex of the upstream channel (ifType 129) this CM is connected to. If the upstream channel is unknown, this object returns a value of zero.

TenthdBmVThis data type represents power levels that are normally expressed in dBmV. Units are in tenths of a dBmV; for example, 5.1 dBmV will be represented as 51. · Integer32 · hint d-1 · ThenthdBmV

The receive power as perceived for upstream data from this cable modem. If the receive power is unknown, this object returns a value of zero. ⓘ

Unsigned32

A measure of the current round trip time for this CM. Used for timing of CM upstream transmissions to ensure synchronized arrivals at the CMTS. Units are in terms of (6.25 microseconds/64). Returns zero if the value is unknown. For channels requiring finer resolution, please refer to object docsIfCmtsCmStatusHighResolutionTimingOffset. ⓘ

DocsEqualizerDataThis data type represents the equalizer data as measured at the receiver interface. The format of the equalizer follows the structure of the Transmit Equalization Adjust RNG-RSP TLV of DOCSIS RFI v2.0 : 1 byte Main tap location 1..(n + m) 1 byte Number of forward taps per symbol 1 byte Number of forward taps: n 1 byte Number of reverse taps: m Following are the equalizer coefficients: First, forward taps coefficients: 2 bytes F1 (real), 2 bytes F1 (imag) ... 2 bytes Fn (real), 2 bytes Fn (imag) Then, reverse taps coefficients: 2 bytes D1 (real), 2 bytes D1 (imag) ... 2 bytes Dm (real), 2 bytes Dm (imag) The equalizer coefficients are considered signed 16-bit integers in the range from -32768 (0x8000) to 32767 (0x7FFF). DOCSIS specifications require up to a maximum of 64 equalizer taps (n + m); therefore, this object size can get up 260 bytes (4 + 4x64). The minimum object size (other than zero) for a t-spaced tap with a minimum of 8 symbols will be 36 (4 + 4x8).Reference: Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I10-051209, Figure 8-23. SIZE (0 | 36..260) · OCTET STRING

Equalization data for this CM, as measured by the CMTS. Returns the zero-length OCTET STRING if the value is unknown or if there is no equalization data available or defined. ⓘ

INTEGER1 = other2 = ranging3 = rangingAborted4 = rangingComplete5 = ipComplete6 = registrationComplete7 = accessDenied8 = operational9 = registeredBPIInitializing · Integer32

Current cable modem connectivity state, as specified in the RF Interface Specification. Returned status information is the CM status, as assumed by the CMTS, and indicates the following events: other(1) Any state other than below. ranging(2) The CMTS has received an Initial Ranging Request message from the CM, and the ranging process is not yet complete. rangingAborted(3) The CMTS has sent a Ranging Abort message to the CM. rangingComplete(4) The CMTS has sent a Ranging Complete message to the CM. ipComplete(5) The CMTS has received a DHCP reply message and forwarded it to the CM. registrationComplete(6) The CMTS has sent a Registration Response message to the CM. accessDenied(7) The CMTS has sent a Registration Aborted message to the CM. operational(8) Value 8 is considered reserved and should not be defined in future revisions of this MIB module to avoid conflict with documented implementations that support value 8 to indicate operational state after completing the BPI initialization process. registeredBPIInitializing(9) Baseline Privacy (BPI) is enabled and the CMTS is in the process of completing BPI initialization. This state MAY last for a significant length of time if failures occur during the initialization process. After completion of BPI initialization, the CMTS will report registrationComplete(6). The CMTS only needs to report states it is able to detect. ⓘ

Counter32 · codewords

Codewords received without error from this cable modem. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex. ⓘ

Counter32 · codewords

Codewords received with correctable errors from this cable modem. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex. ⓘ

Counter32 · codewords

Codewords received with uncorrectable errors from this cable modem. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex. ⓘ

TenthdBThis data type represents power levels that are normally expressed in dB. Units are in tenths of a dB; for example, 5.1 dB will be represented as 51. · Integer32 · hint d-1 · TenthdB

Signal/Noise ratio as perceived for upstream data from this cable modem. If the Signal/Noise is unknown, this object returns a value of zero. ⓘ

Integer32 (0..255) · -dBc

Total microreflections, including in-channel response as perceived on this interface, measured in dBc below the signal level. This object is not assumed to return an absolutely accurate value, but it gives a rough indication of microreflections received on this interface. It is up to the implementer to provide information as accurately as possible. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex. ⓘ

Counter64 (0..18446744073709551615) · codewords

Codewords received without error from this cable modem. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex. ⓘ

Counter64 (0..18446744073709551615) · codewords

Codewords received with correctable errors from this cable modem. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex. ⓘ

Counter64 (0..18446744073709551615) · codewords

Codewords received with uncorrectable errors from this cable modem. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex. ⓘ

DocsisQosVersion1 = docsis102 = docsis11Indicates the referenced quality-of-service level. 'docsis10 refers to DOCSIS 1.0 Class of Service queuing services, and 'docsis11' refers to DOCSIS 1.1 Quality of Service. · Integer32

Indication of whether the CM has registered using 1.0 Class of Service or 1.1 Quality of Service. ⓘ

DocsisUpstreamType0 = unknown1 = tdma2 = atdma3 = scdma4 = tdmaAndAtdmaIndicates the DOCSIS Upstream Channel Type. 'unknown' means information not available. 'tdma' is related to TDMA, Time Division Multiple Access; 'atdma' is related to A-TDMA, Advanced Time Division Multiple Access, 'scdma' is related to S-CDMA, Synchronous Code Division Multiple Access. 'tdmaAndAtdma is related to simultaneous support of TDMA and A-TDMA modes. · Integer32

Indicates modulation type currently used by the CM. Since this object specifically identifies PHY mode, the shared type is not permitted. If the upstream channel is unknown, this object returns a value of zero. ⓘ

InetAddressType0 = unknown1 = ipv42 = ipv63 = ipv4z4 = ipv6z16 = dnsA value that represents a type of Internet address. unknown(0) An unknown address type. This value MUST be used if the value of the corresponding InetAddress object is a zero-length string. It may also be used to indicate an IP address that is not in one of the formats defined below. ipv4(1) An IPv4 address as defined by the InetAddressIPv4 textual convention. ipv6(2) An IPv6 address as defined by the InetAddressIPv6 textual convention. ipv4z(3) A non-global IPv4 address including a zone index as defined by the InetAddressIPv4z textual convention. ipv6z(4) A non-global IPv6 address including a zone index as defined by the InetAddressIPv6z textual convention. dns(16) A DNS domain name as defined by the InetAddressDNS textual convention. Each definition of a concrete InetAddressType value must be accompanied by a definition of a textual convention for use with that InetAddressType. To support future extensions, the InetAddressType textual convention SHOULD NOT be sub-typed in object type definitions. It MAY be sub-typed in compliance statements in order to require only a subset of these address types for a compliant implementation. Implementations must ensure that InetAddressType objects and any dependent objects (e.g., InetAddress objects) are consistent. An inconsistentValue error must be generated if an attempt to change an InetAddressType object would, for example, lead to an undefined InetAddress value. In particular, InetAddressType/InetAddress pairs must be changed together if the address type changes (e.g., from ipv6(2) to ipv4(1)). · Integer32

The type of internet address of docsIfCmtsCmStatusInetAddress. If the cable modem internet address is unassigned or unknown, then the value of this object is unknown(0).

InetAddressDenotes a generic Internet address. An InetAddress value is always interpreted within the context of an InetAddressType value. Every usage of the InetAddress textual convention is required to specify the InetAddressType object that provides the context. It is suggested that the InetAddressType object be logically registered before the object(s) that use the InetAddress textual convention, if they appear in the same logical row. The value of an InetAddress object must always be consistent with the value of the associated InetAddressType object. Attempts to set an InetAddress object to a value inconsistent with the associated InetAddressType must fail with an inconsistentValue error. When this textual convention is used as the syntax of an index object, there may be issues with the limit of 128 sub-identifiers specified in SMIv2, STD 58. In this case, the object definition MUST include a 'SIZE' clause to limit the number of potential instance sub-identifiers; otherwise the applicable constraints MUST be stated in the appropriate conceptual row DESCRIPTION clauses, or in the surrounding documentation if there is no single DESCRIPTION clause that is appropriate. SIZE (0..255) · OCTET STRING

Internet address of this cable modem. If the Cable Modem has no Internet address assigned, or the Internet address is unknown, the value of this object is the zero-length OCTET STRING. If the cable modem has multiple Internet addresses, this object returns the Internet address associated with the Cable (i.e., RF MAC) interface.

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 docsIfCmtsCmStatusValue was last updated.

Unsigned32

A measure of the current round trip time for this CM. Used for timing of CM upstream transmissions to ensure synchronized arrivals at the CMTS. Units are in terms of (6.25 microseconds/(64*256)). Returns zero if the value is unknown. This is the high resolution version of object docsIfCmtsCmStatusTimingOffset, for channels requiring finer resolution. ⓘ

Integer32 (1..16383)

Identifies a service queue for upstream bandwidth. The attributes of this service queue are shared between the Cable Modem and the Cable Modem Termination System. The CMTS allocates upstream bandwidth to this service queue based on requests from the CM and on the class of service associated with this queue.

Integer32 (0..65535)

Pointer to an entry in docsIfCmtsCmStatusTable identifying the cable modem using this Service Queue. If multiple cable modems are using this Service Queue, the value of this object is zero. This object has been deprecated and replaced by docsIfCmtsServiceNewCmStatusIndex, to fix a mismatch of the value range with respect to docsIfCmtsCmStatusIndex (1..2147483647).

INTEGER1 = enabled2 = disabled3 = destroyed · Integer32

Allows a service class for a particular modem to be suppressed, (re-)enabled, or deleted altogether.

Integer32 (0..16383)

The index in docsIfQosProfileTable describing the quality of service attributes associated with this particular service. If no associated docsIfQosProfileTable entry exists, this object returns a value of zero.

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 entry was created.

Counter32 · Bytes

The cumulative number of Packet Data octets received on this Service ID. The count does not include the size of the Cable MAC header. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex.

Counter32 · packets

The cumulative number of Packet Data packets received on this Service ID. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex.

Integer32 (0..2147483647)

Pointer (via docsIfCmtsCmStatusIndex) to an entry in docsIfCmtsCmStatusTable identifying the cable modem using this Service Queue. If multiple cable modems are using this Service Queue, the value of this object is zero.

Integer32 (1..2147483647)

An index into the Channel Modulation table representing a group of Interval Usage Codes, all associated with the same channel.

INTEGER1 = request2 = requestData3 = initialRanging4 = periodicRanging5 = shortData6 = longData9 = advPhyShortData10 = advPhyLongData11 = ugs · Integer32

An index into the Channel Modulation table that, when grouped with other Interval Usage Codes, fully instantiates all modulation sets for a given upstream channel. ⓘ

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

Controls and reflects the status of rows in this table. There is no restriction on the changing of values in this table while their associated rows are active, with the exception of: 1. If a modulation profile is being referenced by one or more upstream channels, an attempt to set the value of docsIfCmtsModChannelType returns an 'inconsistentValue' error. 2. If a modulation profile is being referenced by one or more upstream channels, an attempt to set docsIfCmtsModControl to destroy(6) or notInService(2) returns an 'inconsistentValue' error.

INTEGER1 = other2 = qpsk3 = qam164 = qam85 = qam326 = qam647 = qam128 · Integer32

The modulation type used on this channel. Returns other(1) if the modulation type is not qpsk, qam16, qam8, qam32, qam64, or qam128. Type qam128 is used for SCDMA channels only. See the reference for the modulation profiles implied by different modulation types. ⓘ

Integer32 (0..1536) · bits

The preamble length for this modulation profile in bits. Default value is the minimum needed by the implementation at the CMTS for the given modulation profile. ⓘ

TruthValue1 = true2 = falseRepresents a boolean value. · Integer32

Specifies whether or not differential encoding is used on this channel. ⓘ

Integer32 (0..16) · Bytes

The number of correctable errored bytes (t) used in forward error correction code. The value of 0 indicates that no correction is employed. The number of check bytes appended will be twice this value. ⓘ

Integer32 (1..255) · Bytes

The number of data bytes (k) in the forward error correction codeword. This object is not used if docsIfCmtsModFECErrorCorrection is zero. ⓘ

Integer32 (0..32767)

The 15-bit seed value for the scrambler polynomial. ⓘ

Integer32 (0..255) · mini-slots

The maximum number of mini-slots that can be transmitted during this channel's burst time. Returns zero if the burst length is bounded by the allocation MAP rather than by this profile. Default value is 0, except for shortData, where it is 8. ⓘ

Unsigned32 · Symbol-times

The number of symbol-times that MUST follow the end of this channel's burst. Default value is the minimum time needed by the implementation for this modulation profile. ⓘ

TruthValue1 = true2 = falseRepresents a boolean value. · Integer32

Indicates whether the last FEC codeword is truncated. ⓘ

TruthValue1 = true2 = falseRepresents a boolean value. · Integer32

Indicates whether the scrambler is employed. ⓘ

Unsigned32

ATDMA Byte Interleaver Depth (Ir). This object returns 1 for non-ATDMA profiles. ⓘ

Unsigned32

ATDMA Byte Interleaver Block size (Br). This object returns zero for non-ATDMA profiles ⓘ

INTEGER0 = unknown1 = qpsk02 = qpsk1 · Integer32

Preamble type for DOCSIS 2.0 bursts. The value 'unknown(0)' represents a row entry consisting only of DOCSIS 1.x bursts ⓘ

TruthValue1 = true2 = falseRepresents a boolean value. · Integer32

Trellis Code Modulation (TCM) On/Off. This value returns false for non-S-CDMA profiles. ⓘ

Unsigned32 (0 | 1..32)

S-CDMA Interleaver step size. This value returns zero for non-S-CDMA profiles. ⓘ

TruthValue1 = true2 = falseRepresents a boolean value. · Integer32

S-CDMA spreader. This value returns false for non-S-CDMA profiles. Default value for IUC 3 and 4 is OFF; for all other IUCs it is ON. ⓘ

Unsigned32 (0 | 1..128)

S-CDMA sub-frame size. This value returns zero for non-S-CDMA profiles. ⓘ

DocsisUpstreamType0 = unknown1 = tdma2 = atdma3 = scdma4 = tdmaAndAtdmaIndicates the DOCSIS Upstream Channel Type. 'unknown' means information not available. 'tdma' is related to TDMA, Time Division Multiple Access; 'atdma' is related to A-TDMA, Advanced Time Division Multiple Access, 'scdma' is related to S-CDMA, Synchronous Code Division Multiple Access. 'tdmaAndAtdma is related to simultaneous support of TDMA and A-TDMA modes. · Integer32

Describes the modulation channel type for this modulation entry. All the active entries in a modulation profile (that is all active entries that share a common docsIfCmtsModIndex) MUST have the same value of docsIfCmtsModChannelType. ⓘ

StorageType1 = other2 = volatile3 = nonVolatile4 = permanent5 = readOnlyDescribes 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 written. Conversely, if the value is either other(1), volatile(2) or nonVolatile(3), it cannot be modified to be permanent(4) or readOnly(5). (All illegal modifications result in a 'wrongValue' error.) 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. · Integer32

The storage type for this conceptual row. Entries with this object set to permanent(4) do not require write operations for read-write objects.

MacAddressRepresents 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. SIZE (6) · OCTET STRING · hint 1x:

The RF side MAC address for the referenced CM (e.g., the interface on the CM that has docsCableMacLayer(127) as its ifType).

Integer32 (1..2147483647)

An row index into docsIfCmtsCmStatusTable. When queried with the correct instance value (e.g., a CM's MAC address), returns the index in docsIfCmtsCmStatusTable that represents that CM.

IANAifType1 = other2 = regular18223 = hdh18224 = ddnX255 = rfc877x256 = ethernetCsmacd7 = iso88023Csmacd8 = iso88024TokenBus9 = iso88025TokenRing10 = iso88026Man11 = starLan12 = proteon10Mbit13 = proteon80Mbit14 = hyperchannel15 = fddi16 = lapb17 = sdlc18 = ds119 = e120 = basicISDN21 = primaryISDN22 = propPointToPointSerial23 = ppp24 = softwareLoopback25 = eon26 = ethernet3Mbit27 = nsip28 = slip29 = ultra30 = ds331 = sip32 = frameRelay33 = rs23234 = para35 = arcnet36 = arcnetPlus37 = atm38 = miox2539 = sonet40 = x25ple41 = iso88022llc42 = localTalk43 = smdsDxi44 = frameRelayService45 = v3546 = hssi47 = hippi48 = modem49 = aal550 = sonetPath51 = sonetVT52 = smdsIcip53 = propVirtual54 = propMultiplexor55 = ieee8021256 = fibreChannel57 = hippiInterface58 = frameRelayInterconnect59 = aflane802360 = aflane802561 = cctEmul62 = fastEther63 = isdn64 = v1165 = v3666 = g703at64k67 = g703at2mb68 = qllc69 = fastEtherFX70 = channel71 = ieee8021172 = ibm370parChan73 = escon74 = dlsw75 = isdns76 = isdnu77 = lapd78 = ipSwitch79 = rsrb80 = atmLogical81 = ds082 = ds0Bundle83 = bsc84 = async85 = cnr86 = iso88025Dtr87 = eplrs88 = arap89 = propCnls90 = hostPad91 = termPad92 = frameRelayMPI93 = x21394 = adsl95 = radsl96 = sdsl97 = vdsl98 = iso88025CRFPInt99 = myrinet100 = voiceEM101 = voiceFXO102 = voiceFXS103 = voiceEncap104 = voiceOverIp105 = atmDxi106 = atmFuni107 = atmIma108 = pppMultilinkBundle109 = ipOverCdlc110 = ipOverClaw111 = stackToStack112 = virtualIpAddress113 = mpc114 = ipOverAtm115 = iso88025Fiber116 = tdlc117 = gigabitEthernet118 = hdlc119 = lapf120 = v37121 = x25mlp122 = x25huntGroup123 = transpHdlc124 = interleave125 = fast126 = ip127 = docsCableMaclayer128 = docsCableDownstream129 = docsCableUpstream130 = a12MppSwitch131 = tunnel132 = coffee133 = ces134 = atmSubInterface135 = l2vlan136 = l3ipvlan137 = l3ipxvlan138 = digitalPowerline139 = mediaMailOverIp140 = dtm141 = dcn142 = ipForward143 = msdsl144 = ieee1394145 = if-gsn146 = dvbRccMacLayer147 = dvbRccDownstream148 = dvbRccUpstream149 = atmVirtual150 = mplsTunnel151 = srp152 = voiceOverAtm153 = voiceOverFrameRelay154 = idsl155 = compositeLink156 = ss7SigLink157 = propWirelessP2P158 = frForward159 = rfc1483160 = usb161 = ieee8023adLag162 = bgppolicyaccounting163 = frf16MfrBundle164 = h323Gatekeeper165 = h323Proxy166 = mpls167 = mfSigLink168 = hdsl2169 = shdsl170 = ds1FDL171 = pos172 = dvbAsiIn173 = dvbAsiOut174 = plc175 = nfas176 = tr008177 = gr303RDT178 = gr303IDT179 = isup180 = propDocsWirelessMaclayer181 = propDocsWirelessDownstream182 = propDocsWirelessUpstream183 = hiperlan2184 = propBWAp2Mp185 = sonetOverheadChannel186 = digitalWrapperOverheadChannel187 = aal2188 = radioMAC189 = atmRadio190 = imt191 = mvl192 = reachDSL193 = frDlciEndPt194 = atmVciEndPt195 = opticalChannel196 = opticalTransport197 = propAtm198 = voiceOverCable199 = infiniband200 = teLink201 = q2931202 = virtualTg203 = sipTg204 = sipSig205 = docsCableUpstreamChannel206 = econet207 = pon155208 = pon622209 = bridge210 = linegroup211 = voiceEMFGD212 = voiceFGDEANA213 = voiceDID214 = mpegTransport215 = sixToFour216 = gtp217 = pdnEtherLoop1218 = pdnEtherLoop2219 = opticalChannelGroup220 = homepna221 = gfp222 = ciscoISLvlan223 = actelisMetaLOOP224 = fcipLink225 = rpr226 = qam227 = lmp228 = cblVectaStar229 = docsCableMCmtsDownstream230 = adsl2231 = macSecControlledIF232 = macSecUncontrolledIF233 = aviciOpticalEther234 = atmbond235 = voiceFGDOS236 = mocaVersion1237 = ieee80216WMAN238 = adsl2plus239 = dvbRcsMacLayer240 = dvbTdm241 = dvbRcsTdma242 = x86Laps243 = wwanPP244 = wwanPP2245 = voiceEBS246 = ifPwType247 = ilan248 = pip249 = aluELP250 = gpon251 = vdsl2252 = capwapDot11Profile253 = capwapDot11Bss254 = capwapWtpVirtualRadio255 = bits256 = docsCableUpstreamRfPort257 = cableDownstreamRfPort258 = vmwareVirtualNic259 = ieee802154260 = otnOdu261 = otnOtu262 = ifVfiType263 = g9981264 = g9982265 = g9983266 = aluEpon267 = aluEponOnu268 = aluEponPhysicalUni269 = aluEponLogicalLink270 = aluGponOnu271 = aluGponPhysicalUni272 = vmwareNicTeam277 = docsOfdmDownstream278 = docsOfdmaUpstream279 = gfast280 = sdci281 = xboxWireless282 = fastdsl283 = docsCableScte55d1FwdOob284 = docsCableScte55d1RetOob285 = docsCableScte55d2DsOob286 = docsCableScte55d2UsOob287 = docsCableNdf288 = docsCableNdr289 = ptm290 = ghn291 = otnOtsi292 = otnOtuc293 = otnOduc294 = otnOtsig295 = microwaveCarrierTermination296 = microwaveRadioLinkTerminal297 = ieee8021axDrni298 = ax25299 = ieee19061nanocomThis data type is used as the syntax of the ifType object in the (updated) definition of MIB-II's ifTable. The definition of this textual convention with the addition of newly assigned values is published periodically by the IANA, in either the Assigned Numbers RFC, or some derivative of it specific to Internet Network Management number assignments. (The latest arrangements can be obtained by contacting the IANA.) Interface types must not be directly added to the IANAifType-MIB MIB module. They must instead be added to the 'ifType definitions' registry at https://www.iana.org/assignments/smi-numbers. The relationship between the assignment of ifType values and of OIDs to particular media-specific MIBs is solely the purview of IANA and is subject to change without notice. Quite often, a media-specific MIB's OID-subtree assignment within MIB-II's 'transmission' subtree will be the same as its ifType value. However, in some circumstances this will not be the case, and implementors must not pre-assume any specific relationship between ifType values and transmission subtree OIDs. · Integer32

The secondary index into this table. Indicates the IANA interface type associated with this physical channel. Only docsCableDownstream (128) and docsCableUpstream (129) are valid.

Integer32 (0..255)

The tertiary index into this table. Indicates the CMTS identifier for this physical channel.

Integer32 (0..100) · percent

The calculated and truncated utilization index for this physical upstream or downstream channel, accurate as of the most recent docsIfCmtsChannelUtilizationInterval. Upstream Channel Utilization Index: The upstream channel utilization index is expressed as a percentage of mini-slots utilized on the physical channel, regardless of burst type. For an Initial Maintenance region, the mini-slots for the complete region are considered utilized if the CMTS received an upstream burst within the region from any CM on the physical channel. For contention REQ and REQ/DATA regions, the mini-slots for a transmission opportunity within the region are considered utilized if the CMTS received an upstream burst within the opportunity from any CM on the physical channel. For all other regions, utilized mini-slots are those in which the CMTS granted bandwidth to any unicast SID on the physical channel. For an upstream interface that has multiple logical upstream channels enabled, the utilization index is a weighted sum of utilization indices for the logical channels. The weight for each utilization index is the percentage of upstream mini-slots allocated for the corresponding logical channel. Example: If 75% of bandwidth is allocated to the first logical channel and 25% to the second, and the utilization indices for each are 60 and 40, respectively, the utilization index for the upstream physical channel is (60 * 0.75) + (40 * 0.25) = 55. This figure applies to the most recent utilization interval. Downstream Channel Utilization Index: The downstream channel utilization index is a percentage expressing the ratio between bytes used to transmit data versus the total number of bytes transmitted in the raw bandwidth of the MPEG channel. As with the upstream utilization index, the calculated value represents the most recent utilization interval. Formula: Downstream utilization index = (100 * (data bytes / raw bytes)) Definitions: Data bytes: Number of bytes transmitted as data in the docsIfCmtsChannelUtilizationInterval. Identical to docsIfCmtsDownChannelCtrUsed Bytes measured over the utilization interval. Raw bandwidth: Total number of bytes available for transmitting data, not including bytes used for headers and other overhead. Raw bytes: (raw bandwidth * docsIfCmtsChannelUtilizationInterval). Identical to docsIfCmtsDownChannelCtrTotal Bytes measured over the utilization interval.

Integer32 (0..255)

The Cable Modem Termination System identification of the downstream channel within this particular MAC interface. If the interface is down, the object returns the most current value. If the downstream channel ID is unknown, this object returns a value of 0.

Counter32 · Bytes

At the CMTS, the total number of bytes in the Payload portion of MPEG Packets (i.e., not including MPEG header or pointer_field) transported by this downstream channel. This is the 32-bit version of docsIfCmtsDownChnlCtrExtTotalBytes, included to provide back compatibility with SNMPv1 managers. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex.

Counter32 · Bytes

At the CMTS, the total number of DOCSIS data bytes transported by this downstream channel. The number of data bytes is defined as the total number of bytes transported in DOCSIS payloads minus the number of stuff bytes transported in DOCSIS payloads. This is the 32-bit version of docsIfCmtsDownChnlCtrExtUsedBytes, included to provide back compatibility with SNMPv1 managers. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex.

Counter64 (0..18446744073709551615) · Bytes

At the CMTS, the total number of bytes in the Payload portion of MPEG Packets (i.e., not including MPEG header or pointer_field) transported by this downstream channel. This is the 64-bit version of docsIfCmtsDownChnlCtrTotalBytes and will not be accessible to SNMPv1 managers. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex.

Counter64 (0..18446744073709551615) · Bytes

At the CMTS, the total number of DOCSIS data bytes transported by this downstream channel. The number of data bytes is defined as the total number of bytes transported in DOCSIS payloads minus the number of stuff bytes transported in DOCSIS payloads. This is the 64-bit version of docsIfCmtsDownChnlCtrUsedBytes and will not be accessible to SNMPv1 managers. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex.

Integer32 (0..255)

The CMTS identification of the upstream channel.

Counter32 · mini-slots

Current count, from CMTS initialization, of all mini-slots defined for this upstream logical channel. This count includes all IUCs and SIDs, even those allocated to the NULL SID for a 2.0 logical channel that is inactive. This is the 32-bit version of docsIfCmtsUpChnlCtrExtTotalMslots and is included for back compatibility with SNMPv1 managers. Support for this object is mandatory. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex.

Counter32 · mini-slots

Current count, from CMTS initialization, of unicast granted mini-slots on the upstream logical channel, regardless of burst type. Unicast granted mini-slots are those in which the CMTS assigned bandwidth to any unicast SID on the logical channel. However, this object does not include minis-lots for reserved IUCs, or grants to SIDs designated as meaning 'no CM'. This is the 32-bit version of docsIfCmtsUpChnlCtrExtUcastGrantedMslots, and is included for back compatibility with SNMPv1 managers. Support for this object is mandatory. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex.

Counter32 · mini-slots

Current count, from CMTS initialization, of contention mini-slots defined for this upstream logical channel. This count includes all mini-slots assigned to a broadcast or multicast SID on the logical channel. This is the 32-bit version of docsIfCmtsUpChnlCtrExtTotalCntnMslots, and is included for back compatibility with SNMPv1 managers. Support for this object is mandatory. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex.

Counter32 · mini-slots

Current count, from CMTS initialization, of contention mini-slots utilized on the upstream logical channel. For contention regions, utilized mini-slots are those in which the CMTS correctly received an upstream burst from any CM on the upstream logical channel. This is the 32-bit version of docsIfCmtsUpChnlCtrExtUsedCntnMslots and is included for back compatibility with SNMPv1 managers. Support for this object is mandatory. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex.

Counter64 (0..18446744073709551615) · mini-slots

Current count, from CMTS initialization, of all mini-slots defined for this upstream logical channel. This count includes all IUCs and SIDs, even those allocated to the NULL SID for a 2.0 logical channel that is inactive. This is the 64-bit version of docsIfCmtsUpChnlCtrTotalMslots and will not be accessible to SNMPv1 managers. Support for this object is mandatory. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex.

Counter64 (0..18446744073709551615) · mini-slots

Current count, from CMTS initialization, of unicast granted mini-slots on the upstream logical channel, regardless of burst type. Unicast granted mini-slots are those in which the CMTS assigned bandwidth to any unicast SID on the logical channel. However, this object does not include mini-slots for reserved IUCs, or grants to SIDs designated as meaning 'no CM'. This is the 64-bit version of docsIfCmtsUpChnlCtrUcastGrantedMslots and will not be accessible to SNMPv1 managers. Support for this object is mandatory. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex.

Counter64 (0..18446744073709551615) · mini-slots

Current count, from CMTS initialization, of contention mini-slots defined for this upstream logical channel. This count includes all mini-slots assigned to a broadcast or multicast SID on the logical channel. This is the 64-bit version of docsIfCmtsUpChnlCtrTotalCntnMslots and will not be accessible to SNMPv1 managers. Support for this object is mandatory. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex.

Counter64 (0..18446744073709551615) · mini-slots

Current count, from CMTS initialization, of contention mini-slots utilized on the upstream logical channel. For contention regions, utilized mini-slots are those in which the CMTS correctly received an upstream burst from any CM on the upstream logical channel. This is the 64-bit version of docsIfCmtsUpChnlCtrUsedCntnMslots and will not be accessible to SNMPv1 managers. Support for this object is mandatory. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex.

Counter32 · mini-slots

Current count, from CMTS initialization, of contention mini-slots subjected to collisions on the upstream logical channel. For contention regions, these are the mini-slots applicable to bursts that the CMTS detected but could not correctly receive. This is the 32-bit version of docsIfCmtsUpChnlCtrExtCollCntnMslots and is included for back compatibility with SNMPv1 managers. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex.

Counter32 · mini-slots

Current count, from CMTS initialization, of contention request mini-slots defined for this upstream logical channel. This count includes all mini-slots for IUC1 assigned to a broadcast or multicast SID on the logical channel. This is the 32-bit version of docsIfCmtsUpChnlCtrExtTotalCntnReqMslots and is included for back compatibility with SNMPv1 managers. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex.

Counter32 · mini-slots

Current count, from CMTS initialization, of contention request mini-slots utilized on this upstream logical channel. This count includes all contention mini-slots for IUC1 applicable to bursts that the CMTS correctly received. This is the 32-bit version of docsIfCmtsUpChnlCtrExtUsedCntnReqMslots and is included for back compatibility with SNMPv1 managers. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex.

Counter32 · mini-slots

Current count, from CMTS initialization, of contention request mini-slots subjected to collisions on this upstream logical channel. This includes all contention mini-slots for IUC1 applicable to bursts that the CMTS detected but could not correctly receive. This is the 32-bit version of docsIfCmtsUpChnlCtrExtCollCntnReqMslots and is included for back compatibility with SNMPv1 managers. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex.

Counter32 · mini-slots

Current count, from CMTS initialization, of contention request data mini-slots defined for this upstream logical channel. This count includes all mini-slots for IUC2 assigned to a broadcast or multicast SID on the logical channel. This is the 32-bit version of docsIfCmtsUpChnlCtrExtTotalCntnReqDataMslots and is included for back compatibility with SNMPv1 managers. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex.

Counter32 · mini-slots

Current count, from CMTS initialization, of contention request data mini-slots utilized on this upstream logical channel. This includes all contention mini-slots for IUC2 applicable to bursts that the CMTS correctly received. This is the 32-bit version of docsIfCmtsUpChnlCtrExtUsedCntnReqDataMslots and is included for back compatibility with SNMPv1 managers. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex.

Counter32 · mini-slots

Current count, from CMTS initialization, of contention request data mini-slots subjected to collisions on this upstream logical channel. This includes all contention mini-slots for IUC2 applicable to bursts that the CMTS detected, but could not correctly receive. This is the 32-bit version of docsIfCmtsUpChnlCtrExtCollCntnReqDataMslots and is included for back compatibility with SNMPv1 managers. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex.

Counter32 · mini-slots

Current count, from CMTS initialization, of contention initial maintenance mini-slots defined for this upstream logical channel. This includes all mini-slots for IUC3 assigned to a broadcast or multicast SID on the logical channel. This is the 32-bit version of docsIfCmtsUpChnlCtrExtTotalCntnInitMaintMslots and is included for back compatibility with SNMPv1 managers. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex.

Counter32

Current count, from CMTS initialization, of contention initial maintenance mini-slots utilized on this upstream logical channel. This includes all contention mini-slots for IUC3 applicable to bursts that the CMTS correctly received. This is the 32-bit version of docsIfCmtsUpChnlCtrExtUsedCntnInitMaintMslots and is included for back compatibility with SNMPv1 managers. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex.

Counter32 · mini-slots

Current count, from CMTS initialization, of contention initial maintenance mini-slots subjected to collisions on this upstream logical channel. This includes all contention mini-slots for IUC3 applicable to bursts that the CMTS detected, but could not correctly receive. This is the 32-bit version of docsIfCmtsUpChnlCtrExtCollCntnInitMaintMslots and is included for back compatibility with SNMPv1 managers. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex.

Counter64 (0..18446744073709551615) · mini-slots

Current count, from CMTS initialization, of collision contention mini-slots on the upstream logical channel. For contention regions, these are the mini-slots applicable to bursts that the CMTS detected, but could not correctly receive. This is the 64-bit version of docsIfCmtsUpChnlCtrCollCntnMslots and will not be accessible to SNMPv1 managers. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex.

Counter64 (0..18446744073709551615) · mini-slots

Current count, from CMTS initialization, of contention request mini-slots defined for this upstream logical channel. This count includes all mini-slots for IUC1 assigned to a broadcast or multicast SID on the logical channel. This is the 64-bit version of docsIfCmtsUpChnlCtrTotalCntnReqMslots and will not be accessible to SNMPv1 managers. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex.

Counter64 (0..18446744073709551615) · mini-slots

Current count, from CMTS initialization, of contention request mini-slots utilized on this upstream logical channel. This count includes all contention mini-slots for IUC1 applicable to bursts that the CMTS correctly received. This is the 64-bit version of docsIfCmtsUpChnlCtrUsedCntnReqMslots and will not be accessible to SNMPv1 managers. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex.

Counter64 (0..18446744073709551615) · mini-slots

Current count, from CMTS initialization, of contention request mini-slots subjected to collisions on this upstream logical channel. This includes all contention mini-slots for IUC1 applicable to bursts that the CMTS detected, but could not correctly receive. This is the 64-bit version of docsIfCmtsUpChnlCtrCollCntnReqMslots and will not be accessible to SNMPv1 managers. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex.

Counter64 (0..18446744073709551615) · mini-slots

Current count, from CMTS initialization, of contention request data mini-slots defined for this upstream logical channel. This count includes all mini-slots for IUC2 assigned to a broadcast or multicast SID on the logical channel. This is the 64-bit version of docsIfCmtsUpChnlCtrTotalCntnReqDataMslots and will not be accessible to SNMPv1 managers. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex.

Counter64 (0..18446744073709551615) · mini-slots

Current count, from CMTS initialization, of contention request data mini-slots utilized on this upstream logical channel. This includes all contention mini-slots for IUC2 applicable to bursts that the CMTS correctly received. This is the 64-bit version of docsIfCmtsUpChnlCtrUsedCntnReqDataMslots and will not be accessible to SNMPv1 managers. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex.

Counter64 (0..18446744073709551615) · mini-slots

Current count, from CMTS initialization, of contention request data mini-slots subjected to collisions on this upstream logical channel. This includes all contention mini-slots for IUC2 applicable to bursts that the CMTS detected, but could not correctly receive. This is the 64-bit version of docsIfCmtsUpChnlCtrCollCntnReqDataMslots and will not be accessible to SNMPv1 managers. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex.

Counter64 (0..18446744073709551615) · mini-slots

Current count, from CMTS initialization, of initial maintenance mini-slots defined for this upstream logical channel. This count includes all mini-slots for IUC3 assigned to a broadcast or multicast SID on the logical channel. This is the 64-bit version of docsIfCmtsUpChnlCtrTotalCntnInitMaintMslots and will not be accessible to SNMPv1 managers. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex.

Counter64 (0..18446744073709551615) · mini-slots

Current count, from CMTS initialization, of initial maintenance mini-slots utilized on this upstream logical channel. This includes all contention mini-slots for IUC3 applicable to bursts that the CMTS correctly received. This is the 64-bit version of docsIfCmtsUpChnlCtrUsedCntnInitMaintMslots and will not be accessible to SNMPv1 managers. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex.

Counter64 (0..18446744073709551615) · mini-slots

Current count, from CMTS initialization, of contention initial maintenance mini-slots subjected to collisions on this upstream logical channel. This includes all contention mini-slots for IUC3 applicable to bursts that the CMTS detected, but could not correctly receive. This is the 64-bit version of docsIfCmtsUpChnlCtrCollCntnInitMaintMslots and will not be accessible to SNMPv1 managers. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex.