OPT-IF-MIB

Unsigned32 (1..900)

This object indicates the order of the OTM, which represents the maximum number of wavelengths that can be supported at the bit rate(s) supported on the interface.

TruthValue1 = true2 = falseRepresents a boolean value. · Integer32

This object indicates whether a reduced or full functionality is supported at the interface. A value of true means reduced. A value of false means full.

BITS

This attribute is a bit map representing the bit rate or set of bit rates supported on the interface. The meaning of each bit position is as follows: bitRateK1(0) is set if the 2.5 Gbit/s rate is supported bitRateK2(1) is set if the 10 Gbit/s rate is supported bitRateK3(2) is set if the 40 Gbit/s rate is supported Note that each bit position corresponds to one possible value of the type OptIfBitRateK. The default value of this attribute is system specific.

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..255) · OCTET STRING · hint 255t

This object identifies the type of interface. The value of this attribute will affect the behavior of the OTM with respect to presence/absence of OTM Overhead Signal (OOS) processing and TCM activation. For an IrDI interface, there is no OOS processing and TCM activation is limited to n levels as specified by a TCM level threshold. This object contains two fields that are separated by whitespace. The possible values are: field 1: one of the 4-character ASCII strings 'IrDI' or 'IaDI' field 2: free-form text consisting of printable UTF-8 encoded characters Note that field 2 is optional. If it is not present then there is no requirement for trailing whitespace after field 1. The default values are as follows: field 1: 'IaDI' field 2: an empty string.

Unsigned32 (0..6)

This object identifies the maximum number of TCM levels allowed for any Optical Channel contained in this OTM. A new TCM activation will be rejected if the requested level is greater than the threshold. If InterfaceType object specifies a type of 'IaDI' for this OTM, then this attribute is irrelevant. Possible values: unsigned integers in the range from 0 to 6 inclusive. Default value: 3.

INTEGER1 = intraOffice2 = shortHaul3 = longHaul4 = veryLongHaul5 = ultraLongHaul · Integer32

This object indicates the length the optical signal may travel before requiring termination or regeneration. The meaning of the enumeration are: intraOffice(1) - intra-office (as defined in ITU-T G.957) shortHaul(2) - short haul (as defined in ITU-T G.957) longHaul(3) - long haul (as defined in ITU-T G.957) veryLongHaul(4) - very long haul (as defined in ITU-T G.691) ultraLongHaul(5)- ultra long haul (as defined in ITU-T G.691)

Gauge32 (0..900) · seconds

Number of seconds elapsed in the current 15-minute performance monitoring interval. If, for some reason, such as an adjustment in the NE's time-of-day clock, the number of seconds elapsed exceeds the maximum value, then the maximum value will be returned.

Gauge32 (0..86400) · seconds

Number of seconds elapsed in the current 24-hour interval performance monitoring period. If, for some reason, such as an adjustment in the NE's time-of-day clock, the number of seconds elapsed exceeds the maximum value, then the maximum value will be returned.

Unsigned32 (0..96)

The number of 15-minute intervals for which performance monitoring data is available. The number is the same for all the associated sub layers of the interface. An optical interface must be capable of supporting at least n intervals, where n is defined as follows: The minimum value of n is 4. The default of n is 32. The maximum value of n is 96. The value of this object will be n unless performance monitoring was (re-)started for the interface within the last (n*15) minutes, in which case the value will be the number of complete 15-minute intervals since measurement was (re-)started.

Unsigned32 (0..96)

The number of intervals in the range from 0 to optIfPerfMonIntervalNumIntervals for which no performance monitoring data is available and/or the data is invalid.

OptIfDirectionality1 = sink2 = source3 = bidirectionalIndicates the directionality of an entity. · Integer32

Indicates the directionality of the entity.

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..255) · OCTET STRING · hint 255t

This attribute indicates the status of the Automatic Power Reduction (APR) function of the entity. Valid values are 'on' and 'off'.

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..255) · OCTET STRING · hint 255t

This object is a UTF-8 encoded string that specifies Automatic Power Reduction (APR) control actions requested of this entity (when written) and that returns the current APR control state of this entity (when read). The values are implementation-defined. Any implementation that instantiates this object must document the set of values that it allows to be written, the set of values that it will return, and what each of those values means.

OptIfTxTIThe trace identifier (TI) transmitted. SIZE (64) · OCTET STRING

The trace identifier transmitted. This object is applicable when optIfOTSnDirectionality has the value source(2) or bidirectional(3). This object does not apply to reduced-capability systems (i.e., those for which optIfOTMnReduced has the value true(1)) or at IrDI interfaces (i.e., when optIfOTMnInterfaceType field 1 has the value 'IrDI'). If no value is ever set by a management entity for the object optIfOTSnTraceIdentifierTransmitted, system-specific default value will be used. Any implementation that instantiates this object must document the system-specific default value or how it is derived.

OptIfExDAPIThe Destination Access Point Identifier (DAPI) expected by the receiver. SIZE (16) · OCTET STRING

The DAPI expected by the receiver. This object is applicable when optIfOTSnDirectionality has the value sink(1) or bidirectional(3). It has no effect if optIfOTSnTIMDetMode has the value off(1) or sapi(3). This object does not apply to reduced-capability systems (i.e., those for which optIfOTMnReduced has the value true(1)) or at IrDI interfaces (i.e., when optIfOTMnInterfaceType field 1 has the value 'IrDI').

OptIfExSAPIThe Source Access Point Identifier (SAPI) expected by the receiver. SIZE (16) · OCTET STRING

The SAPI expected by the receiver. This object is applicable when optIfOTSnDirectionality has the value sink(1) or bidirectional(3). It has no effect if optIfOTSnTIMDetMode has the value off(1) or dapi(2). This object does not apply to reduced-capability systems (i.e., those for which optIfOTMnReduced has the value true(1)) or at IrDI interfaces (i.e., when optIfOTMnInterfaceType field 1 has the value 'IrDI').

OptIfAcTIThe trace identifier (TI) accepted at the receiver. SIZE (64) · OCTET STRING

The actual trace identifier received. This object is applicable when optIfOTSnDirectionality has the value sink(1) or bidirectional(3). Its value is unspecified if optIfOTSnCurrentStatus has either or both of the losO(5) and los(6) bits set. This object does not apply to reduced-capability systems (i.e., those for which optIfOTMnReduced has the value true(1)) or at IrDI interfaces (i.e., when optIfOTMnInterfaceType field 1 has the value 'IrDI').

OptIfTIMDetMode1 = off2 = dapi3 = sapi4 = bothIndicates the mode of the Trace Identifier Mismatch (TIM) Detection function. · Integer32

Indicates the mode of the Trace Identifier Mismatch (TIM) Detection function. This object is applicable when optIfOTSnDirectionality has the value sink(1) or bidirectional(3). The default value is off(1). This object does not apply to reduced-capability systems (i.e., those for which optIfOTMnReduced has the value true(1)) or at IrDI interfaces (i.e., when optIfOTMnInterfaceType field 1 has the value 'IrDI'). The default value of this object is off(1).

TruthValue1 = true2 = falseRepresents a boolean value. · Integer32

Indicates whether the Trace Identifier Mismatch (TIM) Consequent Action function is enabled. This object is applicable when optIfOTSnDirectionality has the value sink(1) or bidirectional(3). It has no effect when the value of optIfOTSnTIMDetMode is off(1). This object does not apply to reduced-capability systems (i.e., those for which optIfOTMnReduced has the value true(1)) or at IrDI interfaces (i.e., when optIfOTMnInterfaceType field 1 has the value 'IrDI'). The default value of this object is false(2).

BITS

Indicates the defect condition of the entity, if any. This object is applicable when optIfOTSnDirectionality has the value sink(1) or bidirectional(3). In reduced-capability systems or at IrDI interfaces the only bit position that may be set is los(6).

TruthValue1 = true2 = falseRepresents a boolean value. · Integer32

If true, the data in this entry may be unreliable.

Integer32 · 0.1 dbm

The optical power monitored at the input.

Integer32 · 0.1 dbm

The lowest optical power monitored at the input during the current 15-minute interval.

Integer32 · 0.1 dbm

The highest optical power monitored at the input during the current 15-minute interval.

Integer32 · 0.1 dbm

The lower limit threshold on input power. If optIfOTSnSinkCurrentInputPower drops to this value or below, a Threshold Crossing Alert (TCA) should be sent.

Integer32 · 0.1 dbm

The upper limit threshold on input power. If optIfOTSnSinkCurrentInputPower reaches or exceeds this value, a Threshold Crossing Alert (TCA) should be sent.

