VDSL2-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 xDSL2 Line Configuration Template Table, xdsl2LineConfTemplateTable, that applies for this 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 (0..32) · OCTET STRING · hint 255t

This object is used to identify the template that will be used if the xDSL2 line fails to operate using the primary template. The primary template is identified using the xdsl2LineConfTemplate object. For example, a xDSL2 line may fall back to a template with a lower rate if the rate specified in the primary template cannot be achieved. The value of this object identifies a row in the xDSL2 Line Configuration Template Table, xdsl2LineConfTemplateTable. Any row in the xdsl2LineConfTemplateTable table may be used as a fall-back template. If the xDSL2 line fails to operate using the fall-back template, then the primary template should be retried. The xTU-C should continue to alternate between the primary and fall-back templates until one of them succeeds. If the value of this object is a zero-length string, then no fall-back template is defined and only the primary template will be used. Note that implementation of this object is not mandatory. If this object is not supported, any attempt to modify this object should result in the SET request being rejected. 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 xDSL2 Line Alarm Configuration Template Table, xdsl2LineAlarmConfTemplateTable, which applies to this line. This object MUST be maintained in a persistent manner. ⓘ

Xdsl2ConfPmsForce0 = l3toL02 = l0toL23 = l0orL2toL3Objects with this syntax are configuration parameters that specify the desired power management state transition for the VDSL2/ADSL/ADSL2 or ADSL2+ link. In VDSL2, only L0 and L3 states are defined: 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). · Integer32

Power management state forced (PMSF). Defines the line states to be forced by the near-end xTU on this line. This object MUST be maintained in a persistent manner. ⓘ

Xdsl2LineLdsf0 = inhibit1 = forceObjects with this syntax are configuration parameters that control the Loop Diagnostic mode for a VDSL2/ADSL/ADSL2 or ADSL2+ link. The possible values are: inhibit (0) - Inhibit Loop Diagnostic mode force (1) - Force/Initiate Loop Diagnostic mode · Integer32

Loop diagnostic state forced (LDSF). Defines whether the line should be forced into the loop diagnostics mode by the near-end xTU of this line. Note that a loop diagnostic may be initiated by the far-end xTU at any time. Only when the xdsl2LineStatusPwrMngState object is in the 'l3' state and the xdsl2LineCmndConfPmsf object is in the 'l0orL2toL3' state, can the line be forced into loop diagnostic mode procedures. Upon successful completion of the loop diagnostic mode procedures, the Access Node shall set this object to 'inhibit', and xdsl2LineStatusPwrMngState will remain in the 'l3' state. The loop diagnostic data shall be available at least until xdsl2LineCmndConfPmsf is set to the 'l3toL0' state. The results of the loop diagnostic procedure are stored in the tables xdsl2SCStatusTable, xdsl2SCStatusBandTable, and xdsl2SCStatusSegmentTable. The status of the loop diagnostic procedure is indicated by xdsl2LineCmndConfLdsfFailReason. As long as loop diagnostic procedures are not completed successfully, attempts shall be made to do so, until the loop diagnostic mode is no longer forced on the line through this configuration parameter. ⓘ

Xdsl2LdsfResult1 = none2 = success3 = inProgress4 = unsupported5 = cannotRun6 = aborted7 = failed8 = illegalMode9 = adminUp10 = tableFull11 = noResourcesPossible failure reasons associated with performing 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 most recent occasion when the loop diagnostics state forced (LDSF) command was issued for the associated line.

Xdsl2LineBpsc1 = idle2 = measureObjects with this syntax are configuration parameters that control the bits per subcarrier measurement for a VDSL2/ADSL/ADSL2 or ADSL2+ link. The possible values are: idle (1) - Idle state measure (2) - Measure the bits per subcarrier · Integer32

Request a bits-per-subcarrier measurement to be made. A request for a bits-per-subcarrier measurement is made by setting this object to the value of 'measure'. Upon completion of the measurement request, the Access Node shall set this object to 'idle'. The SNMP agent should allow initiating a bits-per-subcarrier measurement process only if there is no other bits-per-subcarrier measurement already running, and respond with an SNMP error (e.g., wrongValue) otherwise. Note that a bits-per-subcarrier measurement is also performed during a line diagnostic procedure. This object provides an additional mechanism to fetch the bits-per-subcarrier data. This additional mechanism is provided so that bits-per-subcarrier data may be fetched without forcing the line into no power state. This is useful because the bits-per-subcarrier allocation may be adjusted at show time due to rate adaption and bit swapping. The implementation of this additional mechanism for measuring bits per subcarrier is not mandatory. The results of the bits-per-subcarrier measurement are stored in xdsl2LineSegmentTable. The status of the bits-per-subcarrier measurement is indicated by xdsl2LineCmndConfBpscFailReason.

Xdsl2BpscResult1 = none2 = success3 = inProgress4 = unsupported5 = failed6 = noResourcesPossible failure reasons associated with performing a bits per subcarrier measurement on a DSL line. Possible values are: none (1) - The default value, in case a measurement was never requested for the associated line. success (2) - The recent measurement request completed successfully. inProgress (3) - The bits per subcarrier measurement is in progress. unsupported (4) - The bits per subcarrier request mechanism is not supported. failed (5) - The measurement request has failed and no results are available. noResources (6) - The NE cannot initiate the command, due to lack of internal memory resources. · Integer32

The status of the most recent bits-per-subcarrier measurement request issued for the associated line.

Counter32

Measurement request counter. This counter is incremented by one every time a request for a bits-per-subcarrier measurement is made. A measurement request is made by modifying the xdsl2LineCmndConfBpsc object from idle(1) to the value measure(2). The measurement results may be very large and will not fit into a single PDU; hence, multiple SNMP GET requests may be required to fetch the measurement results. Because the measurement results cannot be fetched atomically, it is possible for a second manager to start a new measurement before a first manager has fetched all of its results. An SNMP manager can use this object to ensure that the measurement results retrieved using one or more GET requests all belong to the measurement initiated by that manager. The following steps are suggested in order for the SNMP manager to initiate the bits-per-subcarrier measurement: 1. Wait for xdsl2LineCmndConfBpsc value to be idle(1). 2. Perform an SNMP GET for xdsl2LineCmndConfBpscRequests. 3. Wait a short delay (4 -> 8 seconds). 4. Perform an SNMP SET on xdsl2LineCmndConfBpsc with the value measure(2). 5. If step 4 returns an error, then go to step 1. 6. Wait for xdsl2LineCmndConfBpsc value to be idle(1). 7. Fetch measurement results using one or more GET PDUs. 8. Perform an SNMP GET for xdsl2LineCmndConfBpscRequests. 9. Compute the difference between the two values of xdsl2LineCmndConfBpscRequests. If the value is one, then the results are valid, else go to step 1.

TruthValue1 = true2 = falseRepresents a boolean value. · Integer32

Automode cold start forced. This parameter is defined in order to improve testing of the performance of xTUs supporting automode when it is enabled in the MIB. Change the value of this parameter to 'true' to indicate a change in loop conditions applied to the devices under the test. The xTUs 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 xdsl2LConfProfXtuTransSysEna object in the line configuration profile being used for the line, and where the selection of the actual operation-mode depends not only on the common capabilities of both xTUs (as exchanged in G.994.1), but also on achievable data rates under given loop conditions. ⓘ

Xdsl2LineReset1 = idle2 = resetThis type is used to request a line reset to occur. idle (1) - This state indicates that there is currently no request for a line reset. reset (2) - This state indicates that a line reset request has been issued. · Integer32

Request a line reset to occur. If this object is set to the value of 'reset', then force the line to reset (i.e., the modems will retrain). When the line has successfully reset, the SNMP agent will set the value of this object to 'idle'. Note that the xdsl2LineCmndConfPmsf object will always take precedence over this object. If the xdsl2LineCmndConfPmsf object is set to the value 'l0orL2toL3', then the line MUST NOT return to the Showtime state due to a reset request action performed using this object.

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

This object is used to identify the template that is currently in use for this line. This object is updated when a successful line initialization occurs. This object indicates if the primary template (xdsl2LineConfTemplate) is in use or the fall-back template (xdsl2LineConfFallbackTemplate) is in use. If the line is not successfully initialized, then the value of this object will be a zero-length string.

Xdsl2TransmissionModeTypeA set of xDSL 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 Bit 56 : G.993.2 Annex A Bit 57 : G.993.2 Annex B Bit 58 : G.993.2 Annex C Bit 59-63: Reserved · BITS

The xTU Transmission System (xTS) in use. It is coded in a bitmap representation with one bit set to '1' (the selected coding for the DSL line). This parameter may be derived from the handshaking procedures defined in Recommendation G.994.1. A set of xDSL line transmission modes, with one bit per mode. ⓘ

Xdsl2PowerMngState1 = l02 = l13 = l24 = l3Objects with this syntax uniquely identify each power management state defined for the VDSL2/ADSL/ADSL2 or ADSL2+ link. In VDSL2, only L0 and L3 states are defined. The possible values are: l0(1) - L0: Full power. Synchronized and full transmission (i.e., Showtime). l1(2) - L1: Low power with reduced net data rate (for G.992.2 only). l2(3) - L2: Low power with reduced net data rate (for G.992.3, G.992.4 and G.992.5). l3(4) - L3: Idle power management state / No power. · Integer32

The current power management state. ⓘ

Xdsl2InitResult0 = noFail1 = configError2 = configNotFeasible3 = commFail4 = noPeerAtu5 = otherCauseSpecifies the result of 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 · Integer32

Indicates the result of the last full initialization performed on the line. ⓘ

Xdsl2LastTransmittedState0 = 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 = aturShowtime200 = vtucG9941201 = vtucQuiet1202 = vtucChDiscov1203 = vtucSynchro1204 = vtucPilot1205 = vtucQuiet2206 = vtucPeriodic1207 = vtucSynchro2208 = vtucChDiscov2209 = vtucSynchro3210 = vtucTraining1211 = vtucSynchro4212 = vtucPilot2213 = vtucTeq214 = vtucEct215 = vtucPilot3216 = vtucPeriodic2217 = vtucTraining2218 = vtucSynchro5219 = vtucMedley220 = vtucSynchro6221 = vtucShowtime300 = vturG9941301 = vturQuiet1302 = vturChDiscov1303 = vturSynchro1304 = vturLineprobe305 = vturPeriodic1306 = vturSynchro2307 = vturChDiscov2308 = vturSynchro3309 = vturQuiet2310 = vturTraining1311 = vturSynchro4312 = vturTeq313 = vturQuiet3314 = vturEct315 = vturPeriodic2316 = vturTraining2317 = vturSynchro5318 = vturMedley319 = vturSynchro6320 = vturShowtimeThis parameter represents the last successful 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. ⓘ

Xdsl2LastTransmittedState0 = 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 = aturShowtime200 = vtucG9941201 = vtucQuiet1202 = vtucChDiscov1203 = vtucSynchro1204 = vtucPilot1205 = vtucQuiet2206 = vtucPeriodic1207 = vtucSynchro2208 = vtucChDiscov2209 = vtucSynchro3210 = vtucTraining1211 = vtucSynchro4212 = vtucPilot2213 = vtucTeq214 = vtucEct215 = vtucPilot3216 = vtucPeriodic2217 = vtucTraining2218 = vtucSynchro5219 = vtucMedley220 = vtucSynchro6221 = vtucShowtime300 = vturG9941301 = vturQuiet1302 = vturChDiscov1303 = vturSynchro1304 = vturLineprobe305 = vturPeriodic1306 = vturSynchro2307 = vturChDiscov2308 = vturSynchro3309 = vturQuiet2310 = vturTraining1311 = vturSynchro4312 = vturTeq313 = vturQuiet3314 = vturEct315 = vturPeriodic2316 = vturTraining2317 = vturSynchro5318 = vturMedley319 = vturSynchro6320 = vturShowtimeThis parameter represents the last successful 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. ⓘ

Xdsl2LineStatusObjects with this syntax are status parameters that reflect the failure status for a given endpoint of a VDSL2/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 exist. lossOfFraming (1) - Loss of frame synchronization. lossOfSignal (2) - Loss of signal. lossOfPower (3) - Loss of power. Usually this failure may be reported for CPE units only. initFailure (4) - Recent initialization process failed. Never active on xTU-R. · BITS

Indicates the current state (existing failures) of the xTU-R. This is a bitmap of possible conditions. ⓘ

