tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 5066

Proposed STD
Pages: 90
Top     in Index     Prev     Next
in Group Index     Prev in Group     No Next: Highest Number in Group     Group: HUBMIB

Ethernet in the First Mile Copper (EFMCu) Interfaces MIB

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

Updated by:    7124


Top       ToC       Page 1 
Network Working Group                                           E. Beili
Request for Comments: 5066                              Actelis Networks
Category: Standards Track                                  November 2007


        Ethernet in the First Mile Copper (EFMCu) Interfaces MIB

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.

Abstract

   This document defines Management Information Base (MIB) modules for
   use with network management protocols in TCP/IP-based internets.
   This document describes extensions to the Ethernet-like Interfaces
   MIB and Medium Attachment Unit (MAU) MIB modules with a set of
   objects for managing Ethernet in the First Mile Copper (EFMCu)
   interfaces 10PASS-TS and 2BASE-TL, defined in IEEE Std 802.3ah-2004
   (note: IEEE Std 802.3ah-2004 has been integrated into IEEE Std 802.3-
   2005).  In addition, a set of objects is defined, describing cross-
   connect capability of a managed device with multi-layer (stacked)
   interfaces, extending the stack management objects in the Interfaces
   Group MIB and the Inverted Stack Table MIB modules.

Top       Page 2 
Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  The Internet-Standard Management Framework . . . . . . . . . .  3
   3.  Relation to Other MIB Modules  . . . . . . . . . . . . . . . .  4
     3.1.  Relation to Interfaces Group MIB Module  . . . . . . . . .  4
       3.1.1.  Layering Model . . . . . . . . . . . . . . . . . . . .  4
       3.1.2.  PME Aggregation Function (PAF) . . . . . . . . . . . .  7
       3.1.3.  Discovery Operation  . . . . . . . . . . . . . . . . .  7
       3.1.4.  EFMCu Ports Initialization . . . . . . . . . . . . . .  9
       3.1.5.  Usage of ifTable . . . . . . . . . . . . . . . . . . . 10
     3.2.  Relation to SHDSL MIB Module . . . . . . . . . . . . . . . 11
     3.3.  Relation to VDSL MIB Module  . . . . . . . . . . . . . . . 12
     3.4.  Relation to Ethernet-Like and MAU MIB Modules  . . . . . . 12
   4.  MIB Structure  . . . . . . . . . . . . . . . . . . . . . . . . 13
     4.1.  EFM Copper MIB Overview  . . . . . . . . . . . . . . . . . 13
     4.2.  Interface Stack Capability MIB Overview  . . . . . . . . . 13
     4.3.  PME Profiles . . . . . . . . . . . . . . . . . . . . . . . 14
     4.4.  Mapping of IEEE 802.3ah Managed Objects  . . . . . . . . . 14
   5.  Interface Stack Capability MIB Definitions . . . . . . . . . . 16
   6.  EFM Copper MIB Definitions . . . . . . . . . . . . . . . . . . 22
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 84
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 86
   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 86
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 86
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 86
     10.2. Informative References . . . . . . . . . . . . . . . . . . 88

Top      ToC       Page 3 
1.  Introduction

   New Ethernet-like interfaces have been defined in the Institute of
   Electrical and Electronics Engineers (IEEE) Standard 802.3ah-2004
   [802.3ah], a.k.a.  Ethernet in the First Mile (EFM), which is now a
   part of the base IEEE Standard 802.3-2005 [802.3].  In particular,
   2BASE-TL and 10PASS-TS physical interfaces (PHYs), defined over
   voice-grade copper pairs, have been specified for the long and short
   reach, respectively.  These interfaces, collectively called EFM
   Copper (EFMCu), are based on Single-pair High-speed Digital
   Subscriber Line (SHDSL) [G.991.2] and Very High speed Digital
   Subscriber Line (VDSL) [G.993.1] technology, supporting optional
   Physical Medium Entity (PME) aggregation (a.k.a. multi-pair bonding)
   with variable rates.

   2BASE-TL PHY is capable of providing at least 2 Mbps over a 2700 m
   long single copper pair with a mean Bit Error Rate (BER) of 10^-7
   (using 5 dB target noise margin).

   10PASS-TS PHY is capable of providing at least 10 Mbps over a 750 m
   long single copper pair with a mean BER of 10^-7 (using 6 dB target
   noise margin).

   This memo defines a Management Information Base (MIB) module for use
   with network management protocols in the Internet community to manage
   EFMCu interfaces.  In addition, a MIB module is defined describing
   the cross-connect capability of a stacked interface.

   Note that managed objects for Operation, Administration and
   Maintenance (OAM) and Ethernet over Passive Optical Networks (EPON)
   clauses of IEEE 802.3ah are defined in EFM-COMMON-MIB [RFC4878] and
   EFM-EPON-MIB [RFC4837], respectively.

2.  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 MIB
   modules that are 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 4 
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

3.  Relation to Other MIB Modules

   This section outlines the relationship of the MIB modules defined in
   this document with other MIB modules described in the relevant RFCs.
   Specifically, the Interfaces Group MIB (IF-MIB), Ethernet-Like
   (EtherLike-MIB), MAU (MAU-MIB), SHDSL (HDSL2-SHDSL-LINE-MIB), and
   VDSL (VDSL-LINE-EXT-MCM-MIB) modules are discussed.

