rfc-3591

Definitions of Managed Objects for the Optical Interface Type

H-K. Lam, M. Stewart, A. Huynh
date2003-09 streamIETF areaops wgatommib statusPROPOSED STANDARD pages174 canonicalhttps://www.rfc-editor.org/rfc/rfc3591 doi10.17487/RFC3591 errataview
This memo defines a portion of the Management Information Base (MIB) for use with Simple Network Management Protocol (SNMP) in TCP/IP-based internets. In particular, it defines objects for managing Optical Interfaces associated with WavelengthDivision Multiplexing systems or characterized by the Optical Transport Network (OTN) in accordance with the OTN architecture defined in ITU-T Recommendation G.872. The MIB module defined in this memo can be used for performance monitoring and/or configuration of such optical interface. [STANDARDS-TRACK]

Extracted elements (26)

design-rationale §3

Cross-connect objects (e.g., for OCh optical cross-connects and ODUk electrical cross-connects) are explicitly excluded from this version of the MIB, pending consensus on interface object definitions. This intentional deferral allows the interface layer to stabilize before the cross-connect layer is standardized.

snmp

design-rationale §2.6.2

Optical performance parameters (power levels) are typed as Integer32 rather than Counter32 or Gauge32 because they can both increase and decrease and may take negative values (optical power expressed in 0.1 dBm units). This prevents loss of sign information that would occur with unsigned counter types.

snmp

design-rationale §2.6.2

The MIB intentionally omits laser temperature monitoring and mid-stage power monitoring because no industry consensus was reached regarding their benefit or which lasers to monitor. Implementations wishing to capture these may use a proprietary MIB or the ENTITY-SENSOR-MIB (RFC 3433).

snmp

design-rationale §2.1

The MIB provides the option to model an interface either as a single bidirectional object or as a pair of unidirectional objects (separate sink and source ifTable entries). The directionality is conveyed via xxxDirectionality objects in each layer's configuration table, enabling flexible deployment modeling.

snmp

interoperability-note §2.6.2

There is no requirement for an agent to align 15-minute or 24-hour PM intervals with any wall clock; however, agents may optionally align 15-minute intervals with quarter-hours and 24-hour intervals with a specific UTC hour such as 00:00.

snmp

interoperability-note §4

Trace identifier management (TxTI, ExDAPI, ExSAPI, TIMDetMode, TIMActEnabled) does NOT apply to reduced-capability systems (optIfOTMnReduced = true) or at IrDI interfaces (optIfOTMnInterfaceType field 1 = 'IrDI'). At IrDI interfaces, TCM activation is also limited by the optIfOTMnTcmMax threshold.

snmp

normative-requirement §3.2 MUST

An optical interface MUST be capable of supporting at least N 15-minute PM intervals, where N has a minimum of 4, a default of 32, and a maximum of 96. Previous interval data may be unavailable if the agent restarted within the last 24 hours.

snmp

normative-requirement §2.2 REQUIRED

Only the ifGeneralInformationGroup needs to be supported for the ifTable and the ifStackTable for all OTN layers (OTS/OMS, OChGroup, OCh).

snmp

normative-requirement §2.1 MUST

When separate ifTable entries are used for source and sink functions, the agent MUST maintain consistent directionality values across ifStackTable layers (a sink must not be stacked 1:1 on top of a source). All protocol layers represented by a given ifTable entry must have the same directionality.

snmp

normative-requirement §2.1 RECOMMENDED

When separate ifTable entries are used for the source and sink of a single physical interface, an implementation SHALL explicitly state what mechanism is used to indicate the association if ifName is not used; using identical ifName values is RECOMMENDED.

snmp

protocol-element §2.3

For the OChGroup layer, ifPhysAddress encodes the wavelength range in the format 'w1-w2' (e.g., '1350-1650') where w1 and w2 are ASCII decimal nanometer values. For the OCh layer, ifPhysAddress contains the single wavelength as ASCII decimal digits in nanometers (e.g., '1550').

snmp

protocol-element §2.2

For the OTSn/OMSn layer, ifOperStatus is set to notPresent(6) if a component is missing; otherwise it is set to down(2) if either optIfOTSnCurrentStatus or optIfOMSnCurrentStatus indicates any defect. The value lowerLayerDown(7) is not used since there is no lower layer interface for OTS.

snmp

protocol-element §4

