ADSL2-LINE-MIB

SnmpAdminStringAn octet string containing administrative information, preferably in human-readable form. To facilitate internationalization, this information is represented using the ISO/IEC IS 10646-1 character set, encoded as an octet string using the UTF-8 transformation format described in [RFC2279]. Since additional code points are added by amendments to the 10646 standard from time to time, implementations must be prepared to encounter any code point from 0x00000000 to 0x7fffffff. Byte sequences that do not correspond to the valid UTF-8 encoding of a code point or are outside this range are prohibited. The use of control codes should be avoided. When it is necessary to represent a newline, the control code sequence CR LF should be used. The use of leading or trailing white space should be avoided. For code points not directly supported by user interface hardware or software, an alternative means of entry and display, such as hexadecimal, may be provided. For information encoded in 7-bit US-ASCII, the UTF-8 encoding is identical to the US-ASCII encoding. UTF-8 may require multiple bytes to represent a single character / code point; thus the length of this object in octets may be different from the number of characters encoded. Similarly, size constraints refer to the number of encoded octets, not the number of characters represented by an encoding. Note that when this TC is used for an object that is used or envisioned to be used as an index, then a SIZE restriction MUST be specified so that the number of sub-identifiers for any object instance does not exceed the limit of 128, as defined by [RFC3416]. Note that the size of an SnmpAdminString object is measured in octets, not characters. SIZE (1..32) · OCTET STRING · hint 255t

The value of this object identifies the row in the ADSL2 Line Configuration Templates Table, (adsl2LineConfTemplateTable), which applies for this ADSL2 line. This object MUST be maintained in a persistent manner. ⓘ

SnmpAdminStringAn octet string containing administrative information, preferably in human-readable form. To facilitate internationalization, this information is represented using the ISO/IEC IS 10646-1 character set, encoded as an octet string using the UTF-8 transformation format described in [RFC2279]. Since additional code points are added by amendments to the 10646 standard from time to time, implementations must be prepared to encounter any code point from 0x00000000 to 0x7fffffff. Byte sequences that do not correspond to the valid UTF-8 encoding of a code point or are outside this range are prohibited. The use of control codes should be avoided. When it is necessary to represent a newline, the control code sequence CR LF should be used. The use of leading or trailing white space should be avoided. For code points not directly supported by user interface hardware or software, an alternative means of entry and display, such as hexadecimal, may be provided. For information encoded in 7-bit US-ASCII, the UTF-8 encoding is identical to the US-ASCII encoding. UTF-8 may require multiple bytes to represent a single character / code point; thus the length of this object in octets may be different from the number of characters encoded. Similarly, size constraints refer to the number of encoded octets, not the number of characters represented by an encoding. Note that when this TC is used for an object that is used or envisioned to be used as an index, then a SIZE restriction MUST be specified so that the number of sub-identifiers for any object instance does not exceed the limit of 128, as defined by [RFC3416]. Note that the size of an SnmpAdminString object is measured in octets, not characters. SIZE (1..32) · OCTET STRING · hint 255t

The value of this object identifies the row in the ADSL2 Line Alarm Configuration Template Table, (adsl2LineAlarmConfTemplateTable), which applies to this ADSL2 line. This object MUST be maintained in a persistent manner. ⓘ

Adsl2ConfPmsForce0 = l3toL02 = l0toL23 = l0orL2toL3Attributes with this syntax are configuration parameters that reference the desired power management state for the ADSL/ADSL2 or ADSL2+ link: l3toL0(0) - Perform a transition from L3 to L0 (Full power management state). l0toL2(2) - Perform a transition from L0 to L2 (Low power management state). l0orL2toL3(3) - Perform a transition into L3 (Idle power management state). The values used are as defined in ITU-T G.997.1, paragraph 7.3.1.1.3 · Integer32

Power management state forced. Defines the line states to be forced by the near-end ATU on this line. The various possible values are: l3toL0(0), l0toL2(2), or l0orL2toL3(3). This object MUST be maintained in a persistent manner. ⓘ

Adsl2LineLdsf0 = inhibit1 = forceAttributes with this syntax are configuration parameters that control the Loop Diagnostic mode for the ADSL/ADSL2 or ADSL2+ link. The possible values are: inhibit(0) - Inhibit Loop Diagnostic mode. force(1) - Force/Initiate Loop Diagnostic mode. The values used are as defined in ITU-T G.997.1, paragraph 7.3.1.1.8 · Integer32

Loop diagnostics mode forced (LDSF). Defines whether the line should be forced into the loop diagnostics mode by the near-end ATU on this line or only be responsive to loop diagnostics initiated by the far-end ATU. This object MUST be maintained in a persistent manner. However, in case the operator forces loop diagnostics mode then the access node should reset the object (inhibit) when loop diagnostics mode procedures are completed. ⓘ

Adsl2LdsfResult1 = none2 = success3 = inProgress4 = unsupported5 = cannotRun6 = aborted7 = failed8 = illegalMode9 = adminUp10 = tableFull11 = noResourcesPossible failure reasons associated with performing a Dual Ended Loop Test (DELT) on a DSL line. Possible values are: none(1) - The default value in case LDSF was never requested for the associated line. success(2) - The recent command completed successfully. inProgress(3) - The Loop Diagnostics process is in progress. unsupported(4) - The NE or the line card doesn't support LDSF. cannotRun(5) - The NE cannot initiate the command, due to a nonspecific reason. aborted(6) - The Loop Diagnostics process aborted. failed(7) - The Loop Diagnostics process failed. illegalMode(8) - The NE cannot initiate the command, due to the specific mode of the relevant line. adminUp(9) - The NE cannot initiate the command, as the relevant line is administratively 'Up'. tableFull(10) - The NE cannot initiate the command, due to reaching the maximum number of rows in the results table. noResources(11) - The NE cannot initiate the command, due to lack of internal memory resources. · Integer32

The status of the recent occasion the Loop diagnostics mode forced (LDSF) was issued for the associated line. Possible values are: none(1) - The default value in case LDSF was never requested for the associated line. success(2) - The recent command completed successfully. inProgress(3) - The Loop Diagnostics process is in progress. unsupported(4) - The NE or the line card doesn't support LDSF. cannotRun(5) - The NE cannot initiate the command, due to a nonspecific reason. aborted(6) - The Loop Diagnostics process aborted. failed(7) - The Loop Diagnostics process failed. illegalMode(8) - The NE cannot initiate the command, due to the specific mode of the relevant line. adminUp(9) - The NE cannot initiate the command, as the relevant line is administratively 'Up'. tableFull(10) - The NE cannot initiate the command, due to reaching the maximum number of rows in the results table. noResources(11) - The NE cannot initiate the command, due to lack of internal memory resources.

TruthValue1 = true2 = falseRepresents a boolean value. · Integer32

Automode cold start forced. This parameter is defined in order to improve testing of the performance of ATUs supporting automode when it is enabled in the MIB. Change the value of this parameter to 'true' indicates a change in loop conditions applied to the devices under test. The ATUs shall reset any historical information used for automode and for shortening G.994.1 handshake and initialization. Automode is the case where multiple operation-modes are enabled through the adsl2LConfProfAtuTransSysEna object in the line configuration profile being used for the ADSL line, and where the selection of the actual operation-mode depends not only on the common capabilities of both ATUs (as exchanged in G.994.1), but also on achievable data rates under given loop conditions. This object MUST be maintained in a persistent manner. ⓘ

Adsl2TransmissionModeTypeA set of ADSL2 line transmission modes, with one bit per mode. The notes (F) and (L) denote Full-Rate and Lite/splitterless, respectively: Bit 00 : Regional Std. (ANSI T1.413) (F) Bit 01 : Regional Std. (ETSI DTS/TM06006) (F) Bit 02 : G.992.1 POTS non-overlapped (F) Bit 03 : G.992.1 POTS overlapped (F) Bit 04 : G.992.1 ISDN non-overlapped (F) Bit 05 : G.992.1 ISDN overlapped (F) Bit 06 : G.992.1 TCM-ISDN non-overlapped (F) Bit 07 : G.992.1 TCM-ISDN overlapped (F) Bit 08 : G.992.2 POTS non-overlapped (L) Bit 09 : G.992.2 POTS overlapped (L) Bit 10 : G.992.2 with TCM-ISDN non-overlapped (L) Bit 11 : G.992.2 with TCM-ISDN overlapped (L) Bit 12 : G.992.1 TCM-ISDN symmetric (F) -- not in G.997.1 Bit 13-17: Reserved Bit 18 : G.992.3 POTS non-overlapped (F) Bit 19 : G.992.3 POTS overlapped (F) Bit 20 : G.992.3 ISDN non-overlapped (F) Bit 21 : G.992.3 ISDN overlapped (F) Bit 22-23: Reserved Bit 24 : G.992.4 POTS non-overlapped (L) Bit 25 : G.992.4 POTS overlapped (L) Bit 26-27: Reserved Bit 28 : G.992.3 Annex I All-Digital non-overlapped (F) Bit 29 : G.992.3 Annex I All-Digital overlapped (F) Bit 30 : G.992.3 Annex J All-Digital non-overlapped (F) Bit 31 : G.992.3 Annex J All-Digital overlapped (F) Bit 32 : G.992.4 Annex I All-Digital non-overlapped (L) Bit 33 : G.992.4 Annex I All-Digital overlapped (L) Bit 34 : G.992.3 Annex L POTS non-overlapped, mode 1, wide U/S (F) Bit 35 : G.992.3 Annex L POTS non-overlapped, mode 2, narrow U/S(F) Bit 36 : G.992.3 Annex L POTS overlapped, mode 3, wide U/S (F) Bit 37 : G.992.3 Annex L POTS overlapped, mode 4, narrow U/S (F) Bit 38 : G.992.3 Annex M POTS non-overlapped (F) Bit 39 : G.992.3 Annex M POTS overlapped (F) Bit 40 : G.992.5 POTS non-overlapped (F) Bit 41 : G.992.5 POTS overlapped (F) Bit 42 : G.992.5 ISDN non-overlapped (F) Bit 43 : G.992.5 ISDN overlapped (F) Bit 44-45: Reserved Bit 46 : G.992.5 Annex I All-Digital non-overlapped (F) Bit 47 : G.992.5 Annex I All-Digital overlapped (F) Bit 48 : G.992.5 Annex J All-Digital non-overlapped (F) Bit 49 : G.992.5 Annex J All-Digital overlapped (F) Bit 50 : G.992.5 Annex M POTS non-overlapped (F) Bit 51 : G.992.5 Annex M POTS overlapped (F) Bit 52-55: Reserved · BITS

The ATU Transmission System (ATS) in use. It is coded in a bit-map representation with only a single bit set to '1' (the selected coding for the ADSL line). This parameter may be derived from the handshaking procedures defined in Recommendation G.994.1. A set of ADSL2 line transmission modes, with one bit per mode. ⓘ

Adsl2PowerMngState1 = l02 = l13 = l24 = l3Attributes with this syntax uniquely identify each power management state defined for the ADSL/ADSL2 or ADSL2+ link. The possible values are: l0(1) - L0 - Full power management state. l1(2) - L1 - Low power management state (for G.992.2). l2(3) - L2 - Low power management state (for G.992.3, G.992.4, and G.992.5). l3(4) - L3 - Idle power management state. · Integer32

The current power management state. One of four possible power management states: L0 - Synchronized and full transmission (i.e., Showtime). L1 - Low Power with reduced net data rate (G.992.2 only). L2 - Low Power with reduced net data rate (G.992.3 and G.992.4 only). L3 - No power. The various possible values are: l0(1), l1(2), l2(3), or l3(4). ⓘ

Adsl2InitResult0 = noFail1 = configError2 = configNotFeasible3 = commFail4 = noPeerAtu5 = otherCauseSpecifies the result of a full initialization attempt; the six possible result values are: noFail(0) - Successful initialization. configError(1) - Configuration failure. configNotFeasible(2) - Configuration details not supported. commFail(3) - Communication failure. noPeerAtu(4) - Peer ATU not detected. otherCause(5) - Other initialization failure reason. The values used are as defined in ITU-T G.997.1, paragraph 7.5.1.3 · Integer32

Indicates the result of the last full initialization performed on the line. It is an enumeration type with the following values: noFail(0), configError(1), configNotFeasible(2), commFail(3), noPeerAtu(4), or otherCause(5). ⓘ

Adsl2LastTransmittedState0 = atucG99411 = atucQuiet12 = atucComb13 = atucQuiet24 = atucComb25 = atucIcomb16 = atucLineprob7 = atucQuiet38 = atucComb39 = atucIComb210 = atucMsgfmt11 = atucMsgpcb12 = atucQuiet413 = atucReverb114 = atucTref115 = atucReverb216 = atucEct17 = atucReverb318 = atucTref219 = atucReverb420 = atucSegue121 = atucMsg122 = atucReverb523 = atucSegue224 = atucMedley25 = atucExchmarker26 = atucMsg227 = atucReverb628 = atucSegue329 = atucParams30 = atucReverb731 = atucSegue432 = atucShowtime100 = aturG9941101 = aturQuiet1102 = aturComb1103 = aturQuiet2104 = aturComb2105 = aturIcomb1106 = aturLineprob107 = aturQuiet3108 = aturComb3109 = aturIcomb2110 = aturMsgfmt111 = aturMsgpcb112 = aturReverb1113 = aturQuiet4114 = aturReverb2115 = aturQuiet5116 = aturReverb3117 = aturEct118 = aturReverb4119 = aturSegue1120 = aturReverb5121 = aturSegue2122 = aturMsg1123 = aturMedley124 = aturExchmarker125 = aturMsg2126 = aturReverb6127 = aturSegue3128 = aturParams129 = aturReverb7130 = aturSegue4131 = aturShowtimeThis parameter represents the last successfully transmitted initialization state in the last full initialization performed on the line. States are per the specific xDSL technology and are numbered from 0 (if G.994.1 is used) or 1 (if G.994.1 is not used) up to Showtime. · Integer32

The last successful transmitted initialization state in the downstream direction in the last full initialization performed on the line. ⓘ

Adsl2LastTransmittedState0 = atucG99411 = atucQuiet12 = atucComb13 = atucQuiet24 = atucComb25 = atucIcomb16 = atucLineprob7 = atucQuiet38 = atucComb39 = atucIComb210 = atucMsgfmt11 = atucMsgpcb12 = atucQuiet413 = atucReverb114 = atucTref115 = atucReverb216 = atucEct17 = atucReverb318 = atucTref219 = atucReverb420 = atucSegue121 = atucMsg122 = atucReverb523 = atucSegue224 = atucMedley25 = atucExchmarker26 = atucMsg227 = atucReverb628 = atucSegue329 = atucParams30 = atucReverb731 = atucSegue432 = atucShowtime100 = aturG9941101 = aturQuiet1102 = aturComb1103 = aturQuiet2104 = aturComb2105 = aturIcomb1106 = aturLineprob107 = aturQuiet3108 = aturComb3109 = aturIcomb2110 = aturMsgfmt111 = aturMsgpcb112 = aturReverb1113 = aturQuiet4114 = aturReverb2115 = aturQuiet5116 = aturReverb3117 = aturEct118 = aturReverb4119 = aturSegue1120 = aturReverb5121 = aturSegue2122 = aturMsg1123 = aturMedley124 = aturExchmarker125 = aturMsg2126 = aturReverb6127 = aturSegue3128 = aturParams129 = aturReverb7130 = aturSegue4131 = aturShowtimeThis parameter represents the last successfully transmitted initialization state in the last full initialization performed on the line. States are per the specific xDSL technology and are numbered from 0 (if G.994.1 is used) or 1 (if G.994.1 is not used) up to Showtime. · Integer32

