Network Working Group H-K. Lam Request for Comments: 3591 Lucent Technologies Category: Standards Track M. Stewart Dorado Software A. Huynh Cetus Networks September 2003 Definitions of Managed Objects for the Optical Interface Type Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved.
AbstractThis 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.
1. The Internet-Standard Management Framework ................. 2 2. Overview ................................................... 3 2.1. Use of the ifTable .................................. 3 2.2. Use of ifTable for OTN OTS/OMS Layer................. 8 2.3. Use of ifTable for OTN OChGroup Layer................ 9 2.4. Use of ifTable for OTN OCh Layer..................... 10 2.5. Use of ifStackTable.................................. 12 2.6. Optical Network Terminology ......................... 13 2.7. Tandem Connection Monitoring (TCM) .................. 20 3. Structure of the MIB........................................ 21 3.1. The optIfOTMn group.................................. 23 3.2. The optIfPerfMon group............................... 24 3.3. The optIfOTSn groups................................. 24 3.4. The optIfOMSn groups................................. 25 3.5. The optIfOChGroup groups............................. 26 3.6. The optIfOCh groups.................................. 27 3.7. The optIfOTUk groups................................. 28 3.8. The optIfODUk groups................................. 29 3.9. The optIfODUkT groups................................ 30 4. Object Definitions ......................................... 30 5. Security Considerations .................................... 167 6. Acknowledgments............................................. 169 7. References ................................................. 169 7.1. Normative References ................................. 169 7.2. Informative References ............................... 171 8. Intellectual Property Statement ............................ 171 9. Authors' Addresses ......................................... 172 10. Full Copyright Statement ................................... 173 section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580].
ITU-T G.872], G.709 [ITU-T G.709], G.798 [ITU-T G.798], G.874 [ITU-T G.874], and G.874.1 [ITU-T G.874.1]. The optical objects will be managed using the MIB II ifTable and ifStackTable. Additional tables will also be supported to monitor layer specific status and provide performance monitoring data. In the tables, some entries are required for OTN systems only. A Configuration (Config) table, Current Performance Monitoring (PM) table, and Interval PM table will be maintained for the OTSn, OMSn, OChGroup, and OCh layers on a source and sink trail termination basis. These tables will be linked to the ifTable by using the ifIndex that is associated with that layer. These objects are used when the particular media being used to realize an interface is an Optical Transport interface. At present, this applies to these values of the ifType variable in the Internet- standard MIB: opticalChannel (195), opticalChannelGroup (219), opticalTransport (196) The definitions contained herein are based on the OTN specifications in ITU-T G.872[ITU-T G.872], G.709 [ITU-T G.709], G.798[ITU-T G.798], G.874[ITU-T G.874], and G.874.1 [ITU-T G.874.1]. RFC2863], is used for optical interfaces. Only the ifGeneralInformationGroup will be supported for the ifTable and the ifStackTable to maintain the relationship between the various layers. The OTN layers are managed in the ifTable using IfEntries that correlate to the layers depicted in Figure 1. For example, a DWDM device with an Optical Network Node Interface (ONNI) will have an Optical Transmission Section (OTS) physical layer, an Optical Multiplex Section (OMS) layer (transports multiple optical channels), and an Optical Channel (OCh) layer. There is a one to one relationship between the OMS and OTS layers. The OMS layer has fixed connectivity via the OTS and thus no connectivity flexibility at the OMS layer is supported.
A device with an ONNI that does not multiplex would consist of the OTS and OCh layers supporting a single channel. MIB-II (RFC 1213) [RFC1213], as amended and extended by RFC 3418 [RFC3418], RFC 2863 [RFC2863], and RFC 2864 [RFC2864], accommodates these cases through appropriate use of the system and interfaces groups. The system group names and describes the type of managed resource. The interfaces group defines which OTN layers exist and how these layers are configured and multiplexed. This is achieved by proper representation of OTN Layers as IfEntries as defined in RFC 2863 [RFC2863], as follows. In the following figures, opticalChannel and opticalTransport are abbreviated as och and otn respectively. _____________________ \ Path Data Unit |\ (ODUk) | \ _____________________| \ ______________________ | | | > Tandem Data Unit | | | | (ODUkT) | | OCh Layer | > n och IfEntries _____________________| | | | | |______________________| > Optical | /| | > Transport Unit | / | | | (OTUk) |/ | OMSn Layer | | _____________________/ | | | |______________________| | Sub-layers in | | > m otn IfEntries the OCh Layer | | | | OTSn Layer | | | | | |______________________| > Figure 1: OTN Layers Since the OMSn and OTSn layers have a one to one relationship, only one otn IfEntry is required to support these two layers. Therefore, each opticalChannel IfEntry may be mapped to m opticalTransport IfEntries, where m is greater than or equal to 1. Conversely, each opticalTransport entry may be mapped to n opticalChannel IfEntries, where n is greater than or equal to 1. There are implementations that have banded amplifers that operate on a group of optical channels separately (e.g., C and L band channels) before finally muxing them together and transporting them over a
physical layer. For such DWDM system implementations, it is important to have the ability to model each of the groups (or bands) with an ifIndex and measure the pre-OTN PM parameters for each band separately. The OTN layering, as described in Figure 1, can be extended to accomodate such implementations by introducing another layer called the OChGroup Layer. As an example, Figure 2 depicts the OTN layering of a DWDM system with 80 C-band and 80 L-band channels combined into their respective channel band groups before being muxed into the OMS and transported over the OTS. _________ ____________ |O|O| |O | |O |O | |O | > |C|C| |C | |C |C | |C | | |h|h|..|h | |h |h |..|h | > x och IfEntries |1|2| |80| |81|82| |160| | |_|_|__|__| |__|__|__|___| > | | | | > | | | | | |OChGroup1| | OChGroup2 | > n ochgroup IfEntries | | | | | |_________|__|____________| > | | > | | | | OMSn Layer | | | | | |_________________________| | | | > m otn IfEntries | | | | OTSn Layer | | | | | |_________________________| > Figure 2: OTN Layers for a Banded Configuration If an implementation does not wish to model the banded configuration, the OChGroup layer is absent and the OTN layering model degenerates to the description in Figure 1. In other words, when there is an amplifier that covers the whole band, the optIfOMSn objects should be used, rather than using the optIfOChGroup objects with a degenerate group that covers all channels. The design of the Optical Interface MIB provides the option to model an interface either as a single bidirectional object containing both sink and source functions or as a pair of unidirectional objects, one containing sink functions and the other containing source functions.
If the sink and source for a given protocol layer are to be modelled as separate objects, then there need to be two ifTable entries, one that corresponds to the sink and one that corresponds to the source, where the directionality information is provided in the configuration tables for that layer via the xxxDirectionality objects. The agent is expected to maintain consistent directionality values between ifStackTable layers (e.g., a sink must not be stacked in a 1:1 manner on top of a source, or vice-versa), and all protocol layers that are represented by a given ifTable entry are expected to have the same directionality (i.e., instances of optIfOTSnDirectionality and optIfOMSnDirectionality that correspond to a given ifIndex value must have the same value, and instances of optIfOChDirectionality, optIfOTUkDirectionality, and optIfODUkDirectionality that correspond to a given ifIndex value must have the same value). When separate ifTable entries are used for the source and sink functions of a given physical interface, association between the two uni-directional ifTable entries (one for the source function and the other for the sink functions) should be provided. It is recommended that identical ifName values are used for the two ifTable entries to indicate such association. An implementation shall explicitly state what mechanism is used to indicate the association, if ifName is not used. Example 1: Management of unterminated opticalChannel (och) using passive optics An OTN device connected with two adjacent nodes in a single fiber ring that supports 10 wavelengths per fiber would have 2 opticalTransport IfEntries and 20 opticalChannel IfEntries, as depicted in Figure 3. Thus 10 opticalChannel IfEntries are stacked above the first opticalTransport IfEntry, and the other 10 opticalChannel IfEntries are stacked above the second opticalTransport IfEntry. Note that the optical channels in this example are un-terminated, and thus no OTUk objects will be instantiated for these optical channels. The opticalChannel IfEntries of one otn may be dropped/added from/to the OTN device or cross-connected with the opticalChannel IfEntries of the other otn. Cross-connection from a member of the first 10 opticalChannel IfEntries to a member of the second 10 opticalChannel IfEntries could be modelled by using a cross- connect object, which is not yet defined in this version of the MIB.
______________________ ______________________ | | | | | | | | | och1 | ... | och10 | | och11 | ... | och20 | |_______|______|_______| |_______|______|_______| | | | | | otn1 | | otn2 | |______________________| |______________________| ____________ | | ___________________\| OTN |__________________\ /| device | / |____________| Figure 3: Interface stacks when channels are unterminated Example 2: Management of terminated opticalChannel (och) interfaces An OTN device connected with two adjacent nodes in a single fiber ring that supports 10 wavelengths per fiber would have 2 opticalTransport IfEntries and 20 opticalChannel IfEntries, as depicted in Figure 4. Thus 10 opticalChannel IfEntries are stacked above the first opticalTransport IfEntry, and the other 10 opticalChannel IfEntries are stacked above the second opticalTransport IfEntry. As the optical channels in this example are terminated, OTUk objects and possibly ODUk objects will be instantiated for the terminated opticalChannel IfEntries. ______________________ ______________________ | | | | | | | | | och1 | ... | och10 | | och11 | ... | och20 | |_______|______|_______| |_______|______|_______| | | | | | otn1 | | otn2 | |______________________| |______________________| ____________ | | ___________________\| OTN |__________________\ /| device | / |____________| Figure 4: Interface stacks when channels are terminated Note that the two examples described above depict the interface stacks when the banded configuration is not modeled.
The exact configuration and multiplexing of the layers is maintained in the ifStackTable (RFC 2863) [RFC2863] and in the ifInvStackTable (RFC 2864) [RFC2864]; see section 2.5 for details.
ifName Enterprise-specific convention (e.g., TL-1 AID) to identify the physical or data entity associated with this interface or an OCTET STRING of zero length. The enterprise-specific convention is intended to provide the means to reference one or more enterprise-specific tables. ifLinkUpDownTrapEnable Default value is enabled(1). Supports read-only access. ifHighSpeed Actual bandwidth of the interface in Mega-bits per second. A value of n represents a range of 'n-0.5' to 'n+0.499999'. ifConnectorPresent Set to true(1). ifAlias The (non-volatile) alias name for this interface as assigned by the network manager.
ifAdminStatus The desired administrative status of the interface. Supports read-only access. ifOperStatus The operational status of the interface. This object is set to lowerLayerDown(7) if the ifOperStatus of its otn interface is down(2). Otherwise, it is set to down(2) if the amplifier for this band is unable to carry traffic. ifLastChange The value of sysUpTime at the last change in ifOperStatus. ifName Enterprise-specific convention (e.g., TL-1 AID) to identify the physical or data entity associated with this interface or an OCTET STRING of zero length. The enterprise-specific convention is intended to provide the means to reference one or more enterprise-specific tables. ifLinkUpDownTrapEnable Default value is disabled(2). Supports read-only access. ifHighSpeed Current bandwidth of the interface in Mega-bits per second. A value of n represents a range of 'n-0.5' to 'n+0.499999'. ifConnectorPresent Set to false(2). ifAlias The (non-volatile) alias name for this interface as assigned by the network manager.
ifSpeed Current bandwidth of the interface in bits per second. If the bandwidth of the interface is greater than the maximum value of 4,294,967,295, then the maximum value is reported and ifHighSpeed must be used to report the interface's speed. ifPhysAddress A string of ASCII decimal digits containing the wavelength of the optical channel, expressed in nanometers (e.g., 1550). ifAdminStatus The desired administrative status of the interface. Supports read-only access. ifOperStatus The operational status of the interface. This object is set to lowerLayerDown(7) if the ifOperStatus of its otn interface or of its OChGroup interface is down(2). Otherwise, it is set to down(2) if one or more of the objects optIfOChCurrentStatus, optIfOTUkCurrentStatus, optIfODUkTCurrentStatus, and optIfODUkTtpCurrentStatus indicates that any defect is present. ifLastChange The value of sysUpTime at the last change in ifOperStatus. ifName Enterprise-specific convention (e.g., TL-1 AID) to identify the physical or data entity associated with this interface or an OCTET STRING of zero length. The enterprise-specific convention is intended to provide the means to reference one or more enterprise-specific tables. ifLinkUpDownTrapEnable Default value is disabled(2). Supports read-only access. ifHighSpeed Current bandwidth of the interface in Mega-bits per second. A value of n represents a range of 'n-0.5' to 'n+0.499999'. ifConnectorPresent Set to false(2). ifAlias The (non-volatile) alias name for this interface as assigned by the network manager.
Figure 5. The example assumes an otn interface with ifIndex i that carries two multiplexed och interfaces with ifIndex values of j and k, respectively. The example shows that j and k are stacked above (i.e., multiplexed into) i. Furthermore, it shows that there is no layer lower than i and no layer higher than j and/or k. HigherLayer LowerLayer -------------------------- 0 j 0 k j i k i i 0 Figure 5: Use of ifStackTable for an OTN port Figure 6 illustrates an example for a banded configuration. The example assumes an otn interface with ifIndex i that carries two multiplexed och groups with ifIndex values u and v. An och group with ifIndex value u combines two och interfaces with ifIndex values of a and b. An och group with ifIndex value v combines two och interfaces with ifIndex values of c and d. The example show that a and b are stacked above (i.e., multiplexed into) u. Likewise, c and d are stacked above v. u and v are multiplexed into i. Furthermore, it shows that there is no layer lower than i and no layer higher than a, b, c, and/or d. It also shows that u has a and b as its higher layers, and v has c and d as its higher layers. HigherLayer LowerLayer -------------------------- 0 a 0 b 0 c 0 d a u b u c v d v u i v i i 0 Figure 6: Use of ifStackTable for an OTN port for a banded configuration
For the inverse stack table, it provides the same information as the interface stack table, with the order of the Higher and Lower layer interfaces reversed. ITU-T G.872], G.709 [ITU-T G.709], G.798 [ITU-T G.798], G.874 [ITU-T G.874], G.874.1 [ITU-T G.874.1], and G.806 [ITU-T G.806]. Brief definitions of some terms are also included here to facilitate the readability of this document. Degraded Threshold (DEGTHR) - G.806 A threshold level for declaring a performance monitoring (PM) Second (a time period of one second) to be bad. A PM Second is declared bad if the percentage of detected errored blocks in that second or the number of errored blocks in that Second is greater than or equal to DEGTHR. DEGM - G.806 A threshold level for declaring a Degraded Signal defect (dDEG). A dDEG shall be declared if DEGM consecutive bad PM Seconds are detected. Expected Destination Access Point Identifier (ExDAPI) - G.798 The Expected Destination Access Point Identifier (ExDAPI), provisioned by the managing system, to be compared with the TTI accepted at the overhead position of the sink for the purpose of checking the integrity of connectivity. Expected Source Access Point Identifier (ExSAPI) - G.798 The Expected Source Access Point Identifier (ExSAPI), provisioned by the managing system, to be compared with the TTI accepted at the overhead position of the sink for the purpose of checking the integrity of connectivity. Inter-Domain Interface (IrDI) - G.872 A physical interface that represents the boundary between two administrative domains. G.709 defines the requirements for the IrDI at the Network Node Interface (NNI). Intra-Domain Interface (IaDI) - G.872 A physical interface within an administrative domain.
Optical Channel Layer Network (OCh) - G.872 This layer network provides end-to-end networking of optical channels for transparently conveying client information of varying format (e.g., SDH STM-N, PDH 565 Mbit/s, cell based ATM, etc.). Optical Channel Data Unit Path Layer Network (ODUk) - G.709/Y.1331 This layer network provides functionality for the transport of information structure consisting of the information payload (OPUk) and the related overhead for management of an optical channel. Optical Channel Data Unit Tandem Connection Sub-Layer Network (ODUkT) - G.709/Y.1331 This layer network is a sub-layer of the optical data unit layer, which provides the capability for tandem connection monitoring. One to six nested levels of monitoring are defined for OTN. Optical Channel Payload Unit (OPUk) - G.709/Y.1331 The OPUk is the information structure used to adapt client information for transport over an optical channel. OPUk capacities for k=1, k=2, k=3 are defined in ITU-T. The index "k" is used to represent different versions of OPUk, ODUk and OTUk. k=1 represents an approximate bit rate of 2.5 Gbit/s, k=2 represents an approximate bit rate of 10 Gbit/s, and k=3 represents an approximate bit rate of 40 Gbit/s. Optical Multiplex Section Layer Network (OMS) - G.872 This layer network provides functionality for networking of a multi-wavelength optical signal. Note that a "multi- wavelength" signal includes the case of just one optical channel. Optical Transport Module (OTM-n[r].m) - G.872 The OTM is the information structure that is transported across an ONNI. The index n and m define the number of supported wavelengths and bit rates at the interface. Two OTM structures are defined: OTM with full functionality (OTM-n.m) and OTM with reduced functionality (OTM-0.m & OTM- nr.m). The OTM-n.m consists of up to n multiplexed optical channels and an OTM overhead signal to support the non-associated overhead. The OTM-0 consists of a single optical channel
without a specific color assigned. The OTM-nr.m consists of up to n multiplexed optical channels. Non associated overhead is not supported. Optical Transport Network (OTN) - G.872 A transport network bounded by optical channel access points. The optical transport network layered structure is comprised of the optical channel, optical multiplex section and optical transmission section layer networks. According to G.872, an OTN-compliant interface is an interface of the optical transport network based on the architecture defined in G.872, while an OTN-non-compliant interface is an interface that does not comply with the interface recommendations that will be defined for the optical transport network based on the architecture defined in G.872. Optical Transmission Section Layer Network (OTS) - G.872 This layer network provides functionality for transmission of optical signals on optical media of various types. Optical Channel Transport Unit Section Layer Network (OTUk) - G.709 The OTUk is the layer network that provides for the transport of an ODUk over one or more optical channel link connections. It consists of the optical channel data unit and OTUk related overhead (FEC and overhead for management of an optical channel link connection). It is characterized by its frame structure, bit rate, and bandwidth. Payload Type Mismatch (PLM) The detection of a mismatch of payload type is based on a comparison between the expected Payload Type signal, provisioned via the management interface, and the received Payload Type signal. Trail Trace Identifier Transmitted (TxTI) - G.798 The Trail Trace Identifier (TTI) information, provisioned by the managing system, to be placed in the TTI overhead position of the source of a trail for transmission. Trail Trace Identifier Accepted (AcTI) - G.798 The Trail Trace Identifier (TTI) information accepted from the TTI overhead position at the sink of a trail. Trail Trace Identifier Accepted Status (AcTIStatus) - G.798 The Status of the Trail Trace Identifier (TTI) accepted from the TTI overhead position at the sink of a trail.
Trace Identifier Mismatch (TIM) - G.798 The detection of TIM is based on a comparison between the expected Trial Trace Identifier (TTI), configured via the management interface, and the received TTI. Trace Identifier Mismatch Consequent Action Enabled (TimActEnabled) - G.798 The Consequent Action function of TIM is disabled. Trace Identifier Mismatch Detection Mode (TimDetMode) - G.798 The mode of detecting Trace Identifier Mismatch (TIM). Possible modes are: (1) off - no checking, (2) SAPI - checking the SAPI only, (3) DAPI - checking the DAPI only, and (4) Both - checking both the SAPI and DAPI. ITU-T G.798].
RFC3433] to capture this information.
The sink-side monitoring points for the various layers are shown in Figure 7 below. OCh sink pre-OTN PM params | | OChGroup sink pre-OTN params | | | | OMSn sink pre-OTN PM params | | | | | | OTSn sink pre-OTN PM params | | | | V V V V /| ____/|_______/| /| / | \| . / |__________________/ |________________/ |_____ . \ | ____\ | \ | ____/|_______\| | \| ___\ | \| C-Band | Demux | \| | | | | ____/|_______/| | OSC \| . / |_____________| . \ | ____/|_______\| \| L-Band optical optical optical OSC Drop Filter rcvr (O/E) demux demux OCh OChGroup OMSn OTSn Figure 7: Sink-side pre-OTN monitoring points
The source-side monitoring points for the various layers are shown in Figure 8 below. OCh src pre-OTN PM params | | OChGroup src pre-OTN PM params | | | | OMSn src pre-OTN PM params | | | | | | OTSn src pre-OTN PM params | | | | V V V V |\ ___|\______|\ |\ | \ |/ . | \_________________| \______________| \______ . | / ___| / | / ----|/ | |/ __| / C-Band MUX | Mux | |/ | | | OSC ___|\______|\ | |/ . | \_____________| . | / ----|/ L-Band MUX optical optical optical OSC Add Filter xmtr mux mux (E/O) OCh OChGroup OMSn OTSn Figure 8: Source-side pre-OTN monitoring points Note that optical performance parameters are of type Integer32, rather than Counter32 or Gauge32, because it is possible for these objects to increase or decrease and to assume negative or positive values.
The TCM connection can be nested (B1-B2 is nested in A1-A2) or cascaded (B1-B2 and B3-B4). ______ ______ ______ ______ ______ |TCM6| |TCM6| |TCM6| |TCM6| |TCM6| |----| |----| |----| |----| |----| |TCM5| |TCM5| |TCM5| |TCM5| |TCM5| |----| |----| |----| |----| |----| |TCM4| |TCM4| |TCM4| |TCM4| |TCM4| |----| |----| |----| |----| |----| |TCM3| |TCM3| |TCM3| |TCM3| |TCM3| |----| |----| |----| |----| |----| |TCM2| |TCM2| |TCM2| |TCM2| |TCM2| |----| |----| |----| |----| |----| |TCM1| |TCM1| |TCM1| |TCM1| |TCM1| |----| |----| |----| |----| |----| | | | | | | | | | | | | | | | | | | | | | | | | | |\ |\ /| |\ /| /| ----> | \________| \_______/ |_________| \_____ / |______ / | ----> | / | / \ | | / \ | \ | |/ |/ \| |/ \| \| TCM1: A1 <------------------------------------------------> A2 TCM2: B1 <-----> B2 B3 <-----> B4
The optIfOTSn groups handle the configuration and performance monitoring information for OTS layers. optIfOTSnConfigTable optIfOTSnSinkCurrentTable optIfOTSnSinkIntervalTable optIfOTSnSinkCurDayTable optIfOTSnSinkPrevDayTable optIfOTSnSrcCurrentTable optIfOTSnSrcIntervalTable optIfOTSnSrcCurDayTable optIfOTSnSrcPrevDayTable The optIfOMSn groups handle the configuration and performance information for OMS layers. optIfOMSnConfigTable optIfOMSnSinkCurrentTable optIfOMSnSinkIntervalTable optIfOMSnSinkCurDayTable optIfOMSnSinkPrevDayTable optIfOMSnSrcCurrentTable optIfOMSnSrcIntervalTable optIfOMSnSrcCurDayTable optIfOMSnSrcPrevDayTable The optIfOChGroup groups handle the configuration and performance information for OChGroup layers. optIfOChGroupConfigTable optIfOChGroupSinkCurrentTable optIfOChGroupSinkIntervalTable optIfOChGroupSinkCurDayTable optIfOChGroupSinkPrevDayTable optIfOChGroupSrcCurrentTable optIfOChGroupSrcIntervalTable optIfOChGroupSrcCurDayTable optIfOChGroupSrcPrevDayTable
The optIfOCh groups handle the configuration and performance monitoring information for OCh layers. optIfOChConfigTable optIfOChSinkCurrentTable optIfOChSinkIntervalTable optIfOChSinkCurDayTable optIfOChSinkPrevDayTable optIfOChSrcCurrentTable optIfOChSrcIntervalTable optIfOChSrcCurDayTable optIfOChSrcPrevDayTable The optIfOTUk groups handle configuration information for OTUk. optIfOTUkConfigTable optIfGCC0ConfigTable The optIfODUk groups handle configuration information for ODUk. optIfODUkConfigTable optIfODUkTtpConfigTable optIfODUkPositionSeqTable optIfODUkNimConfigTable optIfGCC12ConfigTable The optIfODUkT groups handle configuration information for ODUkT. optIfODUkTConfigTable optIfODUkTNimConfigTable This memo does not define MIB objects for optical system cross- connects. After a consensus is reached on definitions of the interface MIB objects for optical systems (resulting from resolution of discussions on the objects proposed in this memo), work can progress on the definitions of tables to represent cross-connects (e.g., OCh optical cross-connects and ODUk electrical cross- connects).