Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 5066

Ethernet in the First Mile Copper (EFMCu) Interfaces MIB

Pages: 90
Proposed Standard
Updated by:  7124
Part 1 of 4 – Pages 1 to 22
None   None   Next

Top   ToC   RFC5066 - 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   ToC   RFC5066 - 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   RFC5066 - 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   RFC5066 - 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   RFC5066 - 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   RFC5066 - 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   RFC5066 - 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   RFC5066 - 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   RFC5066 - 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   RFC5066 - 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   RFC5066 - 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   RFC5066 - 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   RFC5066 - 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   RFC5066 - 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   RFC5066 - 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   RFC5066 - 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   RFC5066 - 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   RFC5066 - 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   RFC5066 - 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   RFC5066 - 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   RFC5066 - 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   RFC5066 - 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 Section