The last successful transmitted initialization state in the upstream direction in the last full initialization performed on the line. ⓘ

Adsl2LineStatusAttributes with this syntax are status parameters that reflect the failure status for a given endpoint of ADSL/ADSL2 or ADSL2+ link. This BITS structure can report the following failures: noDefect(0) - This bit position positively reports that no defect or failure exists. lossOfFrame(1) - Loss of frame synchronization. lossOfSignal(2) - Loss of signal. lossOfPower(3) - Loss of power. Usually this failure may be reported for ATU-Rs only. initFailure(4) - Recent initialization process failed. Never active on ATU-R. · BITS

Indicates current state (existing failures) of the ATU-R. This is a bit-map of possible conditions. ⓘ

Adsl2LineStatusAttributes with this syntax are status parameters that reflect the failure status for a given endpoint of ADSL/ADSL2 or ADSL2+ link. This BITS structure can report the following failures: noDefect(0) - This bit position positively reports that no defect or failure exists. lossOfFrame(1) - Loss of frame synchronization. lossOfSignal(2) - Loss of signal. lossOfPower(3) - Loss of power. Usually this failure may be reported for ATU-Rs only. initFailure(4) - Recent initialization process failed. Never active on ATU-R. · BITS

Indicates current state (existing failures) of the ATU-C. This is a bit-map of possible conditions. ⓘ

Unsigned32 (0..1270 | 2147483646 | 2147483647) · 0.1 dB

The measured difference in the total power transmitted by the ATU-C and the total power received by the ATU-R over all sub- carriers during diagnostics mode and initialization. It ranges from 0 to 1270 units of 0.1 dB (physical values are 0 to 127 dB). A special value of 0x7FFFFFFF (2147483647) indicates the line attenuation is out of range to be represented. A special value of 0x7FFFFFFE (2147483646) indicates the line attenuation measurement is currently unavailable. ⓘ

Unsigned32 (0..1270 | 2147483646 | 2147483647) · 0.1 dB

The measured difference in the total power transmitted by the ATU-R and the total power received by the ATU-C over all sub- carriers during diagnostics mode and initialization. It ranges from 0 to 1270 units of 0.1 dB (physical values are 0 to 127 dB). A special value of 0x7FFFFFFF (2147483647) indicates the line attenuation is out of range to be represented. A special value of 0x7FFFFFFE (2147483646) indicates the line attenuation measurement is currently unavailable. ⓘ

Unsigned32 (0..1270 | 2147483646 | 2147483647) · 0.1 dB

The measured difference in the total power transmitted by the ATU-C and the total power received by the ATU-R over all sub- carriers during Showtime. It ranges from 0 to 1270 units of 0.1 dB (physical values are 0 to 127 dB). A special value of 0x7FFFFFFF (2147483647) indicates the signal attenuation is out of range to be represented. A special value of 0x7FFFFFFE (2147483646) indicates the signal attenuation measurement is currently unavailable. ⓘ

Unsigned32 (0..1270 | 2147483646 | 2147483647) · 0.1 dB

The measured difference in the total power transmitted by the ATU-R and the total power received by the ATU-C over all sub- carriers during Showtime. It ranges from 0 to 1270 units of 0.1 dB (physical values are 0 to 127 dB). A special value of 0x7FFFFFFF (2147483647) indicates the signal attenuation is out of range to be represented. A special value of 0x7FFFFFFE (2147483646) indicates the signal attenuation measurement is currently unavailable. ⓘ

Integer32 (-640..630 | 2147483646 | 2147483647) · 0.1 dB

Downstream SNR Margin is the maximum increase in dB of the noise power received at the ATU-R, such that the BER requirements are met for all downstream bearer channels. It ranges from -640 to 630 units of 0.1 dB (physical values are -64 to 63 dB). A special value of 0x7FFFFFFF (2147483647) indicates the SNR Margin is out of range to be represented. A special value of 0x7FFFFFFE (2147483646) indicates the SNR Margin measurement is currently unavailable. ⓘ

Integer32 (-640..630 | 2147483646 | 2147483647) · 0.1 dB

Upstream SNR Margin is the maximum increase in dB of the noise power received at the ATU-C, such that the BER requirements are met for all downstream bearer channels. It ranges from -640 to 630 units of 0.1 dB (physical values are -64 to 63 dB). A special value of 0x7FFFFFFF (2147483647) indicates the SNR Margin is out of range to be represented. A special value of 0x7FFFFFFE (2147483646) indicates the SNR Margin measurement is currently unavailable. ⓘ

Unsigned32 · bits/second

Maximum Attainable Data Rate Downstream. The maximum downstream net data rate currently attainable by the ATU-C transmitter and the ATU-R receiver, coded in bits/second. ⓘ

Unsigned32 · bits/second

Maximum Attainable Data Rate Upstream. The maximum upstream net data rate currently attainable by the ATU-R transmitter and the ATU-C receiver, coded in bits/second. ⓘ

Integer32 (-900..0 | 2147483647) · 0.1 dB

Actual Power Spectrum Density (PSD) Downstream. The average downstream transmit PSD over the sub-carriers used for downstream. It ranges from -900 to 0 units of 0.1 dB (physical values are -90 to 0 dBm/Hz). A value of 0x7FFFFFFF (2147483647) indicates the measurement is out of range to be represented. ⓘ

Integer32 (-900..0 | 2147483647) · 0.1 dB

Actual Power Spectrum Density (PSD) Upstream. The average upstream transmit PSD over the sub-carriers used for upstream. It ranges from -900 to 0 units of 0.1 dB (physical values are -90 to 0 dBm/Hz). A value of 0x7FFFFFFF (2147483647) indicates the measurement is out of range to be represented. ⓘ

Integer32 (-310..310 | 2147483647) · 0.1 dB

Actual Aggregate Transmit Power Downstream. The total amount of transmit power delivered by the ATU-C at the U-C reference point, at the instant of measurement. It ranges from -310 to 310 units of 0.1 dB (physical values are -31 to 31 dBm). A value of 0x7FFFFFFF (2147483647) indicates the measurement is out of range to be represented. ⓘ

Integer32 (-310..310 | 2147483647) · 0.1 dB

Actual Aggregate Transmit Power Upstream. The total amount of transmit power delivered by the ATU-R at the U-R reference point, at the instant of measurement. It ranges from -310 to 310 units of 0.1 dB (physical values are -31 to 31 dBm). A value of 0x7FFFFFFF (2147483647) indicates the measurement is out of range to be represented. ⓘ

Adsl2Unit1 = atuc2 = aturIdentifies a transceiver as being either an ATU-C or an ATU-R. An ADSL line consists of two transceivers, an ATU-C and an ATU-R. Attributes with this syntax reference the two sides of a line. Specified as an INTEGER, the two values are: atuc(1) -- Central office ADSL terminal unit (ATU-C). atur(2) -- Remote ADSL terminal unit (ATU-R). · Integer32

The termination unit atuc(1) or atur(2).

Unsigned32

Provides the bearer channel number associated with this row (i.e., the channel ifIndex). This enables determining the channel configuration profile and the channel thresholds profile applicable for this bearer channel.

Unsigned32 (0..200000000) · bits/second

The actual net data rate that the bearer channel is operating at, if in L0 power management state. In L1 or L2 states, it relates to the previous L0 state. The data rate is coded in bits/second. ⓘ

Unsigned32 (0..200000000) · bits/second

The previous net data rate that the bearer channel was operating at just before the latest rate change event. This could be a full or short initialization, fast retrain, DRA or power management transitions, excluding transitions between L0 state and L1 or L2 states. The data rate is coded in bits/second. ⓘ

Unsigned32 (0..8176) · milliseconds

The actual one-way interleaving delay introduced by the PMS-TC in the direction of the bearer channel, if in L0 power management state. In L1 or L2 states, it relates to the previous L0 state. It is coded in ms (rounded to the nearest ms). ⓘ

Adsl2ChAtmStatusAttributes with this syntax are status parameters that reflect the failure status for Transmission Convergence (TC) layer of a given ATM interface (data path over an ADSL/ADSL2 or ADSL2+ link). This BITS structure can report the following failures: noDefect(0) - This bit position positively reports that no defect or failure exists. noCellDelineation(1) - The link was successfully initialized, but cell delineation was never acquired on the associated ATM data path. lossOfCellDelineation(2) - Loss of cell delineation on the associated ATM data path. · BITS

Indicates the current state (existing failures) of the ADSL channel in case its Data Path is ATM. This is a bit-map of possible conditions. The various bit positions are: noDefect(0), noCellDelineation(1), or lossOfCellDelineation(2). In the case where the channel is not an ATM Data Path, the object is set to '0'. ⓘ

Adsl2ChPtmStatusAttributes with this syntax are status parameters that reflect the failure status for a given PTM interface (packet data path over an ADSL/ADSL2 or ADSL2+ link). This BITS structure can report the following failures: noDefect(0) - This bit position positively reports that no defect or failure exists. outOfSync(1) - Out of synchronization. · BITS

Indicates the current state (existing failures) of the ADSL channel in case its Data Path is PTM. This is a bit-map of possible conditions. The various bit positions are: noDefect(0), or outOfSync(1). In the case where the channel is not a PTM Data Path, the object is set to '0'. ⓘ

Adsl2Direction1 = upstream2 = downstreamIdentifies the direction of a band as being either upstream or downstream. Specified as an INTEGER, the two values are: upstream(1), and downstream(2). · Integer32

The direction of the sub-carrier is either upstream or downstream.

Unsigned32 · symbols

SNR Measurement Time. The number of symbols used to measure the SNR values on the respective transmission direction. It should correspond to the value specified in the recommendation (e.g., the number of symbols in 1 second time interval for G.992.3). This parameter corresponds to 1 second in loop diagnostic procedure and should be updated otherwise. ⓘ

OCTET STRING SIZE (0..512)

The SNR Margin per sub-carrier, expressing the ratio between the received signal power and received noise power per subscriber. It is an array of 512 octets, designed for supporting up to 512 (downstream) sub-carriers. The number of utilized octets on downstream direction depends on NSCds, and on upstream direction it depends on NSCus. This value is referred to here as NSC. Octet i (0 <= i < NSC) is set to a value in the range 0 to 254 to indicate that the respective downstream or upstream sub- carrier i has SNR of: (-32 + Adsl2SubcarrierSnr(i)/2) in dB (i.e., -32 to 95dB). The special value 255 means that no measurement could be done for the subcarrier because it is out of the PSD mask passband or that the noise PSD is out of range to be represented. Each value in this array is 8 bits wide. ⓘ

OCTET STRING SIZE (0..256) · bits

The bits allocation per sub-carrier. An array of 256 octets (512 nibbles), designed for supporting up to 512 (downstream) sub-carriers. The number of utilized nibbles on downstream direction depends on NSCds, and on upstream direction it depends on NSCus. This value is referred to here as NSC. Nibble i (0 <= i < NSC) is set to a value in the range 0 to 15 to indicate that the respective downstream or upstream sub-carrier i has the same amount of bits allocation. ⓘ

OCTET STRING SIZE (0..1024)

The gain allocation per sub-carrier. An array of 512 16-bits values, designed for supporting up to 512 (downstream) sub- carriers. The number of utilized octets on downstream direction depends on NSCds, and on upstream direction it depends on NSCus. This value is referred to here as NSC. Value i (0 <= i < NSC) is in the range 0 to 4093 to indicate that the respective downstream or upstream sub-carrier i has the same amount of gain value. The gain value is represented as a multiple of 1/512 on a linear scale. Each value in this array is 16 bits wide and is stored in big endian format. ⓘ

Adsl2TssiThis is a structure that represents up to 32 transmit spectrum shaping (TSSi) breakpoints. Each breakpoint occupies 3 octets: The first two octets hold the index of the sub-carrier associated with the breakpoint. The third octet holds the shaping parameter at the breakpoint. It is a value from 0 to 127 (units of -0.5 dB). The special value 127 indicates that the sub-carrier is not transmitted. SIZE (0..96) · OCTET STRING

The transmit spectrum shaping (TSSi) breakpoints expressed as the set of breakpoints exchanged during G.994.1. Each breakpoint is a pair of values occupying 3 octets with the following structure: First 2 octets - Index of the subcarrier used in the context of the breakpoint. Third octet - The shaping parameter at the breakpoint. Subcarrier index is an unsigned number in the range 1 to either NSCds (downstream direction) or NSCus (upstream direction). The shaping parameter value is in the range 0 to 127 (units of -0.5dB). The special value 127 indicates that the subcarrier is not transmitted. ⓘ

Unsigned32

The scale factor to be applied to the H(f) linear representation values for the respective transmission direction. This parameter is only available after a loop diagnostic procedure. ⓘ

OCTET STRING SIZE (0..1024)

An array of up to 512 complex H(f) linear representation values in linear scale for the respective transmission direction. It is designed to support up to 512 (downstream) sub-carriers. The number of utilized values on downstream direction depends on NSCds, and on upstream direction it depends on NSCus. This value is referred to here as NSC. Each array entry represents the real component [referred to here as a(i)] of Hlin(f = i*Df) value for a particular sub-carrier index i (0 <= i < NSC). Hlin(f) is represented as ((scale/2^15)*((a(i)+j*b(i))/2^15)), where scale is Adsl2SubcarrierLinScale and a(i) and b(i) [provided by the Adsl2SubcarrierLinImg object] are in the range (-2^15+1) to (+2^15-1). A special value a(i)=b(i)= -2^15 indicates that no measurement could be done for the subcarrier because it is out of the passband or that the attenuation is out of range to be represented. This parameter is only available after a loop diagnostic procedure. Each value in this array is 16 bits wide and is stored in big endian format. ⓘ

OCTET STRING SIZE (0..1024)

An array of up to 512 complex H(f) linear representation values in linear scale for the respective transmission direction. It is designed to support up to 512 (downstream) sub-carriers. The number of utilized values on downstream direction depends on NSCds, and on upstream direction it depends on NSCus. This value is referred to here as NSC. Each array entry represents the imaginary component [referred to here as b(i)] of Hlin(f = i*Df) value for a particular sub- carrier index i (0 <= i < NSC). Hlin(f) is represented as ((scale/2^15)*((a(i)+j*b(i))/2^15)), where scale is Adsl2SubcarrierLinScale and a(i) [provided by the Adsl2SubcarrierLinReal object] and b(i) are in the range (-2^15+1) to (+2^15-1). A special value a(i)=b(i)= -2^15 indicates that no measurement could be done for the subcarrier because it is out of the passband or that the attenuation is out of range to be represented. This parameter is only available after a loop diagnostic procedure. Each value in this array is 16 bits wide and is stored in big endian format. ⓘ

Unsigned32

The number of symbols used to measure the H(f) logarithmic measurement values for the respective transmission direction. This parameter should correspond to the value specified in the recommendation (e.g., the number of symbols in 1 second time interval for G.992.3). This parameter corresponds to 1 second in loop diagnostic procedure and should be updated in initialization ⓘ

OCTET STRING SIZE (0..1024)

An array of up to 512 real H(f) logarithmic representation values in dB for the respective transmission direction. It is designed to support up to 512 (downstream) sub-carriers. The number of utilized values on downstream direction depends on NSCds, and on upstream direction it depends on NSCus. This value is referred to here as NSC. Each array entry represents the real Hlog(f = i*Df) value for a particular sub-carrier index i, (0 <= i < NSC). The real Hlog(f) value is represented as (6-m(i)/10), with m(i) in the range 0 to 1022. A special value m=1023 indicates that no measurement could be done for the subcarrier because it is out of the passband or that the attenuation is out of range to be represented. This parameter is applicable in loop diagnostic procedure and initialization. Each value in this array is 16 bits wide and is stored in big endian format. ⓘ