Integer32 · 0.1 dbm

The optical power monitored at the output.

Integer32 · 0.1 dbm

The lowest optical power monitored at the output during the current 15-minute interval.

Integer32 · 0.1 dbm

The highest optical power monitored at the output during the current 15-minute interval.

Integer32 · 0.1 dbm

The lower limit threshold on output power. If optIfOTSnSinkCurrentOutputPower drops to this value or below, a Threshold Crossing Alert (TCA) should be sent.

Integer32 · 0.1 dbm

The upper limit threshold on output power. If optIfOTSnSinkCurrentOutputPower reaches or exceeds this value, a Threshold Crossing Alert (TCA) should be sent.

OptIfIntervalNumberUniquely identifies a 15-minute interval. The interval identified by 1 is the most recently completed interval, and the interval identified by n is the interval immediately preceding the one identified by n-1. (1..96) · Unsigned32

Uniquely identifies the interval.

TruthValue1 = true2 = falseRepresents a boolean value. · Integer32

If true, the data in this entry may be unreliable.

Integer32 · 0.1 dbm

The last optical power monitored at the input during the interval.

Integer32 · 0.1 dbm

The lowest optical power monitored at the input during the interval.

Integer32 · 0.1 dbm

The highest optical power monitored at the input during the interval.

Integer32 · 0.1 dbm

The last optical power monitored at the output during the interval.

Integer32 · 0.1 dbm

The lowest optical power monitored at the output during the interval.

Integer32 · 0.1 dbm

The highest optical power monitored at the output during the interval.

TruthValue1 = true2 = falseRepresents a boolean value. · Integer32

If true, the data in this entry may be unreliable.

Integer32 · 0.1 dbm

The lowest optical power monitored at the input during the current 24-hour interval.

Integer32 · 0.1 dbm

The highest optical power monitored at the input during the current 24-hour interval.

Integer32 · 0.1 dbm

The lowest optical power monitored at the output during the current 24-hour interval.

Integer32 · 0.1 dbm

The highest optical power monitored at the output during the current 24-hour interval.

TruthValue1 = true2 = falseRepresents a boolean value. · Integer32

If true, the data in this entry may be unreliable.

Integer32 · 0.1 dbm

The last optical power monitored at the input during the previous 24-hour interval.

Integer32 · 0.1 dbm

The lowest optical power monitored at the input during the previous 24-hour interval.

Integer32 · 0.1 dbm

The highest optical power monitored at the input during the previous 24-hour interval.

Integer32 · 0.1 dbm

The last optical power monitored at the output during the previous 24-hour interval.

Integer32 · 0.1 dbm

The lowest optical power monitored at the output during the previous 24-hour interval.

Integer32 · 0.1 dbm

The highest optical power monitored at the output during the previous 24-hour interval.

TruthValue1 = true2 = falseRepresents a boolean value. · Integer32

If true, the data in this entry may be unreliable.

Integer32 · 0.1 dbm

The optical power monitored at the output.

Integer32 · 0.1 dbm

The lowest optical power monitored at the output during the current 15-minute interval.

Integer32 · 0.1 dbm

The highest optical power monitored at the output during the current 15-minute interval.

Integer32 · 0.1 dbm

The lower limit threshold on output power. If optIfOTSnSrcCurrentOutputPower drops to this value or below, a Threshold Crossing Alert (TCA) should be sent.

Integer32 · 0.1 dbm

The upper limit threshold on output power. If optIfOTSnSrcCurrentOutputPower reaches or exceeds this value, a Threshold Crossing Alert (TCA) should be sent.

Integer32 · 0.1 dbm

The optical power monitored at the input.

Integer32 · 0.1 dbm

The lowest optical power monitored at the input during the current 15-minute interval.

Integer32 · 0.1 dbm

The highest optical power monitored at the input during the current 15-minute interval.

Integer32 · 0.1 dbm

The lower limit threshold on input power. If optIfOTSnSrcCurrentInputPower drops to this value or below, a Threshold Crossing Alert (TCA) should be sent.

Integer32 · 0.1 dbm

The upper limit threshold on input power. If optIfOTSnSrcCurrentInputPower reaches or exceeds this value, a Threshold Crossing Alert (TCA) should be sent.

OptIfIntervalNumberUniquely identifies a 15-minute interval. The interval identified by 1 is the most recently completed interval, and the interval identified by n is the interval immediately preceding the one identified by n-1. (1..96) · Unsigned32

Uniquely identifies the interval.

TruthValue1 = true2 = falseRepresents a boolean value. · Integer32

If true, the data in this entry may be unreliable.

Integer32 · 0.1 dbm

The last optical power monitored at the output during the interval.

Integer32 · 0.1 dbm

The lowest optical power monitored at the output during the interval.

Integer32 · 0.1 dbm

The highest optical power monitored at the output during the interval.

Integer32 · 0.1 dbm

The last optical power monitored at the input during the interval.

Integer32 · 0.1 dbm

The lowest optical power monitored at the input during the interval.

Integer32 · 0.1 dbm

The highest optical power monitored at the input during the interval.

TruthValue1 = true2 = falseRepresents a boolean value. · Integer32

If true, the data in this entry may be unreliable.

Integer32 · 0.1 dbm

The lowest optical power monitored at the output during the current 24-hour interval.

Integer32 · 0.1 dbm

The highest optical power monitored at the output during the current 24-hour interval.

Integer32 · 0.1 dbm

The lowest optical power monitored at the input during the current 24-hour interval.

Integer32 · 0.1 dbm

The highest optical power monitored at the input during the current 24-hour interval.

TruthValue1 = true2 = falseRepresents a boolean value. · Integer32

If true, the data in this entry may be unreliable.

Integer32 · 0.1 dbm

The last optical power monitored at the output during the previous 24-hour interval.

Integer32 · 0.1 dbm

The lowest optical power monitored at the output during the previous 24-hour interval.

Integer32 · 0.1 dbm

The highest optical power monitored at the output during the previous 24-hour interval.

Integer32 · 0.1 dbm

The last optical power monitored at the input during the previous 24-hour interval.

Integer32 · 0.1 dbm

The lowest optical power monitored at the input during the previous 24-hour interval.

Integer32 · 0.1 dbm

The highest optical power monitored at the input during the previous 24-hour interval.

OptIfDirectionality1 = sink2 = source3 = bidirectionalIndicates the directionality of an entity. · Integer32

Indicates the directionality of the entity.

BITS

Indicates the defect condition of the entity, if any. This object is applicable only to full capability systems whose interface type is IaDI and for which optIfOMSnDirectionality has the value sink(1) or bidirectional(3).

TruthValue1 = true2 = falseRepresents a boolean value. · Integer32

If true, the data in this entry may be unreliable.

Integer32 · 0.1 dbm

The aggregated optical power of all the DWDM input channels.

Integer32 · 0.1 dbm

The lowest aggregated optical power of all the DWDM input channels during the current 15-minute interval.

Integer32 · 0.1 dbm

The highest aggregated optical power of all the DWDM input channels during the current 15-minute interval.

Integer32 · 0.1 dbm

The lower limit threshold on aggregated input power. If optIfOMSnSinkCurrentAggregatedInputPower drops to this value or below, a Threshold Crossing Alert (TCA) should be sent.

Integer32 · 0.1 dbm

The upper limit threshold on aggregated input power. If optIfOMSnSinkCurrentAggregatedInputPower reaches or exceeds this value, a Threshold Crossing Alert (TCA) should be sent.

Integer32 · 0.1 dbm

The optical power monitored at the output.

Integer32 · 0.1 dbm

The lowest optical power monitored at the output during the current 15-minute interval.

Integer32 · 0.1 dbm

The highest optical power monitored at the output during the current 15-minute interval.

Integer32 · 0.1 dbm

The lower limit threshold on output power. If optIfOMSnSinkCurrentOutputPower drops to this value or below, a Threshold Crossing Alert (TCA) should be sent.

Integer32 · 0.1 dbm

The upper limit threshold on output power. If optIfOMSnSinkCurrentOutputPower reaches or exceeds this value, a Threshold Crossing Alert (TCA) should be sent.

OptIfIntervalNumberUniquely identifies a 15-minute interval. The interval identified by 1 is the most recently completed interval, and the interval identified by n is the interval immediately preceding the one identified by n-1. (1..96) · Unsigned32

Uniquely identifies the interval.

TruthValue1 = true2 = falseRepresents a boolean value. · Integer32

If true, the data in this entry may be unreliable.

Integer32 · 0.1 dbm

