UMC1000-MIB: View SNMP OID List / Download MIB

The system date and time is accessible as follows: octet[0] Timezone (0 through 24) octet[1] High-order 8-bits (MSB) of Year octet[2] Low-order 8-bits (LSB) of Year octet[3] Month (1 through 12, where Jan.=1, Feb.=2, etc.) octet[4] Day (1 through 31) octet[5] Hour (0 through 23) octet[6] Minutes (0 through 59) octet[7] Seconds (0 through 59) octet[8] High-order 8-bits (MSB) of Mseconds (always 0) octet[9] Low-order 8-bits (LSB) of Mseconds (always 0) octet[10] Day of Week (0 through 7)

This table stores BER provisioning information per Plug-In Type. Access to this Table is read-write. By implementation, this table supports GET, SET, and GET-NEXT Operations.

An entry in the System Global Provisioning table. The relationship and allowed ranges of values for the Maintenance and Red BER columns is as follows: _PitAnyE1_ Red BER range in 3-7, Maintenance BER range in 4-8 _PitAnyFO_ Red BER range in 3-9, Maintenance BER range in 4-10 _PitAnyT1_ Red BER range in 3-7, Maintenance BER range in 4-8 _PitAnyRF_ Red BER range in 3-7, Maintenance BER range in 4-8 _PitAnyE1A_ Red BER range in 3-7, Maintenance BER range in 4-8 _PitAnyT1A_ Red BER range in 3-7, Maintenance BER range in 4-8 _PitAnyIsdn_ Red BER range in 3-6, Maintenance BER range in 4-7

See description of the 'PlugInType'. However, currently, entries for the following PITs are supported in this table: _PitAnyE1_ _PitAnyFO_ _PitAnyT1_ _PitAnyRF_ _PitAnyE1A_ _PitAnyT1A_ _PitAnyIsdn_

This is the RED BER threshold exponent. If the value is 5, then the maintenance BER threshold is 10e-05 (10^-5), or 1 in one thousand. The range of this threshold value is dependent upon the PIT type. This value must always be less than that of the Maintenance BER Threshold value.

This is the maintenance BER threshold exponent. If the value is 6, then the maintenance BER threshold is 10e-06 (10^-6), or 1 in one million. The range of this threshold value is dependent upon the PIT type. This value must always be greater than that of the RED BER Threshold value.

This is the facility margin data in dB. Valid values range from zero (0) through fifteen (15), inclusive. The default value is 6.

The range of allowable values is zero (0) through thirty-seven (37) in steps of one (1).

This number indicates the number of Volts; the following voltage levels are supported: Integer Value Meaning 60 60 Volts 65 65 Volts 85 85 Volts 95 95 Volts

This value indicates the frequency of the pulse tone. The following frequencies are supported, with zero (0) disabling pulse metering: Integer Value Meaning 12000 12 KHz pulse metering tone 16000 16 KHz pulse metering tone 8000 8 KHz US EBS backplane tone 0 pulse-metering disabled

This value is equal to the Ring Frequency Hertz multiplied by ten (10); the following values are supported: Integer Value Meaning 167 16.7 Hz 177 17.7 Hz 187 18.7 Hz 200 20.0 Hz 210 21.0 Hz 223 22.3 Hz 235 23.5 Hz 250 25.0 Hz 264 26.4 Hz 280 28.0 Hz 298 29.8 Hz 316 31.6 Hz 333 33.3 Hz 354 35.4 Hz 376 37.6 Hz 400 40.0 Hz 422 42.2 Hz 444 44.4 Hz 474 47.4 Hz 500 50.0 Hz

The EMS uses this table to synchronize its internal representation of System Global Provisioning information with that managed by the UMC Agent. A trap is sent to the EMS indicating a change to System Global Provisioning information has been made and entered as a row in this table. The EMS queries this table, using the sequence number received in the umc1TrapSysProvChange trap to determine whether it can re-learn the changed System Global Provisioning information from this table or must re-learn *all* System Global Provisioning information, bypassing this table.

An entry in the System Global Provisioning Changes table.

This objects value matches the value of umc1SystemSysProvTableChangeSeqNum at the time the row was created. A valid value of this object is in the range of 1 through umc1SystemSysProvTableChangeSeqNum.

The first octet, octet 0, indicates which System Global object has changed. This value will be one of the following: 0x00 - System Date & Time 0x01 - ACO Configuration (NOT SUPPORTED AT PRESENT) 0x02 - System Timing Interface (NOT SUPPORTED AT PRESENT) 0x03 - PSU Ring Voltage 0x04 - PSU Pulse Meter Tone 0x05 - PSU Ring Frequency 0x06 - SNMP Community Name (NOT SUPPORTED AT PRESENT) 0x07 - SNMP Trap Types Enabled 0x08 - SNMP Trap Receiver 1 IP Address 0x09 - SNMP Trap Receiver UDP Port 0x0A - SNMP Trap Receiver 2 IP Address 0x0B - SNMP Trap Receiver 2 Traps Enabled 0x0C - SNMP Trap Receiver 3 IP Address 0x0D - SNMP Trap Receiver 3 Traps Enabled 0x0E - SNMP Trusted Hosts Enabled 0x0F - SNMP Telnet Port (NOT SUPPORTED AT PRESENT) 0x10 - Transceiver Channel Attributes 0x11 - CPU Build Options The trailing octets, octet 1 through the last octet in the object store the new data for the object that has changed. If octet 0 is 0x00 (System Date & Time has changed) octets 1 through the last octet in the octet string store the new value. The new value will be of the format defined by umc1SystemDateTime. If octet 0 is 0x01 (ACO Configuration has changed) octet 1 stores the new value. The format of the new value is defined by umc1SystemSysProvACOConfig. (NOT SUPPORTED AT PRESENT) If octet 0 is 0x02 (System Timing Interface has changed), the trailing octets contain the value. OPEN ISSUE: We will add the description once we ascertain the format of the CPU database record for the current release. The format of the data returned is defined by umc1SystemSysTimingSource. (NOT SUPPORTED AT PRESENT) If octet 0 is 0x03 (PSU Ring Voltage has changed), octet 1 contains PSU Ring Voltage value. The format of the data returned is defined by umc1SystemSysProvPsuRingVoltage. If octet 0 is 0x04 (PSU Meter Tone has changed), octets 1 through 4 contain PSU Meter Tone value, where octets 1, 2, 3, and 4 contain bits 24..31, 16..23, 8..15, 0..7, respectively. The format of the data returned is defined by umc1SystemSysProvPsuPulseMeterTone. If octet 0 is 0x05 (PSU Ring Frequency has changed), octets 1 through 2 contain PSU Ring Frequency value, where octets 1 and 2 contain bits 8..15 and 0..7, respectively. The format of the data returned is defined by umc1SystemSysProvPsuRingFreq. If octet 0 is 0x06 (SNMP Community name has changed), octets 1 through the last octet in the octet string contain the new SNMP community name. (NOT SUPPORTED AT PRESENT - we do not issue this information for security reasons !). If octet 0 is 0x07 (SNMP Trap Types Enabled has changed), octet 1 contains the new value for object umc1SnmpTrapTypesEnabled. If octet 0 is 0x08 (SNMP Trap Receiver 1 IP Address has changed), octets 1 through 4 contain the new value of the object umc1SnmpTrapRcvrAddress. If octet 0 is 0x09 (SNMP Trap Receiver UDP Port has changed), octets 1 through 4 contain the new value of the object umc1SnmpTrapRcvrPort. If octet 0 is 0x0A (SNMP Trap Receiver 2 IP Address has changed), octets 1 through 4 contain the new value of the object umc1SnmpMgmtHost2Address. If octet 0 is 0x0B (SNMP Trap Receiver 2 Traps Enabled has changed), octet 1 contains umc1SnmpMgmtHost2TrapsEnabled. If octet 0 is 0x0C (SNMP Trap Receiver 3 IP Address has changed), octets 1 through 4 contain the new value of the object umc1SnmpMgmtHost3Address. If octet 0 is 0x0D (SNMP Traps Receiver 3 Traps Enabled has changed), octets 1 through 4 contain the new value of the object umc1SnmpMgmtHost3TrapsEnabled. If octet 0 is 0x0E (SNMP Trusted Hosts Enabled has changed), octets 1 through 4 contain the new value of the object umc1SnmpTrustedHostsEnabled. If octet 0 is 0x0F (SNMP Telnet Port has changed), octets 1 through 4 contain the new value of the object umc1SnmpTelnetPort. (NOT SUPPORTED AT PRESENT - this is managed via the IPMI Plugin Provisioning record table and associated TRAPs). If octet 0 is 0x10 (Transceiver Channel Attributes), the trailing octets contain the value. The remainder of the octet contents are described as follow : octet[1] 'version' of data (1 for this release) for octet[1] (version ) equal 1 octet[2] 'action', either record delete or modify/create. See 'DbActionType'. octet[3] 'dbSpecifier', set to _DbChanAtrb_ (0x0A) octet[4] 'dbRecLen', length of the database record to follow in number of bytes. The database record will be held in octets[5] - [?]. The actual number of octets will vary, dependent upon the type of Channel Attribute record being reported. octet[5] - [?] The actual CPU database record. If octet 0 is 0x11 (CPU Build Options), the trailing octets contain the value of the changed option(s) object 'umc1CpuSoftwareFeatures'. If the CPU does not support the reporting of this data the values of all bytes of the object returned will be set to zero (including the version octet[0]).

A sequence number used to indicate that the Global System Provisioning Table, umc1SystemSysProvTable, has been modified and it needs to be re-read. Whenever the SNMP agent is restarted, this value will be reset to 0(zero). The value will be incremented by one whenever a change to the Global System Provisioning Table has been made. This number will also be sent in the umc1TrapSysProvChgTableChangeUpd trap and can be used to determine if any traps have been lost by the manager. This value will be incremented before the trap is sent. The maximum value it can assume is 2,147,483,647. An increment, every time it has reached its maximum value, shall cause it to be reset to 1.

This object defines the configuration of the system-wide alarm cut-off (ACO) button. It could be UMC_Mode, Standard_Mode, or Extended_Mode ACO operation. In the UMC_Mode, one push of the ACO button results in the cut-off of the current alarms and the clearing of the Plug-and-play current alarm conditions. The Plug-and-play alarms are Missing Card Alarm, Loss of Composite Clock Alarm, Loss of A/B Power Lead Alarm, Unexpected RSU Registration Alarm. In Standard_Mode mode, the ACO button operates as a traditional ACO and only cuts off audible alarms. The Plug-and-play alarms can only be cleared via the Craft User interface or the restoration of the event that caused the alarm. In the Extended_Mode ACO the ACO button has two time thresholds, a short one, and a long one. A short depression of the ACO button results in alarm cut-off, but it does not clear the plug and play alarms. A long depression of the ACO button results in the alarm cut off and the clearing of plug and play alarms. The acceptable values for this object and their corresponding meanings are: Integer Value Meaning 1 UMC Mode 2 Standard Mode 3 Extended ACO Mode

This object is used to access or modify the timing source used by the UMC system. OPEN ISSUE: We will add the description once we ascertain the format of the CPU database record for the current release.

This object is used to access get the current temperature of the terminal that houses the IPMI Agent. OPEN ISSUE: We will change the description once we ascertain the CPU support for retrieval of the system temperature.

The EMS uses this table to access and update the channel attributes associated with ADSL port in the system or the channel attributes of transceiver plugin cards (eg, T1).

An entry in the System Global Channel Attribute table.

This object contains the information that identifies the ADSL port associated with the DMT carrier mask being defined or the terminal, shelf, slot and channel(s) associated with the transceiver they are associated with. It also contains the information on the transceiver channel attributes and Nx64 groups. For the initial implementation the OCTET representation will be as follows: octet[0] Version number of the octet representation being used to define this INDEX. The version number for the initial implementation will be 0x01. For Version number 0x01 the remaining octets will be defined as follows : octet[1] DB specifier octet for the type of channel attribute record being referenced. octet[2] High-order byte of plugin type (see PlugInType). octet[3] Low-order byte of the plugin type. octet[4] Terminal Identifier (see TerminalIdType). octet[5] Shelf Identifier (see ShelfIdType). octet[6] Slot Identifier (see SlotIdType). octet[7] Bits 31..24 of Channel or Port identifier. The channel or port identifier value to access Nx64 provisioning records starts at 128, i.e., the index of the first Nx64 provisioning record is 128, the index of the second one is 129ecu, and so on. octet[8] Bits 23..16 of Channel or Port identifier. octet[9] Bits 15..8 of Channel or Port identifier. octet[10] Bits 7..0 of Channel or Port identifier. octet[11] - [?] The packed DB record index info .. this will depend upon the DB specifier type (octet[1]).

This object contains the DMT carrier mask associated with an ADSL port or the channel attributes of a Transceiver card. octet[1] 'version' of data (1 for this release) for octet[1] (version ) equal 1 octet[2] 'dbSpecifier', set to _DbChanAtrb_ (0x0A) octet[3] 'dbRecLen', length of the database record to follow in number of bytes. The database record will be held in octets[4] - [?]. The actual number of octets will vary, dependent upon the type of Channel Attribute record being reported. octet[4] - [?] The actual CPU database record.

A Management Station uses this table to GET and SET a *single* Plug-in Provisioning record. Access to this table is read-write. By implementation, this table supports GET and SET operations, but does not support GET-NEXT operations.

An entry in the Plug-In Provisioning.

See description for 'TerminalIdType'.

See description for 'ShelfIdType'.

See description for 'SlotIdType'.

See description for 'PlugInType'.

The structure of this object is the same for Get Response PDUs and Set Request PDUs. In a SET Request the data is included in the Request PDU. In a GET Request the data is returned in the Response PDU. An operation to delete a PlugIn provisioning record is not implemented, per se. In order to delete a PlugIn Provisioning record for a given PlugInType in a given location, the manager must issue a SET request; the umc1SystemPitProvData column must contain the Default PlugIn Provisioning record for the PlugInType. A GET Request for a PlugIn Provisioning Record thus deleted shall return the Default PlugIn Provisioning Record for the given PlugIn. The byte-format structure of this object, taking into account the above description, is as follows: octet[0] Version number of the octet representation. The version number for the initial implementation will be 0x01. For Version number 0x01 the remaining octets will be defined as follows : octet[1] DB specifier octet. octet[2] - [?] The plug-in provisioning DB record.

A Management Station uses this table to read a *single* Default Plug-in Provisioning record. Access to this table is read-only. By implementation, this table supports GET and GET-NEXT operations but does not support SET operations.

An entry in the Default Plug-In Provisioning Table.

See description for 'TerminalIdType'.

See description for 'ShelfIdType'.

See description for 'SlotIdType'.

See description for 'PlugInType'.

