CISCO-BERT-MIB

BertPatterns1 = allZeros2 = allOnes3 = altOneZero4 = doubleAltOnesZeros5 = oneIn46 = oneIn87 = oneIn168 = threeIn249 = inbandLoopBackActivate10 = inbandLoopBackDeactivate11 = twoE3MinusOne12 = twoE4MinusOne13 = twoE5MinusOne14 = twoE6MinusOne15 = twoE7MinusOne16 = twoE7MinusOneFT1Loopup17 = twoE7MinusOneFT1Loopdown18 = twoE9MinusOne19 = twoE10MinusOne20 = twoE11MinusOne21 = twoE15MinusOne22 = twoE17MinusOne23 = twoE18MinusOne24 = twoE20MinusOne25 = twoE20MinusOneQRSS26 = twoE21MinusOne27 = twoE22MinusOne28 = twoE23MinusOne29 = twoE25MinusOne30 = twoE28MinusOne31 = twoE29MinusOne32 = twoE31MinusOne33 = dds1pattern34 = dds2pattern35 = dds3pattern36 = dds4pattern37 = dds5pattern38 = userPatternThe patterns that can be configured to perform BER Test on an interface. Bit error measurements are widely used to assess the performance of a digital transmission equipment. Precise error measurement requires that the bit pattern transmitted is known before hand. During BER testing a known pattern is transmitted on a interface. The pattern received on the receive side is checked for bit errors. In order to measure the performance of digital line under real condition this patterns should also simulate real traffic as closely as possible. There are two categories of test patterns that can be generated by a BERT equipment: repetitive and pseudo-random. The former test patterns are zeroes or ones or alternating zeroes and ones; the latter patterns are exponential numbers and conform to CCITT/ITU O.151, O.153. There are different patterns for different interface speeds. This object allows the user to configure this BERT patterns. The supported values are : Repetitive Patterns allZeros(1): All Zeroes(Continuous spaces). This is repeating pattern of zeros(...000...). The use of this pattern is to test and verify that the ones density policing mechanism is functioning properly. This pattern must be used in circuits optioned for B8ZS. allOnes(2): All Ones(Continuous Marks). This is repeating pattern of ones(...1111...). This provides testing of maximum power level requirements. The all one pattern test causes the repeater to consume the maximum amount of power. If there is insufficient DC span power then the repeater may begin to fail. Typically this pattern is used for a simple continuity check. It may also be used to detect the presence of unwanted loop in the network. altOneZero(3): Alternate one/zero pattern(..1010..). This pattern produces a 50% ones density. It is used to stress the repeater's DC power consumption. doubleAltOnesZeros(4): Double alternate one/zero(..1100..). oneIn4(5): This pattern is standard loop up remote code. Typically it is used when the loop up remote test fails to place the remote system into loopback. oneIn8(6): This is an eight bit pattern which contains single one. This pattern is used primarily to test timing(clock) recovery and may be used framed or unframed for that purpose. This pattern is used to verify frame synchronization by providing the minimum acceptable pulse density. oneIn16(7): N repetitive pattern, 1 in 16. threeIn24(8): This is a 24 bit pattern which contains 3 ones. The largest string of consecutive zeros is fifteen. This pattern is used primarily to test timing(clock) recovery and may be used framed or unframed for that purpose. This pattern covers both the minimum ones density and the maximum number of consecutive zeros. inbandLoopup(9): D4/SF Loopback activate. Valid only for T1 line. inbandLoopdown(10): D4/SF Loopback deactivate. Valid only for T1 line. Pseudo-Random Patterns twoE3MinusOne(11): This is 2^3-1 (7 bits in length) pattern. twoE4MinusOne(12): This is 2^4-1 (15 bits in length) pattern. twoE5MinusOne(13): This is 2^5-1 (31 bits in length) pattern. twoE6MinusOne(14): This is 2^6-1 (63 bits in length) pattern. twoE7MinusOne(15): This is 2^7-1 (127 bits in length) pattern. twoE7MinusOneFT1Loopup(16): 2^7-1 Fractional T1 Loop Back Activate. twoE7MinusOneFT1Loopdown(17): 2^7-1 Fractional T1 Loop Back Deactivate. twoE9MinusOne(18): This is 2^9-1(511 bits in length) pattern specified in ITU O.153. It has the maximum of 8(non-inverted) sequential zeros and 9 sequential ones. twoE10MinusOne(19): This is the 2^10-1(1023 bits in length). twoE11MinusOne(20): This is the 2^11-1(2047 bits in length) pattern specified in ITU O.152, O.153. It has a maximum of 10(non-inverted) sequential zeros and 11 sequential ones. This pattern is primarily intended for error measurements at bit rates of 64kbit/s and N*64 kbit/s. twoE15MinusOne(21): This is the 2^15-1(32767 bit length) pattern as specified in ITU O.151. It has the maximum of 15(inverted) sequential zeros. This sequence is primarily intended for error and jitter measurements at bit rates of 1544, 2048, 6312, 8448, 32064 and 44736 kbit/s. twoE17MinusOne(22): This the 2^17-1(131071 bits in length). twoE18MinusOne(23): This the 2^18-1(262144 bits in length). twoE20MinusOne(24): This the 2^20-1(1048575 bits in length) pattern specified in ITU O.153.It has the maximum of 19(non-inverted) sequential zeros. This pattern is primarily intended for error measurements at bit rates up to 73kbit/s. This pattern stresses the equalization and timing recovery circuitry of line repeaters. twoE20MinusOneQRSS(25): This is the 2^20-1(1048575 bits) pattern specified in ITU O.151. This is the pattern with Zero suppression(Quasi Random Signal Source This provides the simulation of live data. This is primarily intended for error and jitter measurements at bit rates of 34368, 139264 kbit/s. twoE21MinusOne(26): This is the 2^21-1(2097151 bit length). twoE22MinusOne(27): This is the 2^22-1(4194303 bit length). twoE23MinusOne(28): This is the 2^23-1(8388607 bit length) pattern specified in ITU O.151. Highest stress pseudo-random pattern, with a maximum of 23 (inverted) sequential zeros and 23 sequential ones. This sequence is primarily intended for error and jitter measurements at bit rates of 34368 and 139264 kbit/s. twoE25MinusOne(29): This is the 2^21-1 (33554431 bit length). twoE28MinusOne(30): This is the 2^28-1 (268435455 bit length). twoE29MinusOne(31): Highest stress pseudo random pattern, with a maximum of 29 (inverted) sequential zeros Specified in ITU 0.150. twoE31MinusOne(32): It has maximum 31 sequential zeros. DDS is a special service for transmitting data in a DS-1 frame. dds1pattern(33): This sends 100 bytes of all 1s and then 100 bytes of all 0s to test the stress clocking of the network. dds2pattern(34): This sends 100 bytes of a 0x7e pattern and then 100 bytes of all 0s. This pattern simulates bit oriented protocol flags for DDS testing. dds3pattern(35): This pattern sends continuous bytes of a 0x46 pattern. It is used to simulate a typical DDS signal. dds4pattern(36): This pattern sends continuous bytes of a 0x02 pattern. It is used to stress DDS clock recovery. dds5pattern(37): This pattern sends continuous bytes of a 0x02 pattern. It is used to stress DDS clock recovery. userPattern(38): This is any user defined pattern.Reference: CCITT/ITU O.150, O.151, O.152, O.153, O.161 Standards. · Integer32