The last aggregated optical power of all the DWDM input channels during the interval.

Integer32 · 0.1 dbm

The lowest aggregated optical power of all the DWDM input channels during the interval.

Integer32 · 0.1 dbm

The highest aggregated optical power of all the DWDM input channels during the interval.

Integer32 · 0.1 dbm

The last optical power at the output during the interval.

Integer32 · 0.1 dbm

The lowest optical power at the output during the interval.

Integer32 · 0.1 dbm

The highest optical power at the output during the interval.

TruthValue1 = true2 = falseRepresents a boolean value. · Integer32

If true, the data in this entry may be unreliable.

Integer32 · 0.1 dbm

The lowest aggregated optical power of all the DWDM input channels during the current 24-hour interval.

Integer32 · 0.1 dbm

The highest aggregated optical power of all the DWDM input channels during the current 24-hour interval.

Integer32 · 0.1 dbm

The lowest optical power at the output during the current 24-hour interval.

Integer32 · 0.1 dbm

The highest optical power at the output during the current 24-hour interval.

TruthValue1 = true2 = falseRepresents a boolean value. · Integer32

If true, the data in this entry may be unreliable.

Integer32 · 0.1 dbm

The last aggregated optical power of all the DWDM input channels during the previous 24-hour interval.

Integer32 · 0.1 dbm

The lowest aggregated optical power of all the DWDM input channels during the previous 24-hour interval.

Integer32 · 0.1 dbm

The highest aggregated optical power of all the DWDM input channels during the previous 24-hour interval.

Integer32 · 0.1 dbm

The last optical power at the output during the previous 24-hour interval.

Integer32 · 0.1 dbm

The lowest optical power at the output during the previous 24-hour interval.

Integer32 · 0.1 dbm

The highest optical power at the output during the previous 24-hour interval.

TruthValue1 = true2 = falseRepresents a boolean value. · Integer32

If true, the data in this entry may be unreliable.

Integer32 · 0.1 dbm

The optical power monitored at the output.

Integer32 · 0.1 dbm

The lowest optical power monitored at the output during the current 15-minute interval.

Integer32 · 0.1 dbm

The highest optical power monitored at the output during the current 15-minute interval.

Integer32 · 0.1 dbm

The lower limit threshold on output power. If optIfOMSnSrcCurrentOutputPower drops to this value or below, a Threshold Crossing Alert (TCA) should be sent.

Integer32 · 0.1 dbm

The upper limit threshold on output power. If optIfOMSnSrcCurrentOutputPower reaches or exceeds this value, a Threshold Crossing Alert (TCA) should be sent.

Integer32 · 0.1 dbm

The aggregated optical power at the input.

Integer32 · 0.1 dbm

The lowest aggregated optical power at the input during the current 15-minute interval.

Integer32 · 0.1 dbm

The highest aggregated optical power at the input during the current 15-minute interval.

Integer32 · 0.1 dbm

The lower limit threshold on aggregated input power. If optIfOMSnSrcCurrentAggregatedInputPower drops to this value or below, a Threshold Crossing Alert (TCA) should be sent.

Integer32 · 0.1 dbm

The upper limit threshold on aggregated input power. If optIfOMSnSrcCurrentAggregatedInputPower reaches or exceeds this value, a Threshold Crossing Alert (TCA) should be sent.

OptIfIntervalNumberUniquely identifies a 15-minute interval. The interval identified by 1 is the most recently completed interval, and the interval identified by n is the interval immediately preceding the one identified by n-1. (1..96) · Unsigned32

Uniquely identifies the interval.

TruthValue1 = true2 = falseRepresents a boolean value. · Integer32

If true, the data in this entry may be unreliable.

Integer32 · 0.1 dbm

The last optical power monitored at the output during the interval.

Integer32 · 0.1 dbm

The lowest optical power monitored at the output during the interval.

Integer32 · 0.1 dbm

The highest optical power monitored at the output during the interval.

Integer32 · 0.1 dbm

The last aggregated optical power at the input during the interval.

Integer32 · 0.1 dbm

The lowest aggregated optical power at the input during the interval.

Integer32 · 0.1 dbm

The highest aggregated optical power at the input during the interval.

TruthValue1 = true2 = falseRepresents a boolean value. · Integer32

If true, the data in this entry may be unreliable.

Integer32 · 0.1 dbm

The lowest optical power monitored at the output during the current 24-hour interval.

Integer32 · 0.1 dbm

The highest optical power monitored at the output during the current 24-hour interval.

Integer32 · 0.1 dbm

The lowest aggregated optical power at the input during the current 24-hour interval.

Integer32 · 0.1 dbm

The highest aggregated optical power at the input during the current 24-hour interval.

TruthValue1 = true2 = falseRepresents a boolean value. · Integer32

If true, the data in this entry may be unreliable.

Integer32 · 0.1 dbm

The last optical power monitored at the output during the previous 24-hour interval.

Integer32 · 0.1 dbm

The lowest optical power monitored at the output during the previous 24-hour interval.

Integer32 · 0.1 dbm

The highest optical power monitored at the output during the previous 24-hour interval.

Integer32 · 0.1 dbm

The last aggregated optical power at the input during the previous 24-hour interval.

Integer32 · 0.1 dbm

The lowest aggregated optical power at the input during the previous 24-hour interval.

Integer32 · 0.1 dbm

The highest aggregated optical power at the input during the previous 24-hour interval.

OptIfDirectionality1 = sink2 = source3 = bidirectionalIndicates the directionality of an entity. · Integer32

Indicates the directionality of the entity.

TruthValue1 = true2 = falseRepresents a boolean value. · Integer32

If true, the data in this entry may be unreliable.

Integer32 · 0.1 dbm

The aggregated optical power of all the DWDM input channels in the OChGroup.

Integer32 · 0.1 dbm

The lowest aggregated optical power of all the DWDM input channels in the OChGroup during the current 15-minute interval.

Integer32 · 0.1 dbm

The highest aggregated optical power of all the DWDM input channels in the OChGroup during the current 15-minute interval.

Integer32 · 0.1 dbm

The lower limit threshold on aggregated input power. If optIfOChGroupSinkCurrentAggregatedInputPower drops to this value or below, a Threshold Crossing Alert (TCA) should be sent.

Integer32 · 0.1 dbm

The upper limit threshold on aggregated input power. If optIfOChGroupSinkCurrentAggregatedInputPower reaches or exceeds this value, a Threshold Crossing Alert (TCA) should be sent.

Integer32 · 0.1 dbm

The optical power monitored at the output in the OChGroup.

Integer32 · 0.1 dbm

The lowest optical power monitored at the output in the OChGroup during the current 15-minute interval.

Integer32 · 0.1 dbm

The highest optical power monitored at the output in the OChGroup during the current 15-minute interval.

Integer32 · 0.1 dbm

The lower limit threshold on the output power. If optIfOChGroupSinkCurrentOutputPower drops to this value or below, a Threshold Crossing Alert (TCA) should be sent.

Integer32 · 0.1 dbm

The upper limit threshold on the output power. If optIfOChGroupSinkCurrentOutputPower reaches or exceeds this value, a Threshold Crossing Alert (TCA) should be sent.

OptIfIntervalNumberUniquely identifies a 15-minute interval. The interval identified by 1 is the most recently completed interval, and the interval identified by n is the interval immediately preceding the one identified by n-1. (1..96) · Unsigned32

Uniquely identifies the interval.

TruthValue1 = true2 = falseRepresents a boolean value. · Integer32

If true, the data in this entry may be unreliable.

Integer32 · 0.1 dbm

The last aggregated optical power of all the DWDM input channels in the OChGroup during the interval.

Integer32 · 0.1 dbm

The lowest aggregated optical power of all the DWDM input channels in the OChGroup during the interval.

Integer32 · 0.1 dbm

The highest aggregated optical power of all the DWDM input channels in the OChGroup during the interval.

Integer32 · 0.1 dbm

The last optical power monitored at the output in the OChGroup during the interval.

Integer32 · 0.1 dbm

The lowest optical power monitored at the output in the OChGroup during the interval.

Integer32 · 0.1 dbm

The highest optical power monitored at the output in the OChGroup during the interval.

TruthValue1 = true2 = falseRepresents a boolean value. · Integer32

If true, the data in this entry may be unreliable.

Integer32 · 0.1 dbm

The lowest aggregated optical power of all the DWDM input channels in the OChGroup during the current 24-hour interval.

Integer32 · 0.1 dbm

The highest aggregated optical power of all the DWDM input channels in the OChGroup during the current 24-hour interval.

Integer32 · 0.1 dbm

