--- 1/draft-ietf-hubmib-efm-cu-mib-03.txt 2006-02-04 17:18:11.000000000 +0100 +++ 2/draft-ietf-hubmib-efm-cu-mib-04.txt 2006-02-04 17:18:11.000000000 +0100 @@ -1,85 +1,83 @@ Network Working Group E. Beili Internet-Draft Actelis Networks -Expires: October 3, 2005 April 4, 2005 +Expires: April 27, 2006 October 24, 2005 Ethernet in the First Mile Copper (EFMCu) Interfaces MIB - draft-ietf-hubmib-efm-cu-mib-03.txt + draft-ietf-hubmib-efm-cu-mib-04.txt Status of this Memo - This document is an Internet-Draft and is subject to all provisions - of section 3 of RFC 3667. By submitting this Internet-Draft, each - author represents that any applicable patent or other IPR claims of - which he or she is aware have been or will be disclosed, and any of - which he or she become aware will be disclosed, in accordance with - RFC 3668. + By submitting this Internet-Draft, each author represents that any + applicable patent or other IPR claims of which he or she is aware + have been or will be disclosed, and any of which he or she becomes + aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as - Internet-Drafts. + other groups may also distribute working documents as Internet- + Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on October 3, 2005. + This Internet-Draft will expire on April 27, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document defines a Management Information Base (MIB) module for use with network management protocols in TCP/IP based internets. This document proposes an extension to the Ethernet-like Interfaces MIB and MAU MIB modules with a set of objects for managing an Ethernet in the First Mile Copper (EFMCu) interfaces 10PASS-TS and 2BASE-TL, defined in IEEE Std 802.3ah-2004. 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) . . . . . . . . . . . . 6 - 3.1.3 Discovery Operation . . . . . . . . . . . . . . . . . 6 - 3.1.4 EFMCu ports initialization . . . . . . . . . . . . . . 8 - 3.1.5 Usage of ifTable . . . . . . . . . . . . . . . . . . . 8 - 3.2 Relation to SHDSL MIB module . . . . . . . . . . . . . . . 9 - 3.3 Relation to VDSL MIB module . . . . . . . . . . . . . . . 10 - 3.4 Relation to Ethernet-Like and MAU MIB modules . . . . . . 10 + 3.1. Relation to Interfaces Group MIB module . . . . . . . . . 4 + 3.1.1. Layering Model . . . . . . . . . . . . . . . . . . . . 4 + 3.1.2. PME Aggregation Function (PAF) . . . . . . . . . . . . 6 + 3.1.3. Discovery Operation . . . . . . . . . . . . . . . . . 6 + 3.1.4. EFMCu ports initialization . . . . . . . . . . . . . . 8 + 3.1.5. Usage of ifTable . . . . . . . . . . . . . . . . . . . 8 + 3.2. Relation to SHDSL MIB module . . . . . . . . . . . . . . . 9 + 3.3. Relation to VDSL MIB module . . . . . . . . . . . . . . . 10 + 3.4. Relation to Ethernet-Like and MAU MIB modules . . . . . . 10 4. MIB Structure . . . . . . . . . . . . . . . . . . . . . . . . 11 - 4.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 11 - 4.2 PME Profiles . . . . . . . . . . . . . . . . . . . . . . . 11 - 4.3 Mapping of IEEE 802.3ah Managed Objects . . . . . . . . . 12 + 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 11 + 4.2. PME Profiles . . . . . . . . . . . . . . . . . . . . . . . 11 + 4.3. Mapping of IEEE 802.3ah Managed Objects . . . . . . . . . 12 5. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 67 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 69 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 69 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 69 - 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 69 - 9.2 Informative References . . . . . . . . . . . . . . . . . . . 70 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . 71 - Intellectual Property and Copyright Statements . . . . . . . . 72 + 9.1. Normative References . . . . . . . . . . . . . . . . . . . 69 + 9.2. Informative References . . . . . . . . . . . . . . . . . . 70 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 72 + Intellectual Property and Copyright Statements . . . . . . . . . . 73 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). 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 EFMCu, are based on ITU-T G.SHDSL [G.991.2] and VDSL [G.993.1] specifications @@ -93,62 +91,61 @@ 10PASS-TS PHY is capable of providing at least 10Mbps over 750 m long single copper pair with a mean BER of 10^-7 (using 6dB 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. Note that managed objects for Operation, Administration and Management (OAM) and Ethernet over Passive Optical Networks (EPON) - clauses of IEEE 802.3ah are defined in EFM-COMMON-MIB - [I-D.ietf-hubmib-efm-mib] and EFM-EPON-MIB - [I-D.ietf-hubmib-efm-epon-mib] respectively. + clauses of IEEE 802.3ah are defined in EFM-COMMON-MIB [I-D.ietf- + hubmib-efm-mib] and EFM-EPON-MIB [I-D.ietf-hubmib-efm-epon-mib] + 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 a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 - [RFC2580]. A detailed introduction to the current SNMP Management - Framework can be found in RFC 2570 [RFC2570]. + [RFC2580]. 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 this MIB with other MIB modules described in the relevant RFCs. Specifically, Interfaces Group MIB (IF-MIB), Ethernet-Like (EtherLike-MIB), MAU (MAU-MIB), SHDSL (HDSL2-SHDSL-LINE-MIB) and VDSL (VDSL-LINE-EXT-MCM-MIB) are discussed. -3.1 Relation to Interfaces Group MIB module +3.1. Relation to Interfaces Group MIB module 2BASE-TL and 10PASS-TS PHY's specified in this MIB module are stacked Ethernet interfaces and as such are managed using generic interface management objects defined in the IF-MIB [RFC2863]. The stack management is done via the ifStackTable, as defined in the IF-MIB - [RFC2863] and ifInvStackTable, as defined in the - IF-INVERTED-STACK-MIB [RFC2864]. + [RFC2863] and ifInvStackTable, as defined in the IF-INVERTED-STACK- + MIB [RFC2864]. -3.1.1 Layering Model +3.1.1. Layering Model An EFMCu interface can aggregate up to 32 Physical Medium Entity (PME) sub-layer devices (modems), using so called PME Aggregation Function (PAF). A generic EFMCu device can have a number of Physical Coding Sublayer (PCS) ports, connected to a MAC via 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. @@ -157,22 +154,22 @@ table (ifTable) as a separate port with ifType of shdsl(169) for 2BASE-TL or vdsl(97) for 10PASS-TS. The ifType values are defined in [IANAifType-MIB]. ifSpeed for each PME SHALL return the actual data bitrate of the active PME (e.g. for 2BaseTL PMEs it is a multiple of 64Kbps). Zero value SHALL be returned when 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/65B - encapsulation overhead and PAF overhead, but acounting for the - Inter-Frame Gaps (IFG). + encapsulation overhead and PAF overhead, but acounting for the Inter- + Frame Gaps (IFG). 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 100Mbps, with min and max frame sizes; the EFM interfaces are obviously aggregated): [testset]--10BaseT--[CO]--2BaseTL--[CPE]--10BaseT--[testset] ifSpeed= 10Mbps 10Mbps 10Mbps @@ -205,57 +202,57 @@ 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 ifAvailableStackTable defined in this MIB module, - specifies for each PCS a list of PMEs, which can possibly be - cross-connected to that PCS, determined by the cross-connect - capability of the device. This table, modeled after ifStackTable, is - read only, reflecting current cross-connect capability, 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 ifAvailableStackTable, 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 ensure that a particular PME can be connected - to the PCS, all respective parameters (e.g. ifAvailableStackTable, - ifStackTable and efmCuPAFCapacity) SHALL be inspected. + specifies for each PCS a list of PMEs, which can possibly be cross- + connected to that PCS, determined by the cross-connect capability of + the device. This table, modeled after ifStackTable, is read only, + reflecting current cross-connect capability, 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 ifAvailableStackTable, 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 ensure that a particular PME can be connected to the PCS, all + respective parameters (e.g. ifAvailableStackTable, ifStackTable and + efmCuPAFCapacity) SHALL be inspected. -3.1.2 PME Aggregation Function (PAF) +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). This MIB module allows a Network Management application to query 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 +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 missconnections or for an automatic assignment - of the local PMEs into aggregation groups instead of fixed - pre-configuration. + of the local PMEs into aggregation groups instead of fixed pre- + configuration. This MIB module allows a Network Management application to control EFM Discovery mechanism and query its results. Note that the Discovery mechanism can work only if PAF is supported and enabled. Two tables are used by Discovery mechanism: ifStackTable and ifAvailableStackTable defined. The following pseudo-code defines an example of Discovery and automatic PME assignment for a generic PAF enabled multi-PCS EFMCu device, located at Central Office (CO), using objects defined in this MIB module. [Note that automatic PME @@ -311,21 +308,21 @@ Note that 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 whith 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 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 +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 required data rate on a particular copper pair. Sometimes, when the copper line is too long or the noise environment 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 @@ -345,106 +342,96 @@ 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 this 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 +3.1.5. Usage of ifTable Both PME and PCS interfaces of the EFMCu PHY are managed using interface specific management objects defined in this 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 by the mandatory ifGeneralInformationGroup: - +---------------------------------+---------------------------------+ + +---------------+---------------------------------------------------+ | 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 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/65B encapsulation overhead | - | | and PAF overhead, but acounting | - | | for the Inter-Frame Gaps (IFG) | - | 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. | - +---------------------------------+---------------------------------+ + +---------------+---------------------------------------------------+ + | ifIndex | Interface index. Note that each PME and each PCS | + | | in the EFMCu PHY MUST have a unique index, as | + | | there 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/65B encapsulation overhead and PAF overhead, | + | | but acounting for the Inter-Frame Gaps (IFG) | + | 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 -3.2 Relation to SHDSL MIB module +3.2. Relation to SHDSL MIB module G.SHDSL.bis modems, similar to PME(s) comprising a 2BASE-TL port, are described in HDSL2-SHDSL-LINE-MIB [I-D.ietf-adslmib-gshdslbis]. Note - that not all attributes of G.SHDSL modems reflected in - HDSL2-SHDSL-LINE-MIB have adequate management objects (Clause 30 - attributes and Clause 45 registers) in the EFM standard. + that not all attributes of G.SHDSL modems reflected in HDSL2-SHDSL- + LINE-MIB 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 this MIB module. + 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 this MIB module. However, if some functionality, not available in this MIB module, is required and supported by the PME, e.g. performance monitoring, relevant HDSL2-SHDSL-LINE-MIB groups MAY be included and aplied for PMEs of 2BASE-TL subtype. -3.3 Relation to VDSL MIB module +3.3. Relation to VDSL MIB module VDSL (DMT) modems, similar to the PME(s) comprising a 10PASS-TS port, - are described in VDSL-LINE-EXT-MCM-MIB - [I-D.ietf-adslmib-vdsl-ext-mcm]. Note that not all attributes of - VDSL modems reflected in VDSL-LINE-EXT-MCM-MIB have adequate - management objects (Clause 30 attributes and Clause 45 registers) in - the EFM standard. + are described in VDSL-LINE-EXT-MCM-MIB [RFC4070]. Note that not all + attributes of VDSL modems reflected in VDSL-LINE-EXT-MCM-MIB 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 - this MIB module. + and name consistency, it was decided not to reference VDSL-LINE-EXT- + MCM-MIB objects, but define all the relevant objects in this MIB + module. However, if some functionality, not available in this 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 +3.4. Relation to Ethernet-Like and MAU MIB modules - The implementation of EtherLike-MIB [RFC3635] and MAU-MIB - [I-D.ietf-hubmib-rfc3636bis] is REQUIRED for the EFMCu interfaces. + The implementation of EtherLike-MIB [RFC3635] and MAU-MIB [I-D.ietf- + hubmib-rfc3636bis] is REQUIRED for the 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-TC-MIB [I-D.ietf-hubmib-rfc3636bis] for the EFMCu MAUs: o dot3MauType2BaseTL and b2BaseTL - for 2BASE-TL MAU o dot3MauType10PassTS and b10PassTS - for 10PASS-TS MAU @@ -457,87 +444,85 @@ management software to look in the EFM-CU-MIB 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 this MIB module. Since EFMCu PMEs are not EtherLike interfaces, they cannot be instantiated as MAU interface objects. 4. MIB Structure -4.1 Overview +4.1. Overview The main management objects defined in this 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. In addition the ifAvailableStackTable is defined at the same level. 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 PME Profiles +4.2. 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, this - MIB module makes use of configuration profiles, similar to - HDSL2-SHDSL-LINE-MIB and VDSL-LINE-EXT-MCM-MIB. 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. + MIB module makes use of configuration profiles, similar to HDSL2- + SHDSL-LINE-MIB and VDSL-LINE-EXT-MCM-MIB. 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 efmCuPme2BProfileTable and efmCu10PProfileTable 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. An ability to - define new configuration profiles is also provided to allow for EFMCu - deployment tailored to specific copper environment and spectral - regulations. + rapid provisioning of EFMCu PHYs in most scenarios. In addition this + 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 environment and spectral regulations. A specific configuration or administrative profile is assigned to a specific PME via efmCuPmeAdminProfile object. If efmCuPmeAdminProfile is zero, then 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 to specify a common profile(s) for all PMEs connected to the PCS port, with an ability to change individual PME profiles by setting - efmCuPmeAdminProfile objects, which overwrites profile set by + efmCuPmeAdminProfile object, which overwrites profile set by efmCuAdminProfile. A current operating PME profile is pointed to by efmCuPmeOperProfile object. Note that this profile entry, can be created automatically, to reflect achieved parameters in adaptive (not fixed) initialization. -4.3 Mapping of IEEE 802.3ah Managed Objects +4.3. Mapping of IEEE 802.3ah Managed Objects This section contains the mapping between 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]. + defined in this document and in associated MIB modules, i.e., the IF- + MIB [RFC2863]. Note that majority of the objects defined in this MIB module do not have direct counterparts in Clause 30 and instead refer to Clause 45 registers. - *EdNote: It would be a good idea to update Clause 30 of 802.3ah after - this MIB module is approved. I guess this should be done via a - maintanence request. * +---------------------------------+---------------------------------+ | IEEE 802.3 Managed Object | Corresponding SNMP Object | +---------------------------------+---------------------------------+ | oPAF - Basic Package | | | (Mandatory) | | | aPAFID | ifIndex (IF-MIB) | | aPhyEnd | efmCuPhySide | | aPHYCurrentStatus | efmCuStatus | | aPAFSupported | efmCuPAFSupported | | oPAF - PME Aggregation Package | | @@ -549,49 +534,50 @@ | aRemotePAFSupported | efmCuRemotePAFSupported | | aRemotePAFCapacity | efmCuRemotePAFCapacity | | aRemotePMEAggregate | | | oPME - 10P/2B Package | | | (Mandatory) | | | aPMEID | ifIndex (IF-MIB) | | aPMEAdminState | ifAdminState (IF-MIB) | | aPMEStatus | efmCuPmeStatus | | aPMESNRMgn | efmCuPmeSnrMgn | | aTCCodingViolations | efmCuPmeTCCodingErrors | + | aTCCRCErrors | efmCuPmeTCCrcErrors | | aProfileSelect | efmCuAdminProfile, | | | efmCuPmeAdminProfile | | aOperatingProfile | efmCuPmeOperProfile | | aPMEFECCorrectedBlocks | efmCuPme10PFECCorrectedBlocks | | aPMEFECUncorrectableBlocks | efmCuPme10PFECUncorrectedBlocks | +---------------------------------+---------------------------------+ Table 2 5. Definitions EFM-CU-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, Integer32, Unsigned32, Counter32, mib-2 - FROM SNMPv2-SMI -- [RFC2578] + FROM SNMPv2-SMI -- RFC 2578 TEXTUAL-CONVENTION, TruthValue, RowStatus, PhysAddress - FROM SNMPv2-TC -- [RFC2579] + FROM SNMPv2-TC -- RFC 2579 MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP - FROM SNMPv2-CONF -- [RFC2580] + FROM SNMPv2-CONF -- RFC 2580] SnmpAdminString - FROM SNMP-FRAMEWORK-MIB -- [RFC3411] + FROM SNMP-FRAMEWORK-MIB -- RFC 3411 ifIndex, ifSpeed, InterfaceIndex - FROM IF-MIB -- [RFC2863] + FROM IF-MIB -- RFC 2863 ; efmCuMIB MODULE-IDENTITY - LAST-UPDATED "200504040000Z" -- April 04, 2005 + LAST-UPDATED "200510240000Z" -- October 24, 2005 ORGANIZATION "IETF Ethernet Interfaces and Hub MIB Working Group" CONTACT-INFO "WG charter: http://www.ietf.org/html.charters/hubmib-charter.html Mailing Lists: General Discussion: hubmib@ietf.org To Subscribe: hubmib-request@ietf.org In Body: subscribe your_email_address @@ -598,30 +584,31 @@ Chair: Dan Romascanu Postal: Avaya Atidim Technology Park, Bldg. 3 Tel Aviv 61131 Israel Tel: +972 3 645 8414 E-mail: dromasca@avaya.com Editor: Edward Beili Postal: Actelis Networks Inc. + 25 Bazel St., P.O.B. 10173 Petach-Tikva 10173 Israel Tel: +972-3-924-3491 E-mail: edward.beili@actelis.com" DESCRIPTION "The objects in this MIB module are used to manage the Ethernet in the First Mile (EFM) Copper (EFMCu) Interfaces - 2BASE-TL and 10PASS-TS, defined in IEEE Draft P802.3ah/D3.3. + 2BASE-TL and 10PASS-TS, defined in IEEE Std. 802.3ah-2004. The following reference is used throughout this MIB module: [802.3ah] refers to: IEEE Std 802.3ah-2004: 'IEEE Standard for Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements - Part 3: Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer @@ -645,41 +632,41 @@ EFMCu - EFM Copper MDIO - Management Data Input/Output Mgn - Margin PAF - PME Aggregation Function PCS - Physical Coding Sublayer PMD - Physical Medium Dependent PME - Physical Medium Entity PSD - Power Spectral Density SNR - Signal to Noise Ratio TCPAM - Trellis Coded Pulse Amplitude Modulation - Copyright (C) The Internet Society (2004). This version of this MIB module is part of RFC XXXX; see the RFC itself for full legal notices." + REVISION "200510240000Z" -- October 24, 2005 + DESCRIPTION "Initial version, published as RFC XXXX." + -- EdNote: Replace XXXX with the actual RFC number & -- remove this note - REVISION "200504040000Z" -- April 04, 2005 - DESCRIPTION "Initial version, published as RFC XXXX." - - ::= { mib-2 160 } + ::= { mib-2 YYY } -- EdNote: Replace YYY with a real OID once it is -- allocated & remove this note. -- Sections of the module efmCuObjects OBJECT IDENTIFIER ::= { efmCuMIB 1 } efmCuConformance OBJECT IDENTIFIER ::= { efmCuMIB 2 } + -- Groups in the module efmCuPort OBJECT IDENTIFIER ::= { efmCuObjects 1 } efmCuPme OBJECT IDENTIFIER ::= { efmCuObjects 2 } -- Textual Conventions ProfileIndex ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" @@ -872,23 +859,22 @@ efmCuPortSide. The value of this object is a list of up to 6 indices of Profiles. If this list consists of a single Profile index, then all PMEs assigned to this EFMCu port SHALL be configured according to the Profile referenced by that index, unless it is overwritten by corresponding non-zero efmCuPmeAdminProfile, which takes precedence over efmCuAdminProfile. The list, consisting of more than one index, allows each PME in the port to be configured according to any Profile specified in the list. - By default this object has a single profile index 1, - referencing 1st entry in efmCuPme2BProfileTable/ - efmCuPme2BProfileTable. + By default this object has a value of 0x01, referencing 1st + entry in efmCuPme2BProfileTable or efmCuPme10PProfileTable. This object is writable and readable for the -O subtype (2BaseTL-O or 10PassTS-O) EFMCu ports. It is unavailable for the -R subtype (2BaseTL-R or 10PassTS-R) ports. Note that current operational Profile value is available via efmCuPmeOperProfile object. Modification of this object must be performed when the link is Down. Attempts to change this object MUST be rejected, if the @@ -979,34 +965,31 @@ Note that current SNR Margin of the PMEs comprising the EFMCu port is represented by efmCuPmeSnrMgn. This object MUST be maintained in a persistent manner." REFERENCE "[802.3ah] 61.1.2" ::= { efmCuPortConfEntry 5 } efmCuThreshLowBandwidth OBJECT-TYPE - SYNTAX Unsigned32(0..100000) + SYNTAX Unsigned32(400..100000) UNITS "Kbps" MAX-ACCESS read-write STATUS current DESCRIPTION "This object configures the EFMCu port Low Bandwidth alarm threshold. When the current value of ifSpeed for this port reaches or drops below this threshold, an efmCuLowBandwidth notification MAY be generated if enabled by efmCuLowBandwidthEnable. - The value of 0 means no efmCuLowBandwidth notifications - SHALL ever be generated. - This object is read-write for the -O subtype EFMCu ports (2BaseTL-O/10PassTS-O) and not available for the -R subtypes. This object MUST be maintained in a persistent manner." ::= { efmCuPortConfEntry 6 } efmCuLowBandwidthEnable OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current @@ -1868,21 +1849,22 @@ EfmCuPmeStatusEntry ::= SEQUENCE { efmCuPmeOperStatus INTEGER, efmCuPmeFltStatus BITS, efmCuPmeOperSubType INTEGER, efmCuPmeOperProfile ProfileIndexOrZero, efmCuPmeSnrMgn Integer32, efmCuPmePeerSnrMgn Integer32, efmCuPmeLineAtn Integer32, efmCuPmePeerLineAtn Integer32, - efmCuPmeTCCodingErrors Counter32 + efmCuPmeTCCodingErrors Counter32, + efmCuPmeTCCrcErrors Counter32 } efmCuPmeOperStatus OBJECT-TYPE SYNTAX INTEGER { up(1), downNotReady(2), downReady(3), init(4) } MAX-ACCESS read-only @@ -2113,49 +2096,67 @@ The value of zero SHALL be returned when PME is down or initializing. If a Clause 45 MDIO Interface to the PME TC is present, then this object maps to the TC coding violations register (see 45.2.6.12)." REFERENCE "[802.3ah] 61.3.3.1, 45.2.6.12" ::= { efmCuPmeStatusEntry 9 } + efmCuPmeTCCrcErrors OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A number of TC-CRC errors. This counter is incremented for + each TC-CRC error detected by the 64/65-octet receive function + (see 61.3.3.3 and Figure 61-19). + The value of zero SHALL be returned when PME is down or + initializing. + + If a Clause 45 MDIO Interface to the PCME TC is present, then + this object maps to the TC CRC error register + (see 45.2.6.11)." + REFERENCE + "[802.3ah] 61.3.3.3, 45.2.6.11" + ::= { efmCuPmeStatusEntry 10 } + -- 2BASE-TL specific PME group efmCuPme2B OBJECT IDENTIFIER ::= { efmCuPme 5 } efmCuPme2BProfileTable OBJECT-TYPE SYNTAX SEQUENCE OF EfmCuPme2BProfileEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table supports definitions of administrative and operating Profiles for 2BASE-TL PMEs. First 14 entries in this table SHALL always be defined as follows (see 802.3ah Annex 63A): -------+------+-----+--------+------------------ Profile Rate Power Region Constellation index (Kbps) (dBm) (G.991.2) -------+------+-----+--------+------------------ - 1 512 13.5 1 16-TCPAM (default) - 2 704 13.5 1 16-TCPAM - 3 1024 13.5 1 16-TCPAM - 4 2048 13.5 1 16-TCPAM - 5 3072 13.5 1 32-TCPAM - 6 5696 13.5 1 32-TCPAM - 7 512 13.5 2 16-TCPAM - 8 704 13.5 2 16-TCPAM - 9 1024 13.5 2 16-TCPAM - 10 2048 14.5 2 16-TCPAM - 11 3072 14.5 2 32-TCPAM - 12 5696 14.5 2 32-TCPAM + 1 5696 13.5 1 32-TCPAM (default) + 2 3072 13.5 1 32-TCPAM + 3 2048 13.5 1 16-TCPAM + 4 1024 13.5 1 16-TCPAM + 5 704 13.5 1 16-TCPAM + 6 512 13.5 1 16-TCPAM + 7 5696 14.5 2 32-TCPAM + 8 3072 14.5 2 32-TCPAM + 9 2048 14.5 2 16-TCPAM + 10 1024 13.5 2 16-TCPAM + 11 704 13.5 2 16-TCPAM + 12 512 13.5 2 16-TCPAM 13 0 0 1 0 (best effort) 14 0 0 2 0 (best effort) These default entries SHALL be created during agent initialization and MUST not be deleted. Entries following the first 14, can be dynamically created and deleted, to provide custom administrative (configuration) profiles and automatic operating profiles. @@ -2961,20 +2961,21 @@ efmCuPmeSubTypesSupported, efmCuPmeAdminSubType, efmCuPmeOperSubType, efmCuPAFRemoteDiscoveryCode, efmCuPmeOperProfile, efmCuPmeSnrMgn, efmCuPmePeerSnrMgn, efmCuPmeLineAtn, efmCuPmePeerLineAtn, efmCuPmeTCCodingErrors, + efmCuPmeTCCrcErrors, efmCuPmeThreshLineAtn, efmCuPmeThreshSnrMgn } STATUS current DESCRIPTION "A collection of objects providing information about a 2BASE-TL/10PASS-TS PME." ::= { efmCuGroups 5 } efmCuAlarmConfGroup OBJECT-GROUP @@ -3241,120 +3243,113 @@ Mathias Riess Matt Squire Mike Heard Udi Ashkenazi 9. References -9.1 Normative References +9.1. Normative References [802.3ah] IEEE, "IEEE Standard for Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements - Part 3: Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications - Amendment: Media Access Control Parameters, Physical Layers and Management Parameters for Subscriber Access Networks", IEEE Std 802.3ah-2004, September 2004. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. - [RFC2570] Case, J., Mundy, R., Partain, D. and B. Stewart, - "Introduction to Version 3 of the Internet-standard - Network Management Framework", RFC 2570, April 1999. - [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., - McCloghrie, K., Rose, M. and S. Waldbusser, "Structure of - Management Information Version 2 (SMIv2)", STD 58, RFC - 2578, April 1999. + McCloghrie, K., Rose, M., and S. Waldbusser, "Structure of + Management Information Version 2 (SMIv2)", STD 58, + RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., - McCloghrie, K., Rose, M. and S. Waldbusser, "Textual + McCloghrie, K., Rose, M., and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. - [RFC2580] McCloghrie, K., Perkins, D. and J. Schoenwaelder, + [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. - [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, - "Introduction and Applicability Statements for - Internet-Standard Management Framework", RFC 3410, - December 2002. + [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, + "Introduction and Applicability Statements for Internet- + Standard Management Framework", RFC 3410, December 2002. -9.2 Informative References +9.2. Informative References [G.991.2] ITU-T, "Single-pair High-speed Digital Subscriber Line (SHDSL) transceivers", ITU-T Recommendation G.991.2, December 2003. [G.993.1] ITU-T, "Very High speed Digital Subscriber Line transceivers", ITU-T Recommendation G.993.1, June 2004. [I-D.ietf-adslmib-gshdslbis] - Sikes, C., Ray, B. and R. Abbi, "Definitions of Managed + Sikes, C., Ray, B., and R. Abbi, "Definitions of Managed Objects for G.shdsl.bis Lines", - draft-ietf-adslmib-gshdslbis-09 (work in progress), March - 2005. - - [I-D.ietf-adslmib-vdsl-ext-mcm] - Dodge, M. and B. Ray, "Definitions of Managed Object - Extensions for Very High Speed Digital Subscriber Lines - (VDSL) Using Multiple Carrier Modulation (MCM) Line - Coding", draft-ietf-adslmib-vdsl-ext-mcm-06 (work in - progress), January 2005. + draft-ietf-adslmib-gshdslbis-11 (work in progress), + May 2005. [I-D.ietf-hubmib-efm-epon-mib] Khermosh, L., "Managed Objects for the Ethernet Passive Optical Networks", draft-ietf-hubmib-efm-epon-mib-03 (work in progress), March 2005. [I-D.ietf-hubmib-efm-mib] Squire, M., "Ethernet in the First Mile (EFM) Common MIB", - draft-ietf-hubmib-efm-mib-03 (work in progress), March - 2005. + draft-ietf-hubmib-efm-mib-03 (work in progress), + March 2005. [I-D.ietf-hubmib-rfc3636bis] Beili, E., "Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs)", - draft-ietf-hubmib-rfc3636bis-00 (work in progress), - October 2004. + draft-ietf-hubmib-rfc3636bis-02 (work in progress), + October 2005. [IANAifType-MIB] Internet Assigned Numbers Authority (IANA), "IANAifType Textual Convention definition", http://www.iana.org/assignments/ianaiftype-mib. [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. [RFC2864] McCloghrie, K. and G. Hanson, "The Inverted Stack Table - Extension to the Interfaces Group MIB", RFC 2864, June - 2000. + Extension to the Interfaces Group MIB", RFC 2864, + June 2000. [RFC3635] Flick, J., "Definitions of Managed Objects for the Ethernet-like Interface Types", RFC 3635, September 2003. + [RFC4070] Dodge, M. and B. Ray, "Definitions of Managed Object + Extensions for Very High Speed Digital Subscriber Lines + (VDSL) Using Multiple Carrier Modulation (MCM) Line + Coding", RFC 4070, May 2005. + Author's Address Edward Beili Actelis Networks Bazel 25 Petach-Tikva Israel Phone: +972-3-924-3491 - EMail: edward.beili@actelis.com + Email: edward.beili@actelis.com Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be