3.1.  Relation to Interfaces Group MIB Module

   2BASE-TL and 10PASS-TS PHYs specified in the EFM-CU-MIB module are
   stacked (a.k.a. aggregated or bonded) Ethernet interfaces and as such
   are managed using generic interface management objects defined in the
   IF-MIB [RFC2863].

   The stack management (i.e., actual connection of the sub-layers to
   the top-layer interface) is done via the ifStackTable, as defined in
   the IF-MIB [RFC2863], and its inverse ifInvStackTable, as defined in
   the IF-INVERTED-STACK-MIB [RFC2864].

   The new tables ifCapStackTable and its inverse ifInvCapStackTable
   defined in the IF-CAP-STACK-MIB module below, extend the stack
   management with an ability to describe possible connections or cross-
   connect capability, when a flexible cross-connect matrix is present
   between the interface layers.

3.1.1.  Layering Model

   An EFMCu interface can aggregate up to 32 Physical Medium Entity
   (PME) sub-layer devices (modems), using the so-called PME Aggregation
   Function (PAF).

   A generic EFMCu device can have a number of Physical Coding Sublayer
   (PCS) ports, each connected to a Media Access Controller (MAC) via a
   Medium Independent Interface (MII) at the upper layer, and cross-
   connected to a number of underlying PMEs, with a single PCS per PME
   relationship.  See clause 61.1 of [802.3ah] for more details.

   Each PME in the aggregated EFMCu port is represented in the Interface
   table (ifTable) as a separate interface with ifType of shdsl(169) for
   2BASE-TL or vdsl(97) for 10PASS-TS.  The ifType values are defined in
   [IANAifType-MIB].

Top      ToC       Page 5 
   ifSpeed for each PME SHALL return the actual data bitrate of the
   active PME (e.g., for 2BaseTL PMEs it is a multiple of 64 Kbps).  A
   zero value SHALL be returned when the PME is Initializing or Down.

   The ifSpeed of the PCS is the sum of the current operating data rates
   of all PMEs in the aggregation group, without the 64/65-octet
   encapsulation overhead and PAF overhead, but accounting for the
   Inter-Frame Gaps (IFGs).

   When using the stated definition of ifSpeed for the PCS, there would
   be no frame loss in the following configuration (the test-sets are
   configured to generate 100% of back-to-back traffic, i.e., minimal
   IFG, at 10 or 100 Mbps, with min and max frame sizes; the EFM
   interfaces are aggregated, to achieve the shown speed):

      .-------.           .--.           .---.           .-------.
      |testset|--10BaseT--|CO|--2BaseTL--|CPE|--10BaseT--|testset|
      '-------'           '--'           '---'           '-------'
        ifSpeed= 10 Mbps        10 Mbps         10 Mbps

      .-------.            .--.            .---.            .-------.
      |testset|--100BaseT--|CO|--10PassTS--|CPE|--100BaseT--|testset|
      '-------'            '--'            '---'            '-------'
        ifSpeed= 100 Mbps        100 Mbps         100 Mbps

            Figure 1: Example configuration with no frame loss

Top      ToC       Page 6 
   The following figure shows the IEEE 802.3 layering diagram and
   corresponding use of ifTable and ifMauTable:

    .-------------------------.  -
    |        LLC              |  ^
    +-------------------------+  | 1 ifEntry
    |        MAC              |  |     ifType: ethernetCsmacd(6)
    +-------------------------+  )   ifMauEntry
    |        Reconsiliation   |  |     ifMauType: dot3MauType2BaseTL or
    +-------------------------+  |                dot3MauType10PassTS
    |        PCS              |  v
    +-------------+---+-------+  -
    | TC \        |   |       |  ^
    +-----\       |   |       |  |
    | PMA  )PME 1 |...| PME N |  ) N ifEntry  (N=1..32)
    +-----/       |   |       |  |     ifType: shdsl(169) or vdsl(97)
    | PMD/        |   |       |  v
    '-------------+---+-------'  -

     LLC - Logical Link Control       PMA - Physical Medium Attachment
     MAC - Media Access Control       PMD - Physical Medium Dependent
     PCS - Physical Coding Sub-layer  PME - Physical Medium Entity
     TC  - Transmission Convergence

          Figure 2: Use of ifTable and ifMauTable for EFMCu ports

   The ifStackTable is indexed by the ifIndex values of the aggregated
   EFMCu port (PCS) and the PMEs connected to it. ifStackTable allows a
   Network Management application to determine which PMEs are connected
   to a particular PCS and change connections (if supported by the
   application).  The ifInvStackTable, being an inverted version of the
   ifStackTable, provides an efficient means for a Network Management
   application to read a subset of the ifStackTable and thereby
   determine which PCS runs on top of a particular PME.

   A new table ifCapStackTable, defined in the IF-CAP-STACK-MIB module,
   specifies for each higher-layer interface (e.g., PCS port) a list of
   lower-layer interfaces (e.g., PMEs), which can possibly be cross-
   connected to that higher-layer interface, determined by the cross-
   connect capability of the device.  This table, modeled after
   ifStackTable, is read-only, reflecting current cross-connect
   capability of stacked interface, which can be dynamic in some
   implementations (e.g., if PMEs are located on a pluggable module and
   the module is pulled out).  Note that PME availability per PCS,
   described by ifCapStackTable, can be constrained by other parameters,
   for example, by aggregation capacity of a PCS or by the PME in
   question being already connected to another PCS.  So, in order to