The lowest optical power monitored at the output in the OChGroup during the current 24-hour interval.

Integer32 · 0.1 dbm

The highest optical power monitored at the output in the OChGroup during the current 24-hour interval.

TruthValue1 = true2 = falseRepresents a boolean value. · Integer32

If true, the data in this entry may be unreliable.

Integer32 · 0.1 dbm

The last aggregated optical power of all the DWDM input channels in the OChGroup during the previous 24-hour interval.

Integer32 · 0.1 dbm

The lowest aggregated optical power of all the DWDM input channels in the OChGroup during the previous 24-hour interval.

Integer32 · 0.1 dbm

The highest aggregated optical power of all the DWDM input channels in the OChGroup during the previous 24-hour interval.

Integer32 · 0.1 dbm

The last optical power monitored at the output in the OChGroup during the previous 24-hour interval.

Integer32 · 0.1 dbm

The lowest optical power monitored at the output in the OChGroup during the previous 24-hour interval.

Integer32 · 0.1 dbm

The highest optical power monitored at the output in the OChGroup during the previous 24-hour interval.

TruthValue1 = true2 = falseRepresents a boolean value. · Integer32

If true, the data in this entry may be unreliable.

Integer32 · 0.1 dbm

The optical power monitored at the output.

Integer32 · 0.1 dbm

The lowest optical power monitored at the output during the current 15-minute interval.

Integer32 · 0.1 dbm

The highest optical power monitored at the output during the current 15-minute interval.

Integer32 · 0.1 dbm

The lower limit threshold on output power. If optIfOChGroupSrcCurrentOutputPower drops to this value or below, a Threshold Crossing Alert (TCA) should be sent.

Integer32 · 0.1 dbm

The upper limit threshold on output power. If optIfOChGroupSrcCurrentOutputPower reaches or exceeds this value, a Threshold Crossing Alert (TCA) should be sent.

Integer32 · 0.1 dbm

The aggregated optical power monitored at the input.

Integer32 · 0.1 dbm

The lowest aggregated optical power monitored at the input during the current 15-minute interval.

Integer32 · 0.1 dbm

The highest aggregated optical power monitored at the input during the current 15-minute interval.

Integer32 · 0.1 dbm

The lower limit threshold on input power. If optIfOChGroupSrcCurrentAggregatedInputPower drops to this value or below, a Threshold Crossing Alert (TCA) should be sent.

Integer32 · 0.1 dbm

The upper limit threshold on input power. If optIfOChGroupSrcCurrentAggregatedInputPower reaches or exceeds this value, a Threshold Crossing Alert (TCA) should be sent.

OptIfIntervalNumberUniquely identifies a 15-minute interval. The interval identified by 1 is the most recently completed interval, and the interval identified by n is the interval immediately preceding the one identified by n-1. (1..96) · Unsigned32

Uniquely identifies the interval.

TruthValue1 = true2 = falseRepresents a boolean value. · Integer32

If true, the data in this entry may be unreliable.

Integer32 · 0.1 dbm

The last optical power monitored at the output during the interval.

Integer32 · 0.1 dbm

The lowest optical power monitored at the output during the interval.

Integer32 · 0.1 dbm

The highest optical power monitored at the output during the interval.

Integer32 · 0.1 dbm

The last aggregated optical power monitored at the input during the interval.

Integer32 · 0.1 dbm

The lowest aggregated optical power monitored at the input during the interval.

Integer32 · 0.1 dbm

The highest aggregated optical power monitored at the input during the interval.

TruthValue1 = true2 = falseRepresents a boolean value. · Integer32

If true, the data in this entry may be unreliable.

Integer32 · 0.1 dbm

The lowest optical power monitored at the output during the current 24-hour interval.

Integer32 · 0.1 dbm

The highest optical power monitored at the output during the current 24-hour interval.

Integer32 · 0.1 dbm

The lowest aggregated optical power monitored at the input during the current 24-hour interval.

Integer32 · 0.1 dbm

The highest aggregated optical power monitored at the input during the current 24-hour interval.

TruthValue1 = true2 = falseRepresents a boolean value. · Integer32

If true, the data in this entry may be unreliable.

Integer32 · 0.1 dbm

The last optical power monitored at the output during the previous 24-hour interval.

Integer32 · 0.1 dbm

The lowest optical power monitored at the output during the previous 24-hour interval.

Integer32 · 0.1 dbm

The highest optical power monitored at the output during the previous 24-hour interval.

Integer32 · 0.1 dbm

The last aggregated optical power monitored at the input during the previous 24-hour interval.

Integer32 · 0.1 dbm

The lowest aggregated optical power monitored at the input during the previous 24-hour interval.

Integer32 · 0.1 dbm

The highest aggregated optical power monitored at the input during the previous 24-hour interval.

OptIfDirectionality1 = sink2 = source3 = bidirectionalIndicates the directionality of an entity. · Integer32

Indicates the directionality of the entity.

BITS

Indicates the defect condition of the entity, if any. This object is applicable when optIfOChDirectionality has the value sink(1) or bidirectional(3). In full-capability systems the bit position los(1) is not used. In reduced-capability systems or at IrDI interfaces only the bit positions los(1) and ssfP(3) are used.

TruthValue1 = true2 = falseRepresents a boolean value. · Integer32

If true, the data in this entry may be unreliable.

Integer32 · 0.1 dbm

The optical power monitored at the input.

Integer32 · 0.1 dbm

The lowest optical power monitored at the input during the current 15-minute interval.

Integer32 · 0.1 dbm

The highest optical power monitored at the input during the current 15-minute interval.

Integer32 · 0.1 dbm

The lower limit threshold on input power. If optIfOChSinkCurrentInputPower drops to this value or below, a Threshold Crossing Alert (TCA) should be sent.

Integer32 · 0.1 dbm

The upper limit threshold on input power. If optIfOChSinkCurrentInputPower reaches or exceeds this value, a Threshold Crossing Alert (TCA) should be sent.

OptIfIntervalNumberUniquely identifies a 15-minute interval. The interval identified by 1 is the most recently completed interval, and the interval identified by n is the interval immediately preceding the one identified by n-1. (1..96) · Unsigned32

Uniquely identifies the interval.

TruthValue1 = true2 = falseRepresents a boolean value. · Integer32

If true, the data in this entry may be unreliable.

Integer32 · 0.1 dbm

The last optical power monitored at the input during the interval.

Integer32 · 0.1 dbm

The lowest optical power monitored at the input during the interval.

Integer32 · 0.1 dbm

The highest optical power monitored at the input during the interval.

TruthValue1 = true2 = falseRepresents a boolean value. · Integer32

If true, the data in this entry may be unreliable.

Integer32 · 0.1 dbm

The lowest optical power monitored at the input during the current 24-hour interval.

Integer32 · 0.1 dbm

The highest optical power monitored at the input during the current 24-hour interval.

TruthValue1 = true2 = falseRepresents a boolean value. · Integer32

If true, the data in this entry may be unreliable.

Integer32 · 0.1 dbm

The last optical power monitored at the input during the previous 24-hour interval.

Integer32 · 0.1 dbm

The lowest optical power monitored at the input during the previous 24-hour interval.

Integer32 · 0.1 dbm

The highest optical power monitored at the input during the previous 24-hour interval.

TruthValue1 = true2 = falseRepresents a boolean value. · Integer32

If true, the data in this entry may be unreliable.

Integer32 · 0.1 dbm

The optical power monitored at the output.

Integer32 · 0.1 dbm

The lowest optical power monitored at the output during the current 15-minute interval.

Integer32 · 0.1 dbm

The highest optical power monitored at the output during the current 15-minute interval.

Integer32 · 0.1 dbm

The lower limit threshold on output power. If optIfOChSrcCurrentOutputPower drops to this value or below, a Threshold Crossing Alert (TCA) should be sent.

Integer32 · 0.1 dbm

The upper limit threshold on output power. If optIfOChSrcCurrentOutputPower reaches or exceeds this value, a Threshold Crossing Alert (TCA) should be sent.

OptIfIntervalNumberUniquely identifies a 15-minute interval. The interval identified by 1 is the most recently completed interval, and the interval identified by n is the interval immediately preceding the one identified by n-1. (1..96) · Unsigned32

Uniquely identifies the interval.

TruthValue1 = true2 = falseRepresents a boolean value. · Integer32

If true, the data in this entry may be unreliable.

Integer32 · 0.1 dbm

The last optical power monitored at the output during the interval.

Integer32 · 0.1 dbm

The lowest optical power monitored at the output during the interval.

Integer32 · 0.1 dbm