Xdsl2LineStatusObjects with this syntax are status parameters that reflect the failure status for a given endpoint of a VDSL2/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 exist. lossOfFraming (1) - Loss of frame synchronization. lossOfSignal (2) - Loss of signal. lossOfPower (3) - Loss of power. Usually this failure may be reported for CPE units only. initFailure (4) - Recent initialization process failed. Never active on xTU-R. · BITS

Indicates the current state (existing failures) of the xTU-C. This is a bitmap of possible conditions. ⓘ

Unsigned32 · bits/second

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

Unsigned32 · bits/second

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

Integer32 (-900..0 | 2147483647) · 0.1 dBm/Hz

Actual Power Spectral Density (PSD) Downstream. The average downstream transmit PSD over the subcarriers used for downstream. It ranges from -900 to 0 units of 0.1 dBm/Hz (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 dBm/Hz

Actual Power Spectral Density (PSD) Upstream. The average upstream transmit PSD over the subcarriers used for upstream. It ranges from -900 to 0 units of 0.1 dBm/Hz (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 dBm

Actual Aggregate Transmit Power Downstream. The total amount of transmit power delivered by the xTU-C at the U-C reference point, at the instant of measurement. It ranges from -310 to 310 units of 0.1 dBm (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 dBm

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

Xdsl2LineProfilesObjects with this syntax reference the list of ITU-T G.993.2 implementation profiles supported by an xTU, enabled on the VDSL2 line or active on that line. · BITS

The G.993.2 profile in use. The configuration parameter xdsl2LConfProfProfiles defines the set of allowed G.993.2 profiles. This parameter indicates the profile in use on this line. This parameter may be derived from the handshaking procedures defined in ITU-T Recommendation G.994.1. ⓘ

Xdsl2LineLimitMaskThe G.993.2 limit PSD mask for each class of profile. The profiles are grouped in following profile classes: - Class 8: Profiles 8a, 8b, 8c, 8d. - Class 12: Profiles 12a, 12b. - Class 17: Profile 17a. - Class 30: Profile 30a. · BITS

The Limit PSD mask and band plan in use. The configuration parameter xdsl2LConfProfLimitMask defines the set of allowed G.993.2 limit PSD masks. This parameter indicates the limit PSD mask in use on this line. ⓘ

Xdsl2LineUs0MaskThe US0 PSD masks to be allowed by the near-end xTU on the line. This parameter is only defined for G.993.2 Annex A. It is represented as a bitmap (0 if not allowed and 1 if allowed) with the following definitions. · BITS

The US0 PSD mask in use. The configuration parameter xdsl2LConfProfUs0Mask defines the set of allowed US0 PSD masks. This parameter indicates the US0 PSD mask in use on this line. This parameter may be derived from the handshaking procedures defined in ITU-T Recommendation G.994.1. ⓘ

Xdsl2LineSnrMode1 = virtualNoiseDisabled2 = virtualNoiseEnabledThis type is used to enable the transmitter-referred virtual noise. The value of 1, indicates that virtual noise is disabled. The value of 2, indicates that virtual noise is enabled. virtualNoiseDisabled (1) - virtual noise is disabled. virtualNoiseEnabled (2) - virtual noise is enabled. · Integer32

This parameter indicates if the transmitter-referred virtual noise is active on the line in the downstream direction. The configuration parameter xdsl2LConfProfSnrModeDs is used to configure referred virtual noise. ⓘ

Xdsl2LineSnrMode1 = virtualNoiseDisabled2 = virtualNoiseEnabledThis type is used to enable the transmitter-referred virtual noise. The value of 1, indicates that virtual noise is disabled. The value of 2, indicates that virtual noise is enabled. virtualNoiseDisabled (1) - virtual noise is disabled. virtualNoiseEnabled (2) - virtual noise is enabled. · Integer32

This parameter indicates if the transmitter-referred virtual noise is active on the line in the upstream direction. The configuration parameter xdsl2LConfProfSnrModeUs is used to configure referred virtual noise. ⓘ

Unsigned32 (0..1280) · 0.1 dB

This parameter contains the estimated electrical length expressed in dB at 1 MHz, kl0. This is the final electrical length that would have been sent from the VTU-O to VTU-R if the electrical length was not forced by the CO-MIB. The value ranges from 0 to 128 dB in steps of 0.1 dB. ⓘ

Xdsl2TssiThis is a structure that represents up to 32 transmit spectrum shaping (TSSi) breakpoints. 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. The shaping parameter value is in the range 0 to 126 (units of -0.5 dB). The special value 127 indicates that the subcarrier is not transmitted. The subcarrier index is an unsigned number in the range 0 to NSC-1. SIZE (0..96) · OCTET STRING

The transmit spectrum shaping (TSSi) breakpoints expressed as the set of breakpoints exchanged during G.994.1 (Downstream). ⓘ

Xdsl2TssiThis is a structure that represents up to 32 transmit spectrum shaping (TSSi) breakpoints. 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. The shaping parameter value is in the range 0 to 126 (units of -0.5 dB). The special value 127 indicates that the subcarrier is not transmitted. The subcarrier index is an unsigned number in the range 0 to NSC-1. SIZE (0..96) · OCTET STRING

The transmit spectrum shaping (TSSi) breakpoints expressed as the set of breakpoints exchanged during G.994.1 (Upstream). ⓘ

Xdsl2MrefPsdDsObjects with this syntax are MEDLEY Reference PSD status parameters in the downstream direction. This is expressed as the set of breakpoints exchanged at initialization. The OCTET STRING contains up to 48 pairs of values in the following structure: Octets 0-1 -- Index of the first subcarrier used in the context of a first breakpoint. Octets 2-3 -- The PSD level for the subcarrier indicated in octets 0-1. Octets 4-7 -- Same, for a second breakpoint Octets 8-11 -- Same, for a third breakpoint And so on until Octets 188-191 -- Same, for a 48th breakpoint. The subcarrier index is an unsigned number in the range 0 to NSCds-1. The PSD level is an integer value in the 0 to 4095 range. It is represented in units of 0.1 dB offset from -140 dBm/Hz. SIZE (0..192) · OCTET STRING

The MEDLEY Reference PSD status parameters in the downstream direction expressed as the set of breakpoints exchanged at initialization. ⓘ

Xdsl2MrefPsdUsObjects with this syntax are MEDLEY Reference PSD status parameters in the upstream direction. This is expressed as the set of breakpoints exchanged at initialization. The OCTET STRING contains up to 32 pairs of values in the following structure: Octets 0-1 -- Index of the first subcarrier used in the context of a first breakpoint. Octets 2-3 -- The PSD level for the subcarrier indicated in octets 0-1. Octets 4-7 -- Same, for a second breakpoint Octets 8-11 -- Same, for a third breakpoint And so on until Octets 124-127 -- Same, for a 32nd breakpoint. The subcarrier index is an unsigned number in the range 0 to NSCus-1. The PSD level is an integer value in the 0 to 4095 range. It is represented in units of 0.1 dB offset from -140 dBm/Hz. SIZE (0..128) · OCTET STRING

The MEDLEY Reference PSD status parameters in the upstream direction expressed as the set of breakpoints exchanged at initialization. ⓘ

TruthValue1 = true2 = falseRepresents a boolean value. · Integer32

This parameter reports whether trellis coding is in use in the downstream direction. ⓘ

TruthValue1 = true2 = falseRepresents a boolean value. · Integer32

This parameter reports whether trellis coding is in use in the upstream direction. ⓘ

Unsigned32 (2..16) · N/32 samples

(ACTUALCE) This parameter reports the cyclic extension used on the line. It is coded as an unsigned integer from 2 to 16 in units of N/32 samples, where 2N is the Inverse Discrete Fourier Transform (IDFT) size. ⓘ

Xdsl2Band1 = upstream2 = downstream3 = us04 = ds15 = us16 = ds27 = us28 = ds39 = us310 = ds411 = us4Identifies a band in a VDSL2/ADSL/ADSL2/ADSL2+ link. For a band in the upstream direction, transmission is from the remote end (xTU-R) towards the central office end (xTU-C). For a band in the downstream direction, transmission is from the xTU-C towards the xTU-R. For ADSL, ADSL2 and ADSL2+, which use a single band in the upstream direction and a single band in the downstream direction, the only relevant values are upstream(1) and downstream(2). For VDSL2, which uses multiple bands in each transmission direction, a band in the upstream direction is indicated by any of us0(3), us1(5), us2(7), us3(9), or us4(11), and a band in the downstream direction is indicated by any of ds1(4), ds2(6), ds3(8), or ds4(10). For VDSL2, the values upstream(1) and downstream(2) may be used when there is a need to refer to the whole upstream or downstream traffic (e.g., report the average signal-to-noise ratio on any transmission direction). Specified as an INTEGER, the values are defined as follows: · Integer32

Identifies the band(s) associated with this line. For ADSL/ADSL2/ADSL2+, the values 'upstream' and 'downstream' will always be present. For VDSL2, a subset of {'us0', 'ds1', 'us1' ... 'ds4', 'us4' } will always be present, together with rows for 'upstream' and 'downstream', in which only the xdsl2LineBandStatusSnrMargin object is expected to hold a valid (average) measurement.

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

Line Attenuation. When referring to a band in the downstream direction, it is the measured difference in the total power transmitted by the xTU-C and the total power received by the xTU-R over all subcarriers of that band during initialization. When referring to a band in the upstream direction, it is the measured difference in the total power transmitted by the xTU-R and the total power received by the xTU-C over all subcarriers of that band during initialization. Values range from 0 to 1270 in 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. ⓘ

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

Signal Attenuation. When referring to a band in the downstream direction, it is the measured difference in the total power transmitted by the xTU-C and the total power received by the xTU-R over all subcarriers of that band during Showtime. When referring to a band in the upstream direction, it is the measured difference in the total power transmitted by the xTU-R and the total power received by the xTU-C over all subcarriers of that band during Showtime. Values range from 0 to 1270 in 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. ⓘ

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

SNR Margin is the maximum increase in dB of the noise power received at the xTU (xTU-R for a band in the downstream direction and xTU-C for a band in the upstream direction), such that the BER requirements are met for all bearer channels received at the xTU. Values range from -640 to 630 in 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. ⓘ

Xdsl2Direction1 = upstream2 = downstreamIdentifies the direction of a band in a VDSL2/ADSL/ADSL2/ ADSL2+ link. The upstream direction is a transmission from the remote end (xTU-R) towards the central office end (xTU-C). The downstream direction is a transmission from the xTU-C towards the xTU-R. Specified as an INTEGER, the values are defined as follows: · Integer32

The direction of the subcarrier either upstream or downstream.

Unsigned32 (1..8)

The segment of the subcarriers status information provided by this row. Status parameters in this table are retrieved in segments. The first segment of the status information is retrieved with xdsl2LineSegment=1, the second segment is retrieved with xdsl2LineSegment=2, and so on. When a status parameter is retrieved in n segments where n<8) then, for that parameter, GET operations for the remaining segment numbers (n+1 to 8) will respond with a zero-length OCTET STRING.

Xdsl2BitsAllocThis type specifies an array of nibbles, where each nibble indicates the bits allocation for a subcarrier. Each nibble has a value in the range 0 to 15 to indicate the bits allocation. SIZE (0..256) · OCTET STRING · bits

The bits allocation per subcarrier. An array of 256 octets (512 nibbles), designed for supporting up to 512 (downstream) subcarriers. When more than 512 subcarriers are supported, the status information is reported through multiple (up to 8) segments. The first segment is then used for the first 512 subcarriers. The second segment is used for the subcarriers 512 to 1023 and so on. The aggregate number of utilized nibbles in the downstream direction (in all segments) depends on NSds; in the upstream direction, it depends on NSus. This value is referred to here as NS. The segment number is in xdsl2SCStatusSegment. Nibble i (0 <= i < MIN((NS+1)-(segment-1)*512,512)) in each segment is set to a value in the range 0 to 15 to indicate that the respective downstream or upstream subcarrier j (j=(segement-1)*512+i) has the same amount of bits allocation. ⓘ

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 SNMP agent will create a row in this table for storing the results of a measurement performed on the associated line, if the row does not already exist. The SNMP manager is not permitted to create rows in this table or set the row status to 'notInService'. In the first case, if the SNMP manager tries to create a new row, the SNMP agent responds with the value 'noCreation' in the error status field of the response-PDU. In the latter case, the SNMP agent responds with the value 'wrongValue' in the error status field of the response-PDU. The SNMP agent may have limited resources; therefore, if multiple rows coexist in this table, it may fail to add new rows to this table or allocate memory resources. If that occurs, the SNMP agent responds with the value 'noResources' (for the xdsl2LineCmndConfBpscFailReason object in xdsl2LineTable). The management system (the operator) may delete rows from this table according to any scheme. For example, after retrieving the results. When the SNMP manager deletes any row in this table, the SNMP agent MUST delete all rows in this table that have the same ifIndex value.

Xdsl2Unit1 = xtuc2 = xturIdentifies a transceiver as being either xTU-C or xTU-R. A VDSL2/ADSL/ADSL2 or ADSL2+ line consists of two transceivers: an xTU-C and an xTU-R. In the case of ADSL/ADSL2 and ADSL2+, those two transceivers are also called atuc and atur. In the case of VDSL2, those two transceivers are also called vtuc and vtur. Specified as an INTEGER, the two values are: xtuc(1) -- central office transceiver xtur(2) -- remote site transceiver · Integer32

The termination unit.

Unsigned32 · bits/second

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

Unsigned32 · 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 bit/s. ⓘ

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). ⓘ

Unsigned32 (0..255) · 0.1 symbols

Actual impulse noise protection. This parameter reports the actual impulse noise protection (INP) on the bearer channel in the L0 state. In the L1 or L2 state, the parameter contains the INP in the previous L0 state. For ADSL, this value is computed according to the formula specified in the relevant Recommendation based on the actual framing parameters. For ITU-T Recommendation G.993.2, the method to report this value is according to the INPREPORT parameter. The value is coded in fractions of DMT symbols with a granularity of 0.1 symbols. The range is from 0 to 25.4. The special value of 255 indicates an ACTINP higher than 25.4. ⓘ

Xdsl2ChInpReport1 = inpComputedUsingFormula2 = inpEstimatedByXturThis type is used to indicate the method used to compute the Actual Impulse Noise Protection (ACTINP). If set to 'inpComputedUsingFormula', the ACTINP is computed according to the INP_no_erasure formula (9.6/G.993.2). If set to 'inpEstimatedByXtur', the ACTINP is the value estimated by the xTU receiver. inpComputedUsingFormula (1) - ACTINP computed using INP_no_erasure formula. inpEstimatedByXtur (2) - ACTINP estimated by the xTU receiver. · Integer32

Impulse noise protection reporting mode. ⓘ

Unsigned32 (0..255) · bytes

Actual size of Reed-Solomon codeword. This parameter reports the actual number of Reed-Solomon redundancy bytes per codeword used in the latency path in which the bearer channel is transported. The value is coded in bytes. It ranges from 0 to 16. The value 0 indicates no Reed-Solomon coding. ⓘ

Unsigned32 (0..16) · bits

Actual number of Reed-Solomon redundancy bytes. This parameter reports the actual number of Reed-Solomon redundancy bytes per codeword used in the latency path in which the bearer channel is transported. The value is coded in bytes. It ranges from 0 to 16. The value 0 indicates no Reed-Solomon coding. ⓘ

Unsigned32 (0..65535) · bits

Actual number of bits per symbol. This parameter reports the actual number of bits per symbol assigned to the latency path in which the bearer channel is transported. This value does not include trellis overhead. The value is coded in bits. It ranges from 0 to 65535. ⓘ

Unsigned32 (1..4096)

Actual interleaving depth. This parameter reports the actual depth of the interleaver used in the latency path in which the bearer channel is transported. The value ranges from 1 to 4096 in steps of 1. The value 1 indicates no interleaving. ⓘ

Unsigned32 (4..255)

Actual interleaving block length. This parameter reports the actual block length of the interleaver used in the latency path in which the bearer channel is transported. The value ranges from 4 to 255 in steps of 1. ⓘ

Unsigned32 (0..3)

Actual latency path. This parameter reports the index of the actual latency path in which the bearer is transported. The valid values are 0, 1, 2 and 3. For G.992.1, the FAST path shall be mapped to the latency index 0, and the INTERLEAVED path shall be mapped to the latency index 1. ⓘ

Xdsl2ChAtmStatusObjects with this syntax are status parameters that reflect the failure status for the Transmission Convergence (TC) layer of a given ATM interface (data path over a VDSL2/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 current state (existing failures) of the DSL channel in case its Data Path is ATM. This is a bitmap of possible conditions. In case the channel is not of ATM Data Path, the object is set to '0'. ⓘ

Xdsl2ChPtmStatusObjects with this syntax are status parameters that reflect the failure status for a given PTM interface (packet data path over a VDSL2/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 current state (existing failures) of the DSL channel in case its Data Path is PTM (Packet Transfer Mode). This is a bitmap of possible conditions. In case the channel is not of PTM Data Path, the object is set to '0'. ⓘ

Xdsl2Direction1 = upstream2 = downstreamIdentifies the direction of a band in a VDSL2/ADSL/ADSL2/ ADSL2+ link. The upstream direction is a transmission from the remote end (xTU-R) towards the central office end (xTU-C). The downstream direction is a transmission from the xTU-C towards the xTU-R. Specified as an INTEGER, the values are defined as follows: · Integer32

The direction of the subcarrier either upstream or downstream.

Unsigned32 (1..65535)

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. It is represented as an unsigned integer in the range from 1 to 2^16-1. ⓘ

Unsigned32 (1 | 2 | 4 | 8)

Number of subcarriers per group used to report the H(f) linear representation values for the respective transmission direction. The valid values are 1, 2, 4, and 8. For ADSL, this parameter is equal to one and, for VDSL2, it is equal to the size of a subcarrier group used to compute these parameters. This parameter is only available after a loop diagnostic procedure. ⓘ

Unsigned32 (1..65535)

This parameter contains the number of symbols used to measure the Hlog(f) values. It is represented as an unsigned integer in the range from 1 to 2^16-1. After a loop diagnostic procedure, this parameter shall contain the number of symbols used to measure the Hlog(f). It should correspond to the value specified in the Recommendation (e.g., the number of symbols in 1 s time interval for ITU-T Recommendation. G.992.3). ⓘ

Unsigned32 (1 | 2 | 4 | 8)

Number of subcarriers per group used to report the H(f) logarithmic representation values for the respective transmission direction. The valid values are 1, 2, 4, and 8. For ADSL, this parameter is equal to 1, and for VDSL2, it is equal to the size of a subcarrier group used to compute these parameters. ⓘ

Unsigned32 (1..65535)

This parameter contains the number of symbols used to measure the QLN(f) values. It is an unsigned integer in the range from 1 to 2^16-1. After a loop diagnostic procedure, this parameter shall contain the number of symbols used to measure the QLN(f). It should correspond to the value specified in the Recommendation (e.g., the number of symbols in 1 s time interval for ITU-T Recommendation G.992.3). ⓘ

Unsigned32 (1 | 2 | 4 | 8)

Number of subcarriers per group used to report the Quiet Line Noise values for the respective transmission direction. The valid values are 1, 2, 4, and 8. For ADSL, this parameter is equal to 1, and for VDSL2, it is equal to the size of a subcarrier group used to compute these parameters. ⓘ

Unsigned32 (1..65535) · symbols

This parameter contains the number of symbols used to measure the SNR(f) values. It is an unsigned integer in the range from 1 to 2^16-1. After a loop diagnostic procedure, this parameter shall contain the number of symbols used to measure the SNR(f). It should correspond to the value specified in the Recommendation (e.g., the number of symbols in 1 s time interval for ITU-T Recommendation G.992.3). ⓘ

Unsigned32 (1 | 2 | 4 | 8)

Number of subcarriers per group used to report the SNR values on the respective transmission direction. The valid values are 1, 2, 4, and 8. For ADSL, this parameter is equal to 1, and for VDSL2, it is equal to the size of a subcarrier group used to compute these parameters. ⓘ

Unsigned32 · bits/second

Maximum Attainable Data Rate. The maximum net data rate currently attainable by the xTU-C transmitter and xTU-R receiver (when referring to downstream direction) or by the xTU-R transmitter and xTU-C receiver (when referring to upstream direction). Value is coded in bits/s. 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 SNMP agent will create a row in this table for storing the results of a DELT performed on the associated line, if the row does not already exist. When a row is created in this table, the SNMP agent should also create corresponding rows in the tables xdsl2SCStatusBandTable and xdsl2SCStatusSegmentTable. The SNMP manager is not permitted to create rows in this table or set the row status to 'notInService'. In the first case, if the SNMP manager tries to create a new row, the SNMP agent responds with the value 'noCreation' in the error status field of the response-PDU. In the latter case the SNMP agent responds with the value 'wrongValue' in the error status field of the response-PDU. When a row is deleted in this table, the SNMP agent should also delete corresponding rows in the tables xdsl2SCStatusBandTable and xdsl2SCStatusSegmentTable. The SNMP agent may have limited resources; therefore, if multiple rows coexist in this table, it may fail to add new rows to this table or allocate memory resources for a new DELT process. If that occurs, the SNMP agent responds with either the value 'tableFull' or the value 'noResources' (for the xdsl2LineCmndConfLdsfFailReason object in xdsl2LineTable). The management system (the operator) may delete rows from this table according to any scheme. For example, after retrieving the results.

Xdsl2Band1 = upstream2 = downstream3 = us04 = ds15 = us16 = ds27 = us28 = ds39 = us310 = ds411 = us4Identifies a band in a VDSL2/ADSL/ADSL2/ADSL2+ link. For a band in the upstream direction, transmission is from the remote end (xTU-R) towards the central office end (xTU-C). For a band in the downstream direction, transmission is from the xTU-C towards the xTU-R. For ADSL, ADSL2 and ADSL2+, which use a single band in the upstream direction and a single band in the downstream direction, the only relevant values are upstream(1) and downstream(2). For VDSL2, which uses multiple bands in each transmission direction, a band in the upstream direction is indicated by any of us0(3), us1(5), us2(7), us3(9), or us4(11), and a band in the downstream direction is indicated by any of ds1(4), ds2(6), ds3(8), or ds4(10). For VDSL2, the values upstream(1) and downstream(2) may be used when there is a need to refer to the whole upstream or downstream traffic (e.g., report the average signal-to-noise ratio on any transmission direction). Specified as an INTEGER, the values are defined as follows: · Integer32

The transmission band.

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

When referring to a band in the downstream direction, it is the measured difference in the total power transmitted by the xTU-C and the total power received by the xTU-R over all subcarriers during diagnostics mode. When referring to a band in the upstream direction, it is the measured difference in the total power transmitted by the xTU-R and the total power received by the xTU-C over all subcarriers 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 a band in the downstream direction, it is the measured difference in the total power transmitted by the xTU-C and the total power received by the xTU-R over all subcarriers during Showtime after the diagnostics mode. When referring to the upstream direction, it is the measured difference in the total power transmitted by the xTU-R and the total power received by the xTU-C over all subcarriers 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 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 (1..8)

The segment of the subcarriers status information provided by this row. Several status parameters in this table are retrieved in segments. The first segment of the status information is retrieved with xdsl2SCStatusSegment=1, the second segment is retrieved with xdsl2SCStatusSegment=2, and so on. When any status parameter is retrieved in n segments where n<8), then for that parameter, GET operations for the remaining segment numbers (n+1 to 8) will respond with a zero-length OCTET STRING.

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) subcarrier groups and can be retrieved in a single segment. The number of utilized values in the downstream direction depends on NSds; in the upstream direction, it depends on NSus. This value is referred to here as NS. Each array entry represents the real component (referred to here as a(i)) of Hlin(f = i*Df) value for a particular subcarrier group index i (0 <= i <= NS). Hlin(f) is represented as ((scale/2^15)*((a(i)+j*b(i))/2^15)), where scale is xdsl2SCStatusLinScale and a(i) and b(i) (provided by the xdsl2SCStatusSegmentLinImg 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 group 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) subcarrier groups and can be retrieved in a single segment. The number of utilized values in the downstream direction depends on NSds; in the upstream direction, it depends on NSus. This value is referred to here as NS. Each array entry represents the imaginary component (referred to here as b(i)) of Hlin(f = i*Df) value for a particular subcarrier group index i (0 <= i <= NS). Hlin(f) is represented as ((scale/2^15)*((a(i)+j*b(i))/2^15)), where scale is xdsl2SCStatusLinScale and a(i) (provided by the xdsl2SCStatusSegmentLinReal 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 group 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) · dB

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) subcarrier groups and can be retrieved in a single segment. The number of utilized values in the downstream direction depends on NSds; in the upstream direction, it depends on NSus. This value is referred to here as NS. Each array entry represents the real Hlog(f = i*Df) value for a particular subcarrier group index i, (0 <= i <= NS). 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 group 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. ⓘ

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) subcarrier groups and can be retrieved in a single segment. The number of utilized values in the downstream direction depends on NSds; in the upstream direction, it depends on NSus. This value is referred to here as NS. Each array entry represents the QLN(f = i*Df) value for a particular subcarrier index i, (0 <= i <= NS). 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 group 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. ⓘ