Top      ToC       Page 7 
   ensure that a particular PME can be connected to the PCS, all
   respective parameters (e.g., ifCapStackTable, ifStackTable, and
   efmCuPAFCapacity) SHALL be inspected.

   The ifInvCapStackTable, also defined in the IF-CAP-STACK-MIB module,
   describes which higher-layer interfaces (e.g., PCS ports) can
   possibly be connected to a particular lower-layer interface (e.g.,
   PME), providing an inverted mapping of the ifCapStackTable.  While it
   contains no additional information beyond that already contained in
   the ifCapStackTable, the ifInvCapStackTable has the ifIndex values in
   its INDEX clause in the reverse order, i.e., the lower-layer
   interface first, and the higher-layer interface second, providing an
   efficient means for a Network Management application to read a subset
   of the ifCapStackTable and thereby determine which interfaces can be
   connected to run on top of a particular interface.

3.1.2.  PME Aggregation Function (PAF)

   The PME Aggregation Function (PAF) allows a number of PMEs to be
   aggregated onto a PCS port, by fragmenting the Ethernet frames,
   transmitting the fragments over multiple PMEs, and assembling the
   original frames at the remote port.  PAF is OPTIONAL, meaning that a
   device with a single PME MAY perform fragmentation and re-assembly if
   this function is supported by the device.  Note however that the
   agent is REQUIRED to report on the PAF capability for all EFMCu ports
   (2BASE-TL and 10PASS-TS).

   The EFM-CU-MIB module allows a Network Management application to
   query the PAF capability and enable/disable it if supported.  Note
   that enabling PAF effectively turns on fragmentation and re-assembly,
   even on a single-PME port.

3.1.3.  Discovery Operation

   The EFMCu ports may optionally support discovery operation, whereby
   PMEs, during initialization, exchange information about their
   respective aggregation groups (PCS).  This information can then be
   used to detect copper misconnections or for an automatic assignment
   of the local PMEs into aggregation groups instead of a fixed pre-
   configuration.

   The MIB modules defined in this document allow a Network Management
   application to control the EFM Discovery mechanism and query its
   results.  Note that the Discovery mechanism can work only if PAF is
   supported and enabled.

Top      ToC       Page 8 
   Two tables are used by the EFM Discovery mechanism: ifStackTable and
   ifCapStackTable.  The following pseudo-code gives an example of the
   Discovery and automatic PME assignment for a generic PAF-enabled
   multi-PCS EFMCu device, located at Central Office (CO), using objects
   defined in these MIB modules and in the IF-MIB (Note that automatic
   PME assignment is only shown here for the purposes of the example.
   Fixed PME pre-assignment, manual assignment, or auto-assignment using
   an alternative internal algorithm may be chosen by a particular
   implementation):

 // Go over all PCS ports in the CO device
 FOREACH pcs[i] IN CO_device
 { // Perform discovery and auto-assignment only on PAF enabled ports
   // with room for more PMEs
   IF ( pcs[i].PAFSupported AND pcs[i].NumPMEs < pcs[i].PAFCapacity )
   { // Assign a unique 6-octet local discovery code to the PCS
     // e.g., MAC address
     dc = pcs[i].DiscoveryCode = MAC[i];
     // Go over all disconnected PMEs, which can
     // potentially be connected to the PCS
     FOREACH pme[j] IN ifCapStackTable[pcs[i]] AND
                    NOT IN ifStackTable[pcs[i]]  // not connected
     { // Try to grab the remote RT_device, by writing the value
       // of the local 6-octet discovery code to the remote
       // discovery code register (via handshake mechanism).
       // This operation is atomic Set-if-Clear action, i.e., it
       // would succeed only if the remote discovery register was
       // zero.  Read the remote discovery code register via Get
       // operation to see if the RT_device, attached via the PME
       // is indeed marked as being the CO_device peer.
       pme[j].RemoteDiscoveryCode = dc;          // Set-if-Clear
       r = pme[j].RemoteDiscoveryCode;           // Get
       IF ( r == dc AND pcs[i].NumPMEs < pcs[i].PAFCapacity)
       { // Remote RT_device connected via PME[j] is/was a peer
         // for PCS[i] and there is room for another PME in the
         // PCS[i] aggregation group (max. PAF capacity is not
         // reached yet).
         // Connect this PME to the PCS (via ifStackTable,
         // ifInvStackTable being inverse of ifStackTable is
         // updated automatically, i.e., pcs[i] is auto-added
         // to ifInvStackTable[pme[j]])
         ADD pme[j] TO ifStackTable[pcs[i]];
         pcs[i].NumPMEs = pcs[i].NumPMEs + 1;
         // Discover all other disconnected PMEs,
         // attached to the same RT_device and connect them to
         // the PCS provided there is enough room for more PMEs.
         FOREACH pme[k] IN ifCapStackTable[pcs[i]] AND
                        NOT IN ifStackTable[pcs[i]]

Top      ToC       Page 9 
         { // Get Remote Discovery Code from the PME to see if
           // it belongs to a connected RT_device "grabbed" by
           // the CO_device.
           r = pme[k].RemoteDiscoveryCode;
           IF ( r == dc AND pcs[i].NumPMEs < pcs[i].PAFCapacity)
           { // Physically connect the PME to the PCS
             // (pcs[i] is auto-added TO ifInvStackTable[pme[k]])
             ADD pme[k] TO ifStackTable[pcs[i]];
             pcs[i].NumPMEs = pcs[i].NumPMEs + 1;
           }
         }
       }
       // At this point we have discovered all local PMEs which
       // are physically connected to the same remote RT_device
       // and connected them to PCS[i].  Go to the next PCS.
       BREAK;
     }
   }
 }

   An SNMP Agent for an EFMCu device builds the ifCapStackTable and its
   inverse ifInvCapStackTable according to the information contained in
   the Clause 45 PME_Available_register (see [802.3ah] 61.1.5.3 and
   45.2.3.20).

   Adding a PME to the ifStackTable row for a specific PCS involves
   actual connection of the PME to the PCS, which can be done by
   modifying Clause 45 PME_Aggregate_register (see [802.3ah] 61.1.5.3
   and 45.2.3.21).

   Note that the PCS port does not have to be operationally 'down' for
   the connection to succeed.  In fact, a dynamic PME addition (and
   removal) MAY be implemented with an available PME being initialized
   first (by setting its ifAdminStatus to 'up') and then added to an
   operationally 'up' PCS port, by modifying a respective ifStackTable
   (and respective ifInvStackTable) entry.

   It is RECOMMENDED that a removal of the last operationally 'up' PME
   from an operationally 'up' PCS would be rejected by the
   implementation, as this action would completely drop the link.