The highest optical power monitored at the output during the interval.

TruthValue1 = true2 = falseRepresents a boolean value. · Integer32

If true, the data in this entry may be unreliable.

Integer32 · 0.1 dbm

The lowest optical power monitored at the output during the current 24-hour interval.

Integer32 · 0.1 dbm

The highest optical power monitored at the output during the current 24-hour interval.

TruthValue1 = true2 = falseRepresents a boolean value. · Integer32

If true, the data in this entry may be unreliable.

Integer32 · 0.1 dbm

The last optical power monitored at the output during the previous 24-hour interval.

Integer32 · 0.1 dbm

The lowest optical power monitored at the output during the previous 24-hour interval.

Integer32 · 0.1 dbm

The highest optical power monitored at the output during the previous 24-hour interval.

OptIfDirectionality1 = sink2 = source3 = bidirectionalIndicates the directionality of an entity. · Integer32

Indicates the directionality of the entity.

OptIfBitRateKIndicates the index 'k' that is used to represent a supported bit rate and the different versions of OPUk, ODUk and OTUk. Allowed values of k are defined in ITU-T G.709. Currently allowed values in G.709 are: k=1 represents an approximate bit rate of 2.5 Gbit/s, k=2 represents an approximate bit rate of 10 Gbit/s, k=3 represents an approximate bit rate of 40 Gbit/s. · Integer32

Indicates the bit rate of the entity.

OptIfTxTIThe trace identifier (TI) transmitted. SIZE (64) · OCTET STRING

The trace identifier transmitted. This object is applicable when optIfOTUkDirectionality has the value source(2) or bidirectional(3). It must not be instantiated in rows where optIfOTUkDirectionality has the value sink(1). If no value is ever set by a management entity for this object, system-specific default value will be used. Any implementation that instantiates this object must document the system-specific default value or how it is derived.

OptIfExDAPIThe Destination Access Point Identifier (DAPI) expected by the receiver. SIZE (16) · OCTET STRING

The DAPI expected by the receiver. This object is only applicable to the sink function, i.e., only when optIfOTUkDirectionality has the value sink(1) or bidirectional(3). It must not be instantiated in rows where optIfOTUkDirectionality has the value source(2). This object has no effect when optIfOTUkTIMDetMode has the value off(1).

OptIfExSAPIThe Source Access Point Identifier (SAPI) expected by the receiver. SIZE (16) · OCTET STRING

The SAPI expected by the receiver. This object is only applicable to the sink function, i.e., only when optIfOTUkDirectionality has the value sink(1) or bidirectional(3). It must not be instantiated in rows where optIfOTUkDirectionality has the value source(2). This object has no effect when optIfOTUkTIMDetMode has the value off(1).

OptIfAcTIThe trace identifier (TI) accepted at the receiver. SIZE (64) · OCTET STRING

The actual trace identifier accepted. This object is only applicable to the sink function, i.e., only when optIfOTUkDirectionality has the value sink(1) or bidirectional(3). It must not be instantiated in rows where optIfOTUkDirectionality has the value source(2). The value of this object is unspecified when optIfOTUkCurrentStatus indicates a near-end defect (i.e., ssf(3), lof(4), ais(5), lom(6)) that prevents extraction of the trace message.

OptIfTIMDetMode1 = off2 = dapi3 = sapi4 = bothIndicates the mode of the Trace Identifier Mismatch (TIM) Detection function. · Integer32

Indicates the mode of the Trace Identifier Mismatch (TIM) Detection function. This object is only applicable to the sink function, i.e., only when optIfOTUkDirectionality has the value sink(1) or bidirectional(3). It must not be instantiated in rows where optIfOTUkDirectionality has the value source(2). The default value of this object is off(1).

TruthValue1 = true2 = falseRepresents a boolean value. · Integer32

Indicates whether the Trace Identifier Mismatch (TIM) Consequent Action function is enabled. This object is only applicable to the sink function, i.e., only when optIfOTUkDirectionality has the value sink(1) or bidirectional(3). It must not be instantiated in rows where optIfOTUkDirectionality has the value source(2). This object has no effect when optIfOTUkTIMDetMode has the value off(1). The default value of this object is false(2).

OptIfDEGThrIndicates the threshold level for declaring a performance monitoring (PM) Second to be bad. A PM Second is declared bad if the percentage of detected errored blocks in that second is greater than or equal to OptIfDEGThr. (1..100) · Unsigned32 · percentage

Indicates the threshold level for declaring a performance monitoring (PM) Second to be bad. A PM Second is declared bad if the percentage of detected errored blocks in that second is greater than or equal to optIfOTUkDEGThr. This object is only applicable to the sink function, i.e., only when optIfOTUkDirectionality has the value sink(1) or bidirectional(3). It must not be instantiated in rows where optIfOTUkDirectionality has the value source(2). The default value of this object is Severely Errored Second (SES) Estimator (See ITU-T G.7710).

OptIfDEGMIndicates the threshold level for declaring a Degraded Signal defect (dDEG). A dDEG shall be declared if OptIfDEGM consecutive bad PM Seconds are detected. (2..10) · Unsigned32

Indicates the threshold level for declaring a Degraded Signal defect (dDEG). A dDEG shall be declared if optIfOTUkDEGM consecutive bad PM Seconds are detected. This object is only applicable to the sink function, i.e., only when optIfOTUkDirectionality has the value sink(1) or bidirectional(3). It must not be instantiated in rows where optIfOTUkDirectionality has the value source(2). The default value of this object is 7 (See ITU-T G.7710).

TruthValue1 = true2 = falseRepresents a boolean value. · Integer32

Indicates whether the sink adaptation function is activated or not. This object is only applicable to the sink function, i.e., only when optIfOTUkDirectionality has the value sink(1) or bidirectional(3). It must not be instantiated in rows where optIfOTUkDirectionality has the value source(2). The default value of this object is false(2).

TruthValue1 = true2 = falseRepresents a boolean value. · Integer32

Indicates whether the source adaptation function is activated or not. This object is only applicable to the source function, i.e., only when optIfOTUkDirectionality has the value source(2) or bidirectional(3). It must not be instantiated in rows where optIfOTUkDirectionality has the value sink(1). The default value of this object is false(2).

TruthValue1 = true2 = falseRepresents a boolean value. · Integer32

If Forward Error Correction (FEC) is supported, this object indicates whether FEC at the OTUk sink adaptation function is enabled or not. This object is only applicable to the sink function, i.e., only when optIfOTUkDirectionality has the value sink(1) or bidirectional(3). It must not be instantiated in rows where optIfOTUkDirectionality has the value source(2). The default value of this object is true(1).

BITS

Indicates the defect condition of the entity, if any. This object is only applicable to the sink function, i.e., only when optIfOTUkDirectionality has the value sink(1) or bidirectional(3). It must not be instantiated in rows where optIfOTUkDirectionality has the value source(2).

OptIfDirectionality1 = sink2 = source3 = bidirectionalIndicates the directionality of an entity. · Integer32

Indicates the directionality of the entity. The values source(2) and bidirectional(3) are not allowed if the corresponding instance of optIfOTUkDirectionality has the value sink(1). The values sink(1) and bidirectional(3) are not allowed if the corresponding instance of optIfOTUkDirectionality has the value source(2).

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..255) · OCTET STRING · hint 255t

Indicates the application transported by the GCC0 entity. Example applications are ECC, User data channel. The value of this object may not be changed when optIfGCC0RowStatus has the value active(1).

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 columnar object is used for creating and deleting a conceptual row of the optIfGCC0 config table. It is used to model the addGCC0Access and removeGCC0Access operations of an OTUk_TTP for GCC0 access control as defined in G.874.1. Setting RowStatus to createAndGo or createAndWait implies addGCC0Access. Setting RowStatus to destroy implies removeGCC0Access.

OptIfDirectionality1 = sink2 = source3 = bidirectionalIndicates the directionality of an entity. · Integer32

Indicates the directionality of the entity.

OptIfBitRateKIndicates the index 'k' that is used to represent a supported bit rate and the different versions of OPUk, ODUk and OTUk. Allowed values of k are defined in ITU-T G.709. Currently allowed values in G.709 are: k=1 represents an approximate bit rate of 2.5 Gbit/s, k=2 represents an approximate bit rate of 10 Gbit/s, k=3 represents an approximate bit rate of 40 Gbit/s. · Integer32

Indicates the bit rate of the entity.

BITS

Indicates the TCM field(s) that are currently in use. The positions of the bits correspond to the TCM fields. A bit that is set to 1 means that the corresponding TCM field is used. This object will be updated when rows are created in or deleted from the optIfODUkTConfigTable, or the optIfODUkTNimConfigTable.