OptIfDEGM (2..10) is the threshold count of consecutive bad PM Seconds required to declare a Degraded Signal defect (dDEG). OptIfDEGThr (1..100) is the percentage threshold of errored blocks in a one-second period that declares that second 'bad'.

snmp

protocol-element §3.1

optIfOTMnTable describes the OTM structure per interface: optIfOTMnOrder (1..900 max wavelengths), optIfOTMnReduced (full vs. reduced functionality), optIfOTMnBitRates (supported rates bitmap), optIfOTMnInterfaceType (IrDI or IaDI with optional free-form text), optIfOTMnTcmMax (0..6, default 3), and optIfOTMnOpticalReach (intraOffice through ultraLongHaul).

snmp

protocol-element §4

optIfOTSnConfigEntry holds OTSn layer configuration including directionality, APR status/control, transmitted and expected trace identifiers (TxTI, ExDAPI, ExSAPI), accepted TI, TIM detection mode (off/dapi/sapi/both), TIM consequent action enable, and current defect status bits.

snmp

protocol-element §2.6.2

Performance monitoring data is maintained for the current 15-minute interval, the current 24-hour interval, N previous 15-minute intervals (4 ≤ N ≤ 96, default 32), and one previous 24-hour interval, on a per-interface basis via optIfPerfMonIntervalTable.

snmp

protocol-element §2.7

Tandem Connection Monitoring (ODUkT) supports up to six nested TCM levels per ODUk termination. Each TCM field contains TTI, BIP8, BDI, BEI, and STAT subfields. TCM connections can be nested or cascaded, controlled via optIfODUkTSourceMode, optIfODUkTTimDetMode, and optIfODUkTTimActEnabled.

snmp

protocol-element §2.6.1

The defect conditions monitored per OTN layer (defined in ITU-T G.798) include: ais, bdi, bdiO, bdiP, deg, lck, lof, lom, los, losO, losP, oci, plm, ssf, ssfO, ssfP, and tim. These are reported as BITS in the CurrentStatus objects for each layer.

snmp

protocol-element §2.1

The OChGroup layer (opticalChannelGroup, ifType 219) is an optional layer introduced to support banded amplifier implementations (e.g., C-band and L-band). When not needed, this layer is absent and the model degenerates to the OTS/OMS/OCh structure; when a full-band amplifier is present, optIfOMSn objects should be used instead of optIfOChGroup.

snmp

protocol-element §4

The OptIfTIMDetMode textual convention specifies four TIM detection modes: off(1) — no checking; dapi(2) — check DAPI only; sapi(3) — check SAPI only; both(4) — check both SAPI and DAPI. Default value for OTSn is off(1).

snmp

protocol-element §2.1

The OTN layered model maps to ifTable entries using three ifType values: opticalChannel(195) for OCh, opticalTransport(196) for the combined OTS/OMS layer, and opticalChannelGroup(219) for the optional OChGroup banded-amplifier layer. Each OTN layer is represented as an IfEntry indexed by ifIndex, with layer relationships maintained in ifStackTable and ifInvStackTable.

snmp, yang

registry §4

The OPT-IF-MIB module is assigned OID { transmission 133 } under the IANA-managed transmission subtree. No new IANA registries are created; the MIB registration itself constitutes the IANA action.

snmp, registry

security-consideration §5

Several MIB objects have MAX-ACCESS read-write (e.g., power thresholds, TIM detection mode, trace identifiers, APR control), making them potential targets for unauthorized modification that could disrupt optical network operation. The document recommends applying SNMPv3 with authentication and privacy for all management access to these objects.

snmp, security

security-consideration §4

The optIfOTSnAprControl object allows writing arbitrary implementation-defined values to control Automatic Power Reduction, representing a risk of denial-of-service if accessed by unauthorized managers. Implementations must document all accepted and returned values and their effects.

snmp, security

wire-format §4

OptIfBitRateK is encoded as an Integer32 with allowed values 1 (≈2.5 Gbit/s), 2 (≈10 Gbit/s), and 3 (≈40 Gbit/s) per ITU-T G.709. In optIfOTMnBitRates, supported rates are encoded as a BITS map: bitRateK1(0), bitRateK2(1), bitRateK3(2).

snmp

wire-format §4

OptIfTxTI (Trail Trace Identifier transmitted) and OptIfAcTI (accepted) are each encoded as an OCTET STRING of exactly 64 bytes. OptIfExDAPI (expected DAPI) and OptIfExSAPI (expected SAPI) are each OCTET STRING of exactly 16 bytes.

snmp