The BERT pattern to be sent and expected to be received. An implementation may choose to support only selected patterns. In some implementations, this object can not be modified when the BERT is running, i.e cbRowStatus is active(1).

OCTET STRING SIZE (1..4)

The object used for configuring the user defined pattern for BERT. This is the fixed repeating BERT pattern sent and expected to be received when the cbTestPattern object is set to 'userPattern'. The maximum length of this pattern is 32 bits. Depending on the hardware, the patterns are transmitted with least significant first or most significant bit, until pattern length is reached. This object can not be modified when the BERT is running, i.e cbRowStatus is active(1).

INTEGER1 = notInverted2 = inverted · Integer32

This controls inversion of the transmit BERT pattern. Possible values are : notInverted(1): Pattern is transmitted normally. inverted(2): Each Mark is replaced by Space and vice versa. For predefined BERT patterns, the value for this Object may not be modified. An implementation may choose to ignore the value of this object, for BERT patterns other than 'userPattern'. When the value is ignored, the object contains the value chosen by the underlying hardware. This object can not be modified when the BERT is running i.e cbRowStatus is active(1).

INTEGER1 = notInverted2 = inverted · Integer32

This controls inversion of the received BERT pattern. Possible values are : notInverted(1) : Pattern received is not inverted. inverted(2) : each Mark is replaced by Space and vice versa. When set to inverted(1), the received data is inverted before being processed by the pattern detector. For predefined BERT patterns, the value for this object may not be modified. An implementation may choose to ignore the value of this object, for BERT patterns other than 'userPattern'. When the value is ignored, the object contains the value chosen by the underlying hardware. This object can not be modified when the BERT is running i.e cbRowStatus is active(1).