Unsigned32

The number of symbols used to measure the Quiet Line Noise values on the respective transmission direction. This parameter should correspond to the value specified in the recommendation (e.g., the number of symbols in 1 second time interval for G.992.3). This parameter corresponds to 1 second in loop diagnostic procedure and should be updated in initialization ⓘ

OCTET STRING SIZE (0..512) · dBm/Hz

An array of up to 512 real Quiet Line Noise values in dBm/Hz for the respective transmission direction. It is designed for up to 512 (downstream) sub-carriers. The number of utilized values on downstream direction depends on NSCds, and on upstream direction it depends on NSCus. This value is referred to here as NSC. Each array entry represents the QLN(f = i*Df) value for a particular sub-carrier index i, (0 <= i < NSC). The QLN(f) is represented as ( -23-n(i)/2), with n(i) in the range 0 to 254. A special value n(i)=255 indicates that no measurement could be done for the subcarrier because it is out of the passband or that the noise PSD is out of range to be represented. This parameter is applicable in loop diagnostic procedure and initialization. Each value in this array is 8 bits wide. ⓘ

Unsigned32 (0..1270 | 2147483646 | 2147483647) · 0.1 dB

When referring to the downstream direction, it is the measured difference in the total power transmitted by the ATU-C and the total power received by the ATU-R over all sub-carriers during diagnostics mode. When referring to the upstream direction, it is the measured difference in the total power transmitted by the ATU-R and the total power received by the ATU-C over all sub-carriers during diagnostics mode. It ranges from 0 to 1270 units of 0.1 dB (physical values are 0 to 127 dB). A special value of 0x7FFFFFFF (2147483647) indicates the line attenuation is out of range to be represented. A special value of 0x7FFFFFFE (2147483646) indicates the line attenuation measurement is unavailable. This object reflects the value of the parameter following the most recent DELT performed on the associated line. Once the DELT process is over, the parameter no longer changes until the row is deleted or a new DELT process is initiated. ⓘ

Unsigned32 (0..1270 | 2147483646 | 2147483647) · 0.1 dB

When referring to the downstream direction, it is the measured difference in the total power transmitted by the ATU-C and the total power received by the ATU-R over all sub- carriers during Showtime after the diagnostics mode. When referring to the upstream direction, it is the measured difference in the total power transmitted by the ATU-R and the total power received by the ATU-C over all sub- carriers during Showtime after the diagnostics mode. It ranges from 0 to 1270 units of 0.1 dB (physical values are 0 to 127 dB). A special value of 0x7FFFFFFF (2147483647) indicates the signal attenuation is out of range to be represented. A special value of 0x7FFFFFFE (2147483646) indicates the signal attenuation measurement is unavailable. This object reflects the value of the parameter following the most recent DELT performed on the associated line. Once the DELT process is over, the parameter no longer changes until the row is deleted or a new DELT process is initiated. ⓘ

Integer32 (-640..630 | 2147483646 | 2147483647) · 0.1 dB

SNR Margin is the maximum increase in dB of the noise power received at the ATU (ATU-R on downstream direction and ATU-C on upstream direction), such that the BER requirements are met for all bearer channels received at the ATU. It ranges from -640 to 630 units of 0.1 dB (physical values are -64 to 63 dB). A special value of 0x7FFFFFFF (2147483647) indicates the SNR Margin is out of range to be represented. A special value of 0x7FFFFFFE (2147483646) indicates the SNR Margin measurement is currently unavailable. This object reflects the value of the parameter following the most recent DELT performed on the associated line. Once the DELT process is over, the parameter no longer changes until the row is deleted or a new DELT process is initiated. ⓘ

Unsigned32 · bits/second

Maximum Attainable Data Rate. The maximum net data rate currently attainable by the ATU-C transmitter and ATU-R receiver (when referring to downstream direction) or by the ATU-R transmitter and ATU-C receiver (when referring to upstream direction). Value is coded in bits/second. This object reflects the value of the parameter following the most recent DELT performed on the associated line. Once the DELT process is over, the parameter no longer changes until the row is deleted or a new DELT process is initiated. ⓘ

Integer32 · 0.1 dB

Actual Aggregate Transmit Power from the ATU (ATU-R on downstream direction and ATU-C on upstream direction), at the instant of measurement. It ranges from -310 to 310 units of 0.1 dB (physical values are -31 to 31 dBm). A value of all 1's indicates the measurement is out of range to be represented. This object reflects the value of the parameter following the most recent DELT performed on the associated line. Once the DELT process is over, the parameter no longer changes until the row is deleted or a new DELT process is initiated. ⓘ

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

Row Status. The manager may create and delete rows of this table. Please see the description of adsl2SCStatusTable above for more details.

Adsl2Unit1 = atuc2 = aturIdentifies a transceiver as being either an ATU-C or an ATU-R. An ADSL line consists of two transceivers, an ATU-C and an ATU-R. Attributes with this syntax reference the two sides of a line. Specified as an INTEGER, the two values are: atuc(1) -- Central office ADSL terminal unit (ATU-C). atur(2) -- Remote ADSL terminal unit (ATU-R). · Integer32

The termination unit atuc(1) or atur(2).

OCTET STRING SIZE (8)

The ATU G.994.1 Vendor ID as inserted in the G.994.1 CL/CLR message. It consists of 8 binary octets, including a country code followed by a (regionally allocated) provider code, as defined in Recommendation T.35. ⓘ

OCTET STRING SIZE (8)

The ATU System Vendor ID (identifies the ATU system integrator) as inserted in the Overhead Messages (both ATUs for G.992.3 and G.992.4) or in the Embedded Operations Channel (only ATU-R in G.992.1 and G.992.2). It consists of 8 binary octets, with the same format as used for Adsl2InvG994VendorId. ⓘ

OCTET STRING SIZE (0..16)

The ATU version number (vendor-specific information) as inserted in the Overhead Messages (both ATUs for G.992.3 and G.992.4) or in the Embedded Operations Channel (only ATU-R in G.992.1 and G.992.2). It consists of up to 16 binary octets. ⓘ

OCTET STRING SIZE (0..32)

The ATU serial number (vendor-specific information) as inserted in the Overhead Messages (both ATUs for G.992.3 and G.992.4) or in the Embedded Operations Channel (only ATU-R in G.992.1 and G.992.2). It is vendor-specific information. It consists of up to 32 ASCII characters. ⓘ

Unsigned32

The ATU self-test result, coded as a 32-bit value. The most significant octet of the result is '0' if the self-test passed, and '1' if the self-test failed. The interpretation of the other octets is vendor discretionary. ⓘ

Adsl2TransmissionModeTypeA set of ADSL2 line transmission modes, with one bit per mode. The notes (F) and (L) denote Full-Rate and Lite/splitterless, respectively: Bit 00 : Regional Std. (ANSI T1.413) (F) Bit 01 : Regional Std. (ETSI DTS/TM06006) (F) Bit 02 : G.992.1 POTS non-overlapped (F) Bit 03 : G.992.1 POTS overlapped (F) Bit 04 : G.992.1 ISDN non-overlapped (F) Bit 05 : G.992.1 ISDN overlapped (F) Bit 06 : G.992.1 TCM-ISDN non-overlapped (F) Bit 07 : G.992.1 TCM-ISDN overlapped (F) Bit 08 : G.992.2 POTS non-overlapped (L) Bit 09 : G.992.2 POTS overlapped (L) Bit 10 : G.992.2 with TCM-ISDN non-overlapped (L) Bit 11 : G.992.2 with TCM-ISDN overlapped (L) Bit 12 : G.992.1 TCM-ISDN symmetric (F) -- not in G.997.1 Bit 13-17: Reserved Bit 18 : G.992.3 POTS non-overlapped (F) Bit 19 : G.992.3 POTS overlapped (F) Bit 20 : G.992.3 ISDN non-overlapped (F) Bit 21 : G.992.3 ISDN overlapped (F) Bit 22-23: Reserved Bit 24 : G.992.4 POTS non-overlapped (L) Bit 25 : G.992.4 POTS overlapped (L) Bit 26-27: Reserved Bit 28 : G.992.3 Annex I All-Digital non-overlapped (F) Bit 29 : G.992.3 Annex I All-Digital overlapped (F) Bit 30 : G.992.3 Annex J All-Digital non-overlapped (F) Bit 31 : G.992.3 Annex J All-Digital overlapped (F) Bit 32 : G.992.4 Annex I All-Digital non-overlapped (L) Bit 33 : G.992.4 Annex I All-Digital overlapped (L) Bit 34 : G.992.3 Annex L POTS non-overlapped, mode 1, wide U/S (F) Bit 35 : G.992.3 Annex L POTS non-overlapped, mode 2, narrow U/S(F) Bit 36 : G.992.3 Annex L POTS overlapped, mode 3, wide U/S (F) Bit 37 : G.992.3 Annex L POTS overlapped, mode 4, narrow U/S (F) Bit 38 : G.992.3 Annex M POTS non-overlapped (F) Bit 39 : G.992.3 Annex M POTS overlapped (F) Bit 40 : G.992.5 POTS non-overlapped (F) Bit 41 : G.992.5 POTS overlapped (F) Bit 42 : G.992.5 ISDN non-overlapped (F) Bit 43 : G.992.5 ISDN overlapped (F) Bit 44-45: Reserved Bit 46 : G.992.5 Annex I All-Digital non-overlapped (F) Bit 47 : G.992.5 Annex I All-Digital overlapped (F) Bit 48 : G.992.5 Annex J All-Digital non-overlapped (F) Bit 49 : G.992.5 Annex J All-Digital overlapped (F) Bit 50 : G.992.5 Annex M POTS non-overlapped (F) Bit 51 : G.992.5 Annex M POTS overlapped (F) Bit 52-55: Reserved · BITS

The ATU transmission system capability list of the different coding types. It is coded in a bit-map representation with 1 or more bits set. A bit set to '1' means that the ATU supports the respective coding. The value may be derived from the handshaking procedures defined in G.994.1. A set of ADSL2 line transmission modes, with one bit per mode. ⓘ

Adsl2Unit1 = atuc2 = aturIdentifies a transceiver as being either an ATU-C or an ATU-R. An ADSL line consists of two transceivers, an ATU-C and an ATU-R. Attributes with this syntax reference the two sides of a line. Specified as an INTEGER, the two values are: atuc(1) -- Central office ADSL terminal unit (ATU-C). atur(2) -- Remote ADSL terminal unit (ATU-R). · Integer32

The termination unit atuc(1) or atur(2).

Unsigned32

Valid intervals.

Unsigned32

Invalid intervals.

HCPerfTimeElapsedThe number of seconds that have elapsed since the beginning of the current measurement period. If, for some reason, such as an adjustment in the system's time-of-day clock or the addition of a leap second, the duration of the current interval exceeds the maximum value, the agent will return the maximum value. For 15 minute intervals, the range is limited to (0..899). For 24 hour intervals, the range is limited to (0..86399). (0..86399) · Integer32 · seconds

Total elapsed seconds since this PM interval began. Note that the PM counters are not reset even when the XTU is reinitialized. They are reinitialized only when the agent itself is reset or reinitialized.

Counter32 · seconds

Count of seconds during this interval where there was at least one FEC correction event for one or more bearer channels in this line. This parameter is inhibited during UAS or SES. ⓘ

Counter32 · seconds

Count of seconds during this interval where there was: ATU-C: CRC-8 >= 1 for one or more bearer channels OR LOS >= 1 OR SEF >=1 OR LPR >= 1 ATU-R: FEBE >= 1 for one or more bearer channels OR LOS-FE >=1 OR RDI >=1 OR LPR-FE >=1 . This parameter is inhibited during UAS. ⓘ

Counter32 · seconds

Count of seconds during this interval where there was: ATU-C: (CRC-8 summed over all bearer channels) >= 18 OR LOS >= 1 OR SEF >= 1 OR LPR >= 1 ATU-R: (FEBE summed over all bearer channels) >= 18 OR LOS-FE >= 1 OR RDI >= 1 OR LPR-FE >= 1 . This parameter is inhibited during UAS. ⓘ

Counter32 · seconds

Count of seconds during this interval where there was LOS (or LOS-FE for ATU-R). ⓘ

Counter32 · seconds

Count of seconds in Unavailability State during this interval. Unavailability begins at the onset of 10 contiguous severely-errored seconds, and ends at the onset of 10 contiguous seconds with no severely-errored seconds. ⓘ

Unsigned32

Valid intervals.

Unsigned32

Invalid intervals.

HCPerfTimeElapsedThe number of seconds that have elapsed since the beginning of the current measurement period. If, for some reason, such as an adjustment in the system's time-of-day clock or the addition of a leap second, the duration of the current interval exceeds the maximum value, the agent will return the maximum value. For 15 minute intervals, the range is limited to (0..899). For 24 hour intervals, the range is limited to (0..86399). (0..86399) · Integer32 · seconds

Total elapsed seconds since this PM interval began. Note that the PM counters are not reset even when the XTU is reinitialized. They are reinitialized only when the agent itself is reset or reinitialized.

Counter32 · seconds

Count of seconds during this interval where there was at least one FEC correction event for one or more bearer channels in this line. This parameter is inhibited during UAS or SES. ⓘ

Counter32 · seconds

Count of seconds during this interval where there was: ATU-C: CRC-8 >= 1 for one or more bearer channels OR LOS >= 1 OR SEF >= 1 OR LPR >= 1 ATU-R: FEBE >= 1 for one or more bearer channels OR LOS-FE >= 1 OR RDI >= 1 OR LPR-FE >= 1. This parameter is inhibited during UAS. ⓘ

Counter32 · seconds

Count of seconds during this interval where there was: ATU-C: (CRC-8 summed over all bearer channels) >= 18 OR LOS >= 1 OR SEF >= 1 OR LPR >= 1 ATU-R: (FEBE summed over all bearer channels) >= 18 OR LOS-FE >= 1 OR RDI >= 1 OR LPR-FE >= 1 This parameter is inhibited during UAS. ⓘ

Counter32 · seconds

Count of seconds during this interval where there was LOS (or LOS-FE for ATU-R). ⓘ

Counter32 · seconds

Count of seconds in Unavailability State during this interval. Unavailability begins at the onset of 10 contiguous severely- errored seconds, and ends at the onset of 10 contiguous seconds with no severely-errored seconds. ⓘ

Unsigned32 · seconds

Total elapsed seconds since this PM interval began. Note that the PM counters are not reset even when the XTU is reinitialized. They are reinitialized only when the agent itself is reset or reinitialized.

Unsigned32

Count of full initializations attempted on the line (successful and failed) during this interval. ⓘ

Unsigned32

Count of failed full initializations on the line during this interval. ⓘ

Unsigned32

Count of short initializations attempted on the line (successful and failed) during this interval. ⓘ

Unsigned32

Count of failed short initializations on the line during this interval. ⓘ

Unsigned32 · seconds

Total elapsed seconds since this PM interval began. Note that the PM counters are not reset even when the XTU is reinitialized. They are reinitialized only when the agent itself is reset or reinitialized.

Unsigned32

Count of full initializations attempted on the line (successful and failed) during this interval. ⓘ

Unsigned32

Count of failed full initializations on the line during this interval. ⓘ

Unsigned32

Count of short initializations attempted on the line (successful and failed) during this interval. ⓘ

Unsigned32

Count of failed short initializations on the line during this interval. ⓘ