3.1.4.  EFMCu Ports Initialization

   EFMCu ports being built on top of xDSL technology require a lengthy
   initialization or 'training' process, before any data can pass.
   During this initialization, both ends of a link (peers) work
   cooperatively to achieve the required data rate on a particular

Top      ToC       Page 10 
   copper pair.  Sometimes, when the copper line is too long or the
   noise on the line is too high, that 'training' process may fail to
   achieve a specific target rate with required characteristics.

   The ifAdminStatus object from the IF-MIB controls the desired state
   of a PCS with all the PMEs connected to it or of an individual PME
   port.  Setting this object to 'up' instructs a particular PCS or PME
   to start the initialization process, which may take tens of seconds
   for EFMCu ports, especially if PAF is involved.  The ifOperStatus
   object shows the operational state of an interface (extended by the
   ifMauMediaAvailable object from MAU-MIB for PCS and
   efmCuPmeOperStatus defined in the EFM-CU-MIB module for PME
   interfaces).

   A disconnected PME may be initialized by changing the ifAdminState
   from 'down' to 'up'.  Changing the ifAdminState to 'up' on the PCS
   initializes all PMEs connected to that particular PCS.  Note that in
   case of PAF some interfaces may fail to initialize while others
   succeed.  The PCS is considered operationally 'up' if at least one
   PME aggregated by its PAF is operationally 'up'.  When all PMEs
   connected to the PCS are 'down', the PCS SHALL be considered
   operationally 'lowerLayerDown'.  The PCS SHALL be considered
   operationally 'notPresent' if it is not connected to any PME.  The
   PCS/PME interface SHALL remain operationally 'down' during
   initialization.

   The efmCuPmeOperStatus defined in the EFM-CU-MIB module expands PME's
   ifOperStatus value of 'down' to 'downReady', 'downNotReady', and
   'init' values, indicating various EFMCu PME-specific states.

3.1.5.  Usage of ifTable

   Both PME and PCS interfaces of the EFMCu PHY are managed using
   interface-specific management objects defined in the EFM-CU-MIB
   module and generic interface objects from the ifTable of IF-MIB, with
   all management table entries referenced by the interface index
   ifIndex.

   The following table summarizes EFMCu-specific interpretations for
   some of the ifTable objects specified in the mandatory
   ifGeneralInformationGroup:

Top      ToC       Page 11 
   +---------------+---------------------------------------------------+
   | IF-MIB object | EFMCu interpretation                              |
   +---------------+---------------------------------------------------+
   | ifIndex       | Interface index.  Note that each PME and each PCS |
   |               | in the EFMCu PHY MUST have a unique index, as     |
   |               | there are some PCS- and PME-specific attributes   |
   |               | accessible only on the PCS or PME level.          |
   +---------------+---------------------------------------------------+
   | ifType        | ethernetCsmacd(6) for PCS, shdsl(169) for         |
   |               | 2BASE-TL PME, vdsl(97) for 10PASS-TS PME.         |
   | ifSpeed       | Operating data rate for the PME.  For the PCS, it |
   |               | is the sum of the current operating data rates of |
   |               | all PMEs in the aggregation group, without the    |
   |               | 64/65-octet encapsulation overhead and PAF        |
   |               | overhead, but accounting for the Inter-Frame Gaps |
   |               | (IFGs).                                           |
   +---------------+---------------------------------------------------+
   | ifAdminStatus | Setting this object to 'up' instructs a           |
   |               | particular PCS (with all PMEs connected to it) or |
   |               | PME to start initialization process.              |
   +---------------+---------------------------------------------------+
   | ifOperStatus  | efmCuPmeOperStatus supplements the 'down' value   |
   |               | of ifOperStatus for PMEs.                         |
   +---------------+---------------------------------------------------+

              Table 1: EFMCu interpretation of IF-MIB objects

