tech-invite   World Map
3GPP     Specs     Glossaries     UICC       IETF     RFCs     Groups     SIP     ABNFs       T+       Search     Home

RFC 3591

 Errata 
Proposed STD
Pages: 174
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: ATOMMIB

Definitions of Managed Objects for the Optical Interface Type

Part 1 of 4, p. 1 to 30
None       Next RFC Part

 


Top       ToC       Page 1 
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.

Abstract

   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.

Top       Page 2 
Table of Contents

   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

1.  The Internet-Standard Management Framework

   For a detailed overview of the documents that describe the current
   Internet-Standard Management Framework, please refer to 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].

Top      ToC       Page 3 
2.  Overview

   In this document, the term OTN (Optical Transport Network) system is
   used to describe devices that are compliant with the requirements
   specified in the ITU-T Recommendations 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].

   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].

2.1.  Use of the ifTable

   This section specifies how the MIB II interfaces group, as defined in
   RFC 2863 [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.

Top      ToC       Page 4 
   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

Top      ToC       Page 5 
   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.

Top      ToC       Page 6 
   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.

Top      ToC       Page 7 
    ______________________                      ______________________
   |       |      |       |                    |       |      |       |
   | 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.

Top      ToC       Page 8 
   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.

2.2.  Use of ifTable for OTN OTS/OMS Layer

   Only the ifGeneralInformationGroup needs to be supported.

   ifTable Object      Use for combined OTN OTS/OMS Layer
   =====================================================================
    ifIndex             The interface index.

    ifDescr             Optical Transport Network (OTN) Optical
                        Transmission Section (OTS)/Optical Multiplex
                        Section (OMS)

    ifType              opticalTransport (196)

    ifSpeed             Actual 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       An octet string with zero length.  (There is
                        no specific address associated with the
                        interface.)

    ifAdminStatus       The desired administrative status of the
                        interface.  Supports read-only access.

    ifOperStatus        The operational status of the interface.  The
                        value lowerLayerDown(7) is not used, since
                        there is no lower layer interface.  This object
                        is set to notPresent(6) if a component is
                        missing, otherwise it is set to down(2) if
                        either of the objects optIfOTSnCurrentStatus or
                        optIfOMSnCurrentStatus indicates that any
                        defect is present.

    ifLastChange        The value of sysUpTime at the last change in
                        ifOperStatus.

Top      ToC       Page 9 
    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.

2.3.  Use of ifTable for OTN OChGroup Layer

   Only the ifGeneralInformationGroup needs to be supported.

   ifTable Object      Use for OTN OChGroup Layer
   =====================================================================
    ifIndex             The interface index.

    ifDescr             Optical Transport Network (OTN) Optical
                        Channel Group (OChGroup)

    ifType              opticalChannelGroup(219)

    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 that specifies the range of wavelengths
                        in the format of w1-w2, where w1 and w2 are the
                        lower and upper end of the wavelength range,
                        both in ASCII decimal digits expressed in
                        nanometers (e.g., 1350-1650)

Top      ToC       Page 10 
    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.

2.4.  Use of ifTable for OTN OCh Layer

   Only the ifGeneralInformationGroup needs to be supported.

   ifTable Object      Use for OTN OCh Layer
   =====================================================================
    ifIndex             The interface index.

    ifDescr             Optical Transport Network (OTN) Optical
                        Channel (OCh)

    ifType              opticalChannel(195)

Top      ToC       Page 11 
    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.

Top      ToC       Page 12 
2.5.  Use of ifStackTable

   Use of the ifStackTable and ifInvStackTable to associate the
   opticalTransport and opticalChannel interface entries is best
   illustrated by the example shown in 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

Top      ToC       Page 13 
   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.

2.6.  Optical Network Terminology

   The terminology used in this document to describe the layers of an
   optical network and the error conditions and performance monitoring
   parameters on an optical circuit as monitored by an optical system is
   listed below.  These terms are defined in ITU-T Recommendations G.872
   [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.

Top      ToC       Page 14 
   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

Top      ToC       Page 15 
         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.

Top      ToC       Page 16 
   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.

2.6.1.  Defect Conditions

   The following Defect conditions are defined in G.798 (as fault cause)
   for OTN monitoring.

   ais          Alarm Indication Signal (AIS)
   bdi          Backward Defect Indication (BDI)
   bdiO         Backward Defect Indication - Overhead (BDI-O)
   bdiP         Backward Defect Indication - Payload (BDI-P)
   deg          Degraded (DEG)
   lck          Locked (LCK)
   lof          Loss of Frame (LOF)
   lom          Loss of Multi Frame
   los          Loss of Signal (LOS)
   losO         Loss of Signal - Overhead (LOS-O)
   losP         Loss of Signal - Payload (LOS-P)
   oci          Open Connection Indication (OCI)
   plm          Payload Mismatch (PLM)
   ssf          Server Signal Failure (SSF)
   ssfO         Server Signal Failure - Overhead (SSF-O)
   ssfP         Server Signal Failure - Payload (SSF-P)
   tim          Trace Identifier Mismatch (TIM)

   The relationship of these conditions within a network layer and
   between layers are described in G.798 [ITU-T G.798].

Top      ToC       Page 17 
2.6.2.  Performance Parameters

   To facilitate identification of equipment and facilities that may
   require maintenance, it is necessary to monitor parameters such as
   optical power at each layer.  The measurements are taken
   periodically, and a snapshot of the current value is also made
   available.  More specifically, performance parameters at each layer
   are maintained for the current 15-minute interval, the current 24-
   hour interval, N previous 15-minute intervals where 4 <= N <= 96, and
   one previous 24-hour interval.

   Note that some of the previous interval data will be unavailable if
   the agent has restarted within the last 24 hours.

   There is no requirement for an agent to ensure a fixed relationship
   between the start of a 15-minute or 24-hour interval and any wall
   clock;  however, some agents may align the 15-minute intervals with
   quarter hours and may align the 24-hour intervals with a particular
   hour of the day (e.g., 00:00 UTC).

   Note that some DWDM systems may also monitor the laser temperature of
   the equipment in addition to monitoring the optical power.  However,
   industry opinions vary widely with respect to laser temperature
   monitoring, in particular regarding the benefit of the monitoring and
   which temperatures are to be monitored (i.e., all or only some of the
   pump lasers).  Similarly, there are varying opinions regarding mid-
   stage power monitoring.  Since no consensus was reached, it was
   decided that the laser temperature monitoring and mid-stage
   monitoring would not be standardized in the MIB.  If an
   implementation would like to monitor these parameters, one could use
   a proprietary MIB or the ENTITY-SENSOR-MIB [RFC3433] to capture this
   information.

Top      ToC       Page 18 
   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

Top      ToC       Page 19 
   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.

Top      ToC       Page 20 
2.7.  Tandem Connection Monitoring (TCM)

   An ODUk termination can be provisioned to support (0..6) TCM levels.
   Each TCM field contains the following subfields:

      -  Trail Trace Identifier (TTI)
      -  Bit Interleaved Parity 8 (BIP8)
      -  Backward Defect Indication (BDI)
      -  Backward Error Indication (BEI)
      -  Status bits indicating the presence of TCM overhead, Incoming
         AlignmentError, or a maintenance signal (STAT).

   The insertion of these subfields is controlled by:

      -  optIfODUkTSourceMode or otnODUkTsinkMode

   The detection and corresponding action of these subfields are
   controlled by:

      -  optIfODUkTTimDetMode
      -  optIfODUkTTimActEnabled

   The TCM connection is used for monitoring the quality of an end to
   end connection or any segment, as illustrated in the example:

      TCM1 used for the end-to-end connection from A1 to A2.
      TCM2 used for segment B1-B2, then used again for segment B3-B4.
      TCM3-TCM6 these bytes are not in used in this example.

Top      ToC       Page 21 
   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

3.  Structure of the MIB

   The managed Optical Networking interface objects are arranged into
   the following groups of tables:

   The optIfOTMn group handles the OTM information structure of an
   optical interface.

      optIfOTMnTable

   The optIfPerfMon group handles the current 15-minute and 24-hour
   interval elapsed time, as well as the number of 15-minute intervals
   for all layers.

      optIfPerfMonIntervalTable

Top      ToC       Page 22 
   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

Top      ToC       Page 23 
   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).

3.1.  The optIfOTMn group

3.1.1.  optIfOTMnTable

   This table contains the OTM structure information of an optical
   interface.

Top      ToC       Page 24 
3.2.  The optIfPerfMon group

3.2.1.  optIf Performance Monitoring Interval Table

   This table applies to all performance monitoring on an NE.  It
   records on a per-interface basis the elapsed time in the current 15-
   minute and 24-hour interval, as well as the total number of 15-minute
   intervals and the number of invalid 15-minute intervals.

3.3.  The optIfOTSn groups

3.3.1.  optIfOTSn Configuration group

3.3.1.1.  optIfOTSn Configuration Table

   This table contains information on configuration of optIfOTSn
   interfaces, in addition to the information on such interfaces
   contained in the ifTable.

3.3.2.  optIfOTSn Pre-OTN PM group

3.3.2.1.  optIfOTSn Source Current Table

   This table contains information on current performance of optIfOTSn
   interfaces contained in the ifTable.

3.3.2.2.  optIfOTSn Source Interval Table

   This table contains information on historic performance of optIfOTSn
   interfaces contained in the ifTable.

3.3.2.3.  optIfOTSn Source Current Day Table

   This table contains a snapshot of information for the current 24-hour
   period for optIfOTSn interfaces contained in the ifTable.

3.3.2.4.  optIfOTSn Source Previous Day Table

   This table contains a snapshot of information for the previous 24-
   hour period for optIfOTSn interfaces contained in the ifTable.

3.3.2.5.  optIfOTSn Sink Current Table

   This table contains information on current performance of optIfOTSn
   interfaces contained in the ifTable.

Top      ToC       Page 25 
3.3.2.6.  optIfOTSn Sink Interval Table

   This table contains information on historic performance of optIfOTSn
   interfaces contained in the ifTable.

3.3.2.7.  optIfOTSn Sink Current Day Table

   This table contains a snapshot of information for the current 24-hour
   period for optIfOTSn interfaces contained in the ifTable.

3.3.2.8.  optIfOTSn Sink Previous Day Table

   This table contains a snapshot of information for the previous 24-
   hour period for optIfOTSn interfaces contained in the ifTable.

3.4.  The optIfOMSn groups

3.4.1.  optIfOMSn Configuration group

3.4.1.1.  optIfOMSn Configuration Table

   This table contains information on configuration of optIfOMSn
   interfaces, in addition to the information on such interfaces
   contained in the ifTable.

3.4.2.  optIfOMSn Pre-OTN PM group

3.4.2.1.  optIfOMSn Source Current Table

   This table contains information on current performance of optIfOMSn
   interfaces contained in the ifTable.

3.4.2.2.  optIfOMSn Source Interval Table

   This table contains information on historic performance of optIfOMSn
   interfaces contained in the ifTable.

3.4.2.3.  optIfOMSn Source Current Day Table

   This table contains a snapshot of information for the current 24-hour
   period for optIfOMSn interfaces contained in the ifTable.

3.4.2.4.  optIfOMSn Source Previous Day Table

   This table contains a snapshot of information for the previous 24-
   hour period for optIfOMSn interfaces contained in the ifTable.

Top      ToC       Page 26 
3.4.2.5.  optIfOMSn Sink Current Table

   This table contains information on current performance of optIfOMSn
   interfaces contained in the ifTable.

3.4.2.6.  optIfOMSn Sink Interval Table

   This table contains information on historic performance of optIfOMSn
   interfaces contained in the ifTable.

3.4.2.7.  optIfOMSn Sink Current Day Table

   This table contains a snapshot of information for the current 24-hour
   period for optIfOMSn interfaces contained in the ifTable.

3.4.2.8.  optIfOMSn Sink Previous Day Table

   This table contains a snapshot of information for the previous 24-
   hour period for optIfOMSn interfaces contained in the ifTable.

3.5.  The optIfOChGroup groups

3.5.1.  optIfOChGroup Configuration group

3.5.1.1.  optIfOChGroup Configuration Table

   This table contains information on configuration of optIfOChGroup
   interfaces, in addition to the information on such interfaces
   contained in the ifTable.

3.5.2.  optIfOChGroup Pre-OTN PM group

3.5.2.1.  optIfOChGroup Source Current Table

   This table contains information on current performance of
   optIfOChGroup interfaces contained in the ifTable.

3.5.2.2.  optIfOChGroup Source Interval Table

   This table contains information on historic performance of
   optIfOChGroup interfaces contained in the ifTable.

3.5.2.3.  optIfOChGroup Source Current Day Table

   This table contains a snapshot of information for the current 24-hour
   period for optIfOChGroup interfaces contained in the ifTable.

Top      ToC       Page 27 
3.5.2.4.  optIfOChGroup Source Previous Day Table

   This table contains a snapshot of information for the previous 24-
   hour period for optIfOChGroup interfaces contained in the ifTable.

3.5.2.5.  optIfOChGroup Sink Current Table

   This table contains information on current performance of
   optIfOChGroup interfaces contained in the ifTable.

3.5.2.6.  optIfOChGroup Sink Interval Table

   This table contains information on historic performance of
   optIfOChGroup interfaces contained in the ifTable.

3.5.2.7.  optIfOChGroup Sink Current Day Table

   This table contains a snapshot of information for the current 24-hour
   period for optIfOChGroup interfaces contained in the ifTable.

3.5.2.8.  optIfOChGroup Sink Previous Day Table

   This table contains a snapshot of information for the previous 24-
   hour period for optIfOChGroup interfaces contained in the ifTable.

3.6.  The optIfOCh groups

3.6.1.  optIfOCh Configuration group

3.6.1.1.  optIfOCh Configuration Table

   This table contains information on configuration of optIfOCh
   interfaces, in addition to the information on such interfaces
   contained in the ifTable.

3.6.2.  optIfOCh Pre-OTN PM group

3.6.2.1.  optIfOCh Source Current Table

   This table contains information on current performance of optIfOCh
   interfaces contained in the ifTable.

3.6.2.2.  optIfOCh Source Interval Table

   This table contains information on historic performance of optIfOCh
   interfaces contained in the ifTable.

Top      ToC       Page 28 
3.6.2.3.  optIfOCh Source Current Day Table

   This table contains a snapshot of information for the current 24-hour
   period for optIfOCh interfaces contained in the ifTable.

3.6.2.4.  optIfOCh Source Previous Day Table

   This table contains a snapshot of information for the previous 24-
   hour period for optIfOCh interfaces contained in the ifTable.

3.6.2.5.  optIfOCh Sink Current Table

   This table contains information on current performance of optIfOCh
   interfaces contained in the ifTable.

3.6.2.6.  optIfOCh Sink Interval Table

   This table contains information on historic performance of optIfOCh
   interfaces contained in the ifTable.

3.6.2.7.  optIfOCh Sink Current Day Table

   This table contains a snapshot of information for the current 24-hour
   period for optIfOCh interfaces contained in the ifTable.

3.6.2.8.  optIfOCh Sink Previous Day Table

   This table contains a snapshot of information for the previous 24-
   hour period for optIfOCh interfaces contained in the ifTable.

3.7.  The optIfOTUk groups

3.7.1.  optIfOTUk Configuration group

3.7.1.1.  optIfOTUk Configuration Table

   This table contains information on configuration of optIfOTUk
   interfaces, in addition to the information on such interfaces
   contained in the ifTable.

3.7.2.  optIfGCC0 Configuration group

3.7.2.1.  optIfGCC0 Configuration Table

   This table contains information on configuration of the GCC0
   communication channel.

Top      ToC       Page 29 
3.8.  The optIfODUk groups

3.8.1.  optIfODUk Configuration group

3.8.1.1.  optIfODUk Configuration Table

   This table contains all the objects that are common to endpoints
   (called trail termination points or TTPs) and connection termination
   points (CTPs), and also includes a flag stating whether TTP functions
   are present.

3.8.2.  optIfODUkTtp Configuration group

3.8.2.1.  optIfODUkTtp Configuration Table

   This table contains TTP-specific information on configuration of
   optIfODUk interfaces, in addition to the information on such
   interfaces contained in the ifTable.

3.8.3.  optIfODUk Position Seq group

3.8.3.1.  optIfODUk Position Seq Table

   This table contains information on the position sequence of the TCM
   function and/or GCC12 access that have been created within the
   optIfODUk interfaces, in addition to the information on such
   interfaces contained in the ifTable.

3.8.4.  optIfODUk Nim Configuration group

3.8.4.1.  optIfODUk Nim Configuration Table

   This table contains information on configuration of optIfODUk Non-
   intrusive monitoring.

3.8.5.  optIfGCC12 Configuration group

3.8.5.1.  optIfGCC12 Configuration Table

   This table contains information on configuration of the GCC1 and GCC2
   communication channels.

Top      ToC       Page 30 
3.9.  The optIfODUkT groups

3.9.1.  optIfODUkT Configuration group

3.9.1.1.  optIfODUkT Configuration Table

   This table contains information on configuration of optIfODUkT
   interfaces, in addition to the information on such interfaces
   contained in the ifTable.

3.9.2.  optIfODUkT Nim Configuration group

3.9.2.1.  optIfODUkT Nim Configuration Table

   This table contains information on configuration of optIfODUkT Non-
   intrusive monitoring.



(page 30 continued on part 2)

Next RFC Part