Adsl2Unit1 = atuc2 = aturIdentifies a transceiver as being either an ATU-C or an ATU-R. An ADSL line consists of two transceivers, an ATU-C and an ATU-R. Attributes with this syntax reference the two sides of a line. Specified as an INTEGER, the two values are: atuc(1) -- Central office ADSL terminal unit (ATU-C). atur(2) -- Remote ADSL terminal unit (ATU-R). · Integer32

The termination unit atuc(1) or atur(2).

Unsigned32 (1..96)

The interval number.

Unsigned32 · seconds

Total seconds monitored in this interval.

Counter32 · seconds

Count of seconds during this interval where there was at least one FEC correction event for one or more bearer channels in this line. This parameter is inhibited during UAS or SES. ⓘ

Counter32 · seconds

Count of seconds during this interval where there was: ATU-C: CRC-8 >= 1 for one or more bearer channels OR LOS >= 1 OR SEF >= 1 OR LPR >= 1 ATU-R: FEBE >= 1 for one or more bearer channels OR LOS-FE >= 1 OR RDI >= 1 OR LPR-FE >= 1. This parameter is inhibited during UAS. ⓘ

Counter32 · seconds

Count of seconds during this interval where there was: ATU-C: (CRC-8 summed over all bearer channels) >= 18 OR LOS >= 1 OR SEF >= 1 OR LPR >= 1 ATU-R: (FEBE summed over all bearer channels) >= 18 OR LOS-FE >= 1 OR RDI >= 1 OR LPR-FE >= 1. This parameter is inhibited during UAS. ⓘ

Counter32 · seconds

Count of seconds during this interval where there was LOS (or LOS-FE for ATU-R). ⓘ

Counter32 · seconds

Count of seconds in Unavailability State during this interval. Unavailability begins at the onset of 10 contiguous severely- errored seconds, and ends at the onset of 10 contiguous seconds with no severely-errored seconds. ⓘ

TruthValue1 = true2 = falseRepresents a boolean value. · Integer32

This variable indicates if the data for this interval is valid.

Adsl2Unit1 = atuc2 = aturIdentifies a transceiver as being either an ATU-C or an ATU-R. An ADSL line consists of two transceivers, an ATU-C and an ATU-R. Attributes with this syntax reference the two sides of a line. Specified as an INTEGER, the two values are: atuc(1) -- Central office ADSL terminal unit (ATU-C). atur(2) -- Remote ADSL terminal unit (ATU-R). · Integer32

The termination unit.

Unsigned32 (1..30)

The interval number.

Unsigned32 · seconds

Total seconds monitored in this interval.

Counter32 · seconds

Count of seconds during this interval where there was at least one FEC correction event for one or more bearer channels in this line. This parameter is inhibited during UAS or SES. ⓘ

Counter32 · seconds

Count of seconds during this interval where there was: ATU-C: CRC-8 >= 1 for one or more bearer channels OR LOS >= 1 OR SEF >= 1 OR LPR >= 1 ATU-R: FEBE >= 1 for one or more bearer channels OR LOS-FE >= 1 OR RDI >= 1 OR LPR-FE >= 1. This parameter is inhibited during UAS. ⓘ

Counter32 · seconds

Count of seconds during this interval where there was: ATU-C: (CRC-8 summed over all bearer channels) >= 18 OR LOS >= 1 OR SEF >> 1 OR LPR >= 1 ATU-R: (FEBE summed over all bearer channels) >= 18 OR LOS-FE >= 1 OR RDI >= 1 OR LPR-FE >= 1. This parameter is inhibited during UAS. ⓘ

Counter32 · seconds

Count of seconds during this interval where there was LOS (or LOS-FE for ATU-R). ⓘ

Counter32 · seconds

Count of seconds in Unavailability State during this interval. Unavailability begins at the onset of 10 contiguous severely- errored seconds, and ends at the onset of 10 contiguous seconds with no severely-errored seconds. ⓘ

TruthValue1 = true2 = falseRepresents a boolean value. · Integer32

This variable indicates if the data for this interval is valid.

Unsigned32 (1..96)

The interval number.

Unsigned32 · seconds

Total seconds monitored in this interval.

Unsigned32

Count of full initializations attempted on the line (successful and failed) during this interval. ⓘ

Unsigned32

Count of failed full initializations on the line during this interval. ⓘ

Unsigned32

Count of short initializations attempted on the line (successful and failed) during this interval. ⓘ

Unsigned32

Count of failed short initializations on the line during this interval. ⓘ

TruthValue1 = true2 = falseRepresents a boolean value. · Integer32

This variable indicates if the data for this interval is valid.

Unsigned32 (1..30)

The interval number.

Unsigned32 · seconds

Total seconds monitored in this interval.

Unsigned32

Count of full initializations attempted on the line (successful and failed) during this interval. ⓘ

Unsigned32

Count of failed full initializations on the line during this interval. ⓘ

Unsigned32

Count of short initializations attempted on the line (successful and failed) during this interval. ⓘ

Unsigned32

Count of failed short initializations on the line during this interval. ⓘ

TruthValue1 = true2 = falseRepresents a boolean value. · Integer32

This variable indicates if the data for this interval is valid.

Adsl2Unit1 = atuc2 = aturIdentifies a transceiver as being either an ATU-C or an ATU-R. An ADSL line consists of two transceivers, an ATU-C and an ATU-R. Attributes with this syntax reference the two sides of a line. Specified as an INTEGER, the two values are: atuc(1) -- Central office ADSL terminal unit (ATU-C). atur(2) -- Remote ADSL terminal unit (ATU-R). · Integer32

The termination unit.

Unsigned32

Valid intervals.

Unsigned32

Invalid intervals.

HCPerfTimeElapsedThe number of seconds that have elapsed since the beginning of the current measurement period. If, for some reason, such as an adjustment in the system's time-of-day clock or the addition of a leap second, the duration of the current interval exceeds the maximum value, the agent will return the maximum value. For 15 minute intervals, the range is limited to (0..899). For 24 hour intervals, the range is limited to (0..86399). (0..86399) · Integer32 · seconds

Total elapsed seconds since this PM interval began. Note that the PM counters are not reset even when the XTU is reinitialized. They are reinitialized only when the agent itself is reset or reinitialized.

Unsigned32

Count of CRC-8 (FEBE for ATU-R) anomalies occurring in the channel during the interval. This parameter is inhibited during UAS or SES. If the CRC is applied over multiple channels, then each related CRC-8 (or FEBE) anomaly should increment each of the counters related to the individual channels. ⓘ

Unsigned32

Count of FEC (FFEC for ATU-R) anomalies (corrected code words) occurring in the channel during the interval. This parameter is inhibited during UAS or SES. If the FEC is applied over multiple channels, then each related FEC (or FFEC) anomaly should increment each of the counters related to the individual channels. ⓘ

Unsigned32

Valid intervals.

Unsigned32

Invalid intervals.

HCPerfTimeElapsedThe number of seconds that have elapsed since the beginning of the current measurement period. If, for some reason, such as an adjustment in the system's time-of-day clock or the addition of a leap second, the duration of the current interval exceeds the maximum value, the agent will return the maximum value. For 15 minute intervals, the range is limited to (0..899). For 24 hour intervals, the range is limited to (0..86399). (0..86399) · Integer32 · seconds

Total elapsed seconds since this PM interval began. Note that the PM counters are not reset even when the XTU is reinitialized. They are reinitialized only when the agent itself is reset or reinitialized.

Unsigned32

Count of CRC-8 (FEBE for ATU-R) anomalies occurring in the channel during the interval. This parameter is inhibited during UAS or SES. If the CRC is applied over multiple channels, then each related CRC-8 (or FEBE) anomaly should increment each of the counters related to the individual channels. ⓘ

Unsigned32

Count of FEC (FFEC for ATU-R) anomalies (corrected code words) occurring in the channel during the interval. This parameter is inhibited during UAS or SES. If the FEC is applied over multiple channels, then each related FEC (or FFEC) anomaly should increment each of the counters related to the individual channels. ⓘ

Adsl2Unit1 = atuc2 = aturIdentifies a transceiver as being either an ATU-C or an ATU-R. An ADSL line consists of two transceivers, an ATU-C and an ATU-R. Attributes with this syntax reference the two sides of a line. Specified as an INTEGER, the two values are: atuc(1) -- Central office ADSL terminal unit (ATU-C). atur(2) -- Remote ADSL terminal unit (ATU-R). · Integer32

The termination unit.

Unsigned32 (1..96)

The interval number.

Unsigned32 · seconds

Total seconds monitored in this interval.

Unsigned32

Count of CRC-8 (FEBE for ATU-R) anomalies occurring in the channel during the interval. This parameter is inhibited during UAS or SES. If the CRC is applied over multiple channels, then each related CRC-8 (or FEBE) anomaly should increment each of the counters related to the individual channels. ⓘ

Unsigned32

Count of FEC (FFEC for ATU-R) anomalies (corrected code words) occurring in the channel during the interval. This parameter is inhibited during UAS or SES. If the FEC is applied over multiple channels, then each related FEC (or FFEC) anomaly should increment each of the counters related to the individual channels. ⓘ

TruthValue1 = true2 = falseRepresents a boolean value. · Integer32

This variable indicates if the data for this interval is valid.

Adsl2Unit1 = atuc2 = aturIdentifies a transceiver as being either an ATU-C or an ATU-R. An ADSL line consists of two transceivers, an ATU-C and an ATU-R. Attributes with this syntax reference the two sides of a line. Specified as an INTEGER, the two values are: atuc(1) -- Central office ADSL terminal unit (ATU-C). atur(2) -- Remote ADSL terminal unit (ATU-R). · Integer32

The termination unit.

Unsigned32 (1..30)

The interval number.

Unsigned32 · seconds

Total seconds monitored in this interval.

Unsigned32

Count of CRC-8 (FEBE for ATU-R) anomalies occurring in the channel during the interval. This parameter is inhibited during UAS or SES. If the CRC is applied over multiple channels, then each related CRC-8 (or FEBE) anomaly should increment each of the counters related to the individual channels. ⓘ

Unsigned32

Count of FEC (FFEC for ATU-R) anomalies (corrected code words) occurring in the channel during the interval. This parameter is inhibited during UAS or SES. If the FEC is applied over multiple channels, then each related FEC (or FFEC) anomaly should increment each of the counters related to the individual channels. ⓘ

TruthValue1 = true2 = falseRepresents a boolean value. · Integer32

This variable indicates if the data for this interval is valid.

SnmpAdminStringAn octet string containing administrative information, preferably in human-readable form. To facilitate internationalization, this information is represented using the ISO/IEC IS 10646-1 character set, encoded as an octet string using the UTF-8 transformation format described in [RFC2279]. Since additional code points are added by amendments to the 10646 standard from time to time, implementations must be prepared to encounter any code point from 0x00000000 to 0x7fffffff. Byte sequences that do not correspond to the valid UTF-8 encoding of a code point or are outside this range are prohibited. The use of control codes should be avoided. When it is necessary to represent a newline, the control code sequence CR LF should be used. The use of leading or trailing white space should be avoided. For code points not directly supported by user interface hardware or software, an alternative means of entry and display, such as hexadecimal, may be provided. For information encoded in 7-bit US-ASCII, the UTF-8 encoding is identical to the US-ASCII encoding. UTF-8 may require multiple bytes to represent a single character / code point; thus the length of this object in octets may be different from the number of characters encoded. Similarly, size constraints refer to the number of encoded octets, not the number of characters represented by an encoding. Note that when this TC is used for an object that is used or envisioned to be used as an index, then a SIZE restriction MUST be specified so that the number of sub-identifiers for any object instance does not exceed the limit of 128, as defined by [RFC3416]. Note that the size of an SnmpAdminString object is measured in octets, not characters. SIZE (1..32) · OCTET STRING · hint 255t

This object identifies a row in this table. ⓘ

SnmpAdminStringAn octet string containing administrative information, preferably in human-readable form. To facilitate internationalization, this information is represented using the ISO/IEC IS 10646-1 character set, encoded as an octet string using the UTF-8 transformation format described in [RFC2279]. Since additional code points are added by amendments to the 10646 standard from time to time, implementations must be prepared to encounter any code point from 0x00000000 to 0x7fffffff. Byte sequences that do not correspond to the valid UTF-8 encoding of a code point or are outside this range are prohibited. The use of control codes should be avoided. When it is necessary to represent a newline, the control code sequence CR LF should be used. The use of leading or trailing white space should be avoided. For code points not directly supported by user interface hardware or software, an alternative means of entry and display, such as hexadecimal, may be provided. For information encoded in 7-bit US-ASCII, the UTF-8 encoding is identical to the US-ASCII encoding. UTF-8 may require multiple bytes to represent a single character / code point; thus the length of this object in octets may be different from the number of characters encoded. Similarly, size constraints refer to the number of encoded octets, not the number of characters represented by an encoding. Note that when this TC is used for an object that is used or envisioned to be used as an index, then a SIZE restriction MUST be specified so that the number of sub-identifiers for any object instance does not exceed the limit of 128, as defined by [RFC3416]. Note that the size of an SnmpAdminString object is measured in octets, not characters. SIZE (1..32) · OCTET STRING · hint 255t

The value of this object identifies the row in the ADSL2 Line Configuration Profile Table, (adsl2LineConfProfTable), which applies for this ADSL2 line. ⓘ

SnmpAdminStringAn octet string containing administrative information, preferably in human-readable form. To facilitate internationalization, this information is represented using the ISO/IEC IS 10646-1 character set, encoded as an octet string using the UTF-8 transformation format described in [RFC2279]. Since additional code points are added by amendments to the 10646 standard from time to time, implementations must be prepared to encounter any code point from 0x00000000 to 0x7fffffff. Byte sequences that do not correspond to the valid UTF-8 encoding of a code point or are outside this range are prohibited. The use of control codes should be avoided. When it is necessary to represent a newline, the control code sequence CR LF should be used. The use of leading or trailing white space should be avoided. For code points not directly supported by user interface hardware or software, an alternative means of entry and display, such as hexadecimal, may be provided. For information encoded in 7-bit US-ASCII, the UTF-8 encoding is identical to the US-ASCII encoding. UTF-8 may require multiple bytes to represent a single character / code point; thus the length of this object in octets may be different from the number of characters encoded. Similarly, size constraints refer to the number of encoded octets, not the number of characters represented by an encoding. Note that when this TC is used for an object that is used or envisioned to be used as an index, then a SIZE restriction MUST be specified so that the number of sub-identifiers for any object instance does not exceed the limit of 128, as defined by [RFC3416]. Note that the size of an SnmpAdminString object is measured in octets, not characters. SIZE (1..32) · OCTET STRING · hint 255t

The value of this object identifies the row in the ADSL2 Channel Configuration Profile Table, (adsl2ChConfProfileTable) that applies to ADSL2 bearer channel #1. The channel profile name specified here must match the name of an existing row in the adsl2ChConfProfileTable table.

Unsigned32 (0..100) · percent

Rate Adaptation Ratio. The ratio (in %) that should be taken into account for the bearer channel #1 when performing rate adaptation on Downstream. The ratio refers to the available data rate in excess of the Minimum Data Rate, summed over all bearer channels. Also, the 100 - adsl2LConfTempChan1RaRatioDs is the ratio of excess data rate to be assigned to all other bearer channels on Downstream direction. The sum of rate adaptation ratios over all bearers on the same direction shall be equal to 100%. ⓘ

Unsigned32 (0..100) · percent