Unsigned32

This variable indicates the current size of the position sequence (i.e., number of TCM function and/or GCC12 access that have been created in the ODUk interface). When the value of this variable is greater than zero, it means that one or more TCM function and/or GCC12 access have been created in the ODUk interface. In this case, there will be as many rows in the optIfODUkPositionSeqTable as the value of optIfODUkPositionSeqCurrentSize corresponding to this ODUk interface, one row for each TCM function or GCC12 access. The position of the TCM function and/or GCC12 access within the sequence is indicated by the optIfODUkPositionSeqPosition variable in optIfODUkPositionSeqTable. The optIfODUkPositionSeqTable also provides pointers to the corresponding TCM function (optIfODUkT) and GCC12 access (optIfGCC12) entities.

TruthValue1 = true2 = falseRepresents a boolean value. · Integer32

This object has the value true(1) if the ifEntry under which it is instantiated contains an ODUk Trail Termination Point, i.e., is the endpoint of an ODUk path. In that case there will be a corresponding row in the ODUk TTP config table and it will not be possible to create corresponding rows in the ODUk NIM config table. This object has the value false(2) if the ifEntry under which it is instantiated contains an intermediate ODUk Connection Termination Point. In that case there is no corresponding row in the ODUk TTP config table, but it will be possible to create corresponding rows in the ODUk NIM config table. This object also affects the allowable options in rows created in the GCC12 config table and in the ODUkT config table, as specified in the DESCRIPTION clauses of the columns in those tables.

OptIfTxTIThe trace identifier (TI) transmitted. SIZE (64) · OCTET STRING

The trace identifier transmitted. This object is applicable when optIfODUkDirectionality has the value source(2) or bidirectional(3). It must not be instantiated in rows where optIfODUkDirectionality has the value sink(1). If no value is ever set by a management entity for this object, system-specific default value will be used. Any implementation that instantiates this object must document the system-specific default value or how it is derived.

OptIfExDAPIThe Destination Access Point Identifier (DAPI) expected by the receiver. SIZE (16) · OCTET STRING

The DAPI expected by the receiver. This object is only applicable to the sink function, i.e., only when optIfODUkDirectionality has the value sink(1) or bidirectional(3). It must not be instantiated in rows where optIfODUkDirectionality has the value source(2). This object has no effect when optIfODUkTtpTIMDetMode has the value off(1).

OptIfExSAPIThe Source Access Point Identifier (SAPI) expected by the receiver. SIZE (16) · OCTET STRING

The SAPI expected by the receiver. This object is only applicable to the sink function, i.e., only when optIfODUkDirectionality has the value sink(1) or bidirectional(3). It must not be instantiated in rows where optIfODUkDirectionality has the value source(2). This object has no effect when optIfODUkTtpTIMDetMode has the value off(1).

OptIfAcTIThe trace identifier (TI) accepted at the receiver. SIZE (64) · OCTET STRING

The actual trace identifier accepted. This object is only applicable to the sink function, i.e., only when optIfODUkDirectionality has the value sink(1) or bidirectional(3). It must not be instantiated in rows where optIfODUkDirectionality has the value source(2). The value of this object is unspecified when optIfODUkTtpCurrentStatus indicates a near-end defect (i.e., oci(0), lck(1), ssf(5)) that prevents extraction of the trace message.

OptIfTIMDetMode1 = off2 = dapi3 = sapi4 = bothIndicates the mode of the Trace Identifier Mismatch (TIM) Detection function. · Integer32

Indicates the mode of the Trace Identifier Mismatch (TIM) Detection function. This object is only applicable to the sink function, i.e., only when optIfODUkDirectionality has the value sink(1) or bidirectional(3). It must not be instantiated in rows where optIfODUkDirectionality has the value source(2). The default value of this object is off(1).

TruthValue1 = true2 = falseRepresents a boolean value. · Integer32

Indicates whether the Trace Identifier Mismatch (TIM) Consequent Action function is enabled. This object is only applicable to the sink function, i.e., only when optIfODUkDirectionality has the value sink(1) or bidirectional(3). It must not be instantiated in rows where optIfODUkDirectionality has the value source(2). This object has no effect when optIfODUkTtpTIMDetMode has the value off(1). The default value of this object is false(2).

OptIfDEGThrIndicates the threshold level for declaring a performance monitoring (PM) Second to be bad. A PM Second is declared bad if the percentage of detected errored blocks in that second is greater than or equal to OptIfDEGThr. (1..100) · Unsigned32 · percentage

Indicates the threshold level for declaring a performance monitoring (PM) Second to be bad. A PM Second is declared bad if the percentage of detected errored blocks in that second is greater than or equal to optIfODUkDEGThr. This object is only applicable to the sink function, i.e., only when optIfODUkDirectionality has the value sink(1) or bidirectional(3). It must not be instantiated in rows where optIfODUkDirectionality has the value source(2). The default value of this object is Severely Errored Second (SES) Estimator (See ITU-T G.7710).

OptIfDEGMIndicates the threshold level for declaring a Degraded Signal defect (dDEG). A dDEG shall be declared if OptIfDEGM consecutive bad PM Seconds are detected. (2..10) · Unsigned32

Indicates the threshold level for declaring a Degraded Signal defect (dDEG). A dDEG shall be declared if optIfODUkDEGM consecutive bad PM Seconds are detected. This object is only applicable to the sink function, i.e., only when optIfODUkDirectionality has the value sink(1) or bidirectional(3). It must not be instantiated in rows where optIfODUkDirectionality has the value source(2). The default value of this object is 7 (See ITU-T G.7710).

BITS

Indicates the defect condition of the entity, if any. This object is only applicable to the sink function, i.e., only when optIfODUkDirectionality has the value sink(1) or bidirectional(3). It must not be instantiated in rows where optIfODUkDirectionality has the value source(2).

Unsigned32 (1..4294967295)

This variable identifies a row in the optIfODUkPositionSeqTable Table. Each row of the optIfODUkPositionSeqTable Table represents a TCM or GCC12 access function within the associated ODUk interface.

Unsigned32

This variable indicates the position of the TCM or GCC12 access function within the sequence of TCMs & GCC12 access functions of the associated ODUk interface. The TCM or GCC12 presented by this row is referenced by the optIfODUkPositionSeqPointer variable.

RowPointerRepresents a pointer to a conceptual row. The value is the name of the instance of the first accessible columnar object in the conceptual row. For example, ifIndex.3 would point to the 3rd row in the ifTable (note that if ifIndex were not-accessible, then ifDescr.3 would be used instead). · OBJECT IDENTIFIER

This variable identifies the TCM or GCC12 access function by pointing to the corresponding optIfODUkT or optIfGCC12 entity.

OptIfSinkOrSource1 = sink2 = sourceIndicates the directionality of an entity that is allowed only to be a source or sink. · Integer32

Specifies the monitor point for the ODUk Path non-intrusive monitoring function. The value source(2) is not allowed if the corresponding instance of optIfODUkDirectionality has the value sink(1), and the value sink(1) is not allowed if the corresponding instance of optIfODUkDirectionality has the value source(2). Either the value sink(1) or source(2) is allowed if the corresponding instance of optIfODUkDirectionality has the value bidirectional(3). The value sink(1) means monitoring at the sink direction path signal of the ODUk CTP. The value source(2) means monitoring at the source direction path signal of the ODUk CTP. Monitoring the source direction of an ODUk CTP is necessary in those cases where the ODUk CTP is at an SNCP (Subnetwork Connection Protection) end (e.g., see Figure I.1.2/G.874.1). If one would like to get the performance of the protected connection, one cannot use the NIM function at both ODUk CTP sinks (before the matrix), instead one should monitor the signal at the source ODUk CTP after the matrix.

OptIfExDAPIThe Destination Access Point Identifier (DAPI) expected by the receiver. SIZE (16) · OCTET STRING

The DAPI expected by the receiver. This object has no effect if optIfODUkNimTIMDetMode has the value off(1) or sapi(3).

OptIfExSAPIThe Source Access Point Identifier (SAPI) expected by the receiver. SIZE (16) · OCTET STRING

The SAPI expected by the receiver. This object has no effect if optIfODUkNimTIMDetMode has the value off(1) or dapi(2).

OptIfAcTIThe trace identifier (TI) accepted at the receiver. SIZE (64) · OCTET STRING

The actual trace identifier accepted. The value of this object is unspecified if optIfODUkNimCurrentStatus has any of the bit positions oci(0), lck(1), or ssf(5) set or if optIfODUkNimRowStatus has any value other than active(1).