In a SNMP GET or GET-NEXT operation the data is returned in the Response PDU. The byte-format structure of this object, taking into account the above description, is as follows: octet[0] Version number of the octet representation. The version number for the initial implementation will be 0x01. For Version number 0x01 the remaining octets will be defined as follows : octet[1] DB specifier octet. octet[2] - [?] The default plug-in provisioning DB record.

The EMS uses this table to synchronize its internal representation of the Plug-In Provisioning data with that managed by the UMC Agent. A trap is issued to the EMS indicating a change to the Provisioning data has been made and entered as a row in this table. The EMS queries this table, using the sequence number received in the umc1TrapPitProvChange trap to determine whether it can re-learn the changed Provisioning information from this table or must re-learn *all* Plug-In Provisioning information, bypassing this table. When the value of umc1SystemPitProvTableChangeSeqNum is zero this table is empty.

An entry in the Plug-In Provisioning Change table.

This object's value matches the value of umc1SystemPitProvTableChangeSeqNum at the time the row was created. A valid value of this object is in the range of 1 through umc1SystemPitProvTableChangeSeqNum.

This object records the location of the Plug-in, type of the Plug-In, nature of the change (add/modify/delete) and, possibly, the database record associated with the change that has been made to the Plug-in Provisioning Table. The format of the object is as follows: octet 0: Version number of the octet representation. The version number for the initial implementation will be 0x01. octet 1: Terminal Identifier of the Plug-in. octet 2: Shelf Identifier of the Plug-in. octet 3: Slot Identifier of the Plug-in. octet 4: High-order octet of the plug-in type of the Plug-in. octet 5: Low-order octet of the plug-in type of the Plug-in. octet 6: Action octet, stores the action (update/delete) performed on the umc1SystemPitProvTable. See DbActionType for valid values of this octet. In case of a delete action octet 6 is the last octet in the octet string. Otherwise, more octets are present and they are defined as follows: octet 7: DB specifier octet octet 8 through the last octet contain the database record.

A sequence number used to indicate that the PlugIn Provisioning Table, umc1SystemPitProvTable, has been modified and it needs to be re-read. Whenever the SNMP agent is restarted, this value will be reset to 0(zero). The value will be incremented by one whenever a change to the PlugIn Provisioning Table has been made. This number will also be sent in the umc1TrapPitProvChgTableChangeUpd trap and can be used to determine if any traps have been lost by the manager. This value will be incremented before the trap is sent. The maximum value it can assume is 2,147,483,647. An increment, every time it has reached its maximum value, shall cause it to be reset to 1.

A sequence number used to indicate that facility alarm description string table has been modified and it needs to be re-read. Whenever the SNMP agent is restarted, this value will be reset to 0(zero). The value will be incremented by one whenever a change to the facility alarm description string table is made. This number will also be sent in the umc1TrapFacAlmStringTableChange trap and can be used to determine if any traps have been lost. This value will be incremented before the trap is sent. The maximum value it can assume is 2,147,483,647. An increment, every time it has reached its maximum value, shall cause it to be reset to 1.

This table contains facility alarm description strings for a given plugin in a UMC system. SNMP GET-NEXT operation is not allowed.

An entry in the facility alarm description strings table.

Identifier of a terminal.

Identifier of a shelf.

Identifier of a slot.

Identifier of a port on a card. The range of the value depends on the plugin-type of the card. If the card does not have a port use 0xFF.

This object identifies the plug-in type (PIT) of a card in the UMC system.

This object contains the facility alarm string description. In order to delete an alarm string the user *MUST* perform a SET operation with a string containing just the NULL character. In the current UMC Release the maximum length of a facility alarm description string is 20 characters.. The string is not terminated by a NULL character.

The EMS uses this table to synchronize its internal representation of the facility alarm description strings with that managed by the UMC Agent. A trap is issued to the EMS indicating that a change to the facility alarm description string database (and hence the umc1FacAlmStringTable) has been made and entered as a row in this table. The EMS queries this table, using the sequence number received in the umc1TrapFacAlmStringTableChange trap, to determine whether it can re-learn the changed umc1FacAlmStringTable row/record from this table or must re-learn *all* strings, bypassing this table. When the value of umc1FacAlmStringTableChangeSeqNum is zero this table is empty.

An entry in the facility alarm description string table change history table.

This object's value matches the value of umc1FacAlmStringTableChangeSeqNum at the time the row was created. A valid value of this object is in the range of 1 through umc1FacAlmStringTableChangeSeqNum.

This object records the changes to umc1FacAlmStringTable. In the initial implementation the first octet, octet[0] will store the version number of the octet representation being used to define the changed provisioning data. The version number for the initial implementation will be 0x01. For Version number 0x01 the remaining octets will be defined as follows: octet[1] action octet, stores the action (update/delete) performed on the umc1FacAlmStringTable. See DbActionType for valid values of this octet. octet[2] Terminal Identifier. octet[3] Shelf Identifier. octet[4] Slot Identifier octet[5] Facility Identifier. octet[6] Bits 15..8 of the plugin type. octet[7] Bits 7..0 of the plugin type. octet[8]-[x] The facility alarm description string record that was create/modified/deleted. The string will be terminated by a NULL character.

A sequence number used to indicate that TL1 interface provisioning table has been modified and it needs to be re-read. Whenever the SNMP agent is restarted, this value will be reset to 0(zero). The value will be incremented by one whenever a change to the TL1 interface provisioning table is made. This number will also be sent in the umc1TrapTL1IfProvTableChange trap and can be used to determine if any traps have been lost. This value will be incremented before the trap is sent. The maximum value it can assume is 2,147,483,647. An increment, every time it has reached its maximum value, shall cause it to be reset to 1.

This table contains TL1 interface provisioning for a given OSI card in a UMC system. SNMP GET-NEXT operation is not allowed.

An entry in the TL1 interface provisioning table.

Identifier of a terminal.

Identifier of a shelf.

Identifier of a slot.

Identifier of a TL1 interface on the OSI card. The range of the value is between 1 (one) and 6 (six).

This object identifies the plug-in type (PIT) of a card in the UMC system.

This object contains the TL1 interface provisioning database. In the current UMC Release the maximum length of a TL1 interface provisioning database is 15 octets. For the initial implementation the OCTET representation will be as follows : octet[0] Version number of the octet representation. The version number for the initial implementation will be 0x01. For Version number 0x01 the remaining octets will be defined as follows: octet[1] DB specifier octet. octet[2] TL1 Type octet[3-10] Record Type The values of octet[3] to octet[10] will depends on value of TL1 Type octet. TL1 Type Meaning Value of Record Type 0 Disabled Octet[3]-octet[10] will be Zero 1 Asynchronous Octet[3]-octet[10] will be Zero 2 SVC Octet[3]-octet[10] represents Binary Coded Decimal(BCD) for Data Terminal Number(DTN) 3 PVC Octet[3]represents Logical Channel Number Octet[4]-octet[10] will be Zero In order to delete a TL1 interface provisioning database record, the Management Station *MUST* perform a SET and send an octet string of length 2 octets (for the version octet and the DB specifier octet) with octet[0] set to a valid version number, octet[1] set to the valid DB Specifier and with NO additional data octets supplied.

The EMS uses this table to synchronize its internal representation of the TL1 interface provisioning with that managed by the UMC Agent. A trap is issued to the EMS indicating that a change to the TL1 interface provisioning database (and hence the umc1TL1IfProvTable) has been made and entered as a row in this table. The EMS queries this table, using the sequence number received in the umc1TrapTL1IfProvTableChange trap, to determine whether it can re-learn the changed umc1TL1IfProvTable row/record from this table or must re-learn *all* TL1 interface provisioning database records, bypassing this table. When the value of umc1TL1IfProvTableChangeSeqNum is zero this table is empty.

An entry in the TL1 interface provisioning table change history table.

This object's value matches the value of umc1TL1IfProvTableChangeSeqNum at the time the row was created. A valid value of this object is in the range of 1 through umc1TL1IfProvTableChangeSeqNum.

This object records the changes to umc1TL1IfProvTable. In the initial implementation the first octet, octet[0] will store the version number of the octet representation being used to define the changed provisioning data. The version number for the initial implementation will be 0x01. For Version number 0x01 the remaining octets will be defined as follows: octet[1] action octet, stores the action (update/delete) performed on the umc1TL1IfProvTable. See DbActionType for valid values of this octet. octet[2] Terminal Identifier. octet[3] Shelf Identifier. octet[4] Slot Identifier octet[5] Interface Identifier. Octet[6] Bit 15..8 of Plugin Type Octet[7] Bit 0..7 of Plugin Type Octet[8] TL1 Type Octet[9-16] Record Type See the description of umc1TL1IfProvData for the possible values TL1 Type and Record Type octet.

This object lists the features built into the UMC system. The list information required by the IPMI and EMS to determine the type of features the UMC system supports, and hence, what the EMS and IPMI Agent can manage. octet[0] Version number of the octet representation being used to define this information. The version number for the initial implementation will be 0x01. For Version number 0x01 the remaining octets will be defined as follows : octet[1] CPU Application Version octet[2] CPU Application Revision octet[3] CPU Application Point octet[4] High-order 8-bits (MSB) CPU Application CRC-16 octet[5] Low-order 8-bits (LSB) CPU Application CRC-16 octet[6] Represents National Standards. The valid values and their corresponding meanings are: Value Meaning ===== ======= 0x01 North American (ANSI) 0x02 European Telecommunications Standards International (ETSI) octet[7] Max Terminals the CPU can support octet[8] Max Shelves the CPU can support octet[9] Bit Mapped representation of Supported Languages Value Meaning ===== ======= 0x01 English 0x02 French 0x04 Portuguese 0x08 Spanish 0x10 Hungarian 0x20 Russian octet[10] Max GR303 Groups the CPU can support octet[11] Max TR08 Groups the CPU can support octet[12] Max Number of Plug-in types the CPU supports: MSB octet[13] Max Number of Plug-in types the CPU supports: LSB

A sequence number used to indicate the number of times the ACO operation has been performed since the agent last restarted. Whenever the SNMP agent is restarted, this value will be reset to 0 (zero). This number will also be sent in the umc1TrapSytemRelearnTrap trap and can be used to determine if any traps have been lost. The value will be incremented before the trap is sent.

A change in the value of certain MIB objects could be service affecting. Henceforth, such objects are called restricted objects. The object umc1RestrictedAccess is used to control a SET operation on the restricted objects. A SET to the umc1RestrictedAccess object (set to enable) must precede a SET to restricted objects in the same PDU. Further, a SET to the umc1RestrictedAccess object (set to disable) must follow a SET to restricted objects in the same PDU. A GET operation to read its value shall always return the value disable. Enumeration: 'enable': 1, 'disable': 2.

A sequence number used to indicate that the GR-303 group provisioning Table, umc1GR303Table, has been modified and it needs to be re-read. Whenever the SNMP agent is restarted, this value will be reset to 0(zero). The value will be incremented by one whenever a change to the GR-303 group provisioning table is made. This number will also be sent in the umc1TrapGR303TableChange trap and can be used to determine if the manager has lost any traps. This value will be incremented before the trap is sent. The maximum value it can assume is 2,147,483,647. An increment, every time it has reached its maximum value, shall cause it to be reset to 1.

A Management Station uses this table to read, modify, create or delete a GR-303 Group in the UMC system. The MIB Table has two columns one for the Index and one for the Group provisioning information. It is currently indexed by the GR-303 Group Number value.

An entry in the GR-303 Group Provisioning Table.