3.2.  Relation to SHDSL MIB Module

   G.SHDSL.bis modems, similar to PMEs comprising a 2BASE-TL port, are
   described in the HDSL2-SHDSL-LINE-MIB module [RFC4319].  Note that
   not all attributes of G.SHDSL modems reflected in the HDSL2-SHDSL-
   LINE-MIB module have adequate management objects (Clause 30
   attributes and Clause 45 registers) in the EFM standard.

   Because of these differences and for the purposes of simplicity,
   unification of attributes common to both 2BASE-TL and 10PASS-TS PMEs,
   and name consistency (e.g., prefixing the 2BASE-TL PME related
   objects with 'efmCuPme2B' instead of 'hdsl2shdsl'), it was decided
   not to reference HDSL2-SHDSL-LINE-MIB objects, but define all the
   relevant objects in the EFM-CU-MIB module.

   However, if some functionality not available in the EFM-CU-MIB module
   is required and supported by the PME, e.g., performance monitoring,
   relevant HDSL2-SHDSL-LINE-MIB groups MAY be included and applied for
   PMEs of 2BASE-TL subtype.

Top      ToC       Page 12 
3.3.  Relation to VDSL MIB Module

   VDSL modems, similar to the PME(s) comprising a 10PASS-TS port, are
   described in the VDSL-LINE-EXT-MCM-MIB module [RFC4070].  Note that
   not all attributes of VDSL modems reflected in the VDSL-LINE-EXT-MCM-
   MIB module have adequate management objects (Clause 30 attributes and
   Clause 45 registers) in the EFM standard.

   Because of these differences and for the purposes of simplicity,
   unification of attributes common to both 2BASE-TL and 10PASS-TS PMEs,
   and name consistency, it was decided not to reference VDSL-LINE-EXT-
   MCM-MIB objects, but define all the relevant objects in the EFM-CU-
   MIB module.

   However, if some functionality not available in the EFM-CU-MIB module
   is required and supported by the PME, relevant VDSL-LINE-EXT-MCM-MIB
   groups MAY be included and applied for PMEs of 10PASS-TS subtype.

3.4.  Relation to Ethernet-Like and MAU MIB Modules

   The implementation of the EtherLike-MIB [RFC3635] and MAU-MIB
   [RFC4836] modules is REQUIRED for EFMCu interfaces.

   Two new values of ifMauType (OBJECT-IDENTITIES of dot3MauType) and
   corresponding bit definitions of ifMauTypeListBits
   (IANAifMauTypeListBits) have been defined in the IANA-MAU-MIB module
   [RFC4836] for EFMCu MAUs:

   o  dot3MauType2BaseTL and b2BaseTL - for 2BASE-TL MAU

   o  dot3MauType10PassTS and b10PassTS - for 10PASS-TS MAU

   Additionally, the IANA-MAU-MIB module defines two new values of
   ifMauMediaAvailable, specifically for EFMCu ports: availableReduced
   and ready (in textual convention IANAifMauMediaAvailable).  Due to
   the PME aggregation, the EFMCu interpretation of some possible
   ifMauMediaAvailable values differs from other MAUs as follows:

   o  unknown - the EFMCu interface (PCS with connected PMEs) is
      Initializing

   o  ready - the interface is Down, at least one PME in the aggregation
      group (all PMEs connected to the PCS) is ready for handshake

   o  available - the interface is Up, all PMEs in the aggregation group
      are up

Top      ToC       Page 13 
   o  notAvailable - the interface is Down, all PMEs in the aggregation
      group are Down, no handshake tones are detected by any PME

   o  availableReduced - the interface is Up, a link fault is detected
      at the receive direction by one or more PMEs in the aggregation
      group, but at least one PME is Up

   o  pmdLinkFault - a link fault is detected at the receive direction
      by all PMEs in the aggregation group

   As an EtherLike interface, every EFMCu port (an ifEntry representing
   a consolidation of LLC, MAC, and PCS (sub)layers) SHALL return an
   ifType of ethernetCsmacd(6).  While most of the MAU characteristics
   are not applicable to the EFMCu ports (no auto-negotiation, false
   carriers, or jabber), they SHALL return an appropriate ifMauType
   (dot3MauType2BaseTL or dot3mauType10PassTS) in order to direct the
   management software to look in the EFM-CU-MIB module for the desired
   information.  For example, the information on the particular EFMCu
   flavor that an EFMCu port is running is available from
   efmCuOperSubType, defined in the EFM-CU-MIB module.

   Since EFMCu PMEs are not EtherLike interfaces, they cannot be
   instantiated as MAU interface objects.

4.  MIB Structure

4.1.  EFM Copper MIB Overview

   The main management objects defined in the EFM-CU-MIB module are
   split into 2 groups:

   o  efmCuPort - containing objects for configuration, capabilities,
      status, and notifications, common to all EFMCu PHYs.

   o  efmCuPme - containing objects for configuration, capabilities,
      status, and notifications of EFMCu PMEs.

   The efmCuPme group in turn contains efmCuPme2B and efmCuPme10P
   groups, which define PME profiles specific to 2BASE-TL and 10PASS-TS
   PMEs, respectively, as well as PME-specific status information.

4.2.  Interface Stack Capability MIB Overview

   The IF-CAP-STACK-MIB module contains 2 tables:

   o  ifCapStackTable - containing objects that define possible
      relationships among the sub-layers of an interface with flexible
      cross-connect (cross-connect capability).

Top      ToC       Page 14 
   o  ifInvCapStackTable - an inverse of the ifCapstackTable.