Rate Adaptation Ratio. The ratio (in %) that should be taken into account for the bearer channel #1 when performing rate adaptation on Upstream. The ratio refers to the available data rate in excess of the Minimum Data Rate, summed over all bearer channels. Also, the 100 - adsl2LConfTempChan1RaRatioUs is the ratio of excess data rate to be assigned to all other bearer channels on Upstream direction. The sum of rate adaptation ratios over all bearers on the same direction shall be equal to 100%. ⓘ

SnmpAdminStringAn octet string containing administrative information, preferably in human-readable form. To facilitate internationalization, this information is represented using the ISO/IEC IS 10646-1 character set, encoded as an octet string using the UTF-8 transformation format described in [RFC2279]. Since additional code points are added by amendments to the 10646 standard from time to time, implementations must be prepared to encounter any code point from 0x00000000 to 0x7fffffff. Byte sequences that do not correspond to the valid UTF-8 encoding of a code point or are outside this range are prohibited. The use of control codes should be avoided. When it is necessary to represent a newline, the control code sequence CR LF should be used. The use of leading or trailing white space should be avoided. For code points not directly supported by user interface hardware or software, an alternative means of entry and display, such as hexadecimal, may be provided. For information encoded in 7-bit US-ASCII, the UTF-8 encoding is identical to the US-ASCII encoding. UTF-8 may require multiple bytes to represent a single character / code point; thus the length of this object in octets may be different from the number of characters encoded. Similarly, size constraints refer to the number of encoded octets, not the number of characters represented by an encoding. Note that when this TC is used for an object that is used or envisioned to be used as an index, then a SIZE restriction MUST be specified so that the number of sub-identifiers for any object instance does not exceed the limit of 128, as defined by [RFC3416]. Note that the size of an SnmpAdminString object is measured in octets, not characters. SIZE (0..32) · OCTET STRING · hint 255t

The value of this object identifies the row in the ADSL2 Channel Configuration Profile Table (adsl2ChConfProfileTable) that applies to ADSL2 bearer channel #2. If the channel is unused, then the object is set to a zero-length string. This object may be set to a zero-length string only if adsl2LConfTempChan3ConfProfile contains a zero-length string.

Unsigned32 (0..100) · percent

Rate Adaptation Ratio. The ratio (in %) that should be taken into account for the bearer channel #2 when performing rate adaptation on Downstream. The ratio refers to the available data rate in excess of the Minimum Data Rate, summed over all bearer channels. Also, the 100 - adsl2LConfTempChan2RaRatioDs is the ratio of excess data rate to be assigned to all other bearer channels on Downstream direction. The sum of rate adaptation ratios over all bearers on the same direction shall be equal to 100%. ⓘ

Unsigned32 (0..100) · percent

Rate Adaptation Ratio. The ratio (in %) that should be taken into account for the bearer channel #2 when performing rate adaptation on Upstream. The ratio refers to the available data rate in excess of the Minimum Data Rate, summed over all bearer channels. Also, the 100 - adsl2LConfTempChan2RaRatioUs is the ratio of excess data rate to be assigned to all other bearer channels on Upstream direction. The sum of rate adaptation ratios over all bearers on the same direction shall be equal to 100%. ⓘ

SnmpAdminStringAn octet string containing administrative information, preferably in human-readable form. To facilitate internationalization, this information is represented using the ISO/IEC IS 10646-1 character set, encoded as an octet string using the UTF-8 transformation format described in [RFC2279]. Since additional code points are added by amendments to the 10646 standard from time to time, implementations must be prepared to encounter any code point from 0x00000000 to 0x7fffffff. Byte sequences that do not correspond to the valid UTF-8 encoding of a code point or are outside this range are prohibited. The use of control codes should be avoided. When it is necessary to represent a newline, the control code sequence CR LF should be used. The use of leading or trailing white space should be avoided. For code points not directly supported by user interface hardware or software, an alternative means of entry and display, such as hexadecimal, may be provided. For information encoded in 7-bit US-ASCII, the UTF-8 encoding is identical to the US-ASCII encoding. UTF-8 may require multiple bytes to represent a single character / code point; thus the length of this object in octets may be different from the number of characters encoded. Similarly, size constraints refer to the number of encoded octets, not the number of characters represented by an encoding. Note that when this TC is used for an object that is used or envisioned to be used as an index, then a SIZE restriction MUST be specified so that the number of sub-identifiers for any object instance does not exceed the limit of 128, as defined by [RFC3416]. Note that the size of an SnmpAdminString object is measured in octets, not characters. SIZE (0..32) · OCTET STRING · hint 255t

The value of this object identifies the row in the ADSL2 Channel Configuration Profile Table (adsl2ChConfProfileTable) that applies to ADSL2 bearer channel #3. If the channel is unused, then the object is set to a zero-length string. This object may be set to a zero-length string only if adsl2LConfTempChan4ConfProfile contains a zero-length string. This object may be set to a non-zero-length string only if adsl2LConfTempChan2ConfProfile contains a non-zero-length string.

Unsigned32 (0..100) · percent

Rate Adaptation Ratio. The ratio (in %) that should be taken into account for the bearer channel #3 when performing rate adaptation on Downstream. The ratio refers to the available data rate in excess of the Minimum Data Rate, summed over all bearer channels. Also, the 100 - adsl2LConfTempChan3RaRatioDs is the ratio of excess data rate to be assigned to all other bearer channels on Downstream direction. The sum of rate adaptation ratios over all bearers on the same direction shall be equal to 100%. ⓘ

Unsigned32 (0..100) · percent

Rate Adaptation Ratio. The ratio (in %) that should be taken into account for the bearer channel #3 when performing rate adaptation on Upstream. The ratio refers to the available data rate in excess of the Minimum Data Rate, summed over all bearer channels. Also, the 100 - adsl2LConfTempChan3RaRatioUs is the ratio of excess data rate to be assigned to all other bearer channels on Upstream direction. The sum of rate adaptation ratios over all bearers on the same direction shall be equal to 100%. ⓘ

SnmpAdminStringAn octet string containing administrative information, preferably in human-readable form. To facilitate internationalization, this information is represented using the ISO/IEC IS 10646-1 character set, encoded as an octet string using the UTF-8 transformation format described in [RFC2279]. Since additional code points are added by amendments to the 10646 standard from time to time, implementations must be prepared to encounter any code point from 0x00000000 to 0x7fffffff. Byte sequences that do not correspond to the valid UTF-8 encoding of a code point or are outside this range are prohibited. The use of control codes should be avoided. When it is necessary to represent a newline, the control code sequence CR LF should be used. The use of leading or trailing white space should be avoided. For code points not directly supported by user interface hardware or software, an alternative means of entry and display, such as hexadecimal, may be provided. For information encoded in 7-bit US-ASCII, the UTF-8 encoding is identical to the US-ASCII encoding. UTF-8 may require multiple bytes to represent a single character / code point; thus the length of this object in octets may be different from the number of characters encoded. Similarly, size constraints refer to the number of encoded octets, not the number of characters represented by an encoding. Note that when this TC is used for an object that is used or envisioned to be used as an index, then a SIZE restriction MUST be specified so that the number of sub-identifiers for any object instance does not exceed the limit of 128, as defined by [RFC3416]. Note that the size of an SnmpAdminString object is measured in octets, not characters. SIZE (0..32) · OCTET STRING · hint 255t

The value of this object identifies the row in the ADSL2 Channel Configuration Profile Table (adsl2ChConfProfileTable) that applies to ADSL2 bearer channel #4. If the channel is unused, then the object is set to a zero-length string. This object may be set to a non-zero-length string only if adsl2LConfTempChan3ConfProfile contains a non-zero-length string.

Unsigned32 (0..100) · percent

Rate Adaptation Ratio. The ratio (in %) that should be taken into account for the bearer channel #4 when performing rate adaptation on Downstream. The ratio refers to the available data rate in excess of the Minimum Data Rate, summed over all bearer channels. Also, the 100 - adsl2LConfTempChan4RaRatioDs is the ratio of excess data rate to be assigned to all other bearer channels. The sum of rate adaptation ratios over all bearers on the same direction shall sum to 100%. ⓘ

Unsigned32 (0..100) · percent

Rate Adaptation Ratio. The ratio (in %) that should be taken into account for the bearer channel #4 when performing rate adaptation on Upstream. The ratio refers to the available data rate in excess of the Minimum Data Rate, summed over all bearer channels. Also, the 100 - adsl2LConfTempChan4RaRatioUs is the ratio of excess data rate to be assigned to all other bearer channels. The sum of rate adaptation ratios over all bearers on the same direction shall sum to 100%. ⓘ

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

This object is used to create a new row or to modify or delete an existing row in this table. A template is activated by setting this object to 'active'. When 'active' is set, the system will validate the template. Before a template can be deleted or taken out of service (by setting this object to 'destroy' or 'notInService'), it must first be unreferenced from all associated lines.

SnmpAdminStringAn octet string containing administrative information, preferably in human-readable form. To facilitate internationalization, this information is represented using the ISO/IEC IS 10646-1 character set, encoded as an octet string using the UTF-8 transformation format described in [RFC2279]. Since additional code points are added by amendments to the 10646 standard from time to time, implementations must be prepared to encounter any code point from 0x00000000 to 0x7fffffff. Byte sequences that do not correspond to the valid UTF-8 encoding of a code point or are outside this range are prohibited. The use of control codes should be avoided. When it is necessary to represent a newline, the control code sequence CR LF should be used. The use of leading or trailing white space should be avoided. For code points not directly supported by user interface hardware or software, an alternative means of entry and display, such as hexadecimal, may be provided. For information encoded in 7-bit US-ASCII, the UTF-8 encoding is identical to the US-ASCII encoding. UTF-8 may require multiple bytes to represent a single character / code point; thus the length of this object in octets may be different from the number of characters encoded. Similarly, size constraints refer to the number of encoded octets, not the number of characters represented by an encoding. Note that when this TC is used for an object that is used or envisioned to be used as an index, then a SIZE restriction MUST be specified so that the number of sub-identifiers for any object instance does not exceed the limit of 128, as defined by [RFC3416]. Note that the size of an SnmpAdminString object is measured in octets, not characters. SIZE (1..32) · OCTET STRING · hint 255t

This object identifies a row in this table.

Adsl2ScMaskDsEach one of the 512 bits in this OCTET STRING array represents the corresponding bin in the downstream direction. A value of one indicates that the bin is not in use. SIZE (0..64) · OCTET STRING