It contains the Terminal and GR-303 Group number that identifies the record in the UMC system. For the initial implementation the OCTET representation will be as follows: octet[0] Version number of the octet representation being used to define this INDEX. The version number for the initial implementation will be 0x01. For Version number 0x01 the remaining octets will be defined as follows : octet[1] DB specifier octet for the type of GR-303 record being referenced. octet[2] Terminal number the GR-303 Group is associated with. See 'TerminalIdType' for the definition of valid Terminal values. Currently, only (Terminal equal LET) is valid for this field. octet[3] GR-303 Group number of the GR-303 Group to retrieve. The Group number is 1 based (i.e., set this to 0x01 for GR-303 Group 1, 0x02 for GR-303 Group 2, etc.

The GR-303 Group Provisioning record. For the initial implementation the OCTET representation will be as follows : octet[0] Version number of the octet representation being used to define the following provisioning data. The version number for the initial implementation will be 0x01. For Version number 0x01 the remaining octets will be defined as follows: Octet[1] DB Specifier octet Octet[2] - [n] Octet packed GR-303 Group Provisioning record. In a GET Request the data field is empty. In a SET Request it contains the GR-303 provisioning record. In order to delete a GR-303 Group, the Management Station *MUST* perform a SET and send an octet string of length 2 octets (for the version octet and the DB specifier octet) with octet[0] set to a valid version number, octet[1] set to the valid DB Specifier and with NO additional data octets supplied.

The EMS uses this table to synchronize its internal representation of the GR-303 Group Provisioning data with that managed by the UMC Agent. A trap is issued to the EMS indicating that a change to the GR-303 database (and hence the umc1GR303Table) has been made and entered as a row in this table. The EMS queries this table, using the sequence number received in the umc1TrapGR303TableChange trap, to determine whether it can re-learn the changed umc1GR303Table row/record from this table or must re-learn *all* GR-303 information, bypassing this table. When the value of umc1GR303TableChangeSeqNum is zero this table is empty.

An entry in the GR-303 Group Provisioning Table Change history table.

This objects value matches the value of umc1GR303TableChangeSeqNum at the time the row was created. A valid value of this object is in the range of 1 through umc1GR303TableChangeSeqNum.

This object records the changes to the GR-303 Group Provisioning table. For the initial implementation the OCTET representation will be as follows: octet[0] Version number of the octet representation being used to define the following changed provisioning data. The version number for the initial implementation will be 0x01. For Version number 0x01 the remaining octets will be defined as follows: octet[1] action octet, stores the action (update/delete) performed on the umc1GR303Table. See DbActionType for valid values of this octet. octet[2] DB specifier octet octet[3]-[n] The octet packed GR-303 Group Provisioning record that was create/modified/deleted.

A sequence number used to indicate that the TR-8 group provisioning Table, umc1TR8Table, has been modified and it needs to be re-read. Whenever the SNMP agent is restarted, this value will be reset to 0(zero). The value will be incremented by one whenever a change to the TR-8 group provisioning table is made. This number will also be sent in the mc1TrapTR8TableChange trap and can be used to determine if the manager has lost any traps. This value will be incremented before the trap is sent. The maximum value it can assume is 2,147,483,647. An increment, every time it has reached its maximum value, shall cause it to be reset to 1.

A Management Station uses this table to read, modify, create or delete a TR-8 Group in the UMC system. The MIB Table has two columns one for the Index and one for the Group provisioning information.

An entry in the TR-8 Group Provisioning Table.

It contains the Terminal and TR-8 Group number that identifies the record in the UMC system. For the initial implementation the OCTET representation will be as follows: octet[0] Version number of the octet representation being used to define this INDEX. The version number for the initial implementation will be 0x01. For Version number 0x01 the remaining octets will be defined as follows: octet[1] DB specifier octet for the type of TR-8 record being referenced. octet[2] Terminal number the TR-8 Group is associated with. See 'TerminalIdType' for the definition of valid Terminal values. octet[3] TR-8 Group number of the TR-8 Group to retrieve. The Group number is 1 based (i.e., set this to 0x01 for TR-8 Group 1, 0x02 for TR-8 Group 2, etc.

The TR-8 Group Provisioning record. For the initial implementation the OCTET representation will be as follows: octet[0] Version number of the octet representation being used to define the following provisioning data. The version number for the initial implementation will be 0x01. For Version number 0x01 the remaining octets will be defined as follows: octet[1] DB specifier octet octet[2]-[n] Octet packed TR-8 Group Provisioning record. In a GET Request the data field is empty. In a SET Request it contains the TR-8 provisioning record. In order to delete a TR-8 Group, the Management Station *MUST* perform a SET and send an octet string of length 2 octets (for the version and DB specifier octets) with octet[0] set to a valid version number and octet[1] set to a valid DB type. No additional data octets should be supplied.

The EMS uses this table to synchronize its internal representation of the TR-8 Group Provisioning data with that managed by the UMC Agent. A trap is issued to the EMS indicating that a change to the TR-8 database (and hence the umc1TR8Table) has been made and entered as a row in this table. The EMS queries this table, using the sequence number received in the umc1TrapTR8TableChange trap, to determine whether it can re-learn the changed umc1TR8Table row/record from this table or must re-learn *all* TR-8 information, bypassing this table. When the value of umc1TR8TableChangeSeqNum is zero this table is empty.

An entry in the TR-8 Group Provisioning Table Change history table.

This objects value matches the value of umc1TR8TableChangeSeqNum at the time the row was created. A valid value of this object is in the range of 1 through umc1TR8TableChangeSeqNum.

This object records the changes to the TR-08 Group Provisioning table. For the initial implementation the OCTET representation will be as follows: octet[0] Version number of the octet representation being used to define the following changed provisioning data. The version number for the initial implementation will be 0x01. For Version number 0x01 the remaining octets will be defined as follows: octet[1] action octet, stores the action (update/delete) performed on the umc1Tr8Table. See DbActionType for valid values of this octet. octet[2] DB specifier octet octet[3]-[n] The octet packed TR-08 Group Provisioning record that was create/modified/deleted.

A sequence number used to indicate that the V5 provisioning Table, umc1V5Table, has been modified and it needs to be re-read. Whenever the SNMP agent is restarted, this value will be reset to 0(zero). The value will be incremented by one whenever a change to the V5 provisioning table is made. This number will also be sent in the umc1TrapV5TableChange trap and can be used to determine if the manager has lost any traps. This value will be incremented before the trap is sent. The maximum value it can assume is 2,147,483,647. An increment, every time it has reached its maximum value, shall cause it to be reset to 1.

A Management Station uses this table to read, modify, create or delete V5.1 or V5.2 groups, variant records and C-Channel records (V5.2 only) in the UMC system. The MIB Table has two columns one for the Index and one for the provisioning information.

An entry in the V5 Provisioning Table.

It contains the indices that identify a V5 record in the UMC system. The format of the indices depends on the type of the record that will be accessed. There are three (3) types of records, namely, Group provisioning records, Variant provisioning records and C-Channel provisioning records (V5.2 only). For the initial implementation the OCTET representation for each type of record is given below. octet[0] Version number of the octet representation being used to define this INDEX. The version number for the initial implementation will be 0x01. For Version number 0x01 the remaining octets will be defined as follows for each type of record: 1. For V5 Group Provisioning records. octet[1] DB specifier octet. octet[2] Terminal number the V5 Group is associated with. See 'TerminalIdType' for the definition of valid Terminal values. octet[3] Group number the V5 Group is associated with. The See 'V5GroupIdType' for the definition of valid Group values. 2. For V5 Variant Provisioning records. octet[1] DB specifier octet. octet[2] Terminal number the V5 Variant is associated with. See 'TerminalIdType' for the definition of valid Terminal values. octet[3] Group number the V5 Variant is associated with. The See 'V5GroupIdType' for the definition of valid Group values. octet[4] Variant identifier of the V5 Variant. Valid values are 0x00 and 0x01. 3. For V5.2 C-Channel Provisioning records. octet[1] DB specifier octet. octet[2] Terminal number the V5.2 C-Channel is associated with. See 'TerminalIdType' for the definition of valid Terminal values. octet[3] Group number the V5.2 C-Channel is associated with. The See 'V5GroupIdType' for the definition of valid Group values. octet[4] C-Channel Set identifier. A valid value of the C-Channel Set identifier lies between 0x00 through 0x03.

The V5 Provisioning record. For the initial implementation the OCTET representation will be as follows: octet[0] Version number of the octet representation being used to define the following provisioning data. The version number for the initial implementation will be 0x01. For Version number 0x01 the remaining octets will be defined as follows: octet[1] DB specifier octet octet[2]-[n] Octet packed V5 Provisioning record. In a GET Request the data field is empty. In a SET Request it contains the V5 provisioning record. See the definition of umc1V5Index for the types V5 provisioning records. In order to delete a V5 provisioning record, the Management Station *MUST* perform a SET and send an octet string of length 2 octets (for the version and DB specifier octets) with octet[0] set to a valid version number and octet[1] set to a valid DB type. No additional data octets should be supplied.

The EMS uses this table to synchronize its internal representation of the V5 Provisioning data with that managed by the UMC Agent. A trap is issued to the EMS indicating that a change to the V5 database (and hence the umc1V5Table) has been made and entered as a row in this table. The EMS queries this table, using the sequence number received in the umc1TrapV5TableChange trap, to determine whether it can re-learn the changed umc1V5Table row/record from this table or must re-learn *all* V5 information, bypassing this table. When the value of umc1V5TableChangeSeqNum is zero this table is empty.

An entry in the V5 Provisioning Table Change history table.

This objects value matches the value of umc1V5TableChangeSeqNum at the time the row was created. A valid value of this object is in the range of 1 through umc1V5TableChangeSeqNum.

This object records the changes to the V5 Provisioning table. In the initial implementation the first octet, octet[0] will store the version number of the octet representation being used to define the changed provisioning data. The version number for the initial implementation will be 0x01. For Version number 0x01 the remaining octets will be defined as follows: octet[1] Holds the number of database records in this object. The packed octet representation of each record is given below octet[2] Length of a record. octet[3] action octet, stores the action (update/delete) performed on the umc1V5Table. See DbActionType for valid values of this octet. octet[4] DB specifier octet octet[5]-[x] The octet packed V5 Provisioning record that was create/modified/deleted.

A sequence number used to indicate that the cross connect Table, umc1XCTable, has been modified and it needs to be re-read. Whenever the SNMP agent is restarted, this value will be reset to 0(zero). The value will be incremented by one whenever a change to the cross connect Table is made. This number will also be sent in the umc1TrapXCTableChange trap and can be used to determine if the manager has lost any trap. This value will be incremented before the trap is sent. The maximum value it can assume is 2,147,483,647. An increment, every time it has reached its maximum value, shall cause it to be reset to 1.

A Management Station uses this table to read/update/delete a cross connect in the UMC system. Call Reference Numbers (CRNs) identify the end-points of a cross connect in the UMC system. The CRNs could be of variable size. Every cross connect has two end-points: a CRN IN and a CRN OUT. The MIB Table has two columns one for each CRN. It is indexed by the CRN IN value.

An entry in the cross connect Table.

It contains one end-point of a cross connect in the UMC system, i.e., the CRN IN number. For the initial implementation the OCTET representation will be as follows: octet[0] Version number of the octet representation being used to define the cross connect data. The version number for the initial implementation will be 0x01. For Version number 0x01 the remaining octets will be defined as follows : octet[1] DB specifier octet for the type of cross connect record being referenced. Octet[2] - [n] Octet packed CRN IN of cross connect.

The cross connect record. For the initial implementation the OCTET representation will be as follows: octet[0] Version number of the octet representation being used to define the cross connect data. The version number for the initial implementation will be 0x01. For Version number 0x01 the remaining octets will be defined as follows : Octet[1] DB Specifier octet Octet[2] - [n] Entire cross connect record (i.e. both CRN IN & CRN OUT). In a GET Request the data field is empty. In a SET Request it contains the new cross connect record. In order to delete a cross connect, the Management Station *MUST* perform a SET and send an octet string of length 2 octets (for the version and DB specifier octets) with octet[0] set to a valid version number and octet[1] set to a valid DB type. No additional data octets should be supplied.

The EMS uses this table to synchronize its internal representation of the cross connect data with that managed by the UMC Agent. A trap is issued to the EMS indicating that a change to the cross connect database has been made and entered as a row in this table. The EMS queries this table, using the sequence number received in the umc1TrapXCChange trap, to determine whether it can re-learn the changed cross connect database record from this table or must re-learn *all* cross connect information, bypassing this table. When the value of umc1XCChangeSeqNum is zero this table is empty.

An entry in the cross connect Table Change history table.

This objects value matches the value of umc1XCTableChangeSeqNum at the time the row was created. A valid value of this object is in the range of 1 through umc1XCTableChangeSeqNum.

This object records the changes made to the cross connect table. For the initial implementation the OCTET representation will be as follows : octet[0] Version number of the octet. The version number for the initial implementation will be 0x01. For Version number 0x01 the remaining octets will be defined as follows : octet[1] action octet, stores the action (update/delete) performed on the umc1XCTable. See DbActionType for valid values of this octet. octet[2] DB specifier octet octet[3] - [n] The octet packed cross connect record that was create/modified/deleted

This object encapsulates all sequence numbers. The format of this object is: Octet[0] contains version, 0x01 for this release. Octet[1-4] contains snmpOutTraps, which represents the number of traps sent by Agent. Octet[5-136] contains umc1AlmSeqNumbers corresponding to a umc1AlmTerminalIds. There are four octet for each umc1AlmSeqNumber and 33 Alarm Sequence Numbers one for each Terminal in UMC system. The first four octet represents umc1AlmSeqNumber for Terminal with identifier 1, subsequent four octet represents umc1AlmSeqNumber for Terminal with identifier 2 and so on. Octet[137-140] contains umc1AlmSeqTableChangeSeqNum Octet[141-144] contains umc1InventoryShelfTableChangeSeqNum Octet[145-148] contains umc1InventoryPluginTableChangeSeqNum Octet[149-152] contains umc1ACOSnapTopologySeqNum Octet[153-156] contains umc1SystemSysProvTableChangeSeqNum Octet[157-160] contains umc1SystemRelearnTrapSeqNum Octet[161-164] contains umc1TerminalInfoChangeSeqNum Octet[165-168] contains umc1TerminalStatusChangeSeqNum Octet[169-172] contains umc1TopologyChangeSeqNum Octet[173-176] contains umc1TerminalSpanTableChangeSeqNum Octet[177-180] contains umc1ShelfSpanTableChangeSeqNum Octet[181-184] contains umc1XCTableChangeSeqNum Octet[185-188] contains umc1GR303TableChangeSeqNum Octet[189-192] contains umc1TR8TableChangeSeqNum Octet[193-196] contains umc1AtmProtTableChangeSeqNum Octet[197-200] contains umc1PortProfTableChangeSeqNum Octet[201-204] contains umc1V5TableChangeSeqNum Octet[205-208] contains umc1FacAlmStringTableChangeSeqNum Octet[209-212] contains umc1TL1IfProvTableChangeSeqNum Octet[213-216] contains umc1SecurityDataTableChangeSeqNum Octet[217-220] contains umc1SystemGenericDbProvTableSeqNum Octet[221-224] contains umc1SystemTCAHistoryTableSeqNum Octet[225-255] ignored This object is a varbind for trap umc1TrapAllSeqNumber. The agent shall send trap umc1TrapAllSeqNbrDump when Management Station sends GET Request to read all sequence numbers.

A sequence number used to indicate that the ATM Protection group provisioning Table, umc1AtmProtGrpTable, has been modified and it needs to be re-read. Whenever the SNMP agent is restarted, this value will be reset to 0(zero). The value will be incremented by one whenever a change to the ATM Protection group provisioning Table is made. This number will also be sent in the umc1TrapAtmProtGrpTableChange trap and can be used to determine if the manager has lost any traps. This value will be incremented before the trap is sent. The maximum value it can assume is 2,147,483,647. An increment, every time it has reached its maximum value, shall cause it to be reset to 1.

A Management Station uses this table to read, modify, create or delete a ATM Protection Group in the UMC system. The MIB Table has two columns one for the Index and one for the Group provisioning information. It is currently indexed by the Terminal number and the ATM Protection Group Number value.

An entry in the ATM Protection Group Provisioning Table.

It contains the Terminal and ATM Protection Group number that identifies the record in the UMC system. For the initial implementation the OCTET representation will be as follows : octet[0] Version number of the octet representation being used to define this INDEX. The version number for the initial implementation will be 0x01. For Version number 0x01 the remaining octets will be defined as follows : octet[1] DB specifier octet for the type of ATM Protection Group record being referenced. octet[2] Terminal number the ATM Protection Group is associated with. See TerminalIdType for the definition of valid Terminal values. octet[3] ATM Protection Group number of the ATM Protection Group to retrieve. The Group number is 1 based (i.e., set this to 0x01 for ATM Protection Group 1, 0x02 for ATM Protection Group 2, etc.

The ATM Protection Group Provisioning record. For the initial implementation the OCTET representation will be as follows : octet[0] Version number of the octet representation being used to define the following provisioning data. The version number for the initial implementation will be 0x01. For Version number 0x01 the remaining octets will be defined as follows : octet[1] DB specifier octet octet[2] - [n] Octet packed ATM Protection Group Provisioning record. In a GET Request the data field is empty. In a SET Request it contains the ATM Protection provisioning record to be written to the UMC database. In order to delete a ATM Protection Group, the Management Station *MUST* : 1. perform a SET operation and send an octet string of length 2 octet (for the version octet) with octet[0] set to a valid version number, octet[1] set to a valid DB type specifier and with NO additional data octets supplied. OR 2. perform a SET operation with octet[0] set to a valid version number, octet[1] set to a valid DB type specifier and with all following octets of umc1AtmProtGrpData set to the values of a DEFAULT ATM Protection Group provisioning record.

The EMS uses this table to synchronize its internal representation of the ATM Protection Group Provisioning data with that managed by the UMC Agent. A trap is issued to the EMS indicating that a change to the ATM Protection database (and hence the umc1AtmProtGrpTable) has been made and entered as a row in this table. The EMS queries this table, using the sequence number received in the umc1TrapAtmProtGrpTableChange trap, to determine whether it can re-learn the changed umc1AtmProtGrpTable row/record from this table or must re-learn *all* ATM Protection information, bypassing this table. When the value of umc1AtmProtTableChangeSeqNum is zero this table is empty.

An entry in the ATM Protection Group Provisioning Table Change history table.

This objects value matches the value of umc1AtmProtTableChangeSeqNum at the time the row was created. A valid value of this object is in the range of 1 through umc1AtmProtTableChangeSeqNum.

This object records the changes to the ATM Protection Group Provisioning table. For the initial implementation the OCTET representation will be as follows : octet[0] Version number of the octet representation being used to define the following changed provisioning data. The version number for the initial implementation will be 0x01. For Version number 0x01 the remaining octets will be defined as follows : octet[1] action octet, stores the action (update/delete) performed on the umc1AtmProtGrpTable. See DbActionType for valid values and meaning of this octet. octet[2] DB specifier octet octet[3] - [n] The octet packed ATM Protection Group Provisioning record that was create/modified/deleted.

A sequence number used to indicate that the Port Profile provisioning Table, umc1PortProfTable, has been modified and it needs to be re-read. Whenever the SNMP agent is restarted, this value will be reset to 0x00 (zero). The value will be incremented by one whenever a change to the Port Profile provisioning Table is made. This number will also be sent in the umc1TrapPortProfTableChange trap and can be used to determine if the manager has lost any traps. This value will be incremented before the trap is sent. The maximum value it can assume is 2,147,483,647. An increment, every time it has reached its maximum value, shall cause it to be reset to 1.

A Management Station uses this table to read, modify, create or delete a Port Profile in the UMC system. The MIB Table has two columns one for the Index and one for the Port Profile provisioning information.

An entry in the Port Profile Provisioning Table.

It contains the Plugin type the profile is for and Port Profile number that identifies the record in the UMC system. For the initial implementation the OCTET representation will be as follows : octet[0] Version number of the octet representation being used to define this INDEX. The version number for the initial implementation will be 0x01. For Version number 0x01 the remaining octets will be defined as follows : octet[1] DB specifier octet for the type of Port Profile record being referenced. octet[2] Plugin Type the Port Profile is associated with. octet[3] Port Profile number of the Port Profile being referenced. The Port Profile number is 1 based (i.e., set this to 0x01 for Port Profile 1, 0x02 for Port Profile 2, etc.)

The Port Profile provisioning record. For the initial implementation the OCTET representation will be as follows : octet[0] Version number of the octet representation being used to define the following provisioning data. The version number for the initial implementation will be 0x01. For Version number 0x01 the remaining octets will be defined as follows : octet[1] DB specifier octet octet[2] - [n] Octet packed Port Profile Provisioning record. In a GET Request the data field is empty. In a SET Request it contains the Port Profile provisioning record. In order to delete a Port Profile, the Management Station *MUST* : 1. perform a SET and send an octet string of length 2 octets (for the version octet and the DB specifier octet) with octet[0] set to a valid version number, octet[1] set to a valid DB specifier value and with NO additional data octets supplied. OR 2. perform a SET operation with octet[0] set to a valid version number, octet[1] set to a valid DB specifier value and with all following octets of umc1PortProfData set to the values of a DEFAULT Port Profile provisioning record.

The EMS uses this table to synchronize its internal representation of the Port Profile Provisioning data with that managed by the UMC Agent. A trap is issued to the EMS indicating that a change to the Port Profile database (and hence the umc1PortProfTable) has been made and entered as a row in this table. The EMS queries this table, using the sequence number received in the umc1TrapPortProfTableChange trap, to determine whether it can re-learn the changed umc1PortProfTable row/record from this table or must re-learn *all* Port Profile information, bypassing this table. When the value of umc1PortProfTableChangeSeqNum is zero this table is empty.

An entry in the Port Profile Provisioning Table Change history table.

This objects value matches the value of umc1PortProfTableChangeSeqNum at the time the row was created. A valid value of this object is in the range of 1 through umc1PortProfTableChangeSeqNum.

This object records the changes to the Port Profile Provisioning table. For the initial implementation the OCTET representation will be as follows : octet[0] Version number of the octet representation being used to define the following changed provisioning data. The version number for the initial implementation will be 0x01. For Version number 0x01 the remaining octets will be defined as follows : octet[1] action octet, stores the action (update/delete) on the umc1PortProfTable. See DbActionType for valid values and meaning of this octet. octet[2] DB specifier octet octet[3] - [n] The octet packed Port Profile Provisioning record that was create/modified/deleted.

This object lists the features built into this load of IPMI software. Octet[0] represents the version of the packed format of features described below. For this release the Version number will be 0x01. For version equal 0x01 the format of the following octets will be : OPEN ISSUE - define the format of this info !

A sequence number used to indicate that the User Security Data Table, umc1SecurityDataTable, has been modified and it needs to be re-read. Whenever the SNMP agent is restarted, this value will be reset to 0(zero). The value will be incremented by one whenever a change to the User Security Data Table is made. This number will also be sent in the umc1TrapSecurityDataTableChange trap and can be used to determine if the manager has lost any traps. This value will be incremented before the trap is sent. The maximum value it can assume is 2,147,483,647. An increment, every time it has reached its maximum value, shall cause it to be reset to 1.

A Management Station uses this table to read, modify, create or delete an User Security Data in the UMC system. The MIB Table has two columns one for the Index and one for the User Security Information. It is currently indexed by the User Number. In order to delete a User Security Data record the Management Station *MUST* perform a PUT operation with all octets of umc1SecurityDataTableData (defined shortly) to 0x00.

An entry in the User Security Data Table.

It contains the User Number that identifies the record in the UMC system. For the initial implementation the OCTET representation will be as follows: octet[0] Version number of the octet representation being used to define this INDEX. The version number for the initial implementation will be 0x01. For Version number 0x01 the remaining octets will be defined as follows: octet[1] DB specifier octet for the type of User Security record being referenced. octet[2] User Number with the User Security Data record is associated. It can take value from 0 to 29.

The User security Data record. For the initial implementation the OCTET representation will be as follows: octet[0] Version number of the octet representation being used to define the following provisioning data. The version number for the initial implementation will be 0x01. For Version number 0x01 the remaining octets will be defined as follows: octet[1] DB specifier octet octet[2] - [n] Octet packed encrypted User Security Data record. In a GET Request the data field is empty. In a SET Request it contains the User Security Data record. In order to delete a User Security Data, the Management Station *MUST* perform a SET and send an octet string of length 2 octets (for the version octet and the DB specifier octet) with octet[0] set to a valid version number, octet[1] set to a valid DB specifier value and with NO additional data octets supplied.

The EMS uses this table to synchronize its internal representation of the User Security data with that managed by the UMC Agent. A trap is issued to the EMS indicating that a change to the User Security data (and hence the umc1securityDataTable) has been made and entered as a row in this table. The EMS queries this table, using the sequence number received in the umc1TrapSecurityDataTableChange trap, to determine whether it can re-learn the changed umc1SecurityDataTable row/record from this table or must re-learn *all* User Security data, bypassing this table. When the value of umc1SecurityDataTableChangeSeqNum is zero this table is empty.

An entry in the User Security Data Table Change history table.

This object's value matches the value of umc1SecurityTableTableChangeSeqNum at the time the row was created. A valid value of this object is in the range of 1 through umc1SecurityTableTableChangeSeqNum.

This object records the changes to the User Security Data table. For the initial implementation the OCTET representation will be as follows: octet[0] Version number of the octet representation being used to define the following changed provisioning data. The version number for the initial implementation will be 0x01. For Version number 0x01 the remaining octets will be defined as follows: octet[1] action octet, stores the action (update/delete) on the umc1SecurityDataTable. See DbActionType for valid values and meaning of this octet. octet[2] DB specifier octet octet[3] User Number octet[4] - [n] The octet packed encrypted User Security Data record that was create/modified/deleted.

A sequence number used to indicate that the Generic Database Table, umc1SystemGenericDbProvTable, has been modified and it needs to be re-read. Whenever the SNMP agent is restarted, this value will be reset to 0(zero). The value will be incremented by one whenever a change to the Generic Database Table has been made. This number will also be sent in the umc1TrapGenericDbProvChange trap and can be used to determine if any traps have been lost by the manager. This value will be incremented before the trap is sent. The maximum value it can assume is 2,147,483,647. An increment, every time it has reached its maximum value, shall cause it to be reset to 1.

A Management Station uses this table to GET or SET a *single* UMC database Provisioning record. Access to this table is read-write. By implementation, this table supports GET and SET operations ONLY. GET NEXT (Progressive) is a special variant of GET which emulates a true SNMP GETNEXT by overloading the GET operation. We overload the GET to do this because the Management Station accessing us must actually perform the increment of the INDEX for us to truly make this table a generic interface. If the IPMI had to do this incrementing we would have to roll out a new IPMI release for each new DB record we wanted to support. Like GET NEXT (Progressive), GET DEFAULT is another special variant of GET which allows the retrieval of DEFAULT DATABASE records (where supported by the UMC System) by again overloading the GET operation. DELETE of a provisioning record is an extension of the SNMP SET operation and is described in more detail below.

An entry in the System Database.

This is the table INDEX. It is actually an octet encoded key representing the database record to be managed and how it is to be treated. It contains the Database Operation type, the DBSpecifier for database record, and the UMC system DB KEY identifying the record being referenced. For the initial implementation the OCTET representation will be as follows : octet[0] Version number of the octet representation being used to define this INDEX. The version number for the initial implementation will be 0x01. For Version number 0x01 the remaining octets will be defined as follows : octet[1] DB specifier octet for the database record being referenced. octet[2] Operation Type : See the DataOperation data type. octet[3] The Length (in bytes) of the database key in the following octets. octet[4] - [?] The actual UMC System database key to be used to manage the database record in question.

The structure of this object is the same for Get Response PDUs and Set Request PDUs. In a SET Request the data is included in the Request PDU. In a GET Request the data is returned in the Response PDU. This object holds the actual octets sent (for a SNMP SET) or retrieved (for a SNMP GET) request. The byte-format structure of this object, taking into account the above description, is as follows: octet[0] Version number of the octet representation. The version number for the initial implementation will be 0x01. For Version number 0x01 the remaining octets will be defined as follows : octet[1] Length of the following octet string. octet[2] - [?] The DB record data as it appears in the UMC system database. For a GET PROGRESSIVE request the returned key in the DATA octets described here should be compared to the key in umc1SystemGenericDbProvIndex to identify the actual record returned. In a GET Request the data field is empty. In a SET Request it contains the only the Data portion of database record. It does not contain the key bytes because Key for the database record is already specified in the Index umc1SystemGenericDbProvIndex. In order to delete a database record, the Management Station *MUST* perform a SET and send an octet string of length 1 octets (for the version octet) with octet[0] set to a valid version number with NO additional data octets supplied.

The EMS uses this table to synchronize its internal representation of the Generic Database management data with that managed by the UMC Agent. A trap is issued to the EMS indicating a change to the Generic Database Interface Management data has been made and entered as a row in this table. The EMS queries this table, using the sequence number received in the umc1TrapGenericDbProvChange trap to determine whether it can re-learn the changed Provisioning information from this table or must re-learn *all* the umc1SystemGenericDbProvTable information, bypassing this table. When the value of umc1SystemGenericDbProvTableSeqNum is zero this table is empty.

An entry in the Generic Database Change table.

This object's value matches the value of umc1SystemGenericDbProvTableSeqNum at the time the row was created. A valid value of this object is in the range of 1 through umc1SystemGenericDbProvTableSeqNum.

This object records the list of modified Database record(s) managed by umc1SystemGenericDbProvTable, nature of the change (add/modify/delete) and, possibly, the database record associated with the change that has been made..The format of the object is as follows: octet [0] Version number of the octet representation. The version number for the initial implementation will be 0x01. octet [1] Action octet, stores the action (update/delete) performed on the umc1SystemGenericDbProvTable. See DbActionType for valid values of this octet. octet [2] - [?] The DB record data as it appears in the UMC system database. For a DELETE entry these octets will only include the returned key to identify the DB record.

This object gives Version of MIB supported by this load of IPMI software. Octet[0] represents the version of the packed format of MIB Version described below. For this release the Version number will be 0x01. For version equal 0x01 the format of the following octets will be : Octet[1] MIB Version Octet[2] MIB Revision Octet[3] MIB Point Default Value of this MIB object needs to be modified, in order to reflect the new version of MIB.

This object describes how Db Record Change Trap for a given Db Record Type is being handle by IPMI. For the Db Record Type listed below, IPMI can send db Record change Trap to EMS via two different mechanism: (i) Generic Db Interface (ii) Respective Table Interface Octet[0] represents the version of the packed format of Db Record Change Trap Handling Mask described below. For this release the Version number will be 0x01. For version equal 0x01 the format of the following octets will be : Octet[1-2] Bit 15 to 0 of Db Record Change Trap Handling Mask Where.. Bit 0 corresponds to TR08 Db Record Bit 1 corresponds to GR303 Db Record Bit 2 corresponds to Cross-Connect(Ckt-to-Ckt and ATM Virtual Ckt.) Db Record Bit 3 corresponds to Protection Group Db Record Bit 4 corresponds to Port Profile Db Record Bit 5 corresponds to Channel Attribute Db Record Bit 6 corresponds to V5 (V5 Group and V5 Variant) Db Record Bit 7 corresponds to Facility Alarm String Db Record Bit 8 corresponds to TL1 Interface Provisioning Db Record Bit 9-15 Ignored For a give Db Record Type if corresponding bit is set to 1, The Db Record Change Trap for that Db Record Type shall be send through Generic Db Interface, Otherwise The Db Record Change Trap for that Db Record Type shall be send through it's own Trap handling mechanism.

A counter which gets incremented each time an Autonomous Event(Other than Alarm) occurs in the UMC System. Whenever the SNMP agent is restarted, this value will be reset to 0(zero). The value will be incremented by one whenever Autonomous Event occurs in the UMC System. This number will also be sent in the umc1TrapSystemAutonomousEvent trap and can be used to determine if any traps have been lost by the manager. This value will be incremented before the trap is sent. The maximum value it can assume is 2,147,483,647. An increment, every time it has reached its maximum value, shall cause it to be reset to 1.

The EMS uses this table to synchronize its internal representation of the Autonomous Event data with that managed by the UMC Agent. A trap is issued to the EMS whenever Event occurs in the UMC System and entered as a row in this table. The EMS queries this table, using the sequence number received in the umc1TrapSystemAutonomousEvent trap to synchronize. When the value of umc1SystemAutonomousEventSeqNum is zero this table is empty.

An entry in the Autonomous Event Table.

This object's value matches the value of umc1SystemAutonomousEventSeqNum at the time the row was created. A valid value of this object is in the range of 1 through umc1SystemAutonomousEventSeqNum.

This object represents detailed Autonomous Event Information. The format of the object is as follows: octet [0] Version number of the octet representation. The version number for the initial implementation will be 0x01. octet [1] Event Message Type, i.e 0xbb for _LcMtEvent_ message. octet [2] Length of following octet string. octet [3-255] octet string returned by the CPU.

A sequence number used to indicate that inventory shelf table has been modified and it needs to be re- read. Whenever the SNMP agent restarted, this value will be reset to 0(zero). The value will be incremented by one whenever a change to the inventory shelf table information had been made4. This number will also be sent in the umc1TrapInventoryShelfTableChange trap and can be used to determine if any traps have been lost. This value will be incremented before the trap is sent. The maximum value it can assume is 2,147,483,647. An increment, every time it has reached its maximum value, shall cause it to be reset to 1.

This table contains information about all shelves in a UMC system. There will be an entry in this table for every reachable shelf in the system.

An entry in the shelf table.

Identifier of a terminal.

Identifier of a shelf.

This object describes the type of the shelf. The following table lists the valid values and the corresponding shelf type they denote. Value Shelf Type 0 Old shelf or Unrecognized Shelf type 1 Euro-CBA 120 2 Euro-BBA 120 3 CBA-120 4 CBA-48 5 BBA-120 6 BBA-48 7 CAB-90 8 CAB-30 9 BBA-24 10 DP-BBA-120 11 DP-Euro-BBA-120 12 DP-BBA-48

This table records the location and type of the shelves whose addition to the UMC system caused the agent to emit umc1TrapInventoryShelfTableChange trap. The contents of the table are indexed by the value of umc1InventoryShelfTableChangeSeqNum. When the value of umc1InventoryShelfTableChangeSeqNum is zero the history table is empty. A management station shall query this table, using the value of umc1InventoryShelfTableChangeSeqNum received in umc1TrapInventoryShelfTableChange trap to determine if it can detect the new cards that have been added to the system. If it does not find such a row in this table it must re-read the entire umc1InventoryShelfTable table.

An entry in the history table.

This objects value matches the value of umc1InventoryShelfTableChangeSeqNum at the time the row was created. A valid value of this object is in the range of 1 through umc1InventoryShelfTableChangeSeqNum.

This object stores information of all shelves that were added to the UMC system when umc1TrapInventoryShelfTableChange trap was emitted by the agent with umc1InventoryShelfTableChangeHistoryIndex sequence number. The byte-format structure of this object is as follows: octet[0] Version number of the octet representation. The version number for the initial implementation will be 0x01. For version number 0x01 the remaining octets will be defined as follows : octet[1] Total number of records in the varbind, where each record consists of a length octet(length of the record), a terminal identifier octet, a shelf identifier octet and a shelf-type octet. --- Record #1 octet[2] Length of the first record. octet[3] Terminal Identifier of the first record. octet[4] Shelf identifier of the first record. octet[5] Shelf-type of the first record. ........

This table contains extended information that can be read from a shelf about all shelves in a UMC system. There will be an entry in this table for every reachable shelf in the system.

An entry in the extended shelf table.

Identifier of a terminal.

Identifier of a shelf.

The first octet contains the hardware version of the BOOT PROM of the shelf. The second octet contains the hardware revision of the BOOT PROM of the shelf. For a shelf with an older version of the hardware the values of the octets are 0xFF

This is the assembly number of the shelf. The string is not terminated by a NULL character. For a shelf with an older version of the hardware the values of the octets are 0xFF.

This is the serial number of the shelf. The string is not terminated by a NULL character. For a shelf with an older version of the hardware the values of the octets are 0xFF

This is the CLEI code assigned to the shelf. The string is not terminated by a NULL character.

A sequence number used to indicate that inventory plug-in table has been modified and it needs to be re-read. Whenever the SNMP agent restarted, this value will be reset to 0(zero). The value will be incremented by one whenever a change to the inventory plug-in table information had been made. This number will also be sent in the umc1TrapInventoryPluginTableChange trap and can be used to determine if any traps have been lost. This value will be incremented before the trap is sent. The maximum value it can assume is 2,147,483,647. An increment, very time it has reached its maximum value, shall cause it to be reset to 1.

This table contains information about all plug-in cards in a UMC system.

An entry in the plug-in table.

Identifier of a terminal.

Identifier of a shelf.

Identifier of a slot.

This object identifies the plug-in type (PIT) of a card in the UMC system.

This table records the location and type of the plug- in cards whose addition to the UMC system caused the agent to emit umc1TrapInventoryPluginTableChange trap. The contents of the table are indexed by the value of umc1InventoryPluginTableChangeSeqNum. When the value of umc1InventoryPluginTableChangeSeqNum is zero the history table is empty. A management station shall query this table, using the value of umc1InventoryPluginTableChangeSeqNum received in umc1TrapInventoryPluginTableChange trap to determine if it can detect the new cards that have been added to the system. If it does not find such a row in this table it must re-read the entire umc1InventoryPluginTable table.

An entry in the history table.

This objects value matches the value of umc1InventoryPluginTableChangeSeqNum at the time the row was created. A valid value of this object is in the range of 1 through umc1InventoryPluginTableChangeSeqNum.

This object stores the location and plug-in type of all cards that were added to the UMC system when umc1TrapInventoryPluginTableChange trap was emitted by the agent with umc1InventoryPluginTableChangeHistoryIndex sequence number. The byte-format structure of this object is as follows: octet[0] Version number of the octet representation. The version number for the initial implementation will be 0x01. For version number 0x01 the remaining octets will be defined as follows : octet[1] Total number of records in the varbind, where each record consists of a length octet(length of the record), a terminal identifier octet, a shelf identifier octet, a slot identifier octet and two octets for saving plug-in type. ---Record #1 octet[2] Length of the first record. octet[3] Terminal Identifier of the first record. octet[4] Shelf identifier of the first record. octet[5] Slot identifier of the first record. octet[6] Low-order byte of plug-in type of the first record. octet[7] High-order byte of plug-in type of the first record. ........

This table contains information about all plug-in cards in a UMC system.

An entry in the plug-in table.

Identifier of a terminal.

Identifier of a shelf.

Identifier of a slot.

This object identifies the current state of a plug-in card. The following table lists the valid values and the corresponding plug-in status. Value Plug-in Status 1 failed 2 in-service 3 missing-card 4 disabled 5 unequipped 6 wrong-type 7 old-software 8 active 9 standby 10 upgrade 11 old-boot-prom 12 loopback 13 out-of-service 14 calibration

This object contains the information regarding hardware and software versions of a plug-in card. If the value of octet[0] is not 0 then data in octet[9] through octet[11] contains valid information about standby main code version, revision and point. Otherwise, the data in octet[9] through octet[11] should be ignored. The data in each octet is: Octet[0] If non-zero then Standby main code information is valid. Octet[1] contains hardware version information, e.g., 5. Octet[2] contains hardware revision information, e.g., D. Octet[3] contains boot code version information, e.g., 0x2. Octet[4] contains boot code revision information, e.g., 0x4. Octet[5] contains boot code point information, e.g., 0x0. Octet[6] contains active main code version information, e.g., 0x2. Octet[7] contains active main code revision information, e.g., 0x4. Octet[8] contains active main code point information, e.g., 0x2. Octet[9] contains standby main code version information, e.g., 0x2. Octet[10] contains standby main code revision information, e.g., 0x4. Octet[11] contains standby main code point information, e.g., 0x3.

This is the assembly number of the plug-in card. This string is not terminated by a null character.

This is the serial number of the plug-in card. This string is not terminated by a null character.

This is the CLEI code assigned to the plug-in card. This string is not terminated by a null character.

A sequence number used to indicate that the terminal status table needs to be read again. Whenever the SNMP agent is restarted, this value will be reset to 0 (zero). The value will be incremented by one whenever a change to the table information has been made. This number will also be sent in the umc1TrapTerminalStatusChange trap and can be used to determine if any traps have been lost. The value will be incremented before the trap is sent. The maximum value it can assume is 2,147,483,647. An increment, every time it has reached its maximum value, shall cause it to be reset to 1.

This table contains the status that is associated with each terminal. There will be an entry in this table for every terminal known to the UMC, regardless of whether or not the terminal is actually reachable at this moment. There will not be entries in this table for terminals that have never been known to exist.

An entry in the terminal table. The data is indexed by the terminal whose data is represented.

The ID number of the terminal that this row references. The LET is 1, RST1 is 2, RST2 is 3, etc.

The status of this terminal, based on the status of the most severe current alarm. The status of normal means that there are no current alarms present for this terminal. The status of minor means that only minor alarms are currently active. The status of major means that the worst alarm currently active is of a major status. Likewise for critical, with the exception that link alarms are not taken into account, as they are associated with the link status (as found in the topology link table). If the terminal cannot be reached due to link outages, then the status is unreachable. Enumeration: 'unreachable': 255, 'major': 3, 'critical': 4, 'minor': 2, 'normal': 1.

A sequence number used to indicate that the terminal information table needs to be read again. Whenever the SNMP agent is restarted, this value will be reset to 0 (zero). The value will be incremented by one whenever a change to the table information has been made. This number will also be sent in the umc1TrapTerminalInfoChange trap and can be used to determine if any traps have been lost. The value will be incremented before the trap is sent.

This table contains the provisioning data that is associated with each terminal. This table has an row for every terminal database entry, regardless of whether or not the terminal is actively known to the UMC. (In other words, it is possible to view and/or change the data for a terminal that does not exist.)

An entry in the terminal provisioning table. The data is indexed by the terminal whose data is represented.

The ID number of the terminal that this row references.

The name of the terminal. If this is the LET, then it also ends up being the initial name of the UMC as a whole. This is not a null-terminated string.

Specifies the type of device that is connected to the serial port of the terminal. Enumeration: 'modem': 1, 'other': 255.

Specifies the current baud rate of the serial port of the terminal. Enumeration: 'autobaud': 1, 'other': 255, 'baud1200': 2, 'baud2400': 3, 'baud9600': 4.

The new identifier of the terminal referenced by this row. The terminal shall be rebooted after a successful write. The response to a SET request will refer to the old terminal identifier. Care must be taken to ensure that all cross connects associated with the old terminal identifier value are changed to reflect the new terminal identifier value. When read, it contains the current terminal identifier of the terminal referenced by this row.

The value of umc1TopologyChangeSeqNum at the time that the snapshot was taken. This allows the management station to know if the links specified in the umc1TopologyLinkTable still matches the snapshot. If the value stored here matches that in the umc1TopologyChangeSeqNu , then the data in the tables match. If the tables match, then there is no reason to read the umc1TopologyLinkTable to reconcile any changes that have been made since the ACO operation was performed. If the tables do not match, then the links listed in the two tables will have to be reconciled by the management station. The maximum value it can assume is 2,147,483,647. An increment, very time it has reached its maximum value, shall cause it to be reset to 1.

The link table. This table will be empty if only one terminal makes up this UMC. Only active links will be in this table. If a link is lost, then the corresponding row in this table will be removed.

An entry in the link table.

The Terminal ID of the terminal at one end of the link. This ID will always be lower in value than that specified for Terminal B. The order of the terminal IDs does not in any way indicate which terminal is closer to the lowest numbered terminal. The terminal IDs start with 1. (E.g. the LET is 1, RST1 is 2, RST2 is 3, etc.)

The Terminal ID of the terminal that connects to Terminal A.

A Management application may use the umc1CommandTable to execute a command in an agent. In order to execute a command with an argument, possibly null, the management application shall get a transaction number from the agent (see the definition of umc1CommandTransNbr for a description of how to obtain a transaction number). Once a transaction number has been received the manager shall gather the response from the response table (see the definition of umc1ResponseTable).

An entry in the command table.

This object identifies a command that a manager may execute in an agent. The following table describes the supported commands and their corresponding values. Value Command Type Description 1 _ReadTable_ Read the Table Type specified by the umc1CommandArg 2 _GetAllSeqNbr_ Read All Sequence Numbers 3 _GetActiveTermName_ Read the terminal name of all active terminals 4 _GetCpuDbDumpPort_ Read the port for Cpu Db Dump 5 _SetOrDelete_ Set or Delete the MIB Object specified by umc1CommandArg 6 _ClearCache_ Clear IPMI Agent Cache 7 _RebootIpmi_ Reboot IPMI Card 8 _ActivateAco_ Activate ACO 9 _AotRollover_ AoT to End-To-End Rollover 10 _CurTrafficStats_ Get the Current Traffic Status 11 _GetVcStatusInfo_ Get Virtual Circuit Status Information 12 _GetLineCardStatus_ Get Status Information for Digital Line Card(ADSL's) 13 _GetBlockedVccInfo_ Get Information on blocked VCCs 14 _GetAtmBandwidth_ Get ATM Bandwidth for Uplink circuit 15 _GetAtmStatistics_ Get ATM Statistics 16 _GetAdslBitsPerTone_ Get Bits Per Tone Data for ADSL Line 17 _GetAdslPmAttribute_ Get / Clear ADSL Perfomance Measurement data by attribute 18 _GetPmDataBin_ Get / Clear ADSL or ATM Perfomance Measurement data by bin 19 _GetNBLinkStats_ Get Narrow Band Link Traffic Statistics 20 _DeleteEquipment_ Delete Provisioning and cross-connects for a slot 21 _SoftwareActivation_ Manual Software Activation 22 _ManualProtectionSwitch_ Manual Protection Switch 23 _GetAPSInfo_ Get APS Info 24 _GenericIB_ Generic Get / Set command utilizing IB message types 25 _GetAtmStatsPerVcc_ Get ATM statistic per Vcc 26 _GetDropTestResults_ Get MTU Drop Test results

This object specifies the argument to a command. The format of this object is: octet[0] contains command argument. octet[1] contains Time-out value for Command in seconds. When umc1CommandId is _ReadTable_ and value of octet[0] is 10,20 & 120 than Octet[2] contains Terminal Id. Following table describes valid values of 0ctet[2] with its meaning. Value Octet[2] Description ------------ ---------------------------------- 0 Read entire MIB Table 1-33 Read all entries of MIB Table specified by Octet Zero of Command Arg that corresponds to given Terminal Id For a _ReadTable_ command the first octet is an argument. It identifies the table that has to be read. Any command type that is not explicitly listed below will ignore any value found in octet[0]. Command Type Valid Command Arguments ------------ ----------------------- _ReadTable_ Value Description 0ctet[0] 10 Read umc1InventoryShelfTable 20 Read umc1InventoryPluginTable 30 Read umc1TerminalInfoTable 40 Read umc1TerminalSpanTable 50 Read umc1ACOSnapTopologyLinkTable 60 Read umc1TopologyLinkTable 70 Read umc1InventoryPluginTableChangeHistoryTable 80 Read umc1InventoryShelfTableChangeHistoryTable 90 Read umc1TerminalStatusTable 100 Read umc1CurAlmTable 110 Read umc1XCTable 120 Read umc1ShelfSpanTable 130 Read umc1GR303Table 140 Read umc1TR8Table 150 Read umc1AtmProtGrpTable 160 Read umc1PortProfTable _SetOrDelete_ 10 Set/Delete umc1SystemSysProvCATable _ActivateAco_ 1 or 2 ACO Type _CurTrafficStats_ 0-33 Terminal Id The following table describes valid timeout values: Timeout Value Description octet[1] The Timeout Value used by Agent -------------- ------------------------------------- 0 Use default timeout value 10 seconds. 1-60 Use corresponding timeout value. 61-255 Use maximum timeout value 60 seconds. For _SetOrDelete_ Command for umc1SystemSysProvCATable, the format of Command Argument is: octet[2] Number of records to Set or Delete octet[3] Length of Record (For Delete value of this octet is Zero.) octet[4] Db Specifier octet[5] Plug-in Type octet[6] Terminal Id. octet[7] Icard Id. octet[8] Channel Id ( Always 0) octet[9] Mux Code octet[10] TxSgTCond octet[11] Chan Bits octet[12] Chan Bits 2 For _ActivateAco_ Command, Following table describes Command Argument ACO Type. Value Octet[0] Description -------- ---------------------- 1 CUI Standard ACO Operation 2 CUI Extended ACO Operation For _AotRollover_, _GetVcStatusInfo_, and _GetBlockedVccInfo_ Command, the format of Command Argument is: Octet[2-11] represents Upstream end of the Bb cross-connect Octet[12-21] represents Downstream end of the Bb cross-connect Octet[2] Terminal Id Octet[3] Shelf Id Octet[4] Slot Id Octet[5] Channel Id Octet[6] Group Id Octet[7] CRN Type Octet[8] Bits 15..8 of VCI Octet[9] Bits 7...0 of VCI Octet[10] Bits 15..8 of VPI Octet[11] Bits 7...0 of VPI Octet[12] Terminal Id Octet[13] Shelf Id Octet[14] Slot Id Octet[15] Channel Id Octet[16] Group Id Octet[17] CRN Type Octet[18] Bits 15..8 of VCI Octet[19] Bits 7...0 of VCI Octet[20] Bits 15..8 of VPI Octet[21] Bits 7...0 of VPI Octet[22] Data Operation: Exact Get or Progressive Get (See DataOperation) Octet[23] Crn64reqType: 0 for Plugin to Plugin request, 1 for group to group request 2 both the above (retrieve any type) For _CurTrafficStats_ Command, the following table describes valid values of 0ctet[0] with its meaning. Value Octet[0] Description ------------ -------------------------------------------- 0 Get Current Traffic Status for all Terminals 1-33 Get Current Traffic Status for specified Terminal Id -------------------------------------------------- For _GetLineCardStatus_ Command, the format of Command Argument is: octet[2] Terminal Id octet[3] Shelf Id octet[4] Slot Id octet[5] Bits 15..8 of Plugin Type octet[6] Bits 7...0 of Plugin Type octet[7] Data Operation: Exact Get only (See DataOperation) octet[8] Version (Argument List) Note: octet[8] definition. The UMC1000 supports two unique response data formats for this command. When the version octet is not present, the SNMP host only support the original response data format. A version octet equal to 1 indicates the SNMP host supports both response data formats. ------------------------------------------------------------------------- For the _GetAtmBandwidth_ command, the format of the command argument is: octet[2] Version octet[3] Cac Data Type octet[4] Terminal Id octet[5] Location index 1 octet[6] Location index 2 -------------------------------------------------------------------------- For the _GetAtmStatistics_ command, the format of the command argument is: octet[2] Version octet[3] Terminal Id octet[4] Shelf Id octet[5] Slot Id octet[6] Port: overloaded with Group Number for IMA octet[7] Data Operation: Exact Get or Write Data (Clear Statistics) (See DataOperation) ---------------------------------------------------------------------------- For the _GetAdslBitsPerTone_ command, the format of the command argument is: octet[2] Version octet[3] Terminal Id octet[4] Shelf Id octet[5] Slot Id octet[6] Circuit Id (Port Id) octet[7] Bits 15..8 of Plugin Type octet[8] Bits 7...0 of Plugin Type ---------------------------------------------------------------------------- For the _GetAdslPmAttribute_ command, the format of the command argument is: octet[2] Version octet[3] Terminal Id octet[4] Shelf Id octet[5] Slot Id octet[6] Circuit Id (Port ID) (0-6) octet[7] ADSL PM Attribute ID / clear (reset type ) octet[8] Response format octet[9] Data Operation: Exact Get, or Write Data (Clear PM) (See DataOperation) octet[10] Bits 15..8 of Plugin Type octet[11] Bits 7...0 of Plugin Type Note: octet[7] definition. (ADSL PM Attribute ID) When octet[9] is equal 'GET EXACT'. Attribute enumerations as defined by UMC1000 When octet[9] is equal 'WRITE'(clear). Type of clear, as defined by UMC1000 Note: octet[8] definition. Response format: 0 = Uncompressed, 1 = Compressed. Note: octet[9] (Data Operation) definition. Data Operation = 'GET EXACT' The response data will contain a single record. Valid range for octet[6] is 1-6. Valid range for octet[7] is 1-10. Data Operation = 'WRITE DATA' PM data is cleared for the specified port (octet[6] = 1-6) or all ports (octet[6] = 0). The valid range for octet[7] (0-2). ------------------------------------------------------------------------- For the _GetPmDataBin_ command, the format of the command argument is: octet[2] Version octet[3] Terminal Id octet[4] Shelf Id octet[5] Slot Id octet[6] Port ID (0 = all ports,1-6) for ADSL/OC3c/OC12c cards Group ID (0-3) for IMA card octet[7] Number of ports supported at specified slot (1-6) octet[8] Bin Type / Reset Type (0-2) octet[9] Bits 31..24 of time (seconds since 1992) octet[10] Bits 23..16 of time octet[11] Bits 15..8 of time octet[12] Bits 7..0 of time octet[13] Bits 15..8 of Plugin Type (supports ADSL family, OC3c/OC12c, IMA cards) octet[14] Bits 7...0 of Plugin Type octet[15] Data Operation: Get Exact, or Write Data (Clear PM) (See DataOperation) octet[16] ADSL (0), OC3c/Oc12c (1), or IMA (2) Card Note: octet[6] definition. Port Id is set to 1 for a OC3c/OC12c/IMA PIT type and 0 - 6 (0 - all ports) for an ADSL family PIT types. octet[8] definition. For Data Operation equal Get Exact and Get Progressive, Bin Type is set to 0 = 15 minute near-end(NE) section, 2 = daily NE section, 6 = 15 minute NE line, 7 = all 15 minute bins (pre system 9.0 release), 8 = daily NE line, 18 = 15-minute NE path, 20 = daily NE path, 44 = 15-minute ATM, and 45 = daily ATM. For Data Operation equal Write Data (Clear PM), Reset Type set to 0 = current data, 1 = current day data, 2 = all. octet[15] definition. When Data Operation is 'GET EXACT', the response data will contain a single record if the request is for a single port and a single bin, the response data will contain multiple records if the request is for all ports and/or all bins (GET PROGRESIVE). When Data Operation is 'WRITE DATA', the command arguments specify a card. PM data is cleared for all ports and all bins on the card. ------------------------------------------------------------------------- For the _GetNBLinkStats_ command, the command argument list format is: octet[2] Version octet[3] Bits 31..24 of time (seconds since 1992) octet[4] Bits 23..16 of time octet[5] Bits 15..8 of time octet[6] Bits 7..0 of time octet[7] Terminal End Point 1 octet[8] Terminal End Point 2 octet[9] Data Operation (Exact Get, or Progressive Get) octet[10] GR303 group ID (1-3), Version 3 field only Note: octet[2] represents the version of the request and expected response. This field set to (1) represents the original implementation. This field set to (2) will lead to responses with additional fields for nailed-up DS0s. And, this field set to (3) requires octet[10], and retreives GR303 interface data on a per interface basis. octet[7], octet[8] and octet[10] definitions. Terminal Endpoint 1 and 2 identify the endpoints of the link. For a Get Exact Operation, data on a single link will be retrieved, identified by the two terminal endpoints. For a Get Progressive Data Operation, terminal endpoints will represent the starting point to retrieve data. Both Terminal endpoints set to 1 will indicate GR303 group data will be retrieved from the LET as specified by the GR303 group ID, followed by narrowband CCS Data for each link in the system. octet[9] definition. Data Operation will be set to Get Exact for retrieval of a single link's data or Get Progressive for retrieval of all narrowband CCS data. ------------------------------------------------------------------------- For the _DeleteEquipment_ command, the command argument list format is: octet[2] Version octet[3] Terminal Id octet[4] Shelf Id octet[5] Slot Id octet[6] Bits 15..8 of Plugin Type octet[7] Bits 7...0 of Plugin Type octet[8] Control (0=query,1=delete) ------------------------------------------------------------------------- For the _SoftwareActivation_ command, the cmd argument list format is: octet[2] Version octet[3] Terminal Id octet[4] Shelf Id octet[5] Slot Id octet[6] Action (0=Activate standby bank,1=reset card) ------------------------------------------------------------------------- For the _ManualProtectionSwitch_ command, the cmd argument list format is: octet[2] Version octet[3] Data Operation: Exact Get, or Write Data (Switch) octet[4] Terminal Id octet[5] Active Shelf Id octet[6] Active Slot Id octet[7] Standby Shelf Id (not used with Exact Get) octet[8] Standby Slot Id (not used with Exact Get) octet[9] Bits 15..8 of Plugin Type octet[10] Bits 7...0 of Plugin Type ------------------------------------------------------------------------- For the _GetAPSInfo_ command, the cmd argument list format is: octet[2] Version octet[3] Terminal Id octet[4] Protection Group Id -------------------------------------------------------------------------- For the _GenericIB_ command, the format of the command argument is: octet[2] Version octet[3] Terminal Id octet[4] IB Data Type (IxType) octet[5] Operation (SNMP Get Exact, Get Progressive, or Put) octet[6] IB Payload Length (maximun of 55 bytes) octet[7] First byte of IB Payload octet[x] Last byte of the IB Payload ------------------------------------------------------------------------- For the _GetAtmStatsPerVcc_ command, the cmd argument list format is as follows. This command is used to retrieve ATM statistics for a given channel from upto four circuit cards used to transport the channel. The ATM channel is specified by the Uplink Channel Routing Number (CRN). The CRN is uniquely identified using octets 3 through 12. Four card location identifier follow the CRN. octet[2] Version octet[3] Terminal Id octet[4] Shelf Id octet[5] Slot Id octet[6] Channel Id octet[7] Group Id octet[8] CRN Type octet[9] Bits 15..8 of VCI octet[10] Bits 7...0 of VCI octet[11] Bits 15..8 of VPI octet[12] Bits 7...0 of VPI Location of Primary Uplink circuit When uplink is T1 or T1x, provide location of uplink concentrator. octet[13] Uplink Terminal Id octet[14] Uplink Shelf Id octet[15] Uplink Slot Id Location of Secondary Uplink circuit (if APS Group, set to 0xFF if not provided) octet[16] Uplink Terminal Id octet[17] Uplink Shelf Id octet[18] Uplink Slot Id Location of DSL circuit (or Downlink Group Primary) octet[19] Downlink Terminal Id octet[20] Downlink Shelf Id octet[21] Downlink Slot Id Location of DSL concentration (or Downlink Group Secondary, optional, set to 0xFF if not provided) octet[22] Downlink Terminal Id octet[23] Downlink Shelf Id octet[24] Downlink Slot Id ------------------------------------------------------------------------- For the _GetDropTestResults_ command, the cmd argument list format is: octet[2] Version octet[3] Terminal Id octet[4] Shelf Id octet[5] Slot Id octet[6] Circuit Id (Port Id) -------------------------------------------------------------------------

In order to execute a command, a Management Application must first initiate a Get request to read the transaction number for a given command and a given argument. The agent will assign a unique transaction number that can then be used for all subsequent requests to execute the command the transaction number was requested for. Thus, several managers executing the same command with the same argument will be assigned different transaction numbers. The manager shall use the value of transaction number to gather the response(s) from the response table (see the definition of umc1ResponseTable).

A Management Application may use the umc1ResponseTable to read response that was generated as a result of a command execution in an agent. The response data (see the definition of umc1ResponseData) shall be read by issuing successive Get-Next requests for the object umc1ResponseData. It shall start reading the response data by providing the value of transaction number it read earlier from umc1CommandTransNbr and a sequence number 0 (zero). The response data corresponding to a transaction number and sequence number smaller than the sequence number returned in the response to a Get-Next request shall not be accessible to subsequent Get or Get-Next Requests.

An entry in the Response table.

This object shall be used by the manager to retrieve the response of a command executed by the Agent.

This object uniquely identifies the rows of umc1ResponseTable along with umc1ResponseTransNbr. It keeps track of the last fragment of the response data read by the manager. The manager shall continue to perform Get-Next operations until the end of data is reached. At that stage the manager shall receive the OID of an object that is not in the umc1ResponseTable.

This object encapsulates the data corresponding to the umc1ResponseTransNbr and umc1ResponseSeqNbr. The first byte of this umc1ResponseData is a version byte. The second byte is a number of records encapsulated in the umc1ResponseData. A length field precedes all records (Variable as well as fixed length records). The length field specifies the length of record in Octets. General Response Data Format is shown below: ------------------------------------------- Version Number Of Length of Record 1 Length of Record 2 ... (Byte) Records Record 1 Record 2 (Byte) (Byte) (Byte) The record format depends on the type of data that is being dumped. Record Data Format. ------------------ For the _ReadTable_ command. --------------------------- 1. Record format for Terminal Info Table (umc1TerminalInfoTable) Fields Terminal Terminal Serial Baud New Id Name Device Rate Terminal Type Id Num Bytes 1 1-21 1 1 1 2. Record Format for Terminal Status Table (umcTerminalStatusTable) Fields Terminal Terminal Id Status Num Bytes 1 1 3. Record Format for Inventory Shelf Table (umcInventoryShelfTable) Fields Terminal Shelf Shelf Id Id Type Num Bytes 1 1 2 4. Record Format for Inventory Plug-in Table (umcInventoryPluginTable) Fields Terminal Shelf Slot Plugin Id Id Id Type Num Bytes 1 1 1 2 5. Record Format for Topology Link Table and ACO Snap Topology Link Table (umc1TopologyLinkTable and umc1AcoSnapTopologyLinkTable) Fields TerminalA TerminaB Id Id Num Bytes 1 1 6. Record Format for cross connect Table( umc1XCTable) Fields XC Index XC Data Num Bytes 1-255 0-255 7. Record Format for GR-303 Group Provisioning Table (umc1GR303Table) Fields GR-303 GR-303 Index Data Num Bytes 1-255 0-255 8. Record Format for TR-08 Group Provisioning Table (umc1TR8Table) Fields TR-08 TR-08 Index Data Num Bytes 1-255 0-255 9. Record Format for ATM Protection Group Provisioning Table (umc1AtmProtGrpTable) Fields ATM ATM Protection Protection Index Data Num Bytes 1-255 0-255 10. Record Format for Port Profile Provisioning Table (umc1PortProfTable) Fields Port Port Profile Profile Index Data Num Bytes 1-255 0-255 11. Record Format for Terminal Span Table (umc1TerminalSpanTable) Fields Near Near Near Near Far Far Far End End End End End End End Term Shelf Slot Plugin Term Shelf Slot Id Id Id type Id Id Id Num Bytes 1 1 1 2 1 1 1 12. Record Format for Shelf Span Table (umc1ShelfSpanTable) Fields Near Near Near Near Far Far Far End End End End End End End Term Shelf Slot Plugin Shelf Slot Plugin Id Id Id type Id Id type Num Bytes 1 1 1 2 1 1 2 For the _GetAllSeqNum_ command. ------------------------------ When the umc1CommandId is _GetAllSeqNum_, refer to the object description of umc1SystemAllSeqNbr for the record format. For the _GetActiveTermName_ command. ----------------------------------- When the umc1CommandId is _GetActiveTermName_, the record format is: Fields Terminal Terminal Terminal Baud New Serial Id Status Name Rate Terminal Device Id Type Num Bytes 1 1 1-21 1 1 1 For the _GetCpuDbDumpPort_ command. ---------------------------------- When the umc1CommandId is _GetCpuDbDumpPort_, the record format is: Fields Port Number Num Bytes 4 For the _SetOrDelete_ command. ----------------------------- When the umc1CommandId is _SetOrDelete_, the record format is: Fields No. of Record Created/Deleted Num Bytes 1 For the _ClearCache_ command. ---------------------------- When the umc1CommandId is _ClearCache_, the record format is: Fields Is Cache Cleared Num Bytes 1 Is Cache Cleared value Meaning 1 Cache Successfully cleared If error occured while clearing cache, Agent shall issue _gerErr_ to Management Station. For the _ActivateAco_ command. ----------------------------- When the umc1CommandId is _ActivateAco_, the record format is: Fields Result Byte Num Bytes 1 Result Byte value Meaning 1 ACO Activated Successfully If error occured while activating ACO, Agent shall issue _gerErr_ to Management Station. For the _AotRollover_ command. ----------------------------- When the umc1CommandId is _AotRollover_, the record format is: Fields Result Byte Num Bytes 1 Result Byte value Meaning 1 AoT to End-To-End ATM Rollover was Successful If error occured while rolling over Aot, Agent shall issue _gerErr_ to Management Station. For the _CurTrafficStats_ command. --------------------------------- When the umc1CommandId is _CurTrafficStats_, the record format is: Fields Terminal Total Blocked Used Available Non-Available Current Id Calls Calls Channels Channels Channels Hour Load Num Bytes 1 2 2 2 2 2 2 --------------------------------------------------------------------------- For the command ID equal to _GetLineCardStatus_, the response data will follow the 'General Response Data Format' as defined above. The definition of the response record will vary depending upon the version of the UMC system. In all cases, the response data will contain a single record. Original Response data format for command ID _GetLineCardStatus_. The version octet = 1. The number of records octet = 1. The length of record #1 and the record format are determined by the octet string returned by the UMC system CPU card. In general, the record represents an array of six elements where each element contains the following attributes for a single circuit/port: port status, downstream rate, downstream SNR margin, upstream rate, and upstream SNR margin. Enhanced Response data format for command ID _GetLineCardStatus_. The version octet = 1. The number of records octet = 1. The record will contain an array of equivalent data elements. The size of the array will depend on the number of circuits/ports supported by the card. The length of each element and the element format are determined by the octet string returned by the UMC system CPU card. In general, each record contains the following attributes for a single circuit/port: port status, downstream rate, downstream SNR margin, upstream rate, and upstream SNR margin, downstream signal attenuation, downstream current channel bit rate, downstream transmitted signal power, downstream relative capacity operation, upstream signal attenuation, upstream current channel bit rate, upstream transmitted signal power, and upstream relative capacity operation. --------------------------------------------------------------------------- For the command ID equal to _GetAtmStatistics_, the response data will follow the 'General Response Data Format' as defined above. The version octet = 1. The number of records octet = 2. The response data will contain a two records. The first record represents the 'receive' ATM statistics and the second record represents the 'transmit' ATM statistics. The length of each record and the record format are determined by the octet string returned by the UMC system CPU card. --------------------------------------------------------------------------- For the command ID equal to _GetAdslPmAttribute_, the response data will follow the 'General Response Data Format' as defined above. The response data will contain a single record or multiple equivalent records depending on the 'Data Operation' octet specified in the corresponding command table record. The length of each record and the record format are determined by the octet string returned by the UMC system CPU card. --------------------------------------------------------------------------- For the command ID equal to _GetPmDataBin_, the response data will follow the 'General Response Data Format' as defined above. The version octet = 1. The number of records octet depends on the 'Data Operation' specified in the request. For a 'GET EXACT' request, the response data will contain - a single record for a single port and bin request. - multiple records for an all port and/or all bin request For a Write request, the response data will contain a single record. The format and length of each record is determined by the octet string returned by the UMC system CPU card. --------------------------------------------------------------------------- For the command ID equal to _GetNBLinkStats_, the response data will follow the 'General Response Data Format' as defined above. The version octet = 1. The number of records octet = 1 for a Get Exact operation and 1 - 8 (maximum number of GR303/transport link CCS data before overflowing the 255 byte limit) for a Get Progressive operation. The response data can be one of two record types (transport link record or GR303 Group record). The length of each record and the record format are determined by the octet string returned by the UMC system CPU card (IB response payload). --------------------------------------------------------------------------- For the command ID equal to _ManualProtectionSwitch_, the response data will always contain two records. The first record has a length of one octet and represents the response field from the internal system interface. The possible values are: _RvOk_, _RvInvalidData_, & _RvFailure_. The length and format of the second record are determined by the octet string returned by the internal system interface --------------------------------------------------------------------------- For each of the following commands ID, the response data will follow the 'General Response Data Format' as defined above. The record format will consist of an octet string as returned by the CPU: _GetVcStatusInfo_ _GetBlockedVccInfo_ _GetAtmBandwidth_ _GetAdslBitsPerTone_ _GetDropTestResults_ --------------------------------------------------------------------------- For the command ID equal to _GenericIB_, the response data will be formatted as follows: - First octet = version number = 1. - Second octet = number of records octet = 1. - Third octet = size of record in bytes. - Forth octet = first byte of record will contain the CPU error code. - Fifth octet = second byte of record will contain the first byte of the IB payload. - Sixth octet = third byte of record will contain the second byte of the IB payload. - xth octet = last byte of the record will contain the last byte of the IB payload. Note: The third octet will be set to 1 if the CPU returns an error code (not equal to _RvOk_) back to the IPMI via the IB response message. The third octet will be set to a value of greater than 1 if the CPU returns valid data back to the IPMI via the IB response message. The forth octet will contain a value of 0 (RvOk) when valid data is returned in the IB payload. The forth octet will contain a value greater than 0 (error type) when the CPU identifies an error condition. --------------------------------------------------------------------------- For the command ID equal to _GetAtmStatsPerVcc_, the response data will follow the 'General Response Data Format' as defined above. The response can contain anywhere from zero (0) response records up to six (6) response records. The record format will consist of an octet string as returned by the CPU:

A sequence number used to indicate that the Terminal Span table, umc1TerminalSpanTable, has been modified and it needs to be re-read. Whenever the SNMP agent is restarted, this value will be reset to 0(zero). The value will be incremented by one whenever a change to the Terminal Span table has been made. This number will also be sent in the umc1TrapTerminalSpanTableChange trap and can be used to determine if any traps have been lost. This value will be incremented before the trap is sent. The maximum value it can assume is 2,147,483,647. An increment, every time it has reached its maximum value, shall cause it to be reset to 1.

This table contains current information about all Span Connecting two terminals in a UMC system.

An entry in the Terminal Span table.

The Terminal ID of a terminal at the near end of the span.

The Shelf ID of a shelf at the near end of span.

The Slot ID of a slot at the near end of span.

The plug-in type at at the near end of span.

The Terminal ID of a terminal at the far end of span.

The shelf ID of a shelf at the far end of span.

The Slot ID of a slot at the far end of span.

This table records the near end and far end location of the inter terminal span whose addition/deletion to the UMC system caused the agent to emit umc1TrapTerminalSpanTableChange trap. The contents of the table are indexed by the value of umc1TerminalSpanTableChangeSeqNum. When the value of umc1TerminalSpanTableChangeSeqNum is zero the history table is empty. A management station shall query this table, using the value of umc1TerminalSpanTableChangeSeqNum received in umc1TrapTerminalSpanTableChange trap to determine if it can detect the new terminal span that have been added to the system. If it does not find such a row in this table it must re-read the entire umc1TerminalSpanTable table.

An entry in the history table.

This objects value matches the value of umc1TerminalSpanTableChangeSeqNum at the time the row was created. A valid value of this object is in the range of 1 through umc1TerminalSpanTableChangeSeqNum.

This object stores the near end and far end location of all inter terminal spans that were added to/deleted from the UMC system when umc1TrapTerminalSpanTableChange trap was emitted by the agent with umc1TerminalSpanTableChangeHistoryIndex sequence number. The umc1TerminalSpanTableChangeHistoryData contains multiple terminal span entries corresponding to the all inter terminal spans that were added to/deleted from the UMC system. Each entry in the umc1TerminalSpanTableChangeHistoryData consisting of action byte followed by packed terminal span record. For initial implementation the OCTET representation will be as follows: Octet[0] Version number (currently 0x01) For version 0x01 octet[1] Holds the number of spans in this history record. octets[2] through [11] hold the packed record for the 1st Terminal Span being reported and are defined as follows. Octet[2] Length of record. Octet[3] Action octet which specifies that the record attached after the action object has been added to/deleted from the umc1TerminalSpanTable. See DbActionType for valid values and meaning of this octet. Octet[4] Near End Terminal Id Octet[5] Near End Shelf Id Octet[6] Near End Slot Id Octet[7-8] Near End plug-in type Octet[9] Far End Terminal Id Octet[10] Far End Shelf Id Octet[11] Far End Slot Id octets[12] through [20] hold the packed record for the next Terminal and so forth, until up to octet[1] number of spans have been defined.

A sequence number used to indicate that the Shelf Span table, umc1ShelfSpanTable, has been modified and it needs to be re-read. Whenever the SNMP agent is restarted, this value will be reset to 0(zero). The value will be incremented by one whenever a change to the Shelf Span table has been made. This number will also be sent in the umc1TrapShelfSpanTableChange trap and can be used to determine if any traps have been lost. This value will be incremented before the trap is sent. The maximum value it can assume is 2,147,483,647. An increment, every time it has reached its maximum value, shall cause it to be reset to 1.

This table contains current EBC/ELU links in a terminal in a UMC system. The near end of shelf span is always at EBC card and far end of shelf span at ELU card.

An entry in the Shelf Span table.

The Terminal ID of a terminal to which the requested shelf span belongs.

The Shelf ID of a shelf to which near end of requested shelf span belongs.

The slot ID of a slot to which near end of requested shelf span belongs.

The plug-in type at the near end of span.

The Shelf ID of a shelf to which far end of requested shelf span belongs.

The slot ID of a slot to which far end of requested shelf span belongs.

The plug-in type at the far end of span.

This table records the near end and far end location of the inter shelf span whose addition/deletion to the UMC system caused the agent to emit umc1TrapShelfSpanTableChange trap. The contents of the table are indexed by the value of umc1ShelfSpanTableChangeSeqNum. When the value of umc1ShelfSpanTableChangeSeqNum is zero the history table is empty. A management station shall query this table, using the value of umc1ShelfSpanTableChangeSeqNum received in umc1TrapShelfSpanTableChange trap to determine if it can detect the new shelf span that have been added to the system. If it does not find such a row in this table it must re-read the entire umc1ShelfSpanTable table.

An entry in the history table.

This objects value matches the value of umc1ShelfSpanTableChangeSeqNum at the time the row was created. A valid value of this object is in the range of 1 through umc1ShelfSpanTableChangeSeqNum.

This object stores the near end and far end location of all inter shelf spans that were added to/deleted from the UMC system when umc1TrapShelfSpanTableChange trap was emitted by the agent with umc1ShelfSpanTableChangeHistoryIndex sequence number. The umc1ShelfSpanTableChangeHistoryData contains multiple shelf span entries corresponding to the all inter shelf spans that were added to/deleted from the UMC system. Each entry in the umc1ShelfSpanTableChangeHistoryData consisting of action byte followed by packed shelf span record. For initial implementation the OCTET representation will be as follows: Octet[0] Version number (currently 0x01) The contents of the remaining octets are defined as follows for version 0x01. octet[1] Holds the number of spans in this history record. octets[2] through [12] hold the packed record for the 1st Shelf Span being reported. Octet[2] Length of Record Octet[3] Action object which specifies that the record attached after the action object has been added to/deleted from the umc1ShelfSpanTable. See DbActionType for valid values of this byte. Octet[4] Near End Terminal Id Octet[5] Near End Shelf Id Octet[6] Near End Slot Id Octet[7-8] Near End plug-in type Octet[9] Far End Shelf Id Octet[10] Far End Slot Id Octet[11-12] Far End plug-in type octets[13] through [22] hold the packed record for the next Shelf span and so forth, until up to octet[1] number of spans have been defined.

A sequence number used to indicate that the alarm sequence table has been modified and needs to be re-read. Whenever the SNMP agent restarted, this value will be reset to 0 (zero). The value will be incremented by one whenever a change to the Alarm Sequence table information has been made. This number will also be sent in the umc1AlarmTrap trap and can be used to determine if any traps have been lost. The value will be incremented before the trap is sent. The maximum value it can assume is 2,147,483,647. An increment, every time it has reached its maximum value, shall cause it to be reset to 1.

This table contains the sequence numbers for each terminal in a UMC system. The sequence numbers are used to indicate if the current alarm table for a given Terminal needs to be re-read due to missed TRAP updates. This table is Read Only

A single entry in the Alarm Sequence Table.

The Terminal that has generated the alarms we are tracking via this sequence number.

A counter which gets incremented each time an ALARM or Event for this terminal occurs. It is used to indicate wether the Current Alarm table for this terminal needs to be re-read.

This table contains the currently active alarms in a UMC system (the LET and all of its connected terminals). Only alarms for reachable terminals are available via this table.

A single entry in the Current Alarm Table.

The Terminal that has generated the alarm this record represents. The LET is 1, RST1 is 2, RST2 is 3, etc.

A representation of the relative occurrence of the ALARM/EVENT. The contents of the octets in this OBJECT are actually the ONEs COMPLEMENT of the values represented, a neccessity due to the fact that umc1CurAlmTable entries must be retrievable in reverse chronological order as the table is walked. This would result in decrementing column index values as the umc1CurAlmOccurrenceIndex column was traversed. The true occurrence values can be extracted from this octet string by taking the COMPLEMENT of each byte (with the exception of octets 0 and 1, which must first be combined into a 16 bit representation of the year before COMPLEMENTing and then broken apart into the High and Low bytes after the COMPLEMENT has been accomplished). The format of the umc1CurAlmOccurrenceIndex is as follows: octet[0] High 8bits of the YEAR octet[1] Low 8bits of the YEAR octet[2] Month (January is 1, February is 2, etc.) octet[3] Day (1 through 31) octet[4] Hour (0 through 23) octet[5] Minutes (0 through 59) octet[6] Seconds (0 through 59) octet[7] mSec (0 through 255). This is an index to differentiate this alarm from any others that may have occurred in the same second.

This is a TL1 formatted string representing the ALARM/EVENT

This is an encoded representation of the alarm to be reported. The format of the encoded data is as follows : octet[0] umc1CurAlmDetails IMPLEMENTATION VERSION. This will be used to identify the structure of the following data. For IMPLEMENTATION VERSION equal 1 the following data within umc1CurAlmDetails be of the form: octet[1] UMC eFacAlarm value for this alarm/event (High 8-bits). octet[2] UMC eFacAlarm value for this alarm/event (Low 8-bits). octet[3] category (SET=1, CLEAR=2, EVENT=3) octet[4] severity (CRITICAL=1, MAJOR=2, MINOR=3, EVENT=4, STATUS=5) octet[5] PLUG IN TYPE this alarm was generated for (High 8-bits). octet[6] PLUG IN TYPE this alarm was generated for (Low 8-bits). octet[7] alarm misc byte[0] octet[8] alarm misc byte[1] octet[9] alarm misc byte[2] octet[10] alarm misc byte[3] octet[11] LOCATION_TYPE - indicates the format of the following 4 octets of information. The valid values for this field are listed below: 0 = Invalid_data 1 = Term_valid 2 = Shelf_valid 3 = Slot_valid 4 = Circuit_valid 5 = Group_valid The contents of the following four octets for each of these types is detailed below. LOCATION_TYPE equals Invalid_data octet[12] unused - set to zero octet[13] unused - set to zero octet[14] unused - set to zero octet[15] unused - set to zero LOCATION_TYPE equals Term_valid octet[12] LOCATION - Terminal number (LET = 1, RST1 = 2, RST2 = 3, etc.) octet[13] unused - set to zero octet[14] unused - set to zero octet[15] unused - set to zero LOCATION_TYPE equals Shelf_valid octet[12] LOCATION - Terminal number (LET = 1, RST1 = 2, RST2 = 3, etc.) octet[13] LOCATION - Terminal shelf number octet[14] unused - set to zero octet[15] unused - set to zero LOCATION_TYPE equals Slot_valid octet[12] LOCATION - Terminal number (LET = 1, RST1 = 2, RST2 = 3, etc.) octet[13] LOCATION - Terminal shelf number octet[14] LOCATION - Shelf slot number octet[15] unused - set to zero LOCATION_TYPE equals Circuit_valid octet[12] LOCATION - Terminal number (LET = 1, RST1 = 2, RST2 = 3, etc.) octet[13] LOCATION - Terminal shelf number octet[14] LOCATION - Shelf slot number octet[15] LOCATION - Slot circuit number (0 = circuit 0 LOCATION_TYPE equals Group_valid octet[12] LOCATION - Terminal number (LET = 1, RST1 = 2, RST2 = 3, etc.) octet[13] TR08/TR303/etc. Group number (High 8-bits) octet[14] TR08/TR303/etc. Group number (Low 8-bits) octet[15] unused - set to zero octet[16] COORELATION TAG - High 8-bits of the YEAR octet[17] COORELATION TAG - Low 8-bits of the YEAR octet[18] COORELATION TAG - Month (January=1, February=2, etc.) octet[19] COORELATION TAG - Day (1 through 31) octet[20] COORELATION TAG - Hour (0 through 23) octet[21] COORELATION TAG - Minutes (0 through 59) octet[22] COORELATION TAG - Seconds (0 through 59) octet[23] COORELATION TAG - mSec (0 through 255). mSec is an index to differentiate this alarm from any others that may have occurred in the same second. octet[24] Term name length in octets, (eg, 10 if the terminal name is 130 W. Elm). octet[25] to Term name string. eTNL = (25+Term name length). octet[eTNL] octet[eTNL] RAI/Environmental alarm description string length in octets. This is an OPTIONAL string used to present additional information about RAI or External ALARMS. If the alarm is of one of the types that supports user defined descriptions in the UMC system, that description will be contained in the following string. If it isnt, or there was no user defined string, this byte will be set to zero. octet[eTNL + 1] to Environmental alarm description string. octet[eEADSTR] eEADSTR = ((eTNL + 1) + RAI/External Alarm description string length).

The Community Name that allows read and write access to the UMC1000 MIB variables. Changing this variable will take immediate effect and so must be done with caution. Note that this value must be initially provisioned via the Craft User Interface, as the current value must be known in order to change it to something else. Although its ACCESS field is specified as read-write (to get past a MIB compiler issue), it is really considered a write-only variable. The implementation is such that a read of the variable will always return an empty string.

This is a bit field that specifies which traps, if any, will be generated by the SNMP Agent. If the bit is set, then the traps of the indicated type will be generated. The bits are defined as follows: | BIT HexValue Description | ----------------------------------------------------- | 1 0x01 Send standard SNMP traps | 2 0x02 Send authentication traps | 3 0x04 Send UMC High-level traps | 4 0x08 Send detailed UMC alarm traps | 5 0x10 Reserved (set to zero) | 6 0x20 Reserved (set to zero) | 7 0x40 Reserved (set to zero) | 8 0x80 Send IPMI Software diagnostic traps

The IP Address of the EMS platform to which traps are to be sent.

The UDP Port to which the traps are sent. The default is port 162

The IP Address of the EMS platform on a Secondary Management Host to which traps are to be sent.

A boolean value indicating whether this Management Host receives traps or not.

The IP Address of the EMS platform on a Secondary Management Host to which traps are to be sent.

A boolean value indicating whether this Management Host receives traps or not.

A boolean value indicating whether Trusted Hosts are enabled or not.

The TCP Port on which the Telnet Server listens for connection requests. The default is port 23.

A sequence number used to indicate that the topology link table needs to be read again. Whenever the SNMP agent is restarted, this value will be reset to 0 (zero). The value will be incremented by one whenever a change to either table has been made. This number will also be sent in the umc1TrapTopologyChange trap and can be used to determine if any traps have been lost. The value will be incremented before the trap is sent. The maximum value it can assume is 2,147,483,647. An increment, every time it has reached its maximum value, shall cause it to be reset to 1.

The ID of the terminal that contains the SNMP agent. This may, or may not, identify the root of the topology tree. The root of the toplogy tree is really an abstraction, defined as the terminal having the lowest ID number in a UMC network. If the umc1TopologyTable has any rows in it, then the smallest terminal ID is considered the root of the topology tree. If the umc1TopologyTable empty, then (and only then) can the assumption be made that this variable holds the ID of the root of the topology tree, since it identifies the only known terminal. Unfortunately, all bets are off if the *real* root of the topology tree is unreachable at the time of autodiscovery. The LET is 1, RST1 is 2, RST2 is 3, etc.)

The link table. This table will be empty if only one terminal makes up this UMC. Only active links will be in this table. If a link is lost, then the corresponding row in this table will be removed.

An entry in the link table.

The Terminal ID of the terminal closest to the root of the network tree. The terminal IDs start with 1. (E.g. the LET is 1, RST1 is 2, RST2 is 3, etc.)

The Terminal ID of the terminal that connects to Terminal A.

The Plug-in name table. This table maps the Plug-in type with the appropriate textual Plug-in name. This table does *not* support the get-next operation.

An entry in the Plug-in name table.

The numeric value associated with a UMC Plug-in. This is the index into the table

The name of the UMC Plug-in that is associated with the Plug-in type.

The Alarm string table. This table maps the facility alarm number with the appropriate textual message string. This table does *not* support the get-next operation.

An entry in the Alarm string table.

The numeric value associated with a UMC alarm. This is the index into the table

The text string associated with the UMC alarm value.

This object provides a mechanism for triggering the 'umc1TrapAllSeqNbrDump' trap. A GET operation to read its value shall trigger a trap event and return the value 0 (Trap issued successfully) or 1 (trap failed).

A sequence number used to indicate that the Threshold Crossing Alert History (TCA) Table, umc1SystemTCAHistoryTable, has been modified and it needs to be re-read. Whenever the SNMP agent is restarted, this value will reset to 0(zero). The value will be incremented by one whenever a change to the Threshold Crossing Alert History Table has been made. This number will also be sent in the umc1TrapTCAHistoryTableChange TRAP and can be used to determine if any traps have been lost by the manager. This value will be incremented before the trap is sent. The maximum value it can assume is 2,147,483,647. An increment, every time it has reached its maximum value, shall cause it to be reset to 1.

The EMS uses this table to synchronize its internal representation of the Threshold Crossing Alert data with that managed by the UMC Agent. A trap is issued to the EMS indicating a change to Threshold Crossing Alert History Table data has been made and entered as a row in this table. The EMS queries this table, using the sequence number received in the umc1TrapTCAHistoryTableChange trap to determine whether it can re-learn the missed TCA information from this. When the value of umc1SystemTCAHistoryTableSeqNum is zero this table is empty.

An entry in the TCA History table.

This object's value matches the value of umc1SystemTCASeqNum at the time the row was created. A valid value of this object is in the range of 1 through umc1SystemTCASeqNum.

This object records the list of TCAs managed by the umc1SystemTCAHistoryTable. The format of the object is as follows: octet [0] Version number of the octet representation. The version number for the initial implementation will be 0x01. octet [1] - [?] The TCA data as it was received from the AccessMax system.

Contains the contents of an F5 loopback request

An entry in the terminal provisioning table. The data is indexed by the terminal whose data is represented.

A sequence number used to associate the request with the trap that contains the F5 loopback results

An IP address of the host that requested the loopback

Contents of the ib message that will be sent to the interface card, the tOAMLpbkRequest size + 1 byte for the destination icard

Contains the contents of an ADSL 2+ loop diagnostics request. The EMS shall issue this SET to start the LoopDiagnostics on the specified card. When the operation is complete the agent will send a TRAP that contains the LoopCharacteristics, and the EMS can GET any of the other parameters using the umc1LoopDiagnosticsResponseTable

Format for Umc1LoopDiagnosticsRequestTable.

A sequence number used to associate the request with the trap that contains the LoopCharacteristics results, and subsequent Get requests.

An IP address of the host that requested the diagnostics.

Loop diagnostics request in the following format: byte[0] - version number (1 for now) byte[1] - ADSL PIT byte[2] - ADSL Port number (0-based) byte[3] - Terminal ID (LET = 1) byte[4] - icard (0-based)

Once the LoopDiagnostics have been performed using the umc1LoopDiagnosticsRequestTable, the results are cached on the card. The EMS can then ask for the remaining results (CCF, QLN, etc.) using this table. The LoopCharacteristics are already sent back as part of the trap.

The format of the umc1LoopDiagnosticsResponseTable.

A sequence number used to associate the test that was performed with the results of the test

An IP address of the host that requested the diagnostics

Enumerated value from SIS: 0x01 = Loop Characteristics 0x02 = CCF for Tones 0 to 42 0x03 = CCF for Tones 43 to 85 0x04 = CCF for Tones 86 to 128 0x05 = CCF for Tones 129 to 171 0x06 = CCF for Tones 172 to 214 0x07 = CCF for Tones 215 to 255 0x08 = CCF for Tones 256 to 298 0x09 = CCF for Tones 299 to 341 0x0A = CCF for Tones 342 to 384 0x0B = CCF for Tones 385 to 427 0x0C = CCF for Tones 428 to 470 0x0D = CCF for Tones 471 to 511 0x0E = QLN for Tones 0 to 42 0x0F = QLN for Tones 43 to 85 0x10 = QLN for Tones 86 to 128 0x11 = QLN for Tones 129 to 171 0x12 = QLN for Tones 172 to 214 0x13 = QLN for Tones 215 to 255 0x14 = QLN for Tones 256 to 298 0x15 = QLN for Tones 299 to 341 0x16 = QLN for Tones 342 to 384 0x17 = QLN for Tones 385 to 427 0x18 = QLN for Tones 428 to 470 0x19 = QLN for Tones 471 to 511 0x1A = SNR for Tones 0 to 42 0x1B = SNR for Tones 43 to 85 0x1C = SNR for Tones 86 to 128 0x1D = SNR for Tones 129 to 171 0x1E = SNR for Tones 172 to 214 0x1F = SNR for Tones 215 to 255 0x20 = SNR for Tones 256 to 298 0x21 = SNR for Tones 299 to 341 0x22 = SNR for Tones 342 to 384 0x23 = SNR for Tones 385 to 427 0x24 = SNR for Tones 428 to 470 0x25 = SNR for Tones 471 to 511

The last tone represented in the message, same enumeration as start tone.

Contents of the LoopDiagnostics data in the following format: byte [0] Start tone of response data (from umc1LoopDiagnosticsDataStartToneIdentifier enum) byte [1] End tone of response data (from umc1LoopDiagnosticsDataStartToneIdentifier enum) byte [2] Response Status (0 means valid data) Then either: byte[3-45] Data for first tone byte[46-88] Data for second tone, if applicable byte[89-131] Data for third tone, if applicable byte[132-174] Data for fourth tone, if applicable byte[175-217] Data for fifth tone, if applicable or: byte[3-4] Loop Attenuation byte[5-6] Signal attenuation byte[7-8] SNR margin byte[9-10] Attainable net data rate byte[11-12] Actual aggregate transmit power. The start tone identifier will indicate the value of the payload bytes.

The time the message was reported by the IPMI card. The format of the umc1SoftwareDiagMessageTimestamp is as follows: octet[0] High 8-bits of the YEAR octet[1] Low 8-bits of the YEAR octet[2] Month (January=1, February=2, etc.) octet[3] Day (1 through 31) octet[4] Hour (0 through 23) octet[5] Minutes (0 through 59) octet[6] Seconds (0 through 59)

A representation of the type of diagnostic message to follow. The format of the umc1SoftwareDiagMessageType is as follows: octet[0] Diagnostic message type (SYSERR=1) octet[1] Reserved (set to zero) octet[2] Reserved (set to zero) octet[3] Reserved (set to zero) octet[4] Reserved (set to zero)

The diagnostic message itself.