OCTET STRING SIZE (0..512) · 0.5 dB

The SNR Margin per subcarrier group, expressing the ratio between the received signal power and received noise power per subscriber group. It is an array of 512 octets, designed for supporting up to 512 (downstream) subcarrier groups and can be retrieved in a single segment. The number of utilized octets in the downstream direction depends on NSds; in the upstream direction, it depends on NSus. This value is referred to here as NS. Octet i (0 <= i <= NS) is set to a value in the range 0 to 254 to indicate that the respective downstream or upstream subcarrier group i has an SNR of: (-32 + xdsl2SCStatusSegmentSnr(i)/2) in dB (i.e., -32 to 95 dB). The special value 255 means that no measurement could be done for the subcarrier group 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. ⓘ

Xdsl2BitsAllocThis type specifies an array of nibbles, where each nibble indicates the bits allocation for a subcarrier. Each nibble has a value in the range 0 to 15 to indicate the bits allocation. SIZE (0..256) · OCTET STRING · bits

The bits allocation per subcarrier. An array of 256 octets (512 nibbles) designed for supporting up to 512 (downstream) subcarriers. When more than 512 subcarriers are supported, the status information is reported through multiple (up to 8) segments. The first segment is then used for the first 512 subcarriers. The second segment is used for the subcarriers 512 to 1023 and so on. The aggregate number of utilized nibbles in the downstream direction (in all segments) depends on NSds; in the upstream direction, it depends on NSus. This value is referred to here as NS. The segment number is in xdsl2SCStatusSegment. Nibble i (0 <= i < MIN((NS+1)-(segment-1)*512,512)) in each segment is set to a value in the range 0 to 15 to indicate that the respective downstream or upstream subcarrier j (j=(segement-1)*512+i) has the same amount of bits allocation. ⓘ