4.3.  PME Profiles

   Since a managed node can have a large number of EFMCu PHYs,
   provisioning every parameter on every EFMCu PHY may become
   burdensome.  Moreover, most PMEs are provisioned identically with the
   same set of parameters.  To simplify the provisioning process, the
   EFM-CU-MIB module makes use of configuration profiles, similar to the
   HDSL2-SHDSL-LINE-MIB and VDSL-LINE-EXT-MCM-MIB modules.  A profile is
   a set of parameters, used either for configuration or representation
   of a PME.  The same profile can be shared by multiple PME ports using
   the same configuration.

   The PME profiles are defined in the efmCuPme2BProfileTable and
   efmCuPme10PProfileTable for 2BASE-TL and 10PASS-TS PMEs,
   respectively.  There are 12 predefined standard profiles for 2BASE-TL
   and 22 standard profiles for 10PASS-TS, defined in 802.3ah and
   dedicated for rapid provisioning of EFMCu PHYs in most scenarios.  In
   addition, the EFM-CU-MIB defines two additional predefined profiles
   for "best-effort" provisioning of 2BASE-TL PMEs.  An ability to
   define new configuration profiles is also provided to allow for EFMCu
   deployment tailored to specific copper environments and spectral
   regulations.

   A specific configuration or administrative profile is assigned to a
   specific PME via the efmCuPmeAdminProfile object.  If
   efmCuPmeAdminProfile is zero, then the efmCuAdminProfile object of
   the PCS port connected to the PME determines the configuration
   profile (or a list of possible profiles) for that PME.  This
   mechanism allows specifying a common profile for all PMEs connected
   to the PCS port, with an ability to change individual PME profiles by
   setting efmCuPmeAdminProfile object, which overwrites the profile set
   by efmCuAdminProfile.

   A current operating PME profile is pointed to by the
   efmCuPmeOperProfile object.  Note that this profile entry can be
   created automatically to reflect achieved parameters in adaptive (not
   fixed) initialization.

4.4.  Mapping of IEEE 802.3ah Managed Objects

   This section contains the mapping between relevant managed objects
   (attributes) defined in [802.3ah] Clause 30, and managed objects
   defined in this document and in associated MIB modules, i.e., the IF-
   MIB [RFC2863].

Top      ToC       Page 15 
   Note that the majority of the objects defined in the EFM-CU-MIB
   module do not have direct counterparts in Clause 30 and instead refer
   to Clause 45 registers.

   +---------------------------------+---------------------------------+
   | IEEE 802.3 Managed Object       | Corresponding SNMP Object       |
   +---------------------------------+---------------------------------+
   | oMAU - Basic Package            |                                 |
   | (Mandatory)                     |                                 |
   +---------------------------------+---------------------------------+
   | aMAUType                        | ifMauType (MAU-MIB)             |
   +---------------------------------+---------------------------------+
   | aMAUTypeList                    | ifMauTypeListBits (MAU-MIB)     |
   +---------------------------------+---------------------------------+
   | aMediaAvailable                 | ifMediaAvailable (MAU-MIB)      |
   +---------------------------------+---------------------------------+
   | oPAF - Basic Package            |                                 |
   | (Mandatory)                     |                                 |
   +---------------------------------+---------------------------------+
   | aPAFID                          | ifIndex (IF-MIB)                |
   +---------------------------------+---------------------------------+
   | aPhyEnd                         | efmCuPhySide                    |
   +---------------------------------+---------------------------------+
   | aPHYCurrentStatus               | efmCuStatus                     |
   +---------------------------------+---------------------------------+
   | aPAFSupported                   | efmCuPAFSupported               |
   +---------------------------------+---------------------------------+
   | oPAF - PME Aggregation Package  |                                 |
   | (Optional)                      |                                 |
   +---------------------------------+---------------------------------+
   | aPAFAdminState                  | efmCuPAFAdminState              |
   +---------------------------------+---------------------------------+
   | aLocalPAFCapacity               | efmCuPAFCapacity                |
   +---------------------------------+---------------------------------+
   | aLocalPMEAvailable              | ifCapStackTable                 |
   +---------------------------------+---------------------------------+
   | aLocalPMEAggregate              | ifStackTable (IF-MIB)           |
   +---------------------------------+---------------------------------+
   | aRemotePAFSupported             | efmCuRemotePAFSupported         |
   +---------------------------------+---------------------------------+
   | aRemotePAFCapacity              | efmCuRemotePAFCapacity          |
   +---------------------------------+---------------------------------+
   | aRemotePMEAggregate             |                                 |
   +---------------------------------+---------------------------------+
   | oPME - 10P/2B Package           |                                 |
   | (Mandatory)                     |                                 |
   +---------------------------------+---------------------------------+
   | aPMEID                          | ifIndex (IF-MIB)                |

Top      ToC       Page 16 
   +---------------------------------+---------------------------------+
   | aPMEAdminState                  | ifAdminState (IF-MIB)           |
   +---------------------------------+---------------------------------+
   | aPMEStatus                      | efmCuPmeStatus                  |
   | aPMESNRMgn                      | efmCuPmeSnrMgn                  |
   +---------------------------------+---------------------------------+
   | aTCCodingViolations             | efmCuPmeTCCodingErrors          |
   +---------------------------------+---------------------------------+
   | aTCCRCErrors                    | efmCuPmeTCCrcErrors             |
   +---------------------------------+---------------------------------+
   | aProfileSelect                  | efmCuAdminProfile,              |
   |                                 | efmCuPmeAdminProfile            |
   +---------------------------------+---------------------------------+
   | aOperatingProfile               | efmCuPmeOperProfile             |
   +---------------------------------+---------------------------------+
   | aPMEFECCorrectedBlocks          | efmCuPme10PFECCorrectedBlocks   |
   +---------------------------------+---------------------------------+
   | aPMEFECUncorrectableBlocks      | efmCuPme10PFECUncorrectedBlocks |
   +---------------------------------+---------------------------------+

              Table 2: Mapping of IEEE 802.3 Managed Objects