INTEGER1 = farEndLineLoopback2 = remoteLineLoopback3 = localLoopback4 = farEndPayloadLoopback5 = remotePayloadLoopback6 = noLoopback · Integer32

This object specifies the type of loopback established. Possible values are: farEndLineLoopback(1): This loopback occurs at the CPE upon receiving a special code from the device which initiates the loopback. Upon receiving the loop activation request code, the CPE enters a Line loop mode in which it returns the entire line back to the initiator. The CPE will continue to return the data back to the initiator until it receives loopback deactivation request code. remoteLineLoopback(3): This loopback is established at the Near-end. In this loopback the entire line is looped back to the Far-end with a) bit-sequence integrity maintained, b) no change in framing, and c) no removal of bi- polar violations. localLoopback(3): This is also known as metallic loopback. This loopback is used for checking the internal circuitry of the T3/E3, T1/E1 device. Only for physical lines. farEndPayloadLoopback(4): This loopback occurs at the CPE upon receiving a special code from the device which initiates the loopback. Upon receiving the loop activation request code, CPE enters a Payload loop mode in which it returns the Payload of the received data back to the initiator. The CPE will continue to return the data back to the initiator until it receives loopback deactivation request code. remotePayloadLoopback(5): This loopback is established at the Near-end. In this loopback the signal that is returned to the Far-end consists of the payload of the received signal (with bit sequence integrity retained) and newly generated framing information. noLoopback(6): There is no loopback established on the device.

INTEGER1 = nonLatchOCUwith12 = nonLatchOCUwithout13 = nonLatchCSU4 = nonLatchDSU5 = latchDS0Drop6 = latchDS0Line7 = latchOCU8 = latchCSU9 = latchDSU10 = latchHL9611 = v54PN127Polynomial12 = lineInband13 = lineLoopbackESF14 = localLoopback15 = noLoopbackCode16 = payloadLoopbackESF17 = lineLoopbackFEAC18 = smartJackInband · Integer32

This object specifies the type of the end device and the type of loopback code used. Latching Loopback: Latching Loopback is appropriate with 64 kbit/s DS0-A rate. Once invoked by a specific activation sequence, it typically remains in effect until released by another specific code sequence. non-latching loopback: Non latching activation involves continuous transmission of loopback command codes, followed by test data interspersed with command codes. The possible values are: Note: The values 1 to 14 are for farEndLoopback. cbLoopback object is farEndLoopback(1) when these values are selected. nonLatchOCUwithOneDevice(1): Non-latching OCU with one device. nonLatchOCUwithChainDevices(2): Non-latching OCU with chain of devices. nonLatchCSU(3) : Non-latching CSU. nonLatchDSU(4) : Non-latching DSU. latchDS0Drop(5) : Latching DS0-DP Drop device. latchDS0Line(6) : Latching DS0-DP line device. latchOCU(7) : Latching OCU. latchCSU(8) : Latching CSU. latchDSU(9) : Latching DSU. latchHL96(10) : Latching HL96 device. v54PN127Polynomial(11) : For fractional T1. This loopback is based on CCITT-ITU V.54 and is being used to place either a single DS0 or a DS0 Bundle(N*DS0) in loopback mode. lineInband(12) : This is used for loopback the entire T1 line at the far end. This is a repeating 5-bit pattern(00001). lineLoopbackESF(13): This loopback result in a full 1.544Mbit/s loopback of the incoming signal at the far end. The loopback is activated (latched) and deactivated by a bit sequence defined in ANSI T1.403 - 1995. This corresponds to Facility Data Link (FDL)loopbacks on a T1 channel. This causes a repeating,16-bit ESF data link code word(00001110 11111111) to the remote end requesting that it enter into a network line loopback. localLoopback(14): This is for loop back at the near end (facility end). This is used to test the internals of the device, the interface loops back the outbound traffic from SRM to SM, back to the SRM, hence testing the internal device connectivity. noLoopbackCode(15): This is for situations, where no loopback is needed for bert tests. One example is manual loop back at near or far end. payloadLoopbackESF(16): This loopback results in 1.536 Mbit/s loopback of the payload of the incoming signal at the far end. The loopback is activated (latched) and deactivated by a bit sequence defined in ANSI T1.403 - 1995. This corresponds to Facility Data Link (FDL)loopbacks on a T1 channel. This causes a repeating, 16-bit ESF data link code word(00010100 11111111) to the remote end requesting that it enter into a network payload loopback. lineLoopbackFEAC(17): Use the FEAC channel to establish a line loopback. smartJackInband(18): Inband loop code for SmartJack (a Telco owned device that represents the demarcation point of T1 service), Ref: TR-TSY-000312.