OCTET STRING SIZE (0..1024)

The gain allocation per subcarrier. An array of 512 16-bit values, designed for supporting up to 512 (downstream) subcarriers. When more then 512 subcarriers are supported, the status information is reported through multiple (up to 8) segments. The first segment is then used for the first 512 subcarriers. The second segment is used for the subcarriers 512 to 1023 and so on. The aggregate number of utilized octets in the downstream direction depends on NSds; in the upstream direction, it depends on NSus. This value is referred to here as NS. The segment number is in xdsl2SCStatusSegment. Value i (0 <= i < MIN((NS+1)-(segment-1)*512,512)) in each segment is set to a value in the range 0 to 4093 to indicate that the respective downstream or upstream subcarrier j (j=(segement-1)*512+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. ⓘ

Xdsl2Unit1 = xtuc2 = xturIdentifies a transceiver as being either xTU-C or xTU-R. A VDSL2/ADSL/ADSL2 or ADSL2+ line consists of two transceivers: an xTU-C and an xTU-R. In the case of ADSL/ADSL2 and ADSL2+, those two transceivers are also called atuc and atur. In the case of VDSL2, those two transceivers are also called vtuc and vtur. Specified as an INTEGER, the two values are: xtuc(1) -- central office transceiver xtur(2) -- remote site transceiver · Integer32

The termination unit.

OCTET STRING SIZE (8)

The ADSL Transceiver Unit (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 xTU system integrator) as inserted in the Overhead Messages (both xTUs for G.992.3, G.992.4, G.992.5, and G.993.2) or in the Embedded Operations Channel (xTU-R in G.992.1 and G.992.2). It consists of 8 binary octets, with same format as used for Xdsl2InvG994VendorId. ⓘ

OCTET STRING SIZE (0..16)

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

OCTET STRING SIZE (0..32)

The xTU serial number (vendor-specific information) as inserted in the Overhead Messages (both xTUs for G.992.3, G.992.4, G.992.5, and G.993.2) or in the Embedded Operations Channel (xTU-R in G.992.1 and G.992.2). It is vendor-specific information consisting of up to 32 ASCII characters. ⓘ

Unsigned32

The xTU 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. ⓘ

Xdsl2TransmissionModeTypeA set of xDSL 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 Bit 56 : G.993.2 Annex A Bit 57 : G.993.2 Annex B Bit 58 : G.993.2 Annex C Bit 59-63: Reserved · BITS

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

Xdsl2Unit1 = xtuc2 = xturIdentifies a transceiver as being either xTU-C or xTU-R. A VDSL2/ADSL/ADSL2 or ADSL2+ line consists of two transceivers: an xTU-C and an xTU-R. In the case of ADSL/ADSL2 and ADSL2+, those two transceivers are also called atuc and atur. In the case of VDSL2, those two transceivers are also called vtuc and vtur. Specified as an INTEGER, the two values are: xtuc(1) -- central office transceiver xtur(2) -- remote site transceiver · Integer32

The termination unit.

Unsigned32 (0..96)

The number of 15-minute PM intervals for which data was collected. The value will typically be equal to the maximum number of 15-minute intervals the implementation is planned to store (i.e., beyond the scope of this MIB module) unless the measurement was (re-)started recently, in which case the value will be the number of complete 15-minute intervals for which the agent has at least some data. In certain cases (e.g., in the case where the agent is a proxy), it is possible that some intervals are unavailable. In this case, this interval is the maximum interval number for which data is available.

Unsigned32 (0..96)

The number of 15-minute PM intervals for which no data is available. The value will typically be zero except in cases where the data for some intervals are not available (e.g., in proxy situations).

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 in this interval.

Counter32 · seconds

Count of seconds during this interval that 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 that there was: xTU-C: CRC-8 >= 1 for one or more bearer channels OR LOS >= 1 OR SEF >=1 OR LPR >= 1. xTU-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 that there was: xTU-C: (CRC-8 anomalies in one or more of the received bearer channels) >= 18 OR LOS >= 1 OR SEF >= 1 OR LPR >= 1. xTU-R: (FEBE anomalies in one or more of the received 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 that there was LOS (or LOS-FE for xTU-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 (0..30)

The number of 24-hour PM intervals for which data was collected. The value will typically be equal to the maximum number of 24-hour intervals the implementation is planned to store (i.e., beyond the scope of this MIB module) unless the measurement was (re-)started recently, in which case the value will be the number of complete 24-hour intervals for which the agent has at least some data. In certain cases (e.g., in the case where the agent is a proxy), it is possible that some intervals are unavailable. In this case, this interval is the maximum interval number for which data is available.

Unsigned32 (0..30)

The number of 24-hour PM intervals for which no data is available. The value will typically be zero except in cases where the data for some intervals are not available (e.g., in proxy situations).

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 in this interval.

Counter32 · seconds

Count of seconds during this interval that 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 that there was: xTU-C: CRC-8 >= 1 for one or more bearer channels OR LOS >= 1 OR SEF >= 1 OR LPR >= 1. xTU-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 that there was: xTU-C: (CRC-8 anomalies in one or more of the received bearer channels) >= 18 OR LOS >= 1 OR SEF >= 1 OR LPR >= 1. xTU-R: (FEBE anomalies in one or more of the received 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 that there was LOS (or LOS-FE for xTU-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 (0..96)

The number of 15-minute PM intervals for which data was collected. The value will typically be equal to the maximum number of 15-minute intervals the implementation is planned to store (i.e., beyond the scope of this MIB module) unless the measurement was (re-)started recently, in which case the value will be the number of complete 15-minute intervals for which the agent has at least some data. In certain cases (e.g., in the case where the agent is a proxy), it is possible that some intervals are unavailable. In this case, this interval is the maximum interval number for which data is available.

Unsigned32 (0..96)

The number of 15-minute PM intervals for which no data is available. The value will typically be zero except in cases where the data for some intervals are not available (e.g., in proxy situations).

Unsigned32 · seconds

Total elapsed seconds 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. ⓘ

Unsigned32 (0..30)

The number of 24-hour PM intervals for which data was collected. The value will typically be equal to the maximum number of 24-hour intervals the implementation is planned to store (i.e., beyond the scope of this MIB module) unless the measurement was (re-)started recently, in which case the value will be the number of complete 24-hour intervals for which the agent has at least some data. In certain cases (e.g., in the case where the agent is a proxy), it is possible that some intervals are unavailable. In this case, this interval is the maximum interval number for which data is available.

Unsigned32 (0..30)

The number of 24-hour PM intervals for which no data is available. The value will typically be zero except in cases where the data for some intervals are not available (e.g., in proxy situations).

Unsigned32 · seconds

Total elapsed seconds 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. ⓘ

Xdsl2Unit1 = xtuc2 = xturIdentifies a transceiver as being either xTU-C or xTU-R. A VDSL2/ADSL/ADSL2 or ADSL2+ line consists of two transceivers: an xTU-C and an xTU-R. In the case of ADSL/ADSL2 and ADSL2+, those two transceivers are also called atuc and atur. In the case of VDSL2, those two transceivers are also called vtuc and vtur. Specified as an INTEGER, the two values are: xtuc(1) -- central office transceiver xtur(2) -- remote site transceiver · Integer32

The termination unit.

Unsigned32 (1..96)

The interval number.

Unsigned32 · seconds

Total seconds monitored in this interval.

Counter32 · seconds

Count of seconds during this interval that 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 that there was: xTU-C: CRC-8 >= 1 for one or more bearer channels OR LOS >= 1 OR SEF >= 1 OR LPR >= 1. xTU-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 that there was: xTU-C: (CRC-8 anomalies in one or more of the received bearer channels) >= 18 OR LOS >= 1 OR SEF >= 1 OR LPR >= 1. xTU-R: (FEBE anomalies in one or more of the received 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 that there was LOS (or LOS-FE for xTU-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.

Xdsl2Unit1 = xtuc2 = xturIdentifies a transceiver as being either xTU-C or xTU-R. A VDSL2/ADSL/ADSL2 or ADSL2+ line consists of two transceivers: an xTU-C and an xTU-R. In the case of ADSL/ADSL2 and ADSL2+, those two transceivers are also called atuc and atur. In the case of VDSL2, those two transceivers are also called vtuc and vtur. Specified as an INTEGER, the two values are: xtuc(1) -- central office transceiver xtur(2) -- remote site transceiver · 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 that 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 that there was: xTU-C: CRC-8 >= 1 for one or more bearer channels OR LOS >= 1 OR SEF >= 1 OR LPR >= 1. xTU-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 that there was: xTU-C: (CRC-8 anomalies in one or more of the received bearer channels) >= 18 OR LOS >= 1 OR SEF >= 1 OR LPR >= 1. xTU-R: (FEBE anomalies in one or more of the received 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 that there was LOS (or LOS-FE for xTU-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.

Xdsl2Unit1 = xtuc2 = xturIdentifies a transceiver as being either xTU-C or xTU-R. A VDSL2/ADSL/ADSL2 or ADSL2+ line consists of two transceivers: an xTU-C and an xTU-R. In the case of ADSL/ADSL2 and ADSL2+, those two transceivers are also called atuc and atur. In the case of VDSL2, those two transceivers are also called vtuc and vtur. Specified as an INTEGER, the two values are: xtuc(1) -- central office transceiver xtur(2) -- remote site transceiver · Integer32

The termination unit.

Unsigned32 (0..96)

The number of 15-minute PM intervals for which data was collected. The value will typically be equal to the maximum number of 15-minute intervals the implementation is planned to store (i.e., beyond the scope of this MIB module) unless the measurement was (re-)started recently, in which case the value will be the number of complete 15-minute intervals for which the agent has at least some data. In certain cases (e.g., in the case where the agent is a proxy), it is possible that some intervals are unavailable. In this case, this interval is the maximum interval number for which data is available.

Unsigned32 (0..96)

The number of 15-minute PM intervals for which no data is available. The value will typically be zero except in cases where the data for some intervals are not available (e.g., in proxy situations).

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 in this interval.

Unsigned32

Count of CRC-8 (FEBE for xTU-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 xTU-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 (0..30)

The number of 24-hour PM intervals for which data was collected. The value will typically be equal to the maximum number of 24-hour intervals the implementation is planned to store (i.e., beyond the scope of this MIB module) unless the measurement was (re-)started recently, in which case the value will be the number of complete 24-hour intervals for which the agent has at least some data. In certain cases (e.g., in the case where the agent is a proxy), it is possible that some intervals are unavailable. In this case, this interval is the maximum interval number for which data is available.

Unsigned32 (0..30)

The number of 24-hour PM intervals for which no data is available. The value will typically be zero except in cases where the data for some intervals are not available (e.g., in proxy situations).

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 in this interval.

Unsigned32

Count of CRC-8 (FEBE for xTU-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 xTU-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. ⓘ

Xdsl2Unit1 = xtuc2 = xturIdentifies a transceiver as being either xTU-C or xTU-R. A VDSL2/ADSL/ADSL2 or ADSL2+ line consists of two transceivers: an xTU-C and an xTU-R. In the case of ADSL/ADSL2 and ADSL2+, those two transceivers are also called atuc and atur. In the case of VDSL2, those two transceivers are also called vtuc and vtur. Specified as an INTEGER, the two values are: xtuc(1) -- central office transceiver xtur(2) -- remote site transceiver · 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 xTU-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 xTU-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.

Xdsl2Unit1 = xtuc2 = xturIdentifies a transceiver as being either xTU-C or xTU-R. A VDSL2/ADSL/ADSL2 or ADSL2+ line consists of two transceivers: an xTU-C and an xTU-R. In the case of ADSL/ADSL2 and ADSL2+, those two transceivers are also called atuc and atur. In the case of VDSL2, those two transceivers are also called vtuc and vtur. Specified as an INTEGER, the two values are: xtuc(1) -- central office transceiver xtur(2) -- remote site transceiver · 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 xTU-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 xTU-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 VDSL2/ADSL/ADSL2 and ADSL2+ line configuration Profile Table (xdsl2LineConfProfTable) that applies for this DSL 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 VDSL2/ ADSL/ADSL2 and ADSL2+ channel configuration Profile Table (xdsl2ChConfProfileTable) that applies to DSL bearer channel #1. The channel profile name specified here MUST match the name of an existing row in the xdsl2ChConfProfileTable table.

Unsigned32 (0..100) · percent

Rate Adaptation Ratio. The ratio (in percent) 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 - xdsl2LConfTempChan1RaRatioDs 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 percent) 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 - xdsl2LConfTempChan1RaRatioUs 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 VDSL2/ ADSL/ADSL2 and ADSL2+ channel configuration Profile Table (xdsl2ChConfProfileTable) that applies to DSL 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 xdsl2LConfTempChan3ConfProfile contains a zero-length string.

Unsigned32 (0..100) · percent

Rate Adaptation Ratio. The ratio (in percent) 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 - xdsl2LConfTempChan2RaRatioDs 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 percent) 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 - xdsl2LConfTempChan2RaRatioUs 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 VDSL2/ ADSL/ADSL2 and ADSL2+ channel configuration Profile Table (xdsl2ChConfProfileTable) that applies to DSL 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 xdsl2LConfTempChan4ConfProfile contains a zero-length string. This object may be set to a non-zero-length string only if xdsl2LConfTempChan2ConfProfile contains a non-zero-length string.

Unsigned32 (0..100) · percent

Rate Adaptation Ratio. The ratio (in percent) 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 - xdsl2LConfTempChan3RaRatioDs 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 percent) 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 - xdsl2LConfTempChan3RaRatioUs 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 VDSL2/ ADSL/ADSL2 and ADSL2+ channel configuration Profile Table (xdsl2ChConfProfileTable) that applies to DSL 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 xdsl2LConfTempChan3ConfProfile contains a non-zero-length string.

Unsigned32 (0..100) · percent

Rate Adaptation Ratio. The ratio (in percent) 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 - xdsl2LConfTempChan4RaRatioDs 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 percent) 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 - xdsl2LConfTempChan4RaRatioUs 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'. Before a profile can be deleted or taken out of service (by setting this object to 'destroy' or 'notInService'), it MUST be first unreferenced from all associated lines. A row in this table is said to be unreferenced when there is no instance of xdsl2LineConfTemplate or xdsl2LineConfFallbackTemplate that refers to the row.

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.

Xdsl2ScMaskDsEach one of the 4096 bits in this OCTET STRING array represents the corresponding subcarrier in the downstream direction. A bit value of one indicates that a subcarrier is masked. SIZE (0..512) · OCTET STRING

Subcarrier mask. A bitmap of 4096 bits that allows masking up to 4096 downstream subcarriers. If bit i (0 <= i < NSCds) is set to '1', the respective downstream subcarrier is masked, and if set to '0', the respective subcarrier is unmasked. Note that there should always be unmasked subcarriers (i.e., this object cannot be all 1's). Also note that if NSCds < 4096, all bits i (NSCds < i <= 4096) should be set to '1'. ⓘ

Xdsl2ScMaskUsEach one of the 4096 bits in this OCTET STRING array represents the corresponding subcarrier in the upstream direction. A bit value of one indicates that a subcarrier is masked. SIZE (0..512) · OCTET STRING

Subcarrier mask. A bitmap of 4096 bits that allows masking up to 4096 upstream subcarriers. If bit i (0 <= i < NSCus) is set to '1', the respective upstream subcarrier is masked, and if set to '0', the respective subcarrier is unmasked. Note that there should always be unmasked subcarriers (i.e., this object cannot be all 1's). Also note that if NSCus < 4096, all bits i (NSCus < i <= 4096) should be set to '1'. ⓘ

Xdsl2CarMaskThis type defines an array of bands. Each band is represented by 4 octets and there is a maximum of 32 bands allowed. Each band consists of a 16-bit start subcarrier index followed by a 16-bit stop subcarrier index. The subcarrier index is an unsigned number in the range 0 to NSC-1. SIZE (0..128) · OCTET STRING

VDSL2-specific subcarrier mask. This configuration parameter defines the restrictions, additional to the band plan, to determine the set of subcarriers allowed for transmission in both the upstream and downstream directions. The parameter shall describe the not masked subcarriers as one or more frequency bands. Each band is represented by start and stop subcarrier indices with a subcarrier spacing of 4.3125 kHz. The valid range of subcarrier indices runs from 0 to at least the index of the highest allowed subcarrier in both transmission directions among all profiles enabled by the parameter xdsl2LConfProfProfiles. Up to 32 bands may be specified. Other subcarriers shall be masked. ⓘ

Xdsl2RfiBandsThis type defines a subset of downstream PSD mask breakpoints used to notch radio frequency interference (RFI) bands. Each RFI band is represented by 4 octets: a 16-bit start subcarrier index followed by a 16-bit stop subcarrier index. There is a maximum of 16 RFI bands allowed. The subcarrier index is an unsigned number in the range 0 to NSC-1. SIZE (0..64) · OCTET STRING

For ITU-T Recommendation G.992.5, this configuration parameter defines the subset of downstream PSD mask breakpoints, as specified in xdsl2LConfProfPsdMaskDs (PSDMASKds), that shall be used to notch an RFI band. This subset consists of pairs of consecutive subcarrier indices belonging to breakpoints: [ti; ti + 1], corresponding to the low level of the notch. The specific interpolation around these points is defined in the relevant Recommendations (e.g., ITU-T Recommendation G.992.5). The CO-MIB shall define the RFI notches using breakpoints in xdsl2LConfProfPsdMaskDs (PSDMASKds) as specified in the relevant Recommendations (e.g., ITU-T Recommendation G.992.5). For ITU-T Recommendation G.993.2, this configuration parameter defines the bands where the PSD shall be reduced as specified in #7.2.1.2/G.993.2. Each band shall be represented by a start and stop subcarrier indices with a subcarrier spacing of 4.3125 kHz. Up to 16 bands may be specified. This parameter defines the RFI bands for both the upstream and downstream directions. ⓘ

Xdsl2RaMode1 = 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 xTU-C in the transmit direction. ⓘ

Xdsl2RaMode1 = 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 xTU-R in the transmit direction. ⓘ

Unsigned32 (0..310) · 0.1 dB

The Downstream Up-Shift Noise Margin value, to be used when xdsl2LConfProfRaModeDs 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 xdsl2LConfProfRaUsTimeDs, the xTU-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 xdsl2LConfProfRaModeUs 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 xdsl2LConfProfRaUsTimeUs, the xTU-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 xdsl2LConfProfRaModeDs is set to 'dynamicRa'. The interval of time that the downstream noise margin should stay above the Downstream Up-Shift Noise Margin before the xTU-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 xdsl2LConfProfRaModeUs is set to 'dynamicRa'. The interval of time the upstream noise margin should stay above the Upstream Up-Shift Noise Margin before the xTU-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 xdsl2LConfProfRaModeDs is set to 'dynamicRa'. If the downstream noise margin is below this value and stays below that value, for more than the time specified by the xdsl2LConfProfRaDsTimeDs, the xTU-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 Downshift Noise Margin value, to be used when xdsl2LConfProfRaModeUs is set to 'dynamicRa'. If the upstream noise margin is below this value and stays below that value, for more than the time specified by the xdsl2LConfProfRaDsTimeUs, the xTU-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 Downshift Time Interval, to be used when xdsl2LConfProfRaModeDs is set to 'dynamicRa'. The interval of time the downstream noise margin should stay below the Downstream Down-Shift Noise Margin before the xTU-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 xdsl2LConfProfRaModeUs is set to 'dynamicRa'. The interval of time the upstream noise margin should stay below the Upstream Down-Shift Noise Margin before the xTU-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 xTU-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 xTU-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 xTU-R receiver shall try to sustain. If the Noise Margin is above this level, the xTU-R shall request that the xTU-C reduce the xTU-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 xTU-C receiver shall try to sustain. If the Noise Margin is above this level, the xTU-C shall request that the xTU-R reduce the xTU-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 xTU-R receiver shall tolerate. If the noise margin falls below this level, the xTU-R shall request that the xTU-C increase the xTU-C transmit power. If an increase to xTU-C transmit power is not possible, a loss- of-margin (LOM) defect occurs, the xTU-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 xTU-C receiver shall tolerate. If the noise margin falls below this level, the xTU-C shall request that the xTU-R increase the xTU-R transmit power. If an increase of xTU-R transmit power is not possible, a loss- of-margin (LOM) defect occurs, the xTU-C shall fail and attempt to re-initialize 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..248000) · bits/second

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

Unsigned32 (4000..248000) · bits/second

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

Xdsl2LineCeFlagThis type is used to enable the use of the optional cyclic extension values. If the bit is set to '1', the optional cyclic extension values may be used. Otherwise, the cyclic extension shall be forced to the mandatory length (5N/32). enableCyclicExtension (0) - Enable use of optional Cyclic Extension values. · BITS

This parameter is a bit that enables the use of the optional cyclic extension values. ⓘ

Xdsl2LineSnrMode1 = virtualNoiseDisabled2 = virtualNoiseEnabledThis type is used to enable the transmitter-referred virtual noise. The value of 1, indicates that virtual noise is disabled. The value of 2, indicates that virtual noise is enabled. virtualNoiseDisabled (1) - virtual noise is disabled. virtualNoiseEnabled (2) - virtual noise is enabled. · Integer32

This parameter enables the transmitter-referred virtual noise in the downstream direction. ⓘ

Xdsl2LineSnrMode1 = virtualNoiseDisabled2 = virtualNoiseEnabledThis type is used to enable the transmitter-referred virtual noise. The value of 1, indicates that virtual noise is disabled. The value of 2, indicates that virtual noise is enabled. virtualNoiseDisabled (1) - virtual noise is disabled. virtualNoiseEnabled (2) - virtual noise is enabled. · Integer32

This parameter enables the transmitter-referred virtual noise in the upstream direction. ⓘ

Xdsl2LineTxRefVnDsThis 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 subcarrier associated with the breakpoint. The third octet holds the PSD reduction at the breakpoint from 0 (-140 dBm/Hz) to 200 (-40 dBm/Hz) using units of 0.5 dBm/Hz. A special value of 255 indicates a noise level of 0 W/Hz. The subcarrier index is an unsigned number in the range 0 to NSCds-1. SIZE (0..96) · OCTET STRING

This configuration parameter defines the downstream transmitter-referred virtual noise. The TXREFVNds shall be specified through a set of breakpoints. Each breakpoint shall consist of a subcarrier index t, with a subcarrier spacing of 4.3125 kHz, and a noise PSD level (expressed in dBm/Hz) at that subcarrier. The set of breakpoints can then be represented as: [(t1,PSD1), (t2, PSD2), ... , (tN, PSDN)]. ⓘ

Xdsl2LineTxRefVnUsThis is a structure that represents up to 16 PSD mask breakpoints. Each breakpoint occupies 3 octets: The first two octets hold the index of the subcarrier associated with the breakpoint. The third octet holds the PSD reduction at the breakpoint from 0 (-140 dBm/Hz) to 200 (-40 dBm/Hz) using units of 0.5 dBm/Hz. A special value of 255 indicates a noise level of 0 W/Hz. The subcarrier index is an unsigned number in the range 0 to NSCus-1. SIZE (0..48) · OCTET STRING

This configuration parameter defines the upstream transmitter-referred virtual noise. The TXREFVNus shall be specified through a set of breakpoints. Each breakpoint shall consist of a subcarrier index t, with a subcarrier spacing of 4.3125 kHz, and a noise PSD level (expressed in dBm/Hz) at that subcarrier. The set of breakpoints can then be represented as: [(t1, PSD1), (t2, PSD2), ... , (tN, PSDN)]. ⓘ

Xdsl2TransmissionModeTypeA set of xDSL 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 Bit 56 : G.993.2 Annex A Bit 57 : G.993.2 Annex B Bit 58 : G.993.2 Annex C Bit 59-63: Reserved · BITS

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

Xdsl2LinePmModeObjects with this syntax are configuration parameters that reference the power modes/states into which the xTU-C or xTU-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 (L1/L2) state. · BITS

Power management state Enabling (PMMode). Defines the power states the xTU-C or xTU-R may autonomously transition to on this line. This is a set of bits, where any bit with a '1' value means that the xTU is allowed to transit into the respective state and any bit with a '0' value means that the xTU is not allowed to transit into the respective state. ⓘ

Unsigned32 (0..255) · seconds

The 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

The 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 Requests (i.e., at transition of L0 to L2 state) and Power Trims. ⓘ

Xdsl2LineProfilesObjects with this syntax reference the list of ITU-T G.993.2 implementation profiles supported by an xTU, enabled on the VDSL2 line or active on that line. · BITS

The configuration parameter contains the G.993.2 profiles to be allowed by the near-end xTU on this line. It is coded in a bitmap representation (0 if not allowed, 1 if allowed). ⓘ

Xdsl2PsdMaskDsThis 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 subcarrier 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. The subcarrier index is an unsigned number in the range 0 to NSCds-1. SIZE (0..96) · OCTET STRING

This configuration parameter defines the PSD mask that is assumed to be permitted at the exchange. This parameter shall use the same format as xdsl2LConfProfPsdMaskDs (PSDMASKds). The maximum number of breakpoints for xdsl2LConfProfDpboEPsd is 16. ⓘ

Unsigned32 (0..511) · 0.5 dB

This configuration parameter defines the assumed electrical length of cables (E-side cables) connecting exchange-based DSL services to a remote flexibility point (cabinet), that hosts the xTU-C that is subject to spectrally shaped downstream power back- off (DPBO) depending on this length. The electrical length is defined as the loss (in dB) of an equivalent length of hypothetical cable at a reference frequency defined by the network operator or in spectrum management regulations. This parameter shall be coded as an unsigned integer representing an electrical length from 0 dB (coded as 0) to 255.5 dB (coded as 511) in steps of 0.5 dB. All values in the range are valid. If this parameter is set to '0', the DPBO shall be disabled. ⓘ

Unsigned32 (0..640) · 2^-8

The E-side Cable Model parameter A (DPBOESCMA) of the cable model (DPBOESCM) for cables connecting exchange-based DSL services to a remote flexibility point (cabinet), that hosts the xTU-C that is subject to spectrally shaped downstream power back- off (DPBO) depending on this value. The cable model is in terms of three scalars xdsl2LConfProfDpboEsCableModelA (DPBOESCMA), xdsl2LConfProfDpboEsCableModelB(DPBOESCMB), and xdsl2LConfProfDpboEsCableModelC (DPBOESCMC), that are used to estimate the frequency dependent loss of E-side cables calculated from the xdsl2LConfProfDpboEsEL (DPBOESEL) parameter. Possible values shall be coded as unsigned integers representing a scalar value from -1 (coded as 0) to 1.5 (coded as 640) in steps of 2^-8. All values in the range are valid. This parameter is used only for G.993.2. ⓘ

Unsigned32 (0..640) · 2^-8

The E-side Cable Model parameter B (DPBOESCMB) of the cable model (DPBOESCM) for cables connecting exchange-based DSL services to a remote flexibility point (cabinet), that hosts the xTU-C that is subject to spectrally shaped downstream power back- off (DPBO) depending on this value. The cable model is in terms of three scalars dsl2LConfProfDpboEsCableModelA (DPBOESCMA), xdsl2LConfProfDpboEsCableModelB(DPBOESCMB), and xdsl2LConfProfDpboEsCableModelC (DPBOESCMC), that are used to estimate the frequency dependent loss of E-side cables calculated from the xdsl2LConfProfDpboEsEL (DPBOESEL) parameter. Possible values shall be coded as unsigned integers representing a scalar value from -1 (coded as 0) to 1.5 (coded as 640) in steps of 2^-8. All values in the range are valid. This parameter is used only for G.993.2. ⓘ

Unsigned32 (0..640) · 2^-8

The E-side Cable Model parameter C (DPBOESCMC) of the cable model (DPBOESCM) for cables connecting exchange-based DSL services to a remote flexibility point (cabinet), that hosts the xTU-C that is subject to spectrally shaped downstream power back- off (DPBO) depending on this value. The cable model is in terms of three scalars xdsl2LConfProfDpboEsCableModelA (DPBOESCMA), xdsl2LConfProfDpboEsCableModelB(DPBOESCMB), and xdsl2LConfProfDpboEsCableModelC (DPBOESCMC), that are used to estimate the frequency dependent loss of E-side cables calculated from the xdsl2LConfProfDpboEsEL (DPBOESEL) parameter. Possible values shall be coded as unsigned integers representing a scalar value from -1 (coded as 0) to 1.5 (coded as 640) in steps of 2^-8. All values in the range are valid. This parameter is used only for G.993.2. ⓘ

Unsigned32 (0..255) · 0.5 dBm/Hz

This configuration parameter defines the assumed Minimum Usable receive PSD mask (in dBm/Hz) for exchange-based services, used to modify parameter xdsl2LConfProfDpboFMax (DPBOFMAX) defined below (to determine the DPBO). It shall be coded as an unsigned integer representing a PSD mask level from 0 dBm/Hz (coded as 0) to -127.5 dBm/Hz (coded as 255) in steps of 0.5 dBm/Hz. All values in the range are valid. NOTE - The PSD mask level is 3.5 dB above the signal PSD level. This parameter is used only for G.993.2. ⓘ

Unsigned32 (0..2048) · 4.3125 kHz

This configuration parameter defines the minimum frequency from which the DPBO shall be applied. It ranges from 0 kHz (coded as 0) to 8832 kHz (coded as 2048) in steps of 4.3125 kHz. This parameter is used only for G.993.2. ⓘ

Unsigned32 (32..6956) · 4.3125 kHz

This configuration parameter defines the maximum frequency at which DPBO may be applied. It ranges from 138 kHz (coded as 32) to 29997.75 kHz (coded as 6956) in steps of 4.3125 kHz. This parameter is used only for G.993.2. ⓘ

Unsigned32 (0..1280) · 0.1 dB

This configuration parameter defines the electrical length expressed in dB at 1 MHz, kl0, configured by the CO-MIB. The value ranges from 0 (coded as 0) to 128 dB (coded as 1280) in steps of 0.1 dB. This parameter is relevant only if xdsl2LConfProfUpboKLF is set to 'override(2)', which indicates that this parameter's value will override the VTUs' determination of the electrical length. If xdsl2LConfProfUpboKLF is set either to auto(1) or disableUpbo(3), then this parameter will be ignored. ⓘ

Xdsl2UpboKLF1 = auto2 = override3 = disableUpboDefines the upstream power backoff force mode (UPBOKLF). The three possible mode values are: auto(1) - The VDSL Transceiver Unit (VTUs) will autonomously determine the electrical length. override(2) - Forces the VTU-R to use the electrical length, kl0, of the CO-MIB (UPBOKL) to compute the UPBO. disableUpbo(3) - Disables UPBO such that UPBO is not utilized. · Integer32

Defines the upstream power backoff force mode. ⓘ

Xdsl2LineUs0MaskThe US0 PSD masks to be allowed by the near-end xTU on the line. This parameter is only defined for G.993.2 Annex A. It is represented as a bitmap (0 if not allowed and 1 if allowed) with the following definitions. · BITS

The configuration parameter contains the US0 PSD masks to be allowed by the near-end xTU on the line. This parameter is only defined for G.993.2 Annex A. It is represented as a bitmap (0 if not allowed and 1 if allowed). ⓘ

TruthValue1 = true2 = falseRepresents a boolean value. · Integer32

This parameter, when set to 'true' indicates that the framer settings of the bearer shall be selected such that the impulse noise protection computed according to the formula specified in the relevant Recommendation is greater than or equal to the minimal impulse noise protection requirement. This flag shall have the same value for all the bearers of one line in the same direction. ⓘ

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'. Before a profile can be deleted or taken out of service (by setting this object to 'destroy' or 'notInService'), it MUST be first unreferenced from all templates. A row in this table is said to be unreferenced when there is no instance of xdsl2LConfTempLineProfile that refers to the row. When a row is created in this table, the SNMP agent should also create corresponding rows in the tables xdsl2LineConfProfModeSpecTable and xdsl2LineConfProfModeSpecBandUsTable. When a row is deleted in this table, the SNMP agent should also delete corresponding rows in the tables xdsl2LineConfProfModeSpecTable and xdsl2LineConfProfModeSpecBandUsTable.

Xdsl2OperationModes1 = defMode2 = ansit14133 = etsi4 = g9921PotsNonOverlapped5 = g9921PotsOverlapped6 = g9921IsdnNonOverlapped7 = g9921isdnOverlapped8 = g9921tcmIsdnNonOverlapped9 = g9921tcmIsdnOverlapped10 = g9922potsNonOverlapped11 = g9922potsOverlapped12 = g9922tcmIsdnNonOverlapped13 = g9922tcmIsdnOverlapped14 = g9921tcmIsdnSymmetric20 = g9923PotsNonOverlapped21 = g9923PotsOverlapped22 = g9923IsdnNonOverlapped23 = g9923isdnOverlapped26 = g9924potsNonOverlapped27 = g9924potsOverlapped30 = g9923AnnexIAllDigNonOverlapped31 = g9923AnnexIAllDigOverlapped32 = g9923AnnexJAllDigNonOverlapped33 = g9923AnnexJAllDigOverlapped34 = g9924AnnexIAllDigNonOverlapped35 = g9924AnnexIAllDigOverlapped36 = g9923AnnexLMode1NonOverlapped37 = g9923AnnexLMode2NonOverlapped38 = g9923AnnexLMode3Overlapped39 = g9923AnnexLMode4Overlapped40 = g9923AnnexMPotsNonOverlapped41 = g9923AnnexMPotsOverlapped42 = g9925PotsNonOverlapped43 = g9925PotsOverlapped44 = g9925IsdnNonOverlapped45 = g9925isdnOverlapped48 = g9925AnnexIAllDigNonOverlapped49 = g9925AnnexIAllDigOverlapped50 = g9925AnnexJAllDigNonOverlapped51 = g9925AnnexJAllDigOverlapped52 = g9925AnnexMPotsNonOverlapped53 = g9925AnnexMPotsOverlapped58 = g9932AnnexA59 = g9932AnnexB60 = g9932AnnexCThe VDSL2 management model specified includes an xDSL Mode object that identifies an instance of xDSL Mode-Specific PSD Configuration object in the xDSL Line Profile. The following classes of xDSL operating mode are defined. The notes (F) and (L) denote Full-Rate and Lite/splitterless, respectively: +-------+--------------------------------------------------+ | Value | xDSL 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 - Regional Std. (ANSI T1.413) (F) 3 - Regional Std. (ETSI DTS/TM06006) (F) 4 - G.992.1 POTS non-overlapped (F) 5 - G.992.1 POTS overlapped (F) 6 - G.992.1 ISDN non-overlapped (F) 7 - G.992.1 ISDN overlapped (F) 8 - G.992.1 TCM-ISDN non-overlapped (F) 9 - G.992.1 TCM-ISDN overlapped (F) 10 - G.992.2 POTS non-overlapped (L) 11 - G.992.2 POTS overlapped (L) 12 - G.992.2 with TCM-ISDN non-overlapped (L) 13 - G.992.2 with TCM-ISDN overlapped (L) 14 - G.992.1 TCM-ISDN symmetric (F) --- not in G.997.1 15-19 - Unused. Reserved for future ITU-T specification. 20 - G.992.3 POTS non-overlapped (F) 21 - G.992.3 POTS overlapped (F) 22 - G.992.3 ISDN non-overlapped (F) 23 - G.992.3 ISDN overlapped (F) 24-25 - Unused. Reserved for future ITU-T specification. 26 - G.992.4 POTS non-overlapped (L) 27 - G.992.4 POTS overlapped (L) 28-29 - Unused. Reserved for future ITU-T specification. 30 - G.992.3 Annex I All-Digital non-overlapped (F) 31 - G.992.3 Annex I All-Digital overlapped (F) 32 - G.992.3 Annex J All-Digital non-overlapped (F) 33 - G.992.3 Annex J All-Digital overlapped (F) 34 - G.992.4 Annex I All-Digital non-overlapped (L) 35 - G.992.4 Annex I All-Digital overlapped (L) 36 - G.992.3 Annex L POTS non-overlapped, mode 1, wide U/S (F) 37 - G.992.3 Annex L POTS non-overlapped, mode 2, narrow U/S(F) 38 - G.992.3 Annex L POTS overlapped, mode 3, wide U/S (F) 39 - G.992.3 Annex L POTS overlapped, mode 4, narrow U/S (F) 40 - G.992.3 Annex M POTS non-overlapped (F) 41 - G.992.3 Annex M POTS overlapped (F) 42 - G.992.5 POTS non-overlapped (F) 43 - G.992.5 POTS overlapped (F) 44 - G.992.5 ISDN non-overlapped (F) 45 - G.992.5 ISDN overlapped (F) 46-47 - Unused. Reserved for future ITU-T specification. 48 - G.992.5 Annex I All-Digital non-overlapped (F) 49 - G.992.5 Annex I All-Digital overlapped (F) 50 - G.992.5 Annex J All-Digital non-overlapped (F) 51 - G.992.5 Annex J All-Digital overlapped (F) 52 - G.992.5 Annex M POTS non-overlapped (F) 53 - G.992.5 Annex M POTS overlapped (F) 54-57 - Unused. Reserved for future ITU-T specification. 58 - G.993.2 Annex A 59 - G.993.2 Annex B 60 - G.993.2 Annex C · Integer32

The DSL Mode is a way of categorizing the various xDSL transmission modes into groups, each group (xDSL 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 xdsl2LConfProfXtuTransSysEna 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 to 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 subcarriers. The xTU-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. ⓘ

Xdsl2PsdMaskDsThis 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 subcarrier 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. The subcarrier index is an unsigned number in the range 0 to NSCds-1. 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 the first subcarrier used in the context of a first breakpoint. Octet 2 - The PSD reduction for the subcarrier indicated in octets 0 and 1. Octets 3-5 - Same, for a second breakpoint. Octets 6-8 - Same, for a third 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 0 and NSCds-1. Each PSD reduction value is in the range 0 (0 dBm/Hz) to 255 (-127.5 dBm/Hz) with steps of 0.5 dBm/Hz. Valid values are in the range 0 to 190 (0 to -95 dBm/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 subcarrier mask and with the RFI setup. ⓘ

Xdsl2PsdMaskUsThis is a structure that represents up to 16 PSD mask breakpoints. Each breakpoint occupies 3 octets: The first two octets hold the index of the subcarrier 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. The subcarrier index is an unsigned number in the range 0 to NSCus-1. SIZE (0..48) · 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 16 pairs of values in the following structure: Octets 0-1 - Index of the first subcarrier used in the context of a first breakpoint. Octet 2 - The PSD reduction for the subcarrier indicated in octets 0 and 1. Octets 3-5 - Same, for a second breakpoint. Octets 6-8 - Same, for a third breakpoint. This architecture continues until octets 9-47, which are associated with a 16th breakpoint. Each subcarrier index is an unsigned number in the range 0 and NSCus-1. Each PSD reduction value is in the range 0 (0 dBm/Hz) to 255 (-127.5 dBm/Hz) with steps of 0.5 dBm/Hz. Valid values are in the range 0 to 190 (0 to -95 dBm/Hz). When the number of breakpoints is less than 16, all remaining octets are set to the value '0'. Note that the content of this object should be correlated with the subcarrier mask and with the RFI setup. ⓘ

Xdsl2LinePsdMaskSelectUs1 = adlu32Eu322 = adlu36Eu363 = adlu40Eu404 = adlu44Eu445 = adlu48Eu486 = adlu52Eu527 = adlu56Eu568 = adlu60Eu609 = adlu64Eu64This type is used to define which upstream PSD mask is enabled. This type is used only for Annexes J and M of ITU-T Recommendations G.992.3 and G.992.5. adlu32Eu32 (1), - ADLU-32 / EU-32 adlu36Eu36 (2), - ADLU-36 / EU-36 adlu40Eu40 (3), - ADLU-40 / EU-40 adlu44Eu44 (4), - ADLU-44 / EU-44 adlu48Eu48 (5), - ADLU-48 / EU-48 adlu52Eu52 (6), - ADLU-52 / EU-52 adlu56Eu56 (7), - ADLU-56 / EU-56 adlu60Eu60 (8), - ADLU-60 / EU-60 adlu64Eu64 (9) - ADLU-64 / EU-64 · Integer32

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 xdsl2LConfProfXtuTransSysEna. ⓘ

Xdsl2LineClassMask1 = none2 = a998ORb997M1cORc998B3 = b997M1xOR998co4 = b997M2x5 = b998M1x6 = b998M2x7 = b998AdeM2x8 = bHpeM1VDSL2 PSD Mask Class. The limit Power Spectral Density masks are grouped in the following PSD mask classes: Class 998 Annex A: D-32, D-48, D-64, D-128. Class 997-M1c Annex B: 997-M1c-A-7. Class 997-M1x Annex B: 997-M1x-M-8, 997-M1x-M. Class 997-M2x Annex B: 997-M2x-M-8, 997-M2x-A, 997-M2x-M, 997E17-M2x-NUS0, 997E30-M2x-NUS0. Class 998-M1x Annex B: 998-M1x-A, 998-M1x-B, 998-M1x-NUS0. Class 998-M2x Annex B: 998-M2x-A, 998-M2x-M, 998-M2x-B, 998-M2x-NUS0, 998E17-M2x-NUS0, 998E17-M2x-NUS0-M, 998E30-M2x-NUS0, 998E30-M2x-NUS0-M. Class 998ADE-M2x Annex B: Annex B: 998-M2x-A, 998-M2x-M, 998-M2x-B, 998-M2x-NUS0, 998ADE17-M2x-A, 998ADE17-M2x-B, 998ADE17-M2x-NUS0-M, 998ADE30-M2x-NUS0-A, 998ADE30-M2x-NUS0-M. Class 998-B Annex C: POTS-138b, POTS-276b per C.2.1.1 in G.993.2, TCM-ISDN per C.2.1.2 in G.993.2. Class 998-CO Annex C: POTS-138co, POTS-276co per C.2.1.1 in G.993.2. Class HPE-M1 Annex B: HPE17-M1-NUS0, HPE30-M1-NUS0. · Integer32

In order to reduce the number of configuration possibilities, the limit Power Spectral Density masks (see LIMITMASK) are grouped in PSD mask classes. Each class is designed such that the PSD levels of each limit PSD mask of a specific class are equal in their respective passband above 552 kHz. This parameter is defined per VDSL2 Annex enabled in the xdsl2LConfProfXtuTransSysEna object. It selects a single PSD mask class per Annex that is activated at the VTU-O. ⓘ

Xdsl2LineLimitMaskThe G.993.2 limit PSD mask for each class of profile. The profiles are grouped in following profile classes: - Class 8: Profiles 8a, 8b, 8c, 8d. - Class 12: Profiles 12a, 12b. - Class 17: Profile 17a. - Class 30: Profile 30a. · BITS

This configuration parameter contains the G.993.2 limit PSD masks of the selected PSD mask class, enabled by the near-end xTU on this line for each class of profiles. This parameter is defined per VDSL2 Annex enabled in the xdsl2LConfProfXtuTransSysEna object. Through this parameter, several limit PSD masks of the selected PSD mask class (xdsl2LConfProfClassMask) may be enabled. The enabling parameter is coded in a bitmap representation (0 if the associated mask is not allowed, 1 if it is allowed). ⓘ

Xdsl2LineUs0DisableIndicates if US0 is disabled for each limit PSD mask. The profiles are grouped in following profile classes: - Class 8: Profiles 8a, 8b, 8c, 8d. - Class 12: Profiles 12a, 12b. - Class 17: Profile 17a. - Class 30: Profile 30a. · BITS

This configuration parameter indicates if the use of the US0 is disabled for each limit PSD mask enabled in the xdsl2LConfProfLimitMask parameter. This parameter is defined per VDSL2 Annex enabled in the xdsl2LConfProfXtuTransSysEna object. For each limit PSD mask enabled in the xdsl2LConfProfLimitMask parameter, a bit shall indicate if the US0 is disabled. The disabling parameter is coded as a bitmap. The bit is set to '1' if the US0 is disabled for the associated limit mask. This parameter and the xdsl2LConfProfLimitMask parameter use the same structure. ⓘ

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. This row is activated by setting this object to 'active'. A 'mandatory' row, as defined in the DESCRIPTION clause of xdsl2LineConfProfModeSpecTable, cannot be deleted at all. A 'mandatory' row can be taken out of service (by setting this object to 'notInService') if the parent row in the xdsl2LineConfProfTable table is not in the 'active' state. An 'optional' row (or 'mode-specific' row) can be deleted or taken out of service (by setting this object to 'destroy' or 'notInService') at any time.

Xdsl2BandUs5 = us17 = us29 = us311 = us4Each value identifies a specific band in the upstream transmission direction (excluding the US0 band.). The possible values that identify a band are as follows: us1(5) - Upstream band number 1 (US1). us2(7) - Upstream band number 2 (US2). us3(9) - Upstream band number 3 (US3). us4(11) - Upstream band number 4 (US4). · Integer32

Each value identifies a specific band in the upstream transmission direction (excluding the US0 band). ⓘ

Integer32 (4000..8095) · 0.01 dBm/Hz

This configuration parameter defines the 'a' reference parameter of the UPBO reference PSD used to compute the upstream power back-off for the upstream band. A UPBO PSD defined for each band shall consist of two parameters [a, b]. Parameter 'a' (xdsl2LConfProfUpboPsdA) ranges from 40 dBm/Hz (coded as 4000) to 80.95 dBm/Hz (coded as 8095) in steps of 0.01 dBm/Hz; and parameter 'b' (xdsl2LConfProfUpboPsdB) ranges from 0 dBm/Hz (coded as 0) to 40.95 dBm/Hz (coded as 4095) in steps of 0.01 dBm/Hz. The UPBO reference PSD at the frequency 'f' expressed in MHz shall be equal to '-a-b(SQRT(f))'. Setting xdsl2LConfProfUpboPsdA to 4000 and xdsl2LConfProfUpboPsdB to 0 is a special configuration to disable UPBO in the respective upstream band. ⓘ

Integer32 (0..4095) · 0.01 dBm/Hz

This configuration parameter defines the 'b' reference parameter of the UPBO reference PSD used to compute the upstream power back-off for the upstream band. A UPBO PSD defined for each band shall consist of two parameters [a, b]. Parameter 'a' (xdsl2LConfProfUpboPsdA) ranges from 40 dBm/Hz (coded as 4000) to 80.95 dBm/Hz (coded as 8095) in steps of 0.01 dBm/Hz; and parameter 'b' (xdsl2LConfProfUpboPsdB) ranges from 0 dBm/Hz (coded as 0) to 40.95 dBm/Hz (coded as 4095) in steps of 0.01 dBm/Hz. The UPBO reference PSD at the frequency 'f' expressed in MHz shall be equal to '-a-b(SQRT(f))'. Setting xdsl2LConfProfUpboPsdA to 4000 and xdsl2LConfProfUpboPsdB to 0 is a special configuration to disable UPBO in the respective upstream band. ⓘ

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. This row is activated by setting this object to 'active'. A 'mandatory' row, as defined in the DESCRIPTION clause of xdsl2LineConfProfModeSpecBandUsTable, cannot be deleted at all. A 'mandatory' row can be taken out of service (by setting this object to 'notInService') if the parent row in the xdsl2LineConfProfModeSpecTable table is not in the 'active' state. An 'optional' row (or 'mode-specific' row) can be deleted or taken out of service (by setting this object to 'destroy' or 'notInService') at any time.

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 · bits/second

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

Unsigned32 · bits/second

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

Unsigned32 · bits/second

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

Unsigned32 · bits/second

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

Unsigned32 · bits/second

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

Unsigned32 · bits/second

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

Unsigned32 · bits/second

This parameter specifies the minimum net data rate for the bearer channel as desired by the operator of the system during the low power state (L1/L2). The power management low power states L1 and L2 are defined in ITU-T Recommendations G.992.2 and G.992.3, respectively. The data rate is coded in steps of bit/s. ⓘ

Unsigned32 · bits/second

This parameter specifies the minimum net data rate for the bearer channel as desired by the operator of the system during the low power state (L1/L2). The power management low power states L1 and L2 are defined in ITU-T Recommendations G.992.2 and G.992.3, respectively. The data rate is coded in steps of bit/s. ⓘ

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 xTUs shall choose the S (factor) and D (depth) values such that the actual one-way interleaving delay (Xdsl2ChStatusActDelay) is as close as possible to, but less than or equal to, xdsl2ChConfProfMaxDelayDs. 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 xTUs shall choose the S (factor) and D (depth) values such that the actual one-way interleaving delay (Xdsl2ChStatusActDelay) is as close as possible to, but less than or equal to, xdsl2ChConfProfMaxDelayUs. The delay is coded in ms, with the value 0 indicating no delay bound is being imposed. ⓘ

Xdsl2SymbolProtection1 = noProtection2 = halfSymbol3 = singleSymbol4 = twoSymbols5 = threeSymbols6 = fourSymbols7 = fiveSymbols8 = sixSymbols9 = sevenSymbols10 = eightSymbols11 = nineSymbols12 = tenSymbols13 = elevenSymbols14 = twelveSymbols15 = thirteeSymbols16 = fourteenSymbols17 = fifteenSymbols18 = sixteenSymbolsThis type specifies the minimum impulse noise protection for the bearer channel if it is transported over DMT symbols with a subcarrier spacing of 4.3125 kHz. 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

This parameter specifies the minimum impulse noise protection for the bearer channel if it is transported over DMT symbols with a subcarrier spacing of 4.3125 kHz. The impulse noise protection is expressed in DMT symbols with a subcarrier spacing of 4.3125 kHz and can take the values 1/2 and any integer from 0 to 16, inclusive. If the xTU does not support the configured INPMIN value, it shall use the nearest supported impulse noise protection greater than INPMIN. ⓘ

Xdsl2SymbolProtection1 = noProtection2 = halfSymbol3 = singleSymbol4 = twoSymbols5 = threeSymbols6 = fourSymbols7 = fiveSymbols8 = sixSymbols9 = sevenSymbols10 = eightSymbols11 = nineSymbols12 = tenSymbols13 = elevenSymbols14 = twelveSymbols15 = thirteeSymbols16 = fourteenSymbols17 = fifteenSymbols18 = sixteenSymbolsThis type specifies the minimum impulse noise protection for the bearer channel if it is transported over DMT symbols with a subcarrier spacing of 4.3125 kHz. 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

This parameter specifies the minimum impulse noise protection for the bearer channel if it is transported over DMT symbols with a subcarrier spacing of 4.3125 kHz. The impulse noise protection is expressed in DMT symbols with a subcarrier spacing of 4.3125 kHz and can take the values 1/2 and any integer from 0 to 16, inclusive. If the xTU does not support the configured INPMIN value, it shall use the nearest supported impulse noise protection greater than INPMIN. ⓘ

Xdsl2SymbolProtection81 = noProtection2 = singleSymbol3 = twoSymbols4 = threeSymbols5 = fourSymbols6 = fiveSymbols7 = sixSymbols8 = sevenSymbols9 = eightSymbols10 = nineSymbols11 = tenSymbols12 = elevenSymbols13 = twelveSymbols14 = thirteeSymbols15 = fourteenSymbols16 = fifteenSymbols17 = sixteenSymbolsThis type specifies the minimum impulse noise protection for the bearer channel if it is transported over DMT symbols with a subcarrier spacing of 8.625 kHz. The possible values are: 'noProtection' (i.e., INP not required) and 1-16 symbols in steps of 1 symbol. · Integer32 · symbols

This parameter specifies the minimum impulse noise protection for the bearer channel if it is transported over DMT symbols with a subcarrier spacing of 8.625 kHz. The impulse noise protection is expressed in DMT symbols with a subcarrier spacing of 8.625 kHz. ⓘ

Xdsl2SymbolProtection81 = noProtection2 = singleSymbol3 = twoSymbols4 = threeSymbols5 = fourSymbols6 = fiveSymbols7 = sixSymbols8 = sevenSymbols9 = eightSymbols10 = nineSymbols11 = tenSymbols12 = elevenSymbols13 = twelveSymbols14 = thirteeSymbols15 = fourteenSymbols16 = fifteenSymbols17 = sixteenSymbolsThis type specifies the minimum impulse noise protection for the bearer channel if it is transported over DMT symbols with a subcarrier spacing of 8.625 kHz. The possible values are: 'noProtection' (i.e., INP not required) and 1-16 symbols in steps of 1 symbol. · Integer32 · symbols

This parameter specifies the minimum impulse noise protection for the bearer channel if it is transported over DMT symbols with a subcarrier spacing of 8.625 kHz. The impulse noise protection is expressed in DMT symbols with a subcarrier spacing of 8.625 kHz. ⓘ

Xdsl2MaxBer1 = eminus32 = eminus53 = eminus7Objects 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. ⓘ

Xdsl2MaxBer1 = eminus32 = eminus53 = eminus7Objects 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. ⓘ

Unsigned32 · bits/second

Data Rate Threshold Upshift 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 bit/s. ⓘ

Unsigned32 · bits/second

Data Rate Threshold Downshift 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 bit/s. ⓘ

Unsigned32 · bits/second

Data Rate Threshold Upshift 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 bit/s. ⓘ

Unsigned32 · bits/second

Data Rate Threshold Downshift 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 bit/s. ⓘ

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 of ATM Data Path. When in 'enable' state, the ATM Data Path should comply with the requirements for IMA transmission. ⓘ

Unsigned32 (1..255) · 0.1 milliseconds

Maximum delay variation (DVMAX). This optional VDSL2-specific parameter specifies the maximum value for the delay variation allowed in an OLR procedure. It is ranges from 1 to 254 units of 0.1 milliseconds (i.e., 0.1 to 25.4 milliseconds) with the special value 255, which indicates that no delay variation bound is imposed. ⓘ

Xdsl2ChInitPolicy1 = policy02 = policy1This syntax serves for channel configuration parameters that reference the channel initialization policy. The possible values are: policy0 (1) - Policy 0 according to the applicable standard. policy1 (2) - Policy 1 according to the applicable standard. · Integer32

Channel Initialization Policy Selection (CIPOLICY). This optional parameter indicates which policy shall be applied to determine the transceiver configuration parameters at initialization. Those policies are defined in the respective Recommendations. ⓘ

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'. Before a profile can be deleted or taken out of service (by setting this object to 'destroy' or 'notInService'), it MUST be first unreferenced from all associated templates. A row in xdsl2ChConfProfTable is said to be unreferenced when there is no instance of xdsl2LConfTempChan1ConfProfile, xdsl2LConfTempChan2ConfProfile, xdsl2LConfTempChan3ConfProfile, or xdsl2LConfTempChan4ConfProfile that refers to the row.

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 DSL Line Thresholds Configuration Profile Table (xdsl2LineAlarmConfProfileTable) that applies to this 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 DSL Channel Thresholds Configuration Profile Table (xdsl2ChAlarmConfProfileTable) that applies for DSL bearer channel #1. The channel profile name specified here MUST match the name of an existing row in the xdsl2ChAlarmConfProfileTable 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 DSL Channel Thresholds Configuration Profile Table (xdsl2ChAlarmConfProfileTable) that applies for DSL bearer channel #2. The channel profile name specified here MUST match the name of an existing row in the xdsl2ChAlarmConfProfileTable 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 DSL Channel Thresholds Configuration Profile Table (xdsl2ChAlarmConfProfileTable) that applies for DSL bearer channel #3. The channel profile name specified here MUST match the name of an existing row in the xdsl2ChAlarmConfProfileTable table. This object may be set to a non-zero-length string only if xdsl2LAlarmConfTempChan2ConfProfile 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 DSL Channel Thresholds Configuration Profile Table (xdsl2ChAlarmConfProfileTable) that applies for DSL bearer channel #4. The channel profile name specified here MUST match the name of an existing row in the xdsl2ChAlarmConfProfileTable table. This object may be set to a non-zero-length string only if xdsl2LAlarmConfTempChan3ConfProfile 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'. Before a template can be deleted or taken out of service (by setting this object to 'destroy' or 'notInService'), it MUST be first unreferenced from all associated lines. A row in this table is said to be unreferenced when there is no instance of xdsl2LineAlarmConfTemplate that refers to the row.

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 xdsl2PMLCurr15MFecs counter, when xdsl2PMLCurrUnit is xtuc {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 xdsl2PMLCurr15MEs counter, when xdsl2PMLCurrUnit is xtuc {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 xdsl2PMLCurr15MSes counter, when xdsl2PMLCurrUnit is xtuc {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 xdsl2PMLCurr15MLoss counter, when xdsl2PMLCurrUnit is xtuc {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 xdsl2PMLCurr15MUas counter, when xdsl2PMLCurrUnit is xtuc {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 xdsl2PMLCurr15MFecs counter, when xdsl2PMLCurrUnit is xtur {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 xdsl2PMLCurr15MEs counter, when xdsl2PMLCurrUnit is xtur {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 xdsl2PMLCurr15MSes counter, when xdsl2PMLCurrUnit is xtur {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 xdsl2PMLCurr15MLoss counter, when xdsl2PMLCurrUnit is xtur {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 xdsl2PMLCurr15MUas counter, when xdsl2PMLCurrUnit is xtur {2}. The value 0 means that no threshold is specified for the associated counter. ⓘ

Unsigned32

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

Unsigned32

A threshold for the xdsl2PMLInitCurr15MFailedShortInits 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'. Before a profile can be deleted or taken out of service (by setting this object to 'destroy' or 'notInService'), it MUST be first unreferenced from all associated templates. A row in this table is said to be unreferenced when there is no instance of xdsl2LAlarmConfTempLineProfile that refers to the row.

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 xdsl2PMChCurr15MCodingViolations counter, when xdsl2PMChCurrUnit is xtuc {1}. The value 0 means that no threshold is specified for the associated counter. ⓘ

Unsigned32

A threshold for the xdsl2PMChCurr15MCorrectedBlocks counter, when xdsl2PMChCurrUnit is xtuc {1}. The value 0 means that no threshold is specified for the associated counter. ⓘ

Unsigned32

A threshold for the xdsl2PMChCurr15MCodingViolations counter, when xdsl2PMChCurrUnit is xtur {2}. The value 0 means that no threshold is specified for the associated counter. ⓘ

Unsigned32

A threshold for the xdsl2PMChCurr15MCorrectedBlocks counter, when xdsl2PMChCurrUnit is xtur {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'. Before a profile can be deleted or taken out of service (by setting this object to 'destroy' or 'notInService'), it MUST be first unreferenced from all associated templates. A row in xdsl2ChConfProfTable is said to be unreferenced when there is no instance of xdsl2LAlarmConfTempChan1ConfProfile, xdsl2LAlarmConfTempChan2ConfProfile, xdsl2LAlarmConfTempChan3ConfProfile, or xdsl2LAlarmConfTempChan4ConfProfile that refers to the row.