5.  Interface Stack Capability MIB Definitions

   IF-CAP-STACK-MIB DEFINITIONS ::= BEGIN

     IMPORTS
       MODULE-IDENTITY, OBJECT-TYPE, mib-2
         FROM SNMPv2-SMI         -- [RFC2578]
       TruthValue
         FROM SNMPv2-TC          -- [RFC2579]
       MODULE-COMPLIANCE, OBJECT-GROUP
         FROM SNMPv2-CONF        -- [RFC2580]
       ifStackGroup2, ifStackHigherLayer, ifStackLowerLayer
         FROM IF-MIB             -- [RFC2863]
       ifInvStackGroup
         FROM IF-INVERTED-STACK-MIB -- [RFC2864]
       ;

     ifCapStackMIB MODULE-IDENTITY
       LAST-UPDATED "200711070000Z"  -- November 07, 2007
       ORGANIZATION "IETF Ethernet Interfaces and Hub MIB Working Group"
       CONTACT-INFO
         "WG charter:
           http://www.ietf.org/html.charters/OLD/hubmib-charter.html

         Mailing Lists:
           General Discussion: hubmib@ietf.org

Top      ToC       Page 17 
           To Subscribe: hubmib-request@ietf.org
           In Body: subscribe your_email_address

         Chair:  Bert Wijnen
         Postal: Alcatel-Lucent
                 Schagen 33
                 3461 GL Linschoten
                 Netherlands
          Phone: +31-348-407-775
          EMail: bwijnen@alcatel-lucent.com

         Editor: Edward Beili
         Postal: Actelis Networks Inc.
                 25 Bazel St., P.O.B. 10173
                 Petach-Tikva 10173
                 Israel
          Phone: +972-3-924-3491
          EMail: edward.beili@actelis.com"

       DESCRIPTION
         "The objects in this MIB module are used to describe
         cross-connect capabilities of stacked (layered) interfaces,
         complementing ifStackTable and ifInvStackTable defined in
         IF-MIB and IF-INVERTED-STACK-MIB, respectively.

         Copyright (C) The IETF Trust (2007).  This version
         of this MIB module is part of RFC 5066;  see the RFC
         itself for full legal notices."

       REVISION    "200711070000Z"  -- November 07, 2007
       DESCRIPTION "Initial version, published as RFC 5066."

       ::= { mib-2 166 }

      -- Sections of the module
      -- Structured as recommended by [RFC4181], see
      -- Appendix D: Suggested OID Layout

      ifCapStackObjects     OBJECT IDENTIFIER ::= { ifCapStackMIB 1 }

      ifCapStackConformance OBJECT IDENTIFIER ::= { ifCapStackMIB 2 }

      -- Groups in the module

      --
      -- ifCapStackTable group
      --

Top      ToC       Page 18 
      ifCapStackTable  OBJECT-TYPE
        SYNTAX      SEQUENCE OF IfCapStackEntry
        MAX-ACCESS  not-accessible
        STATUS      current
        DESCRIPTION
          "This table, modeled after ifStackTable from IF-MIB,
          contains information on the possible 'on-top-of'
          relationships between the multiple sub-layers of network
          interfaces (as opposed to actual relationships described in
          ifStackTable).  In particular, it contains information on
          which sub-layers MAY possibly run 'on top of' which other
          sub-layers, as determined by cross-connect capability of the
          device, where each sub-layer corresponds to a conceptual row
          in the ifTable.  For example, when the sub-layer with ifIndex
          value x can be connected to run on top of the sub-layer with
          ifIndex value y, then this table contains:

            ifCapStackStatus.x.y=true

          The ifCapStackStatus.x.y row does not exist if it is
          impossible to connect between the sub-layers x and y.

          Note that for most stacked interfaces (e.g., 2BASE-TL)
          there's always at least one higher-level interface (e.g., PCS
          port) for each lower-level interface (e.g., PME) and at
          least one lower-level interface for each higher-level
          interface, that is, there is at least a single row with a
          'true' status for any such existing value of x or y.

          This table is read-only as it describes device capabilities."
        REFERENCE
          "IF-MIB, ifStackTable"
        ::= { ifCapStackObjects 1 }

      ifCapStackEntry  OBJECT-TYPE
        SYNTAX      IfCapStackEntry
        MAX-ACCESS  not-accessible
        STATUS      current
        DESCRIPTION
          "Information on a particular relationship between two
          sub-layers, specifying that one sub-layer MAY possibly run
          on 'top' of the other sub-layer.  Each sub-layer corresponds
          to a conceptual row in the ifTable (interface index for
          lower and higher layer, respectively)."
        INDEX {
          ifStackHigherLayer,
          ifStackLowerLayer
        }