Sub-carriers mask. A bitmap of 512 bits that allows masking up to 512 downstream sub-carriers, depending on NSCds. If bit i (0 <= i < NSCds) is set to '1', the respective downstream sub-carrier i is masked, and if set to '0', the respective sub-carrier is unmasked. Note that there should always be unmasked sub-carriers (i.e., the object cannot be all 1's). Also note that if NSCds < 512, all bits i (NSCds < i <= 512) should be set to '1'. ⓘ

Adsl2ScMaskUsEach one of the 64 bits in this OCTET STRING array represents the corresponding bin in the upstream direction. A value of one indicates that the bin is not in use. SIZE (0..8) · OCTET STRING

Sub-carriers mask. A bitmap of 64 bits that allows masking up to 64 downstream sub-carriers, depending on NSCds. If bit i (0 <= i < NSCus) is set to '1', the respective upstream sub-carrier i is masked, and if set to '0', the respective sub-carrier is unmasked. Note that there should always be unmasked sub-carriers (i.e., the object cannot be all 1's). Also note that if NSCus < 64, all bits i (NSCus < i <= 64) should be set to '1'. ⓘ

Adsl2RfiDsEach one of the 512 bits in this OCTET STRING array represents the corresponding bin in the downstream direction. A value of one indicates that the bin is part of a notch filter. SIZE (0..64) · OCTET STRING

The subset of downstream PSD mask breakpoints that shall be used to notch an RFI band. The specific interpolation around these points is defined in G.992.5. It is a bitmap of 512 bits that allows referring to up to 512 downstream sub-carriers, depending on NSCds. If bit i (0 <= i < NSCds) is set to '1', the respective downstream sub-carrier i is part of a notch filter, and if set to '0', the respective sub-carrier is not part of a notch filter. This information complements the specification provided by adsl2LConfProfPsdMaskDs. Note that if NSCds < 512, all bits i (NSCds<i<512) should be set to '0'. ⓘ

Adsl2RaMode1 = manual2 = raInit3 = dynamicRaSpecifies the rate adaptation behavior for the line. The three possible behaviors are: manual(1) - No Rate-Adaptation. The initialization process attempts to synchronize to a specified rate. raInit(2) - Rate-Adaptation during initialization process only, which attempts to synchronize to a rate between minimum and maximum specified values. dynamicRa(3) - Dynamic Rate-Adaptation during initialization process as well as during SHOWTIME. · Integer32

The mode of operation of a rate-adaptive ATU-C in the transmit direction. The parameter can take three values: manual(1), raInit(2), or dynamicRa(3). ⓘ

Adsl2RaMode1 = manual2 = raInit3 = dynamicRaSpecifies the rate adaptation behavior for the line. The three possible behaviors are: manual(1) - No Rate-Adaptation. The initialization process attempts to synchronize to a specified rate. raInit(2) - Rate-Adaptation during initialization process only, which attempts to synchronize to a rate between minimum and maximum specified values. dynamicRa(3) - Dynamic Rate-Adaptation during initialization process as well as during SHOWTIME. · Integer32

The mode of operation of a rate-adaptive ATU-R in the transmit direction. The parameter can take three values: manual(1), raInit(2), or dynamicRa(3). ⓘ

Unsigned32 (0..310) · 0.1 dB

The Downstream Up-Shift Noise Margin value, to be used when adsl2LConfProfRaModeDs is set to dynamicRa. If the downstream noise margin is above this value and stays above it for more than the time specified by the adsl2LConfProfRaUsTimeDs, the ATU-R shall attempt to increase the downstream net data rate. The Downstream Up-Shift Noise Margin ranges from 0 to 310 units of 0.1 dB (physical values are 0 to 31 dB). ⓘ

Unsigned32 (0..310) · 0.1 dB

The Upstream Up-Shift Noise Margin value, to be used when adsl2LConfProfRaModeUs is set to dynamicRa. If the upstream noise margin is above this value and stays above it for more than the time specified by the adsl2LConfProfRaUsTimeUs, the ATU-C shall attempt to increase the upstream net data rate. The Upstream Up-Shift Noise Margin ranges from 0 to 310 units of 0.1 dB (physical values are 0 to 31 dB). ⓘ

Unsigned32 (0..16383) · seconds

The Downstream Up-Shift Time Interval, to be used when adsl2LConfProfRaModeDs is set to dynamicRa. The interval of time that the downstream noise margin should stay above the Downstream Up-Shift Noise Margin before the ATU-R shall attempt to increase the downstream net data rate. The time interval ranges from 0 to 16383 seconds. ⓘ

Unsigned32 (0..16383) · seconds

The Upstream Up-Shift Time Interval, to be used when adsl2LConfProfRaModeUs is set to dynamicRa. The interval of time the upstream noise margin should stay above the Upstream Up-Shift Noise Margin before the ATU-C shall attempt to increase the upstream net data rate. The time interval ranges from 0 to 16383 seconds. ⓘ

Unsigned32 (0..310) · 0.1 dB

The Downstream Down-Shift Noise Margin value, to be used when adsl2LConfProfRaModeDs is set to dynamicRa. If the downstream noise margin is below this value and stays below that for more than the time specified by the adsl2LConfProfRaDsTimeDs, the ATU-R shall attempt to decrease the downstream net data rate. The Downstream Down-Shift Noise Margin ranges from 0 to 310 units of 0.1 dB (physical values are 0 to 31 dB). ⓘ

Unsigned32 (0..310) · 0.1 dB

The Upstream Down-Shift Noise Margin value, to be used when adsl2LConfProfRaModeUs is set to dynamicRa. If the upstream noise margin is below this value and stays below that for more than the time specified by the adsl2LConfProfRaDsTimeUs, the ATU-C shall attempt to decrease the upstream net data rate. The Upstream Down-Shift Noise Margin ranges from 0 to 310 units of 0.1 dB (physical values are 0 to 31 dB). ⓘ

Unsigned32 (0..16383) · seconds

The Downstream Down-Shift Time Interval, to be used when adsl2LConfProfRaModeDs is set to dynamicRa. The interval of time the downstream noise margin should stay below the Downstream Down-Shift Noise Margin before the ATU-R shall attempt to decrease the downstream net data rate. The time interval ranges from 0 to 16383 seconds. ⓘ

Unsigned32 (0..16383) · seconds

The Upstream Down-Shift Time Interval, to be used when adsl2LConfProfRaModeUs is set to dynamicRa. The interval of time the upstream noise margin should stay below the Upstream Down-Shift Noise Margin before the ATU-C shall attempt to decrease the upstream net data rate. The time interval ranges from 0 to 16383 seconds. ⓘ

Unsigned32 (0..310) · 0.1 dB

The minimum Noise Margin the ATU-R receiver shall achieve, relative to the BER requirement for each of the downstream bearer channels, to successfully complete initialization. The target noise margin ranges from 0 to 310 units of 0.1 dB (physical values are 0 to 31 dB). ⓘ

Unsigned32 (0..310) · 0.1 dB

The minimum Noise Margin the ATU-C receiver shall achieve, relative to the BER requirement for each of the upstream bearer channels, to successfully complete initialization. The target noise margin ranges from 0 to 310 units of 0.1 dB (physical values are 0 to 31 dB). ⓘ

Unsigned32 (0..310 | 2147483647) · 0.1 dB

The maximum Noise Margin the ATU-R receiver shall try to sustain. If the Noise Margin is above this level, the ATU-R shall request that the ATU-C reduce the ATU-C transmit power to get a noise margin below this limit (if this functionality is supported). The maximum noise margin ranges from 0 to 310 units of 0.1 dB (physical values are 0 to 31 dB). A value of 0x7FFFFFFF (2147483647) means that there is no maximum. ⓘ

Unsigned32 (0..310 | 2147483647) · 0.1 dB

The maximum Noise Margin the ATU-C receiver shall try to sustain. If the Noise Margin is above this level, the ATU-C shall request that the ATU-R reduce the ATU-R transmit power to get a noise margin below this limit (if this functionality is supported). The maximum noise margin ranges from 0 to 310 units of 0.1 dB (physical values are 0 to 31 dB). A value of 0x7FFFFFFF (2147483647) means that there is no maximum. ⓘ

Unsigned32 (0..310) · 0.1 dB

The minimum Noise Margin the ATU-R receiver shall tolerate. If the noise margin falls below this level, the ATU-R shall request that the ATU-C increase the ATU-C transmit power. If an increase to ATU-C transmit power is not possible, a loss-of-margin (LOM) defect occurs, the ATU-R shall fail and attempt to reinitialize, and the NMS shall be notified. The minimum noise margin ranges from 0 to 310 units of 0.1 dB (physical values are 0 to 31 dB). A value of 0 means that there is no minimum. ⓘ

Unsigned32 (0..310) · 0.1 dB

The minimum Noise Margin the ATU-C receiver shall tolerate. If the noise margin falls below this level, the ATU-C shall request that the ATU-R increase the ATU-R transmit power. If an increase of ATU-R transmit power is not possible, a loss-of-margin (LOM) defect occurs, the ATU-C shall fail and attempt to reinitialize, and the NMS shall be notified. The minimum noise margin ranges from 0 to 310 units of 0.1 dB (physical values are 0 to 31 dB). A value of 0 means that there is no minimum. ⓘ

Unsigned32 (4000..63000) · bits/second

Minimum Overhead Rate Upstream. Defines the minimum rate of the message-based overhead that shall be maintained by the ATU in upstream direction. Expressed in bits per second and ranges from 4000 to 63000 bps. ⓘ

Unsigned32 (4000..63000) · bits/second

Minimum Overhead Rate Downstream. Defines the minimum rate of the message-based overhead that shall be maintained by the ATU in downstream direction. Expressed in bits per second and ranges from 4000 to 63000 bps. ⓘ

Adsl2TransmissionModeTypeA set of ADSL2 line transmission modes, with one bit per mode. The notes (F) and (L) denote Full-Rate and Lite/splitterless, respectively: Bit 00 : Regional Std. (ANSI T1.413) (F) Bit 01 : Regional Std. (ETSI DTS/TM06006) (F) Bit 02 : G.992.1 POTS non-overlapped (F) Bit 03 : G.992.1 POTS overlapped (F) Bit 04 : G.992.1 ISDN non-overlapped (F) Bit 05 : G.992.1 ISDN overlapped (F) Bit 06 : G.992.1 TCM-ISDN non-overlapped (F) Bit 07 : G.992.1 TCM-ISDN overlapped (F) Bit 08 : G.992.2 POTS non-overlapped (L) Bit 09 : G.992.2 POTS overlapped (L) Bit 10 : G.992.2 with TCM-ISDN non-overlapped (L) Bit 11 : G.992.2 with TCM-ISDN overlapped (L) Bit 12 : G.992.1 TCM-ISDN symmetric (F) -- not in G.997.1 Bit 13-17: Reserved Bit 18 : G.992.3 POTS non-overlapped (F) Bit 19 : G.992.3 POTS overlapped (F) Bit 20 : G.992.3 ISDN non-overlapped (F) Bit 21 : G.992.3 ISDN overlapped (F) Bit 22-23: Reserved Bit 24 : G.992.4 POTS non-overlapped (L) Bit 25 : G.992.4 POTS overlapped (L) Bit 26-27: Reserved Bit 28 : G.992.3 Annex I All-Digital non-overlapped (F) Bit 29 : G.992.3 Annex I All-Digital overlapped (F) Bit 30 : G.992.3 Annex J All-Digital non-overlapped (F) Bit 31 : G.992.3 Annex J All-Digital overlapped (F) Bit 32 : G.992.4 Annex I All-Digital non-overlapped (L) Bit 33 : G.992.4 Annex I All-Digital overlapped (L) Bit 34 : G.992.3 Annex L POTS non-overlapped, mode 1, wide U/S (F) Bit 35 : G.992.3 Annex L POTS non-overlapped, mode 2, narrow U/S(F) Bit 36 : G.992.3 Annex L POTS overlapped, mode 3, wide U/S (F) Bit 37 : G.992.3 Annex L POTS overlapped, mode 4, narrow U/S (F) Bit 38 : G.992.3 Annex M POTS non-overlapped (F) Bit 39 : G.992.3 Annex M POTS overlapped (F) Bit 40 : G.992.5 POTS non-overlapped (F) Bit 41 : G.992.5 POTS overlapped (F) Bit 42 : G.992.5 ISDN non-overlapped (F) Bit 43 : G.992.5 ISDN overlapped (F) Bit 44-45: Reserved Bit 46 : G.992.5 Annex I All-Digital non-overlapped (F) Bit 47 : G.992.5 Annex I All-Digital overlapped (F) Bit 48 : G.992.5 Annex J All-Digital non-overlapped (F) Bit 49 : G.992.5 Annex J All-Digital overlapped (F) Bit 50 : G.992.5 Annex M POTS non-overlapped (F) Bit 51 : G.992.5 Annex M POTS overlapped (F) Bit 52-55: Reserved · BITS

ATU Transmission System Enabling (ATSE). A list of the different coding types enabled in this profile. It is coded in a bit-map representation with 1 or more bits set. A bit set to '1' means that the ATUs may apply the respective coding for the ADSL line. A bit set to '0' means that the ATUs cannot apply the respective coding for the ADSL line. All 'reserved' bits should be set to '0'. ⓘ

Adsl2LConfProfPmModeAttributes with this syntax are configuration parameters that reference the power modes/states into which the ATU-C or ATU-R may autonomously transit. It is a BITS structure that allows control of the following transit options: allowTransitionsToIdle(0) - XTU may autonomously transit to idle (L3) state. allowTransitionsToLowPower(1) - XTU may autonomously transit to low-power (L2) state. · BITS

Power management state Enabling. Defines the power states the ATU-C or ATU-R may autonomously transition to on this line. The various bit positions are: allowTransitionsToIdle(0) and allowTransitionsToLowPower(1). A bit with a '1' value means that the ATU is allowed to transit into the respective state, and a '0' value means that the ATU is not allowed to transit into the respective state. ⓘ

Unsigned32 (0..255) · seconds

This minimum time (in seconds) between an Exit from the L2 state and the next Entry into the L2 state. It ranges from 0 to 255 seconds. ⓘ

Unsigned32 (0..255) · seconds

This minimum time (in seconds) between an Entry into the L2 state and the first Power Trim in the L2 state and between two consecutive Power Trims in the L2 State. It ranges from 0 to 255 seconds. ⓘ

Unsigned32 (0..31) · dB

The maximum aggregate transmit power reduction (in dB) that can be performed at transition of L0 to L2 state or through a single Power Trim in the L2 state. It ranges from 0 dB to 31 dB. ⓘ

Unsigned32 (0..31) · dB

The total maximum aggregate transmit power reduction (in dB) that can be performed in an L2 state. This is the sum of all reductions of L2 Request (i.e., at transition of L0 to L2 state) and Power Trims. ⓘ

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

This object is used to create a new row or to modify or delete an existing row in this table. A profile is activated by setting this object to 'active'. When 'active' is set, the system will validate the profile. Before a profile can be deleted or taken out of service (by setting this object to 'destroy' or 'notInService'), it must first be unreferenced from all associated templates.

Adsl2OperationModes1 = defMode2 = adsl8 = g9923PotsNonOverlapped9 = g9923PotsOverlapped10 = g9923IsdnNonOverlapped11 = g9923isdnOverlapped14 = g9924potsNonOverlapped15 = g9924potsOverlapped18 = g9923AnnexIAllDigNonOverlapped19 = g9923AnnexIAllDigOverlapped20 = g9923AnnexJAllDigNonOverlapped21 = g9923AnnexJAllDigOverlapped22 = g9924AnnexIAllDigNonOverlapped23 = g9924AnnexIAllDigOverlapped24 = g9923AnnexLMode1NonOverlapped25 = g9923AnnexLMode2NonOverlapped26 = g9923AnnexLMode3Overlapped27 = g9923AnnexLMode4Overlapped28 = g9923AnnexMPotsNonOverlapped29 = g9923AnnexMPotsOverlapped30 = g9925PotsNonOverlapped31 = g9925PotsOverlapped32 = g9925IsdnNonOverlapped33 = g9925isdnOverlapped36 = g9925AnnexIAllDigNonOverlapped37 = g9925AnnexIAllDigOverlapped38 = g9925AnnexJAllDigNonOverlapped39 = g9925AnnexJAllDigOverlapped40 = g9925AnnexMPotsNonOverlapped41 = g9925AnnexMPotsOverlappedThe ADSL2 management model specified includes an ADSL Mode attribute that identifies an instance of ADSL Mode-Specific PSD Configuration object in the ADSL Line Profile. The following classes of ADSL operating mode are defined. The notes (F) and (L) denote Full-Rate and Lite/splitterless respectively: +-------+--------------------------------------------------+ | Value | ADSL operation mode description | +-------+--------------------------------------------------+ 1 - The default/generic PSD configuration. Default configuration will be used when no other matching mode-specific configuration can be found. 2 - ADSL family. The attributes included in the Mode- Specific PSD Configuration are irrelevant for ITU-T G.992.1 and G.992.2 ADSL modes. Hence, it is possible to map those modes to this generic class. 3-7 - Unused. Reserved for future ITU-T specification. 8 - G.992.3 POTS non-overlapped (F) 9 - G.992.3 POTS overlapped (F) 10 - G.992.3 ISDN non-overlapped (F) 11 - G.992.3 ISDN overlapped (F) 12-13 - Unused. Reserved for future ITU-T specification. 14 - G.992.4 POTS non-overlapped (L) 15 - G.992.4 POTS overlapped (L) 16-17 - Unused. Reserved for future ITU-T specification. 18 - G.992.3 Annex I All-Digital non-overlapped (F) 19 - G.992.3 Annex I All-Digital overlapped (F) 20 - G.992.3 Annex J All-Digital non-overlapped (F) 21 - G.992.3 Annex J All-Digital overlapped (F) 22 - G.992.4 Annex I All-Digital non-overlapped (L) 23 - G.992.4 Annex I All-Digital overlapped (L) 24 - G.992.3 Annex L POTS non-overlapped, mode 1, wide U/S (F) 25 - G.992.3 Annex L POTS non-overlapped, mode 2, narrow U/S(F) 26 - G.992.3 Annex L POTS overlapped, mode 3, wide U/S (F) 27 - G.992.3 Annex L POTS overlapped, mode 4, narrow U/S (F) 28 - G.992.3 Annex M POTS non-overlapped (F) 29 - G.992.3 Annex M POTS overlapped (F) 30 - G.992.5 POTS non-overlapped (F) 31 - G.992.5 POTS overlapped (F) 32 - G.992.5 ISDN non-overlapped (F) 33 - G.992.5 ISDN overlapped (F) 34-35 - Unused. Reserved for future ITU-T specification. 36 - G.992.5 Annex I All-Digital non-overlapped (F) 37 - G.992.5 Annex I All-Digital overlapped (F) 38 - G.992.5 Annex J All-Digital non-overlapped (F) 39 - G.992.5 Annex J All-Digital overlapped (F) 40 - G.992.5 Annex M POTS non-overlapped (F) 41 - G.992.5 Annex M POTS overlapped (F) · Integer32

The ADSL Mode is a way of categorizing the various ADSL transmission modes into groups; each group (ADSL Mode) shares the same PSD configuration. There should be multiple entries in this table for a given line profile in case multiple bits are set in adsl2LConfProfAtuTransSysEna for that profile. ⓘ

Integer32 (-600..-300) · 0.1 dBm/Hz

The maximum nominal transmit PSD in the downstream direction during initialization and Showtime. It ranges from -600 to -300 units of 0.1 dBm/Hz (physical values are -60 to -30 dBm/Hz). ⓘ

Integer32 (-600..-300) · 0.1 dBm/Hz

The maximum nominal transmit PSD in the upstream direction during initialization and Showtime. It ranges from -600 to -300 units of 0.1 dBm/Hz (physical values are -60 to -30 dBm/Hz). ⓘ

Unsigned32 (0..255) · 0.1 dBm

The maximum nominal aggregate transmit power in the downstream direction during initialization and Showtime. It ranges from 0 to 255 units of 0.1 dBm (physical values are 0 to 25.5 dBm). ⓘ

Unsigned32 (0..255) · 0.1 dBm

The maximum nominal aggregate transmit power in the upstream direction during initialization and Showtime. It ranges from 0 to 255 units of 0.1 dBm (physical values are 0 to 25.5 dBm). ⓘ

Integer32 (-255..255 | 2147483647) · 0.1 dBm

The maximum upstream aggregate receive power over the relevant set of sub-carriers. The ATU-C should verify that the upstream power cutback is such that this maximum aggregate receive power value is honored. It ranges from -255 to 255 units of 0.1 dBm (physical values are -25.5 to 25.5 dBm). A value of 0x7FFFFFFF (2147483647) means that there is no limit. ⓘ

Adsl2PsdMaskDsThis is a structure that represents up to 32 PSD Mask breakpoints. Each breakpoint occupies 3 octets: The first two octets hold the index of the sub-carrier associated with the breakpoint. The third octet holds the PSD reduction at the breakpoint from 0 (0 dBm/Hz) to 255 (-127.5 dBm/Hz) using units of 0.5 dBm/Hz. SIZE (0..96) · OCTET STRING

The downstream PSD mask applicable at the U-C2 reference point. This parameter is used only for G.992.5, and it may impose PSD restrictions (breakpoints) in addition to the Limit PSD mask defined in G.992.5. This is a string of 32 pairs of values in the following structure: Octets 0+1 - Index of 1st sub-carrier used in the context of a first breakpoint. Octet 2 - The PSD reduction for the sub-carrier indicated in octets 0 and 1. Octets 3-5 - Same, for a 2nd breakpoint. Octets 6-8 - Same, for a 3rd breakpoint. This architecture continues until octets 94-95, which are associated with a 32nd breakpoint. Each subcarrier index is an unsigned number in the range 1 to NSCds. Each PSD reduction value is in the range 0 (0dBm/Hz) to 255 (-127.5dBm/Hz) with steps of 0.5dBm/Hz. Valid values are in the range 0 to 190 (0 to -95dBm/Hz). When the number of breakpoints is less than 32, all remaining octets are set to the value 0. Note that the content of this object should be correlated with the sub-carriers mask and with the RFI setup. ⓘ

Adsl2PsdMaskUsThis is a structure that represents up to 4 PSD Mask breakpoints. Each breakpoint occupies 3 octets: The first two octets hold the index of the sub-carrier associated with the breakpoint. The third octet holds the PSD reduction at the breakpoint from 0 (0 dBm/Hz) to 255 (-127.5 dBm/Hz) using units of 0.5 dBm/Hz. SIZE (0..12) · OCTET STRING

The upstream PSD mask applicable at the U-R2 reference point. This parameter is used only for G.992.5, and it may impose PSD restrictions (breakpoints) in addition to the Limit PSD mask defined in G.992.5. This is a string of 4 pairs of values in the following structure: Octets 0+1 - Index of 1st sub-carrier used in the context of a first breakpoint. Octet 2 - The PSD reduction for the sub-carrier indicated in octets 0 and 1. Octets 3-5 - Same, for a 2nd breakpoint. Octets 6-8 - Same, for a 3rd breakpoint. This architecture continues until octets 9-11, which are associated with a 4th breakpoint. Each subcarrier index is an unsigned number in the range 1 to NSCus. Each PSD reduction value is in the range 0 (0dBm/Hz) to 255 (-127.5dBm/Hz) with steps of 0.5dBm/Hz. Valid values are in the range 0 to 190 (0 to -95dBm/Hz). When the number of breakpoints is less than 4, all remaining octets are set to the value 0. Note that the content of this object should be correlated with the sub-carriers mask and with the RFI setup. ⓘ

Unsigned32 (1..9)

The selected upstream PSD mask. This parameter is used only for annexes J and M of G.992.3 and G.992.5, and the same selection is used for all relevant enabled bits in adsl2LConfProfAtuTransSysEna. ⓘ

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

This object is used to create a new row or to modify or delete an existing row in this table. A profile is activated by setting this object to 'active'. When 'active' is set, the system will validate the profile. Before a profile can be deleted or taken out of service (by setting this object to 'destroy' or 'notInService'), it must first be unreferenced from all associated templates.

SnmpAdminStringAn octet string containing administrative information, preferably in human-readable form. To facilitate internationalization, this information is represented using the ISO/IEC IS 10646-1 character set, encoded as an octet string using the UTF-8 transformation format described in [RFC2279]. Since additional code points are added by amendments to the 10646 standard from time to time, implementations must be prepared to encounter any code point from 0x00000000 to 0x7fffffff. Byte sequences that do not correspond to the valid UTF-8 encoding of a code point or are outside this range are prohibited. The use of control codes should be avoided. When it is necessary to represent a newline, the control code sequence CR LF should be used. The use of leading or trailing white space should be avoided. For code points not directly supported by user interface hardware or software, an alternative means of entry and display, such as hexadecimal, may be provided. For information encoded in 7-bit US-ASCII, the UTF-8 encoding is identical to the US-ASCII encoding. UTF-8 may require multiple bytes to represent a single character / code point; thus the length of this object in octets may be different from the number of characters encoded. Similarly, size constraints refer to the number of encoded octets, not the number of characters represented by an encoding. Note that when this TC is used for an object that is used or envisioned to be used as an index, then a SIZE restriction MUST be specified so that the number of sub-identifiers for any object instance does not exceed the limit of 128, as defined by [RFC3416]. Note that the size of an SnmpAdminString object is measured in octets, not characters. SIZE (1..32) · OCTET STRING · hint 255t

This object identifies a row in this table.

Unsigned32 (0..200000000) · bits/second

Minimum Data Rate on Downstream direction. The minimum net data rate for the bearer channel, coded in bits/second. ⓘ

Unsigned32 (0..200000000) · bits/second

Minimum Data Rate on Upstream direction. The minimum net data rate for the bearer channel, coded in bits/second. ⓘ

Unsigned32 (0..200000000) · bits/second

Minimum Reserved Data Rate on Downstream direction. The minimum reserved net data rate for the bearer channel, coded in bits/second. This parameter is used only if the Rate Adaptation Mode in the direction of the bearer channel (i.e., adsl2LConfProfRaModeDs) is set to dynamicRa. ⓘ

Unsigned32 (0..200000000) · bits/second

Minimum Reserved Data Rate on Upstream direction. The minimum reserved net data rate for the bearer channel, coded in bits/second. This parameter is used only if the Rate Adaptation Mode in the direction of the bearer channel (i.e., adsl2LConfProfRaModeUs) is set to dynamicRa. ⓘ

Unsigned32 (0..200000000) · bits/second

Maximum Data Rate on Downstream direction. The maximum net data rate for the bearer channel, coded in bits/second. ⓘ

Unsigned32 (0..200000000) · bits/second

Maximum Data Rate on Upstream direction. The maximum net data rate for the bearer channel, coded in bits/second. ⓘ

Unsigned32 (0..200000000) · bits/second

Minimum Data Rate in Low Power state on Downstream direction. The minimum net data rate for the bearer channel, coded in bits/second, during the low power state (L1 in G.992.2, L2 in G.992.3). ⓘ

Unsigned32 (0..63) · milliseconds

Maximum Interleave Delay on Downstream direction. The maximum one-way interleaving delay introduced by the PMS-TC on Downstream direction. The ATUs shall choose the S (factor) and D (depth) values such that the actual one-way interleaving delay (adsl2ChStatusActDelay) is as close as possible to, but less than or equal to, adsl2ChConfProfMaxDelayDs. The delay is coded in ms, with the value 0 indicating no delay bound is being imposed. ⓘ

Unsigned32 (0..63) · milliseconds

Maximum Interleave Delay on Upstream direction. The maximum one-way interleaving delay introduced by the PMS-TC on Upstream direction. The ATUs shall choose the S (factor) and D (depth) values such that the actual one-way interleaving delay (adsl2ChStatusActDelay) is as close as possible to, but less than or equal to, adsl2ChConfProfMaxDelayUs. The delay is coded in ms, with the value 0 indicating no delay bound is being imposed. ⓘ

Adsl2SymbolProtection1 = noProtection2 = halfSymbol3 = singleSymbol4 = twoSymbols5 = threeSymbols6 = fourSymbols7 = fiveSymbols8 = sixSymbols9 = sevenSymbols10 = eightSymbols11 = nineSymbols12 = tenSymbols13 = elevenSymbols14 = twelveSymbols15 = thirteeSymbols16 = fourteenSymbols17 = fifteenSymbols18 = sixteenSymbolsAttributes with this syntax are configuration parameters that reference the minimum-length impulse noise protection (INP) in terms of number of symbols. The possible values are: noProtection (i.e., INP not required), halfSymbol (i.e., INP length is 1/2 symbol), and 1-16 symbols in steps of 1 symbol. · Integer32 · symbols

Minimum Impulse Noise Protection on Downstream direction. The minimum impulse noise protection for the bearer channel, expressed in symbols. The parameter can take the following values: noProtection (i.e., INP not required), halfSymbol (i.e., INP length is 1/2 symbol), and 1-16 symbols in steps of 1 symbol. ⓘ

Adsl2SymbolProtection1 = noProtection2 = halfSymbol3 = singleSymbol4 = twoSymbols5 = threeSymbols6 = fourSymbols7 = fiveSymbols8 = sixSymbols9 = sevenSymbols10 = eightSymbols11 = nineSymbols12 = tenSymbols13 = elevenSymbols14 = twelveSymbols15 = thirteeSymbols16 = fourteenSymbols17 = fifteenSymbols18 = sixteenSymbolsAttributes with this syntax are configuration parameters that reference the minimum-length impulse noise protection (INP) in terms of number of symbols. The possible values are: noProtection (i.e., INP not required), halfSymbol (i.e., INP length is 1/2 symbol), and 1-16 symbols in steps of 1 symbol. · Integer32 · symbols

Minimum Impulse Noise Protection on Upstream direction. The minimum impulse noise protection for the bearer channel, expressed in symbols. The parameter can take the following values: noProtection (i.e., INP not required), halfSymbol (i.e., INP length is 1/2 symbol), and 1-16 symbols in steps of 1 symbol. ⓘ

Adsl2MaxBer1 = eminus32 = eminus53 = eminus7Attributes with this syntax are configuration parameters that reference the maximum Bit Error Rate (BER). The possible values are: eminus3(1) - Maximum BER=E^-3 eminus5(2) - Maximum BER=E^-5 eminus7(3) - Maximum BER=E^-7 · Integer32

Maximum Bit Error Ratio on Downstream direction. The maximum bit error ratio for the bearer channel. The parameter can take the following values (for 1E-3, 1E-5 or 1E-7): eminus3(1), eminus5(2), or eminus7(3). ⓘ

Adsl2MaxBer1 = eminus32 = eminus53 = eminus7Attributes with this syntax are configuration parameters that reference the maximum Bit Error Rate (BER). The possible values are: eminus3(1) - Maximum BER=E^-3 eminus5(2) - Maximum BER=E^-5 eminus7(3) - Maximum BER=E^-7 · Integer32

Maximum Bit Error Ratio on Upstream direction. The maximum bit error ratio for the bearer channel. The parameter can take the following values (for 1E-3, 1E-5 or 1E-7): eminus3(1), eminus5(2), or eminus7(3). ⓘ

Unsigned32 (0..200000000) · bits/second

Data Rate Threshold Up shift for downstream direction. An 'Up-shift rate change' event is triggered when the actual downstream data rate exceeds, by more than the threshold, the data rate at the last entry into Showtime. The parameter is coded in bits/second. ⓘ

Unsigned32 (0..200000000) · bits/second

Data Rate Threshold Down-shift for downstream direction. A 'Down-shift rate change' event is triggered when the actual downstream data rate is below the data rate at the last entry into Showtime, by more than the threshold. The parameter is coded in bits/second. ⓘ

Unsigned32 (0..200000000) · bits/second

Data Rate Threshold Up shift for upstream direction. An 'Up-shift rate change' event is triggered when the actual upstream data rate exceeds, by more than the threshold, the data rate at the last entry into Showtime. The parameter is coded in bits/second. ⓘ

Unsigned32 (0..200000000) · bits/second

Data Rate Threshold Down-shift for upstream direction. A 'Down-shift rate change' event is triggered when the actual upstream data rate is below the data rate at the last entry into Showtime, by more than the threshold. The parameter is coded in bits/second. ⓘ

TruthValue1 = true2 = falseRepresents a boolean value. · Integer32

IMA Mode Enable. The parameter enables the IMA operation mode in the ATM Data Path. Relevant only if the channel is an ATM Data Path. When in 'enable' state, the ATM data path should comply with the requirements for IMA transmission. ⓘ

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

This object is used to create a new row or to modify or delete an existing row in this table. A profile is activated by setting this object to 'active'. When 'active' is set, the system will validate the profile. Before a profile can be deleted or taken out of service (by setting this object to 'destroy' or 'notInService'), it must first be unreferenced from all associated templates.

SnmpAdminStringAn octet string containing administrative information, preferably in human-readable form. To facilitate internationalization, this information is represented using the ISO/IEC IS 10646-1 character set, encoded as an octet string using the UTF-8 transformation format described in [RFC2279]. Since additional code points are added by amendments to the 10646 standard from time to time, implementations must be prepared to encounter any code point from 0x00000000 to 0x7fffffff. Byte sequences that do not correspond to the valid UTF-8 encoding of a code point or are outside this range are prohibited. The use of control codes should be avoided. When it is necessary to represent a newline, the control code sequence CR LF should be used. The use of leading or trailing white space should be avoided. For code points not directly supported by user interface hardware or software, an alternative means of entry and display, such as hexadecimal, may be provided. For information encoded in 7-bit US-ASCII, the UTF-8 encoding is identical to the US-ASCII encoding. UTF-8 may require multiple bytes to represent a single character / code point; thus the length of this object in octets may be different from the number of characters encoded. Similarly, size constraints refer to the number of encoded octets, not the number of characters represented by an encoding. Note that when this TC is used for an object that is used or envisioned to be used as an index, then a SIZE restriction MUST be specified so that the number of sub-identifiers for any object instance does not exceed the limit of 128, as defined by [RFC3416]. Note that the size of an SnmpAdminString object is measured in octets, not characters. SIZE (1..32) · OCTET STRING · hint 255t

This object identifies a row in this table.

SnmpAdminStringAn octet string containing administrative information, preferably in human-readable form. To facilitate internationalization, this information is represented using the ISO/IEC IS 10646-1 character set, encoded as an octet string using the UTF-8 transformation format described in [RFC2279]. Since additional code points are added by amendments to the 10646 standard from time to time, implementations must be prepared to encounter any code point from 0x00000000 to 0x7fffffff. Byte sequences that do not correspond to the valid UTF-8 encoding of a code point or are outside this range are prohibited. The use of control codes should be avoided. When it is necessary to represent a newline, the control code sequence CR LF should be used. The use of leading or trailing white space should be avoided. For code points not directly supported by user interface hardware or software, an alternative means of entry and display, such as hexadecimal, may be provided. For information encoded in 7-bit US-ASCII, the UTF-8 encoding is identical to the US-ASCII encoding. UTF-8 may require multiple bytes to represent a single character / code point; thus the length of this object in octets may be different from the number of characters encoded. Similarly, size constraints refer to the number of encoded octets, not the number of characters represented by an encoding. Note that when this TC is used for an object that is used or envisioned to be used as an index, then a SIZE restriction MUST be specified so that the number of sub-identifiers for any object instance does not exceed the limit of 128, as defined by [RFC3416]. Note that the size of an SnmpAdminString object is measured in octets, not characters. SIZE (1..32) · OCTET STRING · hint 255t

The value of this object identifies the row in the ADSL2 Line Thresholds Configuration Profile Table (adsl2LineAlarmConfProfileTable) that applies to this ADSL2 line. ⓘ

SnmpAdminStringAn octet string containing administrative information, preferably in human-readable form. To facilitate internationalization, this information is represented using the ISO/IEC IS 10646-1 character set, encoded as an octet string using the UTF-8 transformation format described in [RFC2279]. Since additional code points are added by amendments to the 10646 standard from time to time, implementations must be prepared to encounter any code point from 0x00000000 to 0x7fffffff. Byte sequences that do not correspond to the valid UTF-8 encoding of a code point or are outside this range are prohibited. The use of control codes should be avoided. When it is necessary to represent a newline, the control code sequence CR LF should be used. The use of leading or trailing white space should be avoided. For code points not directly supported by user interface hardware or software, an alternative means of entry and display, such as hexadecimal, may be provided. For information encoded in 7-bit US-ASCII, the UTF-8 encoding is identical to the US-ASCII encoding. UTF-8 may require multiple bytes to represent a single character / code point; thus the length of this object in octets may be different from the number of characters encoded. Similarly, size constraints refer to the number of encoded octets, not the number of characters represented by an encoding. Note that when this TC is used for an object that is used or envisioned to be used as an index, then a SIZE restriction MUST be specified so that the number of sub-identifiers for any object instance does not exceed the limit of 128, as defined by [RFC3416]. Note that the size of an SnmpAdminString object is measured in octets, not characters. SIZE (1..32) · OCTET STRING · hint 255t

The value of this object identifies the row in the ADSL2 Channel Thresholds Configuration Profile Table (adsl2ChAlarmConfProfileTable) that applies for ADSL2 bearer channel #1. The channel profile name specified here must match the name of an existing row in the adsl2ChAlarmConfProfileTable table. ⓘ

SnmpAdminStringAn octet string containing administrative information, preferably in human-readable form. To facilitate internationalization, this information is represented using the ISO/IEC IS 10646-1 character set, encoded as an octet string using the UTF-8 transformation format described in [RFC2279]. Since additional code points are added by amendments to the 10646 standard from time to time, implementations must be prepared to encounter any code point from 0x00000000 to 0x7fffffff. Byte sequences that do not correspond to the valid UTF-8 encoding of a code point or are outside this range are prohibited. The use of control codes should be avoided. When it is necessary to represent a newline, the control code sequence CR LF should be used. The use of leading or trailing white space should be avoided. For code points not directly supported by user interface hardware or software, an alternative means of entry and display, such as hexadecimal, may be provided. For information encoded in 7-bit US-ASCII, the UTF-8 encoding is identical to the US-ASCII encoding. UTF-8 may require multiple bytes to represent a single character / code point; thus the length of this object in octets may be different from the number of characters encoded. Similarly, size constraints refer to the number of encoded octets, not the number of characters represented by an encoding. Note that when this TC is used for an object that is used or envisioned to be used as an index, then a SIZE restriction MUST be specified so that the number of sub-identifiers for any object instance does not exceed the limit of 128, as defined by [RFC3416]. Note that the size of an SnmpAdminString object is measured in octets, not characters. SIZE (0..32) · OCTET STRING · hint 255t

The value of this object identifies the row in the ADSL2 Channel Thresholds Configuration Profile Table (adsl2ChAlarmConfProfileTable) that applies for ADSL2 bearer channel #2. The channel profile name specified here must match the name of an existing row in the adsl2ChAlarmConfProfileTable table. If the channel is unused, then the object is set to a zero-length string. ⓘ

SnmpAdminStringAn octet string containing administrative information, preferably in human-readable form. To facilitate internationalization, this information is represented using the ISO/IEC IS 10646-1 character set, encoded as an octet string using the UTF-8 transformation format described in [RFC2279]. Since additional code points are added by amendments to the 10646 standard from time to time, implementations must be prepared to encounter any code point from 0x00000000 to 0x7fffffff. Byte sequences that do not correspond to the valid UTF-8 encoding of a code point or are outside this range are prohibited. The use of control codes should be avoided. When it is necessary to represent a newline, the control code sequence CR LF should be used. The use of leading or trailing white space should be avoided. For code points not directly supported by user interface hardware or software, an alternative means of entry and display, such as hexadecimal, may be provided. For information encoded in 7-bit US-ASCII, the UTF-8 encoding is identical to the US-ASCII encoding. UTF-8 may require multiple bytes to represent a single character / code point; thus the length of this object in octets may be different from the number of characters encoded. Similarly, size constraints refer to the number of encoded octets, not the number of characters represented by an encoding. Note that when this TC is used for an object that is used or envisioned to be used as an index, then a SIZE restriction MUST be specified so that the number of sub-identifiers for any object instance does not exceed the limit of 128, as defined by [RFC3416]. Note that the size of an SnmpAdminString object is measured in octets, not characters. SIZE (0..32) · OCTET STRING · hint 255t

The value of this object identifies the row in the ADSL2 Channel Thresholds Configuration Profile Table (adsl2ChAlarmConfProfileTable) that applies for ADSL2 bearer channel #3. The channel profile name specified here must match the name of an existing row in the adsl2ChAlarmConfProfileTable table. This object may be set to a non-zero-length string only if adsl2LAlarmConfTempChan2ConfProfile contains a non-zero- length string. ⓘ

SnmpAdminStringAn octet string containing administrative information, preferably in human-readable form. To facilitate internationalization, this information is represented using the ISO/IEC IS 10646-1 character set, encoded as an octet string using the UTF-8 transformation format described in [RFC2279]. Since additional code points are added by amendments to the 10646 standard from time to time, implementations must be prepared to encounter any code point from 0x00000000 to 0x7fffffff. Byte sequences that do not correspond to the valid UTF-8 encoding of a code point or are outside this range are prohibited. The use of control codes should be avoided. When it is necessary to represent a newline, the control code sequence CR LF should be used. The use of leading or trailing white space should be avoided. For code points not directly supported by user interface hardware or software, an alternative means of entry and display, such as hexadecimal, may be provided. For information encoded in 7-bit US-ASCII, the UTF-8 encoding is identical to the US-ASCII encoding. UTF-8 may require multiple bytes to represent a single character / code point; thus the length of this object in octets may be different from the number of characters encoded. Similarly, size constraints refer to the number of encoded octets, not the number of characters represented by an encoding. Note that when this TC is used for an object that is used or envisioned to be used as an index, then a SIZE restriction MUST be specified so that the number of sub-identifiers for any object instance does not exceed the limit of 128, as defined by [RFC3416]. Note that the size of an SnmpAdminString object is measured in octets, not characters. SIZE (0..32) · OCTET STRING · hint 255t

The value of this object identifies the row in the ADSL2 Channel Thresholds Configuration Profile Table (adsl2ChAlarmConfProfileTable) that applies for ADSL2 bearer channel #4. The channel profile name specified here must match the name of an existing row in the adsl2ChAlarmConfProfileTable table. This object may be set to a non-zero-length string only if adsl2LAlarmConfTempChan3ConfProfile contains a non-zero- length string. ⓘ

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

This object is used to create a new row or to modify or delete an existing row in this table. A template is activated by setting this object to 'active'. When 'active' is set, the system will validate the template. Before a template can be deleted or taken out of service (by setting this object to 'destroy' or 'notInService'), it must first be unreferenced from all associated lines.

SnmpAdminStringAn octet string containing administrative information, preferably in human-readable form. To facilitate internationalization, this information is represented using the ISO/IEC IS 10646-1 character set, encoded as an octet string using the UTF-8 transformation format described in [RFC2279]. Since additional code points are added by amendments to the 10646 standard from time to time, implementations must be prepared to encounter any code point from 0x00000000 to 0x7fffffff. Byte sequences that do not correspond to the valid UTF-8 encoding of a code point or are outside this range are prohibited. The use of control codes should be avoided. When it is necessary to represent a newline, the control code sequence CR LF should be used. The use of leading or trailing white space should be avoided. For code points not directly supported by user interface hardware or software, an alternative means of entry and display, such as hexadecimal, may be provided. For information encoded in 7-bit US-ASCII, the UTF-8 encoding is identical to the US-ASCII encoding. UTF-8 may require multiple bytes to represent a single character / code point; thus the length of this object in octets may be different from the number of characters encoded. Similarly, size constraints refer to the number of encoded octets, not the number of characters represented by an encoding. Note that when this TC is used for an object that is used or envisioned to be used as an index, then a SIZE restriction MUST be specified so that the number of sub-identifiers for any object instance does not exceed the limit of 128, as defined by [RFC3416]. Note that the size of an SnmpAdminString object is measured in octets, not characters. SIZE (1..32) · OCTET STRING · hint 255t

This object identifies a row in this table.

HCPerfIntervalThresholdThis convention defines a range of values that may be set in a fault threshold alarm control. As the number of seconds in a 15-minute interval numbers at most 900, objects of this type may have a range of 0...900, where the value of 0 disables the alarm. (0..900) · Unsigned32 · seconds

A threshold for the adsl2PMLCurr15MFecs counter, when adsl2PMLCurrUnit is atuc(1). The value 0 means that no threshold is specified for the associated counter. ⓘ

HCPerfIntervalThresholdThis convention defines a range of values that may be set in a fault threshold alarm control. As the number of seconds in a 15-minute interval numbers at most 900, objects of this type may have a range of 0...900, where the value of 0 disables the alarm. (0..900) · Unsigned32 · seconds

A threshold for the adsl2PMLCurr15MEs counter, when adsl2PMLCurrUnit is atuc(1). The value 0 means that no threshold is specified for the associated counter. ⓘ

HCPerfIntervalThresholdThis convention defines a range of values that may be set in a fault threshold alarm control. As the number of seconds in a 15-minute interval numbers at most 900, objects of this type may have a range of 0...900, where the value of 0 disables the alarm. (0..900) · Unsigned32 · seconds

A threshold for the adsl2PMLCurr15MSes counter, when adsl2PMLCurrUnit is atuc(1). The value 0 means that no threshold is specified for the associated counter. ⓘ

HCPerfIntervalThresholdThis convention defines a range of values that may be set in a fault threshold alarm control. As the number of seconds in a 15-minute interval numbers at most 900, objects of this type may have a range of 0...900, where the value of 0 disables the alarm. (0..900) · Unsigned32 · seconds

A threshold for the adsl2PMLCurr15MLoss counter, when adsl2PMLCurrUnit is atuc(1). The value 0 means that no threshold is specified for the associated counter. ⓘ

HCPerfIntervalThresholdThis convention defines a range of values that may be set in a fault threshold alarm control. As the number of seconds in a 15-minute interval numbers at most 900, objects of this type may have a range of 0...900, where the value of 0 disables the alarm. (0..900) · Unsigned32 · seconds

A threshold for the adsl2PMLCurr15MUas counter, when adsl2PMLCurrUnit is atuc(1). The value 0 means that no threshold is specified for the associated counter. ⓘ

HCPerfIntervalThresholdThis convention defines a range of values that may be set in a fault threshold alarm control. As the number of seconds in a 15-minute interval numbers at most 900, objects of this type may have a range of 0...900, where the value of 0 disables the alarm. (0..900) · Unsigned32 · seconds

A threshold for the adsl2PMLCurr15MFecs counter, when adsl2PMLCurrUnit is atur(2). The value 0 means that no threshold is specified for the associated counter. ⓘ

HCPerfIntervalThresholdThis convention defines a range of values that may be set in a fault threshold alarm control. As the number of seconds in a 15-minute interval numbers at most 900, objects of this type may have a range of 0...900, where the value of 0 disables the alarm. (0..900) · Unsigned32 · seconds

A threshold for the adsl2PMLCurr15MEs counter, when adsl2PMLCurrUnit is atur(2). The value 0 means that no threshold is specified for the associated counter. ⓘ

HCPerfIntervalThresholdThis convention defines a range of values that may be set in a fault threshold alarm control. As the number of seconds in a 15-minute interval numbers at most 900, objects of this type may have a range of 0...900, where the value of 0 disables the alarm. (0..900) · Unsigned32 · seconds

A threshold for the adsl2PMLCurr15MSes counter, when adsl2PMLCurrUnit is atur(2). The value 0 means that no threshold is specified for the associated counter. ⓘ

HCPerfIntervalThresholdThis convention defines a range of values that may be set in a fault threshold alarm control. As the number of seconds in a 15-minute interval numbers at most 900, objects of this type may have a range of 0...900, where the value of 0 disables the alarm. (0..900) · Unsigned32 · seconds

A threshold for the adsl2PMLCurr15MLoss counter, when adsl2PMLCurrUnit is atur(2). The value 0 means that no threshold is specified for the associated counter. ⓘ

HCPerfIntervalThresholdThis convention defines a range of values that may be set in a fault threshold alarm control. As the number of seconds in a 15-minute interval numbers at most 900, objects of this type may have a range of 0...900, where the value of 0 disables the alarm. (0..900) · Unsigned32 · seconds

A threshold for the adsl2PMLCurr15MUas counter, when adsl2PMLCurrUnit is atur(2). The value 0 means that no threshold is specified for the associated counter. ⓘ

Unsigned32

A threshold for the adsl2PMLCurrInit15MfailedFullInits counter. The value 0 means that no threshold is specified for the associated counter. ⓘ

Unsigned32

A threshold for the adsl2PMLCurrInit15MFailedShortInits counter. The value 0 means that no threshold is specified for the associated counter. ⓘ

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

This object is used to create a new row or to modify or delete an existing row in this table. A profile is activated by setting this object to 'active'. When 'active' is set, the system will validate the profile. Before a profile can be deleted or taken out of service (by setting this object to 'destroy' or 'notInService'), it must first be unreferenced from all associated templates.

SnmpAdminStringAn octet string containing administrative information, preferably in human-readable form. To facilitate internationalization, this information is represented using the ISO/IEC IS 10646-1 character set, encoded as an octet string using the UTF-8 transformation format described in [RFC2279]. Since additional code points are added by amendments to the 10646 standard from time to time, implementations must be prepared to encounter any code point from 0x00000000 to 0x7fffffff. Byte sequences that do not correspond to the valid UTF-8 encoding of a code point or are outside this range are prohibited. The use of control codes should be avoided. When it is necessary to represent a newline, the control code sequence CR LF should be used. The use of leading or trailing white space should be avoided. For code points not directly supported by user interface hardware or software, an alternative means of entry and display, such as hexadecimal, may be provided. For information encoded in 7-bit US-ASCII, the UTF-8 encoding is identical to the US-ASCII encoding. UTF-8 may require multiple bytes to represent a single character / code point; thus the length of this object in octets may be different from the number of characters encoded. Similarly, size constraints refer to the number of encoded octets, not the number of characters represented by an encoding. Note that when this TC is used for an object that is used or envisioned to be used as an index, then a SIZE restriction MUST be specified so that the number of sub-identifiers for any object instance does not exceed the limit of 128, as defined by [RFC3416]. Note that the size of an SnmpAdminString object is measured in octets, not characters. SIZE (1..32) · OCTET STRING · hint 255t

This object identifies a row in this table.

Unsigned32

A threshold for the adsl2PMChCurr15MCodingViolations counter, when adsl2PMChCurrUnit is atuc(1). The value 0 means that no threshold is specified for the associated counter. ⓘ

Unsigned32

A threshold for the adsl2PMChCurr15MCorrectedBlocks counter, when adsl2PMChCurrUnit is atuc(1). The value 0 means that no threshold is specified for the associated counter. ⓘ

Unsigned32

A threshold for the adsl2PMChCurr15MCodingViolations counter, when adsl2PMChCurrUnit is atur(2). The value 0 means that no threshold is specified for the associated counter. ⓘ

Unsigned32

A threshold for the adsl2PMChCurr15MCorrectedBlocks counter, when adsl2PMChCurrUnit is atur(2). The value 0 means that no threshold is specified for the associated counter. ⓘ

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

This object is used to create a new row or to modify or delete an existing row in this table. A profile is activated by setting this object to 'active'. When 'active' is set, the system will validate the profile. Before a profile can be deleted or taken out of service (by setting this object to 'destroy' or 'notInService'), it must first be unreferenced from all associated templates.