OptIfTIMDetMode1 = off2 = dapi3 = sapi4 = bothIndicates the mode of the Trace Identifier Mismatch (TIM) Detection function. · Integer32

Indicates the mode of the Trace Identifier Mismatch (TIM) Detection function.

TruthValue1 = true2 = falseRepresents a boolean value. · Integer32

Indicates whether the Trace Identifier Mismatch (TIM) Consequent Action function is enabled.

OptIfDEGThrIndicates the threshold level for declaring a performance monitoring (PM) Second to be bad. A PM Second is declared bad if the percentage of detected errored blocks in that second is greater than or equal to OptIfDEGThr. (1..100) · Unsigned32 · percentage

Indicates the threshold level for declaring a performance monitoring (PM) Second to be bad. A PM Second is declared bad if the percentage of detected errored blocks in that second is greater than or equal to optIfODUkNimDEGThr.

OptIfDEGMIndicates the threshold level for declaring a Degraded Signal defect (dDEG). A dDEG shall be declared if OptIfDEGM consecutive bad PM Seconds are detected. (2..10) · Unsigned32

Indicates the threshold level for declaring a Degraded Signal defect (dDEG). A dDEG shall be declared if optIfODUkNimDEGM consecutive bad PM Seconds are detected.

BITS

Indicates the defect condition of the entity, if any. The value of this object is unspecified if optIfODUkNimRowStatus has any value other than active(1).

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 columnar object is used for creating and deleting a conceptual row of the optIfODUkNim config table. It is used to model the activateNim and deactivateNim operations of an OTUk_CTP for non-intrusive monitoring control as defined in G.874.1. Setting RowStatus to createAndGo or createAndWait implies activateNim. Setting RowStatus to destroy implies deactivateNim.

TruthValue1 = true2 = falseRepresents a boolean value. · Integer32

Indicates the directionality of the GCC12 termination with respect to the associated ODUk CTP. The value true(1) means that the sink part of the GCC12 extracts COMMS data from the signal at the input to the ODUk CTP sink and the source part of the GCC12 inserts COMMS data into the signal at the output of the ODUk CTP source. The value false(2) means that the sink part of the GCC12 extracts COMMS data from the signal at the output of the ODUk CTP source and the source part of the GCC12 inserts COMMS data into the signal at the input of the ODUk CTP sink. This attribute may assume either value when the corresponding instance of optIfODUkTtpPresent has the value false(2). When the value of the corresponding instance of optIfODUkTtpPresent is true(1) then the only value allowed for this attribute is true(1).

INTEGER1 = gcc12 = gcc23 = gcc1and2 · Integer32

Indicates the GCC access represented by the entity.

TruthValue1 = true2 = falseRepresents a boolean value. · Integer32

Controls whether the selected GCC overhead bytes are passed through or modified. The value true(1) means that the selected GCC overhead bytes are passed through unmodified from the ODUk CTP input to the ODUk CTP output. The value false(2) means that the selected GCC overhead bytes are set to zero at the ODUk CTP output after the extraction of the COMMS data. This object has no effect if the corresponding instance of optIfODUkTtpPresent has the value true(1). The value of this object may not be changed when optIfGCC12RowStatus has the value active(1).

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..255) · OCTET STRING · hint 255t

Indicates the application transported by the GCC12 entity. Example applications are ECC, User data channel. The value of this object may not be changed when optIfGCC12RowStatus has the value active(1).

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 columnar object is used for creating and deleting a conceptual row of the optIfGCC12 config table. It is used to model the addGCC12Access and removeGCC12Access operations of an ODUk_CTP or ODUk_TTP for GCC12 access control as defined in G.874.1. Setting RowStatus to createAndGo or createAndWait implies addGCC12Access. Setting RowStatus to destroy implies removeGCC12Access. Successful addition/removal of the GCC12 access function will result in updating the optIfODUkPositionSeqCurrentSize variable and the optIfODUkPositionSeqTable table of the associated ODUk entry in the optIfODUkConfigTable.

Unsigned32 (1..6)

Indicates the tandem connection monitoring field of the ODUk OH. Valid values are integers from 1 to 6.

TruthValue1 = true2 = falseRepresents a boolean value. · Integer32

Indicates the directionality of the ODUkT termination point with respect to the associated ODUk CTP. The value true(1) means that the sink part of the ODUkT TP extracts TCM data from the signal at the input to the ODUk CTP sink and the source part of the ODUkT TP inserts TCM data into the signal at the output of the ODUk CTP source. The value false(2) means that the sink part of the ODUkT TP extracts TCM data from the signal at the output of the ODUk CTP source and the source part of the ODUkT TP inserts TCM data into the signal at the input of the ODUk CTP sink. This attribute may assume either value when the corresponding instance of optIfODUkTtpPresent has the value false(2). When the value of the corresponding instance of optIfODUkTtpPresent is true(1) then the only value allowed for this attribute is true(1).

OptIfTxTIThe trace identifier (TI) transmitted. SIZE (64) · OCTET STRING

The trace identifier transmitted. This object is applicable only to the following three cases. (i) optIfODUkDirectionality has the value bidirectional(3), or (ii) optIfODUkDirectionality has the value sink(1) and optIfODUkTCodirectional has the value false(2), or (iii) optIfODUkDirectionality has the value source(3) and optIfODUkTCodirectional has the value true(1). It must not be instantiated in rows for all other cases.

OptIfExDAPIThe Destination Access Point Identifier (DAPI) expected by the receiver. SIZE (16) · OCTET STRING

The DAPI expected by the receiver. This object is applicable only to the following three cases. (i) optIfODUkDirectionality has the value bidirectional(3), or (ii) optIfODUkDirectionality has the value sink(1) and optIfODUkTCodirectional has the value true(1), or (iii) optIfODUkDirectionality has the value source(3) and optIfODUkTCodirectional has the value false(2). It must not be instantiated in rows for all other cases. This object has no effect when optIfODUkTTIMDetMode has the value off(1).

OptIfExSAPIThe Source Access Point Identifier (SAPI) expected by the receiver. SIZE (16) · OCTET STRING

The SAPI expected by the receiver. This object is applicable only to the following three cases. (i) optIfODUkDirectionality has the value bidirectional(3), or (ii) optIfODUkDirectionality has the value sink(1) and optIfODUkTCodirectional has the value true(1), or (iii) optIfODUkDirectionality has the value source(3) and optIfODUkTCodirectional has the value false(2). It must not be instantiated in rows for all other cases. This object has no effect when optIfODUkTTIMDetMode has the value off(1).

OptIfAcTIThe trace identifier (TI) accepted at the receiver. SIZE (64) · OCTET STRING

The actual trace identifier accepted. This object is applicable only to the following three cases. (i) optIfODUkDirectionality has the value bidirectional(3), or (ii) optIfODUkDirectionality has the value sink(1) and optIfODUkTCodirectional has the value true(1), or (iii) optIfODUkDirectionality has the value source(3) and optIfODUkTCodirectional has the value false(2). It must not be instantiated in rows for all other cases. The value of this object is unspecified when optIfODUkTCurrentStatus indicates a near-end defect (i.e., oci(0), lck(1), ssf(5)) that prevents extraction of the trace message.

OptIfTIMDetMode1 = off2 = dapi3 = sapi4 = bothIndicates the mode of the Trace Identifier Mismatch (TIM) Detection function. · Integer32

Indicates the mode of the Trace Identifier Mismatch (TIM) Detection function. This object is applicable only to the following three cases. (i) optIfODUkDirectionality has the value bidirectional(3), or (ii) optIfODUkDirectionality has the value sink(1) and optIfODUkTCodirectional has the value true(1), or (iii) optIfODUkDirectionality has the value source(3) and optIfODUkTCodirectional has the value false(2). It must not be instantiated in rows for all other cases. The default value of this object is off(1).

TruthValue1 = true2 = falseRepresents a boolean value. · Integer32

Indicates whether the Trace Identifier Mismatch (TIM) Consequent Action function is enabled. This object is applicable only to the following three cases. (i) optIfODUkDirectionality has the value bidirectional(3), or (ii) optIfODUkDirectionality has the value sink(1) and optIfODUkTCodirectional has the value true(1), or (iii) optIfODUkDirectionality has the value source(3) and optIfODUkTCodirectional has the value false(2). It must not be instantiated in rows for all other cases. This object has no effect when optIfODUkTTIMDetMode has the value off(1). The default value of this object is false(2).