Top      ToC       Page 19 
        ::= { ifCapStackTable 1 }

      IfCapStackEntry ::= SEQUENCE {
           ifCapStackStatus       TruthValue
         }

      ifCapStackStatus  OBJECT-TYPE
        SYNTAX      TruthValue
        MAX-ACCESS  read-only
        STATUS      current
        DESCRIPTION
          "The status of the 'cross-connect capability' relationship
          between two sub-layers.  The following values can be returned:
            true(1)         - indicates that the sub-layer interface,
                              identified by the ifStackLowerLayer MAY
                              be connected to run 'below' the sub-layer
                              interface, identified by the
                              ifStackHigherLayer index.
            false(2)        - the sub-layer interfaces cannot be
                              connected temporarily due to
                              unavailability of the interface(s), e.g.,
                              one of the interfaces is located on an
                              absent pluggable module.

          Note that lower-layer interface availability per higher-layer,
          indicated by the value of 'true', can be constrained by
          other parameters, for example, by the aggregation capacity of
          a higher-layer interface or by the lower-layer interface in
          question being already connected to another higher-layer
          interface.  In order to ensure that a particular sub-layer can
          be connected to another sub-layer, all respective objects
          (e.g., ifCapStackTable, ifStackTable, and efmCuPAFCapacity for
          EFMCu interfaces) SHALL be inspected.

          This object is read-only, unlike ifStackStatus, as it
          describes a cross-connect capability."
        ::= { ifCapStackEntry 1 }

      ifInvCapStackTable  OBJECT-TYPE
        SYNTAX        SEQUENCE OF IfInvCapStackEntry
        MAX-ACCESS    not-accessible
        STATUS        current
        DESCRIPTION
          "A table containing information on the possible relationships
          between the multiple sub-layers of network interfaces.  This
          table, modeled after ifInvStackTable from
          IF-INVERTED-STACK-MIB, is an inverse of the ifCapStackTable
          defined in this MIB module.

Top      ToC       Page 20 
          In particular, this table contains information on which
          sub-layers MAY run 'underneath' which other sub-layers, where
          each sub-layer corresponds to a conceptual row in the ifTable.
          For example, when the sub-layer with ifIndex value x MAY be
          connected to run underneath the sub-layer with ifIndex value
          y, then this table contains:

             ifInvCapStackStatus.x.y=true

          This table contains exactly the same number of rows as the
          ifCapStackTable, but the rows appear in a different order.

          This table is read-only as it describes a cross-connect
          capability."
        REFERENCE
           "IF-INVERTED-STACK-MIB, ifInvStackTable"
        ::= { ifCapStackObjects 2 }

      ifInvCapStackEntry  OBJECT-TYPE
        SYNTAX        IfInvCapStackEntry
        MAX-ACCESS    not-accessible
        STATUS        current
        DESCRIPTION
           "Information on a particular relationship between two sub-
           layers, specifying that one sub-layer MAY run underneath the
           other sub-layer.  Each sub-layer corresponds to a conceptual
           row in the ifTable."
        INDEX { ifStackLowerLayer, ifStackHigherLayer }
        ::= { ifInvCapStackTable 1 }

       IfInvCapStackEntry ::= SEQUENCE {
         ifInvCapStackStatus       TruthValue
       }

      ifInvCapStackStatus  OBJECT-TYPE
        SYNTAX         TruthValue
        MAX-ACCESS     read-only
        STATUS         current
        DESCRIPTION
           "The status of the possible 'cross-connect capability'
           relationship between two sub-layers.

           An instance of this object exists for each instance of the
           ifCapStackStatus object, and vice versa.  For example, if the
           variable ifCapStackStatus.H.L exists, then the variable
           ifInvCapStackStatus.L.H must also exist, and vice versa.  In
           addition, the two variables always have the same value.

Top      ToC       Page 21 
           The ifInvCapStackStatus object is read-only, as it describes
           a cross-connect capability."
        REFERENCE
           "ifCapStackStatus"
        ::= { ifInvCapStackEntry 1 }

     --
     -- Conformance Statements
     --

      ifCapStackGroups      OBJECT IDENTIFIER ::=
           { ifCapStackConformance 1 }

      ifCapStackCompliances OBJECT IDENTIFIER ::=
           { ifCapStackConformance 2 }

      -- Units of Conformance

      ifCapStackGroup OBJECT-GROUP
        OBJECTS {
          ifCapStackStatus,
          ifInvCapStackStatus
        }
        STATUS  current
        DESCRIPTION
          "A collection of objects providing information on the
          cross-connect capability of multi-layer (stacked) network
          interfaces."
        ::= { ifCapStackGroups 1 }


     -- Compliance Statements

      ifCapStackCompliance MODULE-COMPLIANCE
        STATUS      current
        DESCRIPTION
          "The compliance statement for SNMP entities, which provide
          information on the cross-connect capability of multi-layer
          (stacked) network interfaces, with flexible cross-connect
          between the sub-layers."


        MODULE  -- this module
          MANDATORY-GROUPS {
            ifCapStackGroup
          }

          OBJECT       ifCapStackStatus

Top      ToC       Page 22 
          SYNTAX       TruthValue { true(1) }
          DESCRIPTION
            "Support for the false(2) value is OPTIONAL for
            implementations supporting pluggable interfaces."

          OBJECT       ifInvCapStackStatus
          SYNTAX       TruthValue { true(1) }
          DESCRIPTION
            "Support for the false(2) value is OPTIONAL for
            implementations supporting pluggable interfaces."

        MODULE  IF-MIB
          MANDATORY-GROUPS {
            ifStackGroup2
          }

        MODULE  IF-INVERTED-STACK-MIB
          MANDATORY-GROUPS {
            ifInvStackGroup
          }

        ::= { ifCapStackCompliances 1 }
   END



(page 22 continued on part 2)

Next RFC Part