INTEGER1 = noError2 = insertError · Integer32

This object is used for inserting single bit error in the transmitted BERT pattern. The possible values are: noError(1) : do not insert single bit errors insertError(2) : insert single bit errors.

INTEGER1 = noError2 = oneInTen3 = oneInHundred4 = oneInThousand5 = oneInTenThousand6 = oneInHundredThousand7 = oneInMillion8 = oneInTenMillion · Integer32

This object is used for injecting continuous errors into transmitted BERT pattern. The errors are inserted in a BERT pattern sent, in order to do sanity check on receive interface in the event that no bit errors are detected. Injecting errors allows users to stress communication links and to check the functionality of error monitoring equipment along the path. Once set to send continuous errors, errors will be inserted at the configured rate until set to noError(1). The possible values are : noError(1) : no bit errors are inserted. oneInTen(2) : insert bit errors at the rate of 1 bit error per 10 bits (10^-1) transmitted. oneInHundred(3) : insert bit errors at the rate of 1 bit error per 100 bits (10^-2) transmitted. oneInThousand(4): insert bit errors at the rate of 1 bit error per 1000 bits (10^-3) transmitted. oneIn10Thousand(5): insert bit errors at the rate of 1 bit error per 10000 (10^-4) bits transmitted. oneInHundredThousand(6): insert bit errors at the rate of 1 bit error per 100000 bits (10^-5) transmitted. oneInMillion(7): insert bit errors at the rate of 1 bit error per 1000000 bits (10^-6) transmitted. oneInTenMillion(8): insert bit errors at the rate of 1 bit error per 10,000,000 (10^-7)bits transmitted.

Integer32 (1..86400) · seconds

This object specifies the duration for which BERT is to be run.

INTEGER1 = success2 = inSync3 = outOfSync4 = inLoopback5 = clockOutOfSync6 = bertFailed · Integer32

This object shows the status of BERT in the shelf. The values for this object are valid only when cbRowStatus contains active(1). Possible values for this object: success(1) : BERT is successfully completed. inSync(2) : BERT is activated and receive side is synchronized with the incoming sequence of patterns. outOfSync(3) : BERT is activated, but receive is out of synchronization with the incoming sequence. Criteria for out of synchronization state is defined in ITU document O.150. inLoopback(4): loopback establish or de-establish in progress. The type of loopback can be determined by cbLoopback. clockOutOfSync(5): When the send and receive clocks are not synchronized. bertFailed(6): BERT failed. The cbFailedReason object contains the reason for the failure.

INTEGER1 = aborted2 = loopbackFailed3 = interfaceStateChange4 = processorModuleStateChange5 = unknown · Integer32

This object contains the reason for the BERT failure. This object gives the additional information when cbOperStatus is set to bertFailed(6). The possible values are : aborted(1) : BERT test is completed as a result of a user request. loopbackFailed(2) : loop up operation failed. interfaceStateChange(3) : interface State changed due to module state change. processorModuleStateChange(4) : Processor module changed state. unknown(5) : Failure Reason Unknown.

DateAndTimeA date-time specification. field octets contents range ----- ------ -------- ----- 1 1-2 year* 0..65536 2 3 month 1..12 3 4 day 1..31 4 5 hour 0..23 5 6 minutes 0..59 6 7 seconds 0..60 (use 60 for leap-second) 7 8 deci-seconds 0..9 8 9 direction from UTC '+' / '-' 9 10 hours from UTC* 0..13 10 11 minutes from UTC 0..59 * Notes: - the value of year is in network-byte order - daylight saving time in New Zealand is +13 For example, Tuesday May 26, 1992 at 1:30:15 PM EDT would be displayed as: 1992-5-26,13:30:15.0,-4:0 Note that if only local time is known, then timezone information (fields 8-10) is not present. SIZE (8 | 11) · OCTET STRING · hint 2d-1d-1d,1d:1d:1d.1d,1a1d:1d