OptIfDEGThrIndicates the threshold level for declaring a performance monitoring (PM) Second to be bad. A PM Second is declared bad if the percentage of detected errored blocks in that second is greater than or equal to OptIfDEGThr. (1..100) · Unsigned32 · percentage

Indicates the threshold level for declaring a performance monitoring (PM) Second to be bad. A PM Second is declared bad if the percentage of detected errored blocks in that second is greater than or equal to optIfODUkTDEGThr. This object is applicable only to the following three cases. (i) optIfODUkDirectionality has the value bidirectional(3), or (ii) optIfODUkDirectionality has the value sink(1) and optIfODUkTCodirectional has the value true(1), or (iii) optIfODUkDirectionality has the value source(3) and optIfODUkTCodirectional has the value false(2). It must not be instantiated in rows for all other cases. The default value of this object is Severely Errored Second (SES) Estimator (See ITU-T G.7710).

OptIfDEGMIndicates the threshold level for declaring a Degraded Signal defect (dDEG). A dDEG shall be declared if OptIfDEGM consecutive bad PM Seconds are detected. (2..10) · Unsigned32

Indicates the threshold level for declaring a Degraded Signal defect (dDEG). A dDEG shall be declared if optIfODUkTDEGM consecutive bad PM Seconds are detected. This object is applicable only to the following three cases. (i) optIfODUkDirectionality has the value bidirectional(3), or (ii) optIfODUkDirectionality has the value sink(1) and optIfODUkTCodirectional has the value true(1), or (iii) optIfODUkDirectionality has the value source(3) and optIfODUkTCodirectional has the value false(2). It must not be instantiated in rows for all other cases. The default value of this object is 7 (See ITU-T G.7710).

INTEGER1 = operational2 = monitor · Integer32

This variable specifies the TCM mode at the entity. The value operational(1) means that TCM Overhead (TCMOH) processes (see ITU-T G.798) shall be performed and consequent actions for AIS, Trail Signal Fail (TSF), Trail Signal Degraded (TSD) shall be initiated in case of defects. The value monitor(2) means that TCMOH processes shall be performed but consequent actions for AIS, Trail Server Failure (TSF), Trail Server Degraded (TSD) shall _not_ be initiated in case of defects. This object is applicable only when the value of optIfODUkTtpPresent is false(2) and also either one of the following three cases holds: (i) optIfODUkDirectionality has the value bidirectional(3), or (ii) optIfODUkDirectionality has the value sink(1) and optIfODUkTCodirectional has the value true(1), or (iii) optIfODUkDirectionality has the value source(3) and optIfODUkTCodirectional has the value false(2). It must not be instantiated in rows for all other cases.

INTEGER1 = locked2 = normal · Integer32

Provides the capability to provision the LOCK signal, which is one of the ODUk maintenance signals, at the ODUKT sink. When a Tandem Connection endpoint is set to admin state locked, it inserts the ODUk-LCK signal in the sink direction. This object is applicable only when the value of optIfODUkTtpPresent is false(2) and also either one of the following three cases holds: (i) optIfODUkDirectionality has the value bidirectional(3), or (ii) optIfODUkDirectionality has the value sink(1) and optIfODUkTCodirectional has the value true(1), or (iii) optIfODUkDirectionality has the value source(3) and optIfODUkTCodirectional has the value false(2). It must not be instantiated in rows for all other cases.

INTEGER1 = locked2 = normal · Integer32

Provides the capability to provision the LOCK signal, which is one of the ODUk maintenance signals, at the source. When a Tandem Connection endpoint is set to admin state locked, it inserts the ODUk-LCK signal in the source direction. This object is applicable only when either one of the following three cases holds: (i) optIfODUkDirectionality has the value bidirectional(3), or (ii) optIfODUkDirectionality has the value sink(1) and optIfODUkTCodirectional has the value false(2), or (iii) optIfODUkDirectionality has the value source(3) and optIfODUkTCodirectional has the value true(1). It must not be instantiated in rows for all other cases.

BITS

Indicates the defect condition of the entity, if any. This object is applicable only when either one of the following three cases holds: (i) optIfODUkDirectionality has the value bidirectional(3), or (ii) optIfODUkDirectionality has the value sink(1) and optIfODUkTCodirectional has the value true(1), or (iii) optIfODUkDirectionality has the value source(3) and optIfODUkTCodirectional has the value false(2). It must not be instantiated in rows for all other cases.

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 columnar object is used for creating and deleting a conceptual row of the optIfODUkT config table. It is used to model the addTCM and removeTCM operations of an ODUk_CTP or ODUk_TTP for Tandem connection monitoring as defined in ITU-T G.874.1. Setting RowStatus to createAndGo or createAndWait implies addTCM. Setting RowStatus to destroy implies removeTCM. Successful addition/removal of TCM will result in updating the optIfODUkTcmFieldsInUse and optIfODUkPositionSeqCurrentSize variables and the optIfODUkPositionSeqTable table of the associated ODUk entry in the optIfODUkConfigTable.

Unsigned32 (1..6)

Indicates the tandem connection monitoring field of the ODUk OH on which non-intrusive monitoring is performed. Valid values are integers from 1 to 6.

OptIfSinkOrSource1 = sink2 = sourceIndicates the directionality of an entity that is allowed only to be a source or sink. · Integer32

Specifies the monitor point for the ODUk TCM non-intrusive monitoring function. The value source(2) is not allowed if the corresponding instance of optIfODUkDirectionality has the value sink(1), and the value sink(1) is not allowed if the corresponding instance of optIfODUkDirectionality has the value source(2). Either the value sink(1) or source(2) is allowed if the corresponding instance of optIfODUkDirectionality has the value bidirectional(3). The value sink(1) means monitoring at the sink direction TCM signal of the ODUk CTP. The value source(2) means monitoring at the source direction path signal of the ODUk CTP.

OptIfExDAPIThe Destination Access Point Identifier (DAPI) expected by the receiver. SIZE (16) · OCTET STRING

The DAPI expected by the receiver. This object has no effect if optIfODUkTNimTIMDetMode has the value off(1) or sapi(3).

OptIfExSAPIThe Source Access Point Identifier (SAPI) expected by the receiver. SIZE (16) · OCTET STRING

The SAPI expected by the receiver. This object has no effect if optIfODUkTNimTIMDetMode has the value off(1) or dapi(2).

OptIfAcTIThe trace identifier (TI) accepted at the receiver. SIZE (64) · OCTET STRING

The actual trace identifier accepted. The value of this object is unspecified if optIfODUkTNimCurrentStatus has any of the bit positions oci(0), lck(1), or ssf(5) set or if optIfODUkTNimRowStatus has any value other than active(1).

OptIfTIMDetMode1 = off2 = dapi3 = sapi4 = bothIndicates the mode of the Trace Identifier Mismatch (TIM) Detection function. · Integer32

Indicates the mode of the Trace Identifier Mismatch (TIM) Detection function.

TruthValue1 = true2 = falseRepresents a boolean value. · Integer32

Indicates whether the Trace Identifier Mismatch (TIM) Consequent Action function is enabled.

OptIfDEGThrIndicates the threshold level for declaring a performance monitoring (PM) Second to be bad. A PM Second is declared bad if the percentage of detected errored blocks in that second is greater than or equal to OptIfDEGThr. (1..100) · Unsigned32 · percentage

Indicates the threshold level for declaring a performance monitoring (PM) Second to be bad. A PM Second is declared bad if the percentage of detected errored blocks in that second is greater than or equal to optIfODUkTNimDEGThr.

OptIfDEGMIndicates the threshold level for declaring a Degraded Signal defect (dDEG). A dDEG shall be declared if OptIfDEGM consecutive bad PM Seconds are detected. (2..10) · Unsigned32

Indicates the threshold level for declaring a Degraded Signal defect (dDEG). A dDEG shall be declared if optIfODUkTNimDEGM consecutive bad PM Seconds are detected.

BITS

Indicates the defect condition of the entity, if any. The value of this object is unspecified if optIfODUkTNimRowStatus has any value other than active(1).

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 columnar object is used for creating and deleting a conceptual row of the optIfODUkTNim config table. It is used to model the addTCM and removeTCM operations of an ODUk_CTP or ODUk_TTP for non-intrusive Tandem connection monitoring as defined in ITU-T G.874.1. Setting RowStatus to createAndGo or createAndWait implies addTCM. Setting RowStatus to destroy implies removeTCM. Successful addition/removal of Nim TCM will result in updating the optIfODUkPositionSeqCurrentSize variable and the optIfODUkPositionSeqTable table of the associated ODUk entry in the optIfODUkConfigTable.