The Date and Time when the last BERT testing is started on the interface. This object is valid only when cbRowStatus is active(1).

Integer32 (1..32)

Valid only with cbLoopbackCode = latchDS0Drop. DSP-OP devices can be cross connected in the central office in a daisy chain. By this, the user has capability to put any of the devices in the chain in loopback mode. A value of 1 results in no iteration and will cause the very first device in chain to go into loop back. A value of 2 will result into one iteration and will cause the second device to go into loopback and so on. This tests the channels across multiple devices connected in a chain.

RowStatus1 = active2 = notInService3 = notReady4 = createAndGo5 = createAndWait6 = destroyThe RowStatus textual convention is used to manage the creation and deletion of conceptual rows, and is used as the value of the SYNTAX clause for the status column of a conceptual row (as described in Section 7.7.1 of [2].) The status column has six defined values: - `active', which indicates that the conceptual row is available for use by the managed device; - `notInService', which indicates that the conceptual row exists in the agent, but is unavailable for use by the managed device (see NOTE below); 'notInService' has no implication regarding the internal consistency of the row, availability of resources, or consistency with the current state of the managed device; - `notReady', which indicates that the conceptual row exists in the agent, but is missing information necessary in order to be available for use by the managed device (i.e., one or more required columns in the conceptual row have not been instanciated); - `createAndGo', which is supplied by a management station wishing to create a new instance of a conceptual row and to have its status automatically set to active, making it available for use by the managed device; - `createAndWait', which is supplied by a management station wishing to create a new instance of a conceptual row (but not make it available for use by the managed device); and, - `destroy', which is supplied by a management station wishing to delete all of the instances associated with an existing conceptual row. Whereas five of the six values (all except `notReady') may be specified in a management protocol set operation, only three values will be returned in response to a management protocol retrieval operation: `notReady', `notInService' or `active'. That is, when queried, an existing conceptual row has only three states: it is either available for use by the managed device (the status column has value `active'); it is not available for use by the managed device, though the agent has sufficient information to attempt to make it so (the status column has value `notInService'); or, it is not available for use by the managed device, and an attempt to make it so would fail because the agent has insufficient information (the state column has value `notReady'). NOTE WELL This textual convention may be used for a MIB table, irrespective of whether the values of that table's conceptual rows are able to be modified while it is active, or whether its conceptual rows must be taken out of service in order to be modified. That is, it is the responsibility of the DESCRIPTION clause of the status column to specify whether the status column must not be `active' in order for the value of some other column of the same conceptual row to be modified. If such a specification is made, affected columns may be changed by an SNMP set PDU if the RowStatus would not be equal to `active' either immediately before or after processing the PDU. In other words, if the PDU also contained a varbind that would change the RowStatus value, the column in question may be changed if the RowStatus was not equal to `active' as the PDU was received, or if the varbind sets the status to a value other than 'active'. Also note that whenever any elements of a row exist, the RowStatus column must also exist. To summarize the effect of having a conceptual row with a status column having a SYNTAX clause value of RowStatus, consider the following state diagram: STATE +--------------+-----------+-------------+------------- | A | B | C | D | |status col.|status column| |status column | is | is |status column ACTION |does not exist| notReady | notInService| is active --------------+--------------+-----------+-------------+------------- set status |noError ->D|inconsist- |inconsistent-|inconsistent- column to | or | entValue| Value| Value createAndGo |inconsistent- | | | | Value| | | --------------+--------------+-----------+-------------+------------- set status |noError see 1|inconsist- |inconsistent-|inconsistent- column to | or | entValue| Value| Value createAndWait |wrongValue | | | --------------+--------------+-----------+-------------+------------- set status |inconsistent- |inconsist- |noError |noError column to | Value| entValue| | active | | | | | | or | | | | | | | |see 2 ->D|see 8 ->D| ->D --------------+--------------+-----------+-------------+------------- set status |inconsistent- |inconsist- |noError |noError ->C column to | Value| entValue| | notInService | | | | | | or | | or | | | | | |see 3 ->C| ->C|see 6 --------------+--------------+-----------+-------------+------------- set status |noError |noError |noError |noError ->A column to | | | | or destroy | ->A| ->A| ->A|see 7 --------------+--------------+-----------+-------------+------------- set any other |see 4 |noError |noError |see 5 column to some| | | | value | | see 1| ->C| ->D --------------+--------------+-----------+-------------+------------- (1) goto B or C, depending on information available to the agent. (2) if other variable bindings included in the same PDU, provide values for all columns which are missing but required, and all columns have acceptable values, then return noError and goto D. (3) if other variable bindings included in the same PDU, provide legal values for all columns which are missing but required, then return noError and goto C. (4) at the discretion of the agent, the return value may be either: inconsistentName: because the agent does not choose to create such an instance when the corresponding RowStatus instance does not exist, or inconsistentValue: if the supplied value is inconsistent with the state of some other MIB object's value, or noError: because the agent chooses to create the instance. If noError is returned, then the instance of the status column must also be created, and the new state is B or C, depending on the information available to the agent. If inconsistentName or inconsistentValue is returned, the row remains in state A. (5) depending on the MIB definition for the column/table, either noError or inconsistentValue may be returned. (6) the return value can indicate one of the following errors: wrongValue: because the agent does not support notInService (e.g., an agent which does not support createAndWait), or inconsistentValue: because the agent is unable to take the row out of service at this time, perhaps because it is in use and cannot be de-activated. (7) the return value can indicate the following error: inconsistentValue: because the agent is unable to remove the row at this time, perhaps because it is in use and cannot be de-activated. (8) the transition to D can fail, e.g., if the values of the conceptual row are inconsistent, then the error code would be inconsistentValue. NOTE: Other processing of (this and other varbinds of) the set request may result in a response other than noError being returned, e.g., wrongValue, noCreation, etc. Conceptual Row Creation There are four potential interactions when creating a conceptual row: selecting an instance-identifier which is not in use; creating the conceptual row; initializing any objects for which the agent does not supply a default; and, making the conceptual row available for use by the managed device. Interaction 1: Selecting an Instance-Identifier The algorithm used to select an instance-identifier varies for each conceptual row. In some cases, the instance- identifier is semantically significant, e.g., the destination address of a route, and a management station selects the instance-identifier according to the semantics. In other cases, the instance-identifier is used solely to distinguish conceptual rows, and a management station without specific knowledge of the conceptual row might examine the instances present in order to determine an unused instance-identifier. (This approach may be used, but it is often highly sub-optimal; however, it is also a questionable practice for a naive management station to attempt conceptual row creation.) Alternately, the MIB module which defines the conceptual row might provide one or more objects which provide assistance in determining an unused instance-identifier. For example, if the conceptual row is indexed by an integer-value, then an object having an integer-valued SYNTAX clause might be defined for such a purpose, allowing a management station to issue a management protocol retrieval operation. In order to avoid unnecessary collisions between competing management stations, `adjacent' retrievals of this object should be different. Finally, the management station could select a pseudo-random number to use as the index. In the event that this index was already in use and an inconsistentValue was returned in response to the management protocol set operation, the management station should simply select a new pseudo-random number and retry the operation. A MIB designer should choose between the two latter algorithms based on the size of the table (and therefore the efficiency of each algorithm). For tables in which a large number of entries are expected, it is recommended that a MIB object be defined that returns an acceptable index for creation. For tables with small numbers of entries, it is recommended that the latter pseudo-random index mechanism be used. Interaction 2: Creating the Conceptual Row Once an unused instance-identifier has been selected, the management station determines if it wishes to create and activate the conceptual row in one transaction or in a negotiated set of interactions. Interaction 2a: Creating and Activating the Conceptual Row The management station must first determine the column requirements, i.e., it must determine those columns for which it must or must not provide values. Depending on the complexity of the table and the management station's knowledge of the agent's capabilities, this determination can be made locally by the management station. Alternately, the management station issues a management protocol get operation to examine all columns in the conceptual row that it wishes to create. In response, for each column, there are three possible outcomes: - a value is returned, indicating that some other management station has already created this conceptual row. We return to interaction 1. - the exception `noSuchInstance' is returned, indicating that the agent implements the object-type associated with this column, and that this column in at least one conceptual row would be accessible in the MIB view used by the retrieval were it to exist. For those columns to which the agent provides read-create access, the `noSuchInstance' exception tells the management station that it should supply a value for this column when the conceptual row is to be created. - the exception `noSuchObject' is returned, indicating that the agent does not implement the object-type associated with this column or that there is no conceptual row for which this column would be accessible in the MIB view used by the retrieval. As such, the management station can not issue any management protocol set operations to create an instance of this column. Once the column requirements have been determined, a management protocol set operation is accordingly issued. This operation also sets the new instance of the status column to `createAndGo'. When the agent processes the set operation, it verifies that it has sufficient information to make the conceptual row available for use by the managed device. The information available to the agent is provided by two sources: the management protocol set operation which creates the conceptual row, and, implementation-specific defaults supplied by the agent (note that an agent must provide implementation-specific defaults for at least those objects which it implements as read-only). If there is sufficient information available, then the conceptual row is created, a `noError' response is returned, the status column is set to `active', and no further interactions are necessary (i.e., interactions 3 and 4 are skipped). If there is insufficient information, then the conceptual row is not created, and the set operation fails with an error of `inconsistentValue'. On this error, the management station can issue a management protocol retrieval operation to determine if this was because it failed to specify a value for a required column, or, because the selected instance of the status column already existed. In the latter case, we return to interaction 1. In the former case, the management station can re-issue the set operation with the additional information, or begin interaction 2 again using `createAndWait' in order to negotiate creation of the conceptual row. NOTE WELL Regardless of the method used to determine the column requirements, it is possible that the management station might deem a column necessary when, in fact, the agent will not allow that particular columnar instance to be created or written. In this case, the management protocol set operation will fail with an error such as `noCreation' or `notWritable'. In this case, the management station decides whether it needs to be able to set a value for that particular columnar instance. If not, the management station re-issues the management protocol set operation, but without setting a value for that particular columnar instance; otherwise, the management station aborts the row creation algorithm. Interaction 2b: Negotiating the Creation of the Conceptual Row The management station issues a management protocol set operation which sets the desired instance of the status column to `createAndWait'. If the agent is unwilling to process a request of this sort, the set operation fails with an error of `wrongValue'. (As a consequence, such an agent must be prepared to accept a single management protocol set operation, i.e., interaction 2a above, containing all of the columns indicated by its column requirements.) Otherwise, the conceptual row is created, a `noError' response is returned, and the status column is immediately set to either `notInService' or `notReady', depending on whether it has sufficient information to (attempt to) make the conceptual row available for use by the managed device. If there is sufficient information available, then the status column is set to `notInService'; otherwise, if there is insufficient information, then the status column is set to `notReady'. Regardless, we proceed to interaction 3. Interaction 3: Initializing non-defaulted Objects The management station must now determine the column requirements. It issues a management protocol get operation to examine all columns in the created conceptual row. In the response, for each column, there are three possible outcomes: - a value is returned, indicating that the agent implements the object-type associated with this column and had sufficient information to provide a value. For those columns to which the agent provides read-create access (and for which the agent allows their values to be changed after their creation), a value return tells the management station that it may issue additional management protocol set operations, if it desires, in order to change the value associated with this column. - the exception `noSuchInstance' is returned, indicating that the agent implements the object-type associated with this column, and that this column in at least one conceptual row would be accessible in the MIB view used by the retrieval were it to exist. However, the agent does not have sufficient information to provide a value, and until a value is provided, the conceptual row may not be made available for use by the managed device. For those columns to which the agent provides read-create access, the `noSuchInstance' exception tells the management station that it must issue additional management protocol set operations, in order to provide a value associated with this column. - the exception `noSuchObject' is returned, indicating that the agent does not implement the object-type associated with this column or that there is no conceptual row for which this column would be accessible in the MIB view used by the retrieval. As such, the management station can not issue any management protocol set operations to create an instance of this column. If the value associated with the status column is `notReady', then the management station must first deal with all `noSuchInstance' columns, if any. Having done so, the value of the status column becomes `notInService', and we proceed to interaction 4. Interaction 4: Making the Conceptual Row Available Once the management station is satisfied with the values associated with the columns of the conceptual row, it issues a management protocol set operation to set the status column to `active'. If the agent has sufficient information to make the conceptual row available for use by the managed device, the management protocol set operation succeeds (a `noError' response is returned). Otherwise, the management protocol set operation fails with an error of `inconsistentValue'. NOTE WELL A conceptual row having a status column with value `notInService' or `notReady' is unavailable to the managed device. As such, it is possible for the managed device to create its own instances during the time between the management protocol set operation which sets the status column to `createAndWait' and the management protocol set operation which sets the status column to `active'. In this case, when the management protocol set operation is issued to set the status column to `active', the values held in the agent supersede those used by the managed device. If the management station is prevented from setting the status column to `active' (e.g., due to management station or network failure) the conceptual row will be left in the `notInService' or `notReady' state, consuming resources indefinitely. The agent must detect conceptual rows that have been in either state for an abnormally long period of time and remove them. It is the responsibility of the DESCRIPTION clause of the status column to indicate what an abnormally long period of time would be. This period of time should be long enough to allow for human response time (including `think time') between the creation of the conceptual row and the setting of the status to `active'. In the absence of such information in the DESCRIPTION clause, it is suggested that this period be approximately 5 minutes in length. This removal action applies not only to newly-created rows, but also to previously active rows which are set to, and left in, the notInService state for a prolonged period exceeding that which is considered normal for such a conceptual row. Conceptual Row Suspension When a conceptual row is `active', the management station may issue a management protocol set operation which sets the instance of the status column to `notInService'. If the agent is unwilling to do so, the set operation fails with an error of `wrongValue' or `inconsistentValue'. Otherwise, the conceptual row is taken out of service, and a `noError' response is returned. It is the responsibility of the DESCRIPTION clause of the status column to indicate under what circumstances the status column should be taken out of service (e.g., in order for the value of some other column of the same conceptual row to be modified). Conceptual Row Deletion For deletion of conceptual rows, a management protocol set operation is issued which sets the instance of the status column to `destroy'. This request may be made regardless of the current value of the status column (e.g., it is possible to delete conceptual rows which are either `notReady', `notInService' or `active'.) If the operation succeeds, then all instances associated with the conceptual row are immediately removed. · Integer32

The status of this conceptual row. This object is used for create or modify or deleting an entry from this table. To create a row in this table, a manager must set this object to either createAndGo(4) or createAndWait(5). Until instances of all corresponding columns are appropriately configured, the value of the corresponding instance of the cbRowStatus is notReady(3). An entry can be deleted by setting this object to destroy(6). STARTING BERT: Two approaches: 1. set this object to createAndGo(4) with all the mandatory objects set to valid values. 2. Set this object to createAndWait(4). Reading this object at this stage returns notReady(3). Set all the other required objects with valid values. Set this object to active(1). STOP/RESTART BERT: The BERT can be stopped by setting this object to notInService(2). After setting it to notInService(2), some parameters can be modified and BERT can be started by setting this object to active(1). STOP BERT: An entry can be deleted by setting this object to destroy(6). Deleting an entry stops the BERT test.

BITS

This object is only used IF the interface type is DS1 (ifType is 18 on ifTable). This object is used to indicate which DS0 is involved on the BERT. The defualt value (DEFVAL) is valid and should be used for implementation purposes. But the DEFVAL is commented out due to known mib compiler problems associated with DEFVAL clauses in objects using BITS SYNTAX.

Counter32

The total number of bits transmitted.

Counter32

The number of times the associated cbTxBitCountLower object has wrapped (i.e. restarted from zero).

Counter64 (0..18446744073709551615)

The total number of bits transmitted. This object is a 64-bit version of cbTxBitCounts.

Counter32

The total number of bits received.

Counter32

The number of times the associated cbRxBitCountLower counter has wrapped (i.e. restarted from zero).

Counter64 (0..18446744073709551615)

The total number of bits received. This object is 64-bit version of cbRxBitCounts.

Counter32

The total number of bit errors detected in the received pattern.

Counter32

The number of times the associated cbRxBitErrCountLower counter has wrapped (i.e. restarted from zero).

Counter64 (0..18446744073709551615)

The number of bit errors detected in the received pattern. This is the 64-bit version of cbRxBitErrCounts.

Counter32

This is the count of number of times that synchronization has been lost since the BERT was started or restarted.

Counter32

The number of 1 second intervals during the BER test in which pattern synchronization was not maintained for the entire second.

Counter32

The number of 1 second intervals during the BER test in which frame synchronization was not maintained for the entire second.

Counter32

Number of 1 second interval during the BER test that at least one bit error was detected in the received data pattern.

Counter32

The number of 1 second intervals during the BER test that the Bit Error Rate was greater than 10^-3.

Counter32

The number of 1 second intervals during the BER test that there were not errors detected and pattern synchronization was maintained.

Counter32

This object contains the number of times error was injected.