RE: EFM PHY status for 2BASE-TL
"Edward Beili" <[email protected]>
| Newsgroups | gmane.ietf.hubmib |
|---|---|
| Message-ID | <[email protected]> |
Mathias, Thank you for the comments. I was beginning to think that nobody is really interested in that MIB:) Let's start from the end: - Loss of Power (LOP): In SHDSL the idea was that -R device would have enough power on local power failure, to send 3 consecutive frames to -C device, with power indicator bit set. Sort of a "dying gasp". In theory this should help in troubleshooting link interruption reasons, i.e. differentiate between wires cut and CPE power failure or may be helping the CO to shutdown its modems in an orderly fashion. In practice, implementation of such feature would place certain requirements on the equipment design (i.e. provide ~20ms of current for the PHY in the event of power failure), which is out of the scope of the PHY design (and not mentioned anywhere in the text of the EFM standard). So, I'm inclined to throw 'Loss of Power' value out. If any of you think otherwise please make yourselves heard. In case we decide on letting it stay, its definition should be changed to: 'Remote PHY indicated power loss. The value is not supported by -R port sub-types.' - Loss of Signal (LOS): According to SHDSL definition LOS indeed indicates LOS at the application interface, i.e. MII. If this is the preferred explanation I would remove this value as well. (My original thought was that there's a way of differentiating between Loss of Framing, e.g. DSL framing or 64/65B framing and real Loss of Signal, e.g. cut line, similar to optical SDH/SONET LOF/LOS differentiation. It looks like there's no unambiguous and fast way to differentiate between the two at least in SHDSL. If I'm wrong please speak up). - Loss of Framing (LOF): It should be mapped to LOSW failure, which is a soaked alarm, you wouldn't want your SNMP variable to change it's value all the time on intermittent LOSW defects. Now that you mentioned it I ask myself if we really need Remote Loss of Framing in the MIB? I think that in most cases remote LOF would always be accompanied by a local LOF, unless you are debugging your interop:). Do you think we should keep Remote LOF? Few more points I would like to clarify using this opportunity: 1. Target SNR Margin In EFM today the target SNR margin is fixed - 6dB for 10PassTS and 5dB for 2BaseTL. Should we allow for configurable Target SNR Margin? 2. Initially I thought to propagate PME defects to the PHY level, that's why all those "one or more PME's indicate defect" values have made it into efmCuStatus. I'm thinking now that this individual PME's defects shall stay at the PME level and not be escalated. So I would like to remove lossOfSignal, lossOfPower, lossOfFraming, lossOfRemoteFraming, snrMgnDefect, snrMgnRemoteDefect, lineAtnDefect, lineAtnRemoteDefect values from the efmCuStatus. What do you think? Regards, -E. I've attached the latest version of EFM CU MIB. > -----Original Message----- > From: [email protected] [mailto:[email protected]] > Sent: Tuesday, 22 June, 2004 02:25 PM > To: Edward Beili; [email protected] > Subject: EFM PHY status for 2BASE-TL > > > Edward & Mark, > when analyzing the IEEE standard more in detail and also going > thru the hubmib you, Edward, provided some more question for > clarification for the PHY status came up. > Currently form my point of view it is not clearly specified how > to map the following entries: > Clause 30.11.1.1.3 defines the variable aPHYCurrentStatus. > The following > enumeration types are not clear > -loss of framing: > SHDSL provides 2 kind of primitives, the LOSW defect (Loss of Syncword > in 3 consecutive frames) and LOSW failure (persistence of LOSW defect > for a certain time) > - which of the 2 should be mapped to 'loss of framing'; on one > hand personally I believe LOSW defect does reflect a status, > but on the > other hand the hubmib also defines a lossOfRemoteFraming. > This variable > seems to be clear to me when using the LOSW failure > transmitted with the > respective EOC message. Based on the remote variable I would prefer > mapping the loss of framing to the LOSW failure > > - loss of signal: > currently there is a loss of signal bit defined in the SHDSL frame in > order to report a loss of signal from the application interface of the > remote end, > So based on this SHDSL definition this would be a loss of signal from > the remote side on the MII interface (I would consider the > MII interface > as the application interface). This leads to 3 questions: a) Do we > really want to report the status form the other side (based > on the loss > of signal definition)? B) Is the MII interface considered as > application > interface and how do I detect a loss of signal? C) Do we want to use a > completely different definition? > > - loss of power > The situation is similar to the 'loss of signal' The SHDSL frame has a > reserved power bit. This is used in order to report the power status > from the other side? Similarily, 2 question come up. A) Do we want to > support the power status from the remote end? B) In a CO application > reporting the local status does not seem to make sense, since, I would > assume; there is a central instance > > > It would be great if you could send me your opinion on that (or may be > this is already defined?) > > Thanks > Mathias > > _______________________________________________ Hubmib mailing list [email protected] https://www1.ietf.org/mailman/listinfo/hubmib
draft-ietf-hubmib-efm-cu-mib-01.html
(text/html, 107 KB) - not displayed
draft-ietf-hubmib-efm-cu-mib-01.txt
(text/plain, 99.9 KB)
Network Working Group E. Beili
Internet-Draft Actelis Networks
Expires: December 22, 2004 June 23, 2004
Ethernet in the First Mile Copper (EFMCu) Interfaces MIB
draft-ietf-hubmib-efm-cu-mib-01.txt
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
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.
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 December 22, 2004.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
This document defines a portion of the Management Information Base
(MIB) 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 with a set of objects for managing an
Ethernet in the First Mile Copper (EFMCu) interfaces 10Pass-TS and
2Base-TL defined in IEEE standard 802.3ah.
Beili Expires December 22, 2004 [Page 1]
Internet-Draft EFMCu Interfaces MIB June 2004
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. The Internet-Standard Management Framework . . . . . . . . . . 3
3. Relation to Interfaces Group MIB . . . . . . . . . . . . . . . 3
3.1 Layering Model . . . . . . . . . . . . . . . . . . . . . . 4
3.2 PME Aggregation Function (PAF) . . . . . . . . . . . . . . 4
3.3 Discovery Operation . . . . . . . . . . . . . . . . . . . 5
3.4 Relation to SHDSL MIB . . . . . . . . . . . . . . . . . . 6
3.5 Relation to VDSL MIB . . . . . . . . . . . . . . . . . . . 6
3.6 Relation to Ethernet-Like and MAU MIBs . . . . . . . . . . 6
3.7 Mapping of IEEE 802.3ah Managed Objects . . . . . . . . . 7
4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 42
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 43
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 44
7.1 Normative References . . . . . . . . . . . . . . . . . . . . 44
7.2 Informative References . . . . . . . . . . . . . . . . . . . 44
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 45
Intellectual Property and Copyright Statements . . . . . . . . 46
Beili Expires December 22, 2004 [Page 2]
Internet-Draft EFMCu Interfaces MIB June 2004
1. Introduction
New Ethernet like interfaces have been defined in the Institute of
Electrical and Electronics Engineers (IEEE) 802.3ah project a.k.a.
Ethernet in the First Mile (EFM) [802.3ah]. 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, support
variable rates and optional Physical Medium Entity (PME) aggregation
(multi-pair bonding).
This memo defines a portion of the Management Information Base (MIB)
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.
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].
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 Interfaces Group MIB
This section specifies how the ifStackTable, as defined in the IF-MIB
[RFC2863] and ifInvStackTable, as defined in the
IF-INVERTED-STACK-MIB [RFC2864] are used for the EFMCu application.
Beili Expires December 22, 2004 [Page 3]
Internet-Draft EFMCu Interfaces MIB June 2004
3.1 Layering Model
An EFMCu interface can aggregate up to 32 Physical Medium Entity
(PME) sublayer devices (modems), using so called PME Aggregation
Function (PAF).
An 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.
Each PME comprising an aggregated EFMCu port is represented in the
Interface table 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 an actual bitrate
of the active PME or a configured bitrate for pre-activated modems
(note that unassigned PME has its default bitrate).
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 efmCuAvailableStackTable defined in this MIB, 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.
*EdNote: An alternative would be to use ifStackTable to describe
cross-connect capability and efmCuAvailableStackTable to describe
actual connections, so that the cross-connect action would be done in
the EFM-CU-MIB by modifying the efmCuAvailableStackTable (and not in
IF-MIB).*
3.2 PME Aggregation Function (PAF)
The PME Aggregation Function (PAF) is optional and may not be
supported. Note however that it is mandatory for the agent to report
on the PAF capability for all EFMCu ports (2BASE-TL and 10PASS-TS).
*EdNote: Add more info.*
Beili Expires December 22, 2004 [Page 4]
Internet-Draft EFMCu Interfaces MIB June 2004
3.3 Discovery Operation
This MIB 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
efmCuAvailableStackTable defined. The following pseudo-code defines
an example of Discovery for a generic PAF enabled multi-PCS EFMCu
device, located at Central Office (CO):
foreach PCS[i] in Device
{ if ( PCS[i].PAFSupported ) // Discover only on ports supporting PAF
{ dc = PCS[i].DiscoveryCode = MAC[i]; // unique 6 Byte per PCS
// go over all currently disconnected PMEs, which can
// pottentially be connected to PCS[i]
foreach PME[j] in efmCuAvailableStackTable[PCS[i]] and
not in ifStackTable[PCS[i]]
{ PME[j].RemoteDiscoveryCode = dc; // Set if Clear
r = PME[j].RemoteDiscoveryCode; // Get
if ( r == dc )
{ // Remote CPE connected via PME[j] is/was a peer for
// PCS[i]. Connect this PME to the PCS
Add PME[j] to ifStackTable[PCS[i]];
// Discover all other currently disconnected PMEs,
// attached to the same CPE and connect them to the PCS
foreach PME[k] in efmCuAvailableStackTable[PCS[i]] and
not in ifStackTable[PCS[i]]
{ r = PME[k].RemoteDiscoveryCode; // Get
if ( r == dc )
Add PME[k] to ifStackTable[PCS[i]];
}
}
// Discovered all PMEs which lead to the same CPE and
// connected them to PCS[i]. Go to the next PCS.
break;
}
}
}
The SNMP Agent builds efmCuStackTable 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).
Beili Expires December 22, 2004 [Page 5]
Internet-Draft EFMCu Interfaces MIB June 2004
3.4 Relation to SHDSL MIB
SHDSL modems, similar to PME(s) comprising a 2BaseTL port are
described in HDSL2-SHDSL-LINE-MIB [RFC3276]. While
HDSL2-SHDSL-LINE-MIB describes standard G.SHDSL modems according to
ITU-T G.991.2, IEEE 802.3ah uses soon to be approved G.SHDSL.bis
spec, extended to support higher constellations and rates. In
addition not all attributes of G.SHDSL modems reflected in
HDSL2-SHDSL-LINE-MIB have adequate management objects in the EFM
standards.
Because of these differences and for the purposes of simplicity and
name consistency it was decided not to reference HDSL2-SHDSL-LINE-MIB
objects, but define all the relevant objects in this MIB.
3.5 Relation to VDSL MIB
PME(s) comprising a 10PassTS port are described in VDSL-LINE-MIB
[I-D.ietf-adslmib-vdsl]. In cases where VDSL-LINE-MIB and 802.3ah
differ, the definitions in 802.3ah take precedence.
Because of these differences and for the purposes of simplicity and
name consistency it was decided not to reference VDSL-LINE-MIB
objects, but define all the relevant objects in this MIB.
3.6 Relation to Ethernet-Like and MAU MIBs
The implementation of EtherLike-MIB [RFC3635] and MAU-MIB [RFC3636]
is REQUIRED for the EFMCu interfaces. As such EFMCu interfaces
2Base-TL/10Pass-TS SHALL return an ifType of ethernetCsmacd(6).
Information on the particular flavor of EFMCu that an interface is
running is available from ifSpeed in the IF-MIB [RFC2863], and
ifMauType in the MAU-MIB.
The MAU-MIB shall be augmented to include the following new values
for ifMauType (instances of dot2MauType):
o dot3MauType2BaseTL - voice grade UTP Phy specified in Clause 61
and 63
o dot3MauType10PassTS - voice grade UTP Phy specified in Clause 61
and 62
o *EdNote: Should we also include -O/-R subtypes?*
Beili Expires December 22, 2004 [Page 6]
Internet-Draft EFMCu Interfaces MIB June 2004
3.7 Mapping of IEEE 802.3ah Managed Objects
This section contains the mapping between managed objects defined in
[802.3ah] Clause 30, and managed objects defined in this document and
in associated MIB modules, i.e., the IF-MIB [RFC2863] and the MAU-MIB
[RFC3636].
+---------------------------------+---------------------------------+
| IEEE 802.3 Managed Object | Corresponding SNMP Object |
+---------------------------------+---------------------------------+
| oPAF - PME Basic Package | |
| (Mandatory) | |
| aPAFID | IF-MIB - ifIndex |
| aPhyEnd | efmCuPhySide |
| aPHYCurrentStatus | efmCuStatus |
| aPAFSupported | efmCuPAFSupported |
| oPAF - PME Aggregation Package | |
| (Optional) | |
| aPAFAdminState | efmCuPAFAdminState |
| aLocalPAFCapacity | efmCuPAFCapacity |
| aLocalPMEAvailable | efmCuAvailableStackTable |
| aLocalPMEAggregate | ifStackTable |
| aRemotePAFSupported | efmCuRemotePAFSupported |
| aRemotePAFCapacity | efmCuRemotePAFCapacity |
| aRemotePMEAvailable | |
| aRemotePMEAggregate | ifStackTable |
| oPME - 10P/2B Package | |
| (Mandatory) | |
| aPMEID | |
| aPMEAdminState | |
| aPMEStatus | |
| aPMESNRMgn | SHDSL-MIB - |
| | hdsl2ShdslEndpointCurrSnrMgn |
| aTCCodingViolations | |
| aProfileSelect | efmCuProfileSelect |
| aOperatingProfile | |
| aPMEFECCorrectedBlocks | |
| aPMEFECUncorrectableBlocks | |
+---------------------------------+---------------------------------+
Table 1
4. Definitions
EFM-CU-MIB DEFINITIONS ::= BEGIN
IMPORTS
Beili Expires December 22, 2004 [Page 7]
Internet-Draft EFMCu Interfaces MIB June 2004
MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, Integer32
FROM SNMPv2-SMI
TruthValue, RowStatus, PhysAddress
FROM SNMPv2-TC
ifIndex, InterfaceIndexOrZero
FROM IF-MIB
MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP
FROM SNMPv2-CONF
;
efmCuMIB MODULE-IDENTITY
LAST-UPDATED "200406220000Z" -- June 22, 2004
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: [email protected]
To Subscribe: [email protected]
In Body: subscribe your_email_address
Chair: Dan Romascanu
Postal: Avaya
Atidim Technology Park, Bldg. 3
Tel Aviv 61131
Israel
Tel: +972 3 645 8414
E-mail: [email protected]
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: [email protected]"
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.
The following reference is used throughout this MIB module:
[802.3ah] refers to:
IEEE Draft P802.3ah/D3.3: 'Draft amendment to -
Information technology - Telecommunications and
Beili Expires December 22, 2004 [Page 8]
Internet-Draft EFMCu Interfaces MIB June 2004
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 - Media Access Control Parameters, Physical
Layers and Management Parameters for subscriber access
networks', 19 April 2003.
Of particular interest are Clause 61, 'Physical Coding
Sublayer (PCS) and common specifications, type 10PASS-TS and
type 2BASE-TL', Clause 30, 'Management', and Clause 45,
'Management Data Input/Output (MDIO) Interface'.
Naming Conventions:
Atn - Attenuation
CO - Central Office
CPE - Customer Premises Equipment
EFM - Ethernet in the First Mile
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
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."
-- EdNote: Replace XXXX with the actual RFC number &
-- remove this note
REVISION "200406220000Z" -- June 22, 2004
DESCRIPTION "Initial version, published as RFC XXXX."
::= { mib-2 160 }
-- 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 }
Beili Expires December 22, 2004 [Page 9]
Internet-Draft EFMCu Interfaces MIB June 2004
-- Groups in the module
efmCuPort OBJECT IDENTIFIER ::= { efmCuObjects 1 }
efmCuPme OBJECT IDENTIFIER ::= { efmCuObjects 2 }
-- PCS Port group
efmCuPortTable OBJECT-TYPE
SYNTAX SEQUENCE OF EfmCuPortEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Table for EFMCu 2BaseTL/10PassTS (PCS) Ports."
::= { efmCuPort 1 }
efmCuPortEntry OBJECT-TYPE
SYNTAX EfmCuPortEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the EFMCu Port table."
INDEX { ifIndex }
::= { efmCuPortTable 1 }
EfmCuPortEntry ::=
SEQUENCE {
efmCuStatus BITS,
efmCuPortSide INTEGER,
efmCuPAFSupported TruthValue,
efmCuRemotePAFSupported TruthValue,
efmCuPAFAdminState INTEGER,
efmCuPAFCapacity Integer32,
efmCuRemotePAFCapacity Integer32,
efmCuPAFDiscoveryCode PhysAddress
}
efmCuStatus OBJECT-TYPE
SYNTAX BITS {
noPMEAssigned(0), -- no PME assigned to the PCS
noPeerPMEPresent(1), -- no peer PME present
lossOfSignal(2), -- Loss of Signal
lossOfPower (3), -- Loss of Power
lossOfFraming(4), -- Loss of Framing
lossOfRemoteFraming(5), -- Remote Loss of Framing
snrMgnDefect(6), -- SNR Margin Violation
snrMgnRemoteDefect(7), -- Remote SNR Margin Violation
lineAtnDefect(8), -- Loop Attenuation Violation
Beili Expires December 22, 2004 [Page 10]
Internet-Draft EFMCu Interfaces MIB June 2004
lineAtnRemoteDefect(9), -- Remote Loop Attenuation Violation
deviceFault(10), -- vendor-dependent diag fault
configInitFailure(11), -- configuration init. failure
protocolInitFailure(12), -- protocol initialization failure
subTypePMEMismatch(13), -- Assigned PMEs Sub-type Mismatch
pafDefect(14), -- PAF related defect
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"EFMCu (PCS) port Status. This is a bitmap of possible
conditions. The various bit positions are:
noPMEAssigned - no PME has been assigned to the PCS
(in case of PAF)
noPeerPMEPresent - one or more PMEs in the aggregation
group indicate no peer PME present
(down)
lossOfSignal - one or more PMEs in the aggregation
group indicate Loss of Signal
lossOfPower - one or more PMEs in the aggregation
group indicate Loss of Power
lossOfFraming - one or more PMEs in the aggregation
group indicate Loss of Framing
lossOfRemoteFraming - one or more PMEs in the aggregation
group indicate Remote Loss of Framing
snrMgnDefect - one or more PMEs in the aggregation
group indicate SNR Margin Violation
snrMgnRemoteDefect - one or more PMEs in the aggregation
group indicate Remote SNR Margin
Violation
lineAtnDefect - one or more PMEs in the aggregation
group indicate Loop Attenuation
Violation
lineAtnRemoteDefect - one or more PMEs in the aggregation
group indicate Remote Loop
Attenuation Violation
deviceFault - one or more PMEs in the aggregation
group indicate vendor-dependent diag
fault.
configInitFailure - one or more PMEs in the aggregation
group indicate configuration
initialization failure (e.g. the Peer
PME could not support configuration
requested during init).
protocolInitFailure - one or more PMEs in the aggregation
group indicate protocol
initialization failure.
pmeSubTypeMismatch - PMEs in the aggregation group are not
Beili Expires December 22, 2004 [Page 11]
Internet-Draft EFMCu Interfaces MIB June 2004
of the same sub-type, e.g. PMEs with
-O and -R subtype
pafDefect - PAF related defect
-- EdNote: Do we need that?
-- When do we clear this bit?
This is intended to supplement aPHYCurrentStatus.
This attribute partially maps to the Clause 30 variable
aPHYCurrentStatus, supplementing it with additional values.
If a Clause 45 MDIO Interface to the PCS is present, then this
attribute consolidates various PMA/PMD registers, namely:
TBD"
REFERENCE
"[802.3ah] 30.11.1.1.3"
::= { efmCuPortEntry 1 }
efmCuPortSide OBJECT-TYPE
SYNTAX INTEGER {
subscriber(1), -- -R sub-type
office(2), -- -O sub-type
unknown(3) -- no PMEs assigned or PME sub-type mismatch
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"EFM port mode of operation (subtype).
The value of 'subscriber' indicates the port is designated as
'-R' subtype (all PMEs assigned to this port are of subtype
'-R').
The value of the 'office' indicates that the port is
designated as '-O' subtype (all PMEs assigned to this port are
of subtype '-O').
The value of 'unknown' indicates that the port has no assigned
PMEs yet or that the assigned PMEs are not of the same side
(subTypePMEMismatch).
This attribute partially maps to the Clause 30 variable
aPhyEnd"
REFERENCE
"[802.3ah] 61.1, 30.11.1.1.2"
::= { efmCuPortEntry 2 }
efmCuPAFSupported OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
Beili Expires December 22, 2004 [Page 12]
Internet-Draft EFMCu Interfaces MIB June 2004
"PME Aggregation Function (PAF) Capability of the EFMCu port
(PCS).
This object has a value of true(1) when the PCS can perform
PME aggregation on the available PMEs.
Ports incapable of PAF shall return a value of false(2).
This attribute maps to the Clause 30 variable aPAFSupported.
If a Clause 45 MDIO Interface to the PCS is present,
then this attribute will map to the PAF available bit in the
10P/2B capability register."
REFERENCE
"[802.3ah] 61.2.2, 30.11.1.1.4, 45.2.3.17.1"
::= { efmCuPortEntry 4 }
efmCuRemotePAFSupported OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"PME Aggregation Function (PAF) Capability of the EFMCu port
(PCS) link partner.
This object has a value of true(1) when the remote PCS can
perform PME aggregation on the available PMEs.
Ports incapable of PAF shall return a value of false(2).
This attribute maps to the Clause 30 variable
aRemotePAFSupported.
If a Clause 45 MDIO Interface to the PCS is present, then
this attribute maps to the Remote PAF supported bit in the
10P/2B capability register."
REFERENCE
"[802.3ah] 61.2.2, 30.11.1.1.9, 45.2.3.17.2"
::= { efmCuPortEntry 5 }
efmCuPAFAdminState OBJECT-TYPE
SYNTAX INTEGER {
enabled(1),
disabled(2)
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"Administrative (desired) state of the PAF of the EFMCu port
(PCS).
When 'disabled', PME Aggregation will not be performed by the
PCS.
Beili Expires December 22, 2004 [Page 13]
Internet-Draft EFMCu Interfaces MIB June 2004
When 'enabled', PAF will be performed by the PCS when the link
is Up, even on a single PME, if PAF is supported.
PCS ports incapable of supporting PAF shall return a value of
'disabled'. Attempts to 'enable' such port shall be ignored.
Changing PAFAdminState is a traffic disruptive operation and
as such shall be done when the link is Down. Attempts to
change this object shall be ignored if the link is Up or
Initializing.
This attribute maps to the Clause 30 variable aPAFAdminState.
If a Clause 45 MDIO Interface to the PCS is present, then this
attribute will map to the PAF enable bit in the 10P/2B PCS
control register"
REFERENCE
"[802.3ah] 61.2.2, 45.2.3.18.3"
::= { efmCuPortEntry 6 }
efmCuPAFCapacity OBJECT-TYPE
SYNTAX Integer32 (1..32)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Number of PMEs that can be aggregated by the local PAF.
Some PMEs may not be present in a given PCS port instance,
in which case the actual number of PMEs present is less than
efmCuPAFCapacity.
The number of PMEs present is never greater than
aLocalPAFCapacity.
This attribute maps to the Clause 30 variable
aLocalPAFCapacity."
REFERENCE
"[802.3ah] 61.2.2, 30.11.1.1.6"
::= { efmCuPortEntry 7 }
efmCuRemotePAFCapacity OBJECT-TYPE
SYNTAX Integer32 (1..32)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Number of PMEs that can be aggregated by the PAF of the peer
Phy (PCS port).
Some PMEs may not be present in a given PCS port instance,
in which case the actual number of PMEs present is less than
efmCuRemotePAFCapacity. The number of PMEs present is never
greater than efmCuRemotePAFCapacity.
Beili Expires December 22, 2004 [Page 14]
Internet-Draft EFMCu Interfaces MIB June 2004
This attribute maps to the Clause 30 variable
aRemotePAFCapacity."
REFERENCE
"[802.3ah] 61.2.2, 30.11.1.1.10"
::= { efmCuPortEntry 8 }
efmCuPAFDiscoveryCode OBJECT-TYPE
SYNTAX PhysAddress
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"PAF Discovery Code of the EFMCu port (PCS).
A unique 6 Byte long code used by the Discovery function, when
PAF is supported.
PCS ports incapable of supporting PAF shall return a value of
all zeroes. Attempts to change this object shall be ignored in
this case.
This object must be instantiated for the -O subtype PCS before
writing operations on the efmCuPAFRemoteDiscoveryCode
(Set_if_Clear and Clear_if_Same) are performed by PMEs
associated with the PCS.
The value of this object is read-only for -R port subtypes.
The initial value of this object for -R ports after reset
is 0. This value may be changed as a result of writing
operation on efmCuPAFRemoteDiscoveryCode variable of remote
PME of -O subtype, connected to one of the local PMEs
associated with the PCS.
Discovery must be performed when the link is Down.
Attempts to change this object MUST be rejected with the error
inconsistentValue if the link is Up or Initializing.
The PAF Discovery code maps to the local Discovery code
variable in PAF (note that it does not have a corresponding
Clause 45 register)"
REFERENCE
"[802.3ah] 61.2.2.8.3, 61.2.2.8.4, 45.2.6.6.1"
::= { efmCuPortEntry 9 }
-- The PME group
efmCuPmeTable OBJECT-TYPE
SYNTAX SEQUENCE OF EfmCuPmeEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Table for EFMCu 2BaseTL/10PassTS PMEs (modems). Common part"
Beili Expires December 22, 2004 [Page 15]
Internet-Draft EFMCu Interfaces MIB June 2004
::= { efmCuPme 1 }
efmCuPmeEntry OBJECT-TYPE
SYNTAX EfmCuPmeEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the EFMCu PME Common table."
INDEX { ifIndex }
::= { efmCuPmeTable 1 }
EfmCuPmeEntry ::=
SEQUENCE {
efmCuPmeStatus BITS,
efmCuPmeSubTypesSupported BITS,
efmCuPmeSubType INTEGER,
efmCuPAFRemoteDiscoveryCode PhysAddress,
efmCuPmeOperProfile INTEGER,
efmCuPmeSnrMgn Integer32,
efmCuPmeRemoteSnrMgn Integer32,
efmCuPmeLineAtn Integer32,
efmCuPmeRemoteLineAtn Integer32,
efmCuPmeTCCodingErrors Counter32,
efmCuPmeThreshLineAtn Integer32,
efmCuPmeThreshSnrMgn Integer32
}
efmCuPmeStatus OBJECT-TYPE
SYNTAX BITS {
downNotReady(0), -- link is Down and not Ready
downReady(1), -- link is Down and Ready
init(2), -- link is Initializing
up10PassTS(3), -- link is Up as 10PassTS
up2BaseTL(4), -- link is Up as 2BaseTL
unassigned(5), -- detached from PCS in case of PAF
lossOfSignal(6), -- Loss of Signal
lossOfPower(7), -- Loss of Power
lossOfFraming(8), -- Loss of Framing
lossOfRemoteFraming(9), -- Loss of Framing at peer PMD
snrMgnDefect(10), -- SNR Margin dropped below Threshold
snrMgnRemoteDefect(11), -- Peer SNR Margin dropped below
-- Threshold at the peer PME
lineAtnDefect(12), -- Line Attenuation exceeds Threshold
lineAtnRemoteDefect(13),-- Remote Line Attenuation exceeds
-- Threshold
deviceFault(14), -- Vendor-dependent diag or self-test
-- fault
configInitFailure(15), -- configuration init. failure
Beili Expires December 22, 2004 [Page 16]
Internet-Draft EFMCu Interfaces MIB June 2004
protocolInitFailure(16) -- protocol initialization failure
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Current PME link Status. This is a bitmap of possible
conditions. The various bit positions are:
downNotReady - link is Down and the PME does not
detect Handshake tones from its peer.
downReady - link is Down and the PME detects
Handshake tones from its peer.
init - link is initializing
up10PassTS - link is Up as 10PassTS
up2BaseTL - link is Up as 2BaseTL
unassigned - disconnected from PCS in case of PAF
lossOfSignal - Loss of Signal
lossOfPower - Loss of Power
lossOfFraming - Loss of Framing for 10P or
Loss of Sync word for 2B PMD or
Loss of 64/65B Framing
lossOfRemoteFraming - Loss of Synchronization word at the
peer PMD
snrMgnDefect - SNR Margin dropped below the Threshold
snrMgnRemoteDefect - SNR Margin dropped below the Threshold
at the peer PME
lineAtnDefect - Line Attenuation exceeds the Threshold
lineAtnRemoteDefect - Line Attenuation exceeds the Threshold
at the peer PME
deviceFault - Indicates a vendor-dependent
diagnostic or self-test fault
has been detected.
configInitFailure - configuration initialization failure.
the Peer PME could not support
configuration requested during init.
protocolInitFailure - protocol initialization failure.
due to incompatible protocol used by
the Peer PME during init (that could
happen if a peer PMD is G.SDHSL/VDSL
modem for 2BaseTL/10PassTS PME
respectively).
This is intended to supplement ifOperStatus. Note that there
is a 1-1 relationship between the status bits defined in this
object and the notification thresholds defined elsewhere in
this MIB.
This attribute partially maps to the Clause 30 variable
Beili Expires December 22, 2004 [Page 17]
Internet-Draft EFMCu Interfaces MIB June 2004
aPMEStatus.
If a Clause 45 MDIO Interface to the PME is present, then this
attribute consolidates information from various PMA/PMD
registers, namely: PMA/PMD link status bits in 10P/2B PMA/PMD
status register, Fault bit in PMA/PMD status 1 register,
10P/2B PMA/PMD link loss register,
10P outgoing indicator bits status register,
10P incoming indicator bits status register,
2B state defects register"
REFERENCE
"[802.3ah] 30.11.2.1.3, 45.2.1.12.4, 45.2.1.2.1, 45.2.1.38,
45.2.1.39, 45.2.1.54"
::= { efmCuPmeEntry 1 }
efmCuPmeSubTypesSupported OBJECT-TYPE
SYNTAX BITS {
ieee2BaseTL-O(1),
ieee2BaseTL-R(2),
ieee10PassTS-O(3),
ieee10PassTS-R(4)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"PME supported sub-types. This is a bitmap of possible
sub-types. The various bit positions are:
ieee2BaseTL-O - PME is capable of operating as 2BaseTL-O
ieee2BaseTL-R - PME is capable of operating as 2BaseTL-R
ieee10PassTS-O - PME is capable of operating as 10PassTS-O
ieee10PassTS-R - PME is capable of operating as 10PassTS-R
An actual mode of operation is determined by efmCuPmeSubType.
If a Clause 45 MDIO Interface to the PCS is present, then this
attribute combines the 10PASS-TS capable and 2BASE-TL capable
bits in the 10P/2B PMA/PMD speed ability register and the
CO supported and CPE supported bits in the 10P/2B PMA/PMD
status register"
REFERENCE
"[802.3ah] 61.1, 45.2.1.4.1, 45.2.1.4.2, 45.2.1.12.2,
45.2.1.12.3"
::= { efmCuPmeEntry 2 }
efmCuPmeSubType OBJECT-TYPE
SYNTAX INTEGER {
ieee2BaseTL-O(1),
ieee2BaseTL-R(2),
Beili Expires December 22, 2004 [Page 18]
Internet-Draft EFMCu Interfaces MIB June 2004
ieee10PassTS-O(3),
ieee10PassTS-R(4),
ieee2BaseTLor10PassTS-R(5),
ieee2BaseTLor10PassTS-0(6),
ieee10PassTSor2BseTL-0(7)
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"Administrative (desired) sub-type of the PME.
Possible values are:
ieee2BaseTL-O - PME shall operate as 2BaseTL-O
ieee2BaseTL-R - PME shall operate as 2BaseTL-R
ieee10PassTS-O - PME shall operate as 10PassTS-O
ieee10PassTS-R - PME shall operate as 10PassTS-R
ieee2BaseTLor10PassTS-R - PME shall operate as 2BaseTL-R or
10PassTS-R. Actual value will be
set by -O link partner during
initialization (handshake).
ieee2BaseTLor10PassTS-0 - PME shall operate as 2BaseTL-O
(preferred) or 10PassTS-O. Actual
value will be set during
initialization depending on -R
link partner capability (i.e. if
-R is incapable of the preferred
2BaseTL mode, 10PassTS will be
used).
ieee10PassTSor2BseTL-0 - PME shall operate as 10PassTS-O
(preferred) or 2BaseTL-O. Actual
value will be set during
initialization depending on -R
link partner capability (i.e. if
-R is incapable of the preferred
10PassTS mode, 2BaseTL will be
used).
Changing efmCuPmeSubType is a traffic disruptive operation
and as such shall be done when the link is Down. Attempts to
change this object shall be ignored if the link is Up or
Initializing.
Attempts to change this object to an unsupported subtype
(see efmCuPmeSubTypesSupported) shall be ignored.
If a Clause 45 MDIO Interface to the PMA/PMD is present, then
this attribute combines values of the Port sub-type select
bits and the PMA/PMD type selection bits in the 10P/2B
PMA/PMD control register"
REFERENCE
Beili Expires December 22, 2004 [Page 19]
Internet-Draft EFMCu Interfaces MIB June 2004
"[802.3ah] 61.1, 45.2.1.11.4, 45.2.1.11.7"
::= { efmCuPmeEntry 3 }
efmCuPAFRemoteDiscoveryCode OBJECT-TYPE
SYNTAX PhysAddress
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"PAF Remote Discovery Code of the PME port at CO.
A 6 Byte long Discovery Code of the peer PCS connected via
the PME.
Reading this object results in a Discovery Get operation.
Writing a zero to this object results in a Discovery
Clear_if_Same operation (the value of efmCuPAFDiscoveryCode
at the peer PCS shall be the same as efmCuPAFDiscoveryCode of
the local PCS associated with the PME for the operation to
succeed).
Writing a non-zero value to this object results in a
Discovery Set_if_Clear operation.
This object does not exist in CPE port subtypes. A zero length
octet string shall be returned for CPE port subtypes and also
when PAF aggregation is not enabled.
Discovery must be performed when the link is Down.
Attempts to change this object MUST be rejected with the error
inconsistentValue, if the link is Up or Initializing.
If a Clause 45 MDIO Interface to the PMA/PMD is present, then
this attribute is a function of 10P/2B aggregation discovery
control register, Discovery operation result bits in 10P/2B
aggregation and discovery status register and
10P/2B aggregation discovery code register"
REFERENCE
"[802.3ah] 61.2.2.8.4, 45.2.6.6-45.2.6.8"
::= { efmCuPmeEntry 4 }
efmCuPmeOperProfile OBJECT-TYPE
SYNTAX INTEGER {
activateFailure(-2), -- link activation failure
noLink(-1), -- link is down or initializing
profile0(0), -- no match (individual PME params are
-- used)
profile1(1), -- profile1 of 2BaseTL or 10PassTS
profile2(2), -- profile2 of 2BaseTL or 10PassTS
profile3(3), -- profile3 of 2BaseTL or 10PassTS
profile4(4), -- profile4 of 2BaseTL or 10PassTS
profile5(5), -- profile5 of 2BaseTL or 10PassTS
profile6(6), -- profile6 of 2BaseTL or 10PassTS
Beili Expires December 22, 2004 [Page 20]
Internet-Draft EFMCu Interfaces MIB June 2004
profile7(7), -- profile7 of 2BaseTL or 10PassTS
profile8(8), -- profile8 of 2BaseTL or 10PassTS
profile9(9), -- profile9 of 2BaseTL or 10PassTS
profile10(10), -- profile10 of 2BaseTL or 10PassTS
profile11(11), -- profile11 of 2BaseTL or 10PassTS
profile12(12), -- profile12 of 2BaseTL or 10PassTS
profile12(13), -- profile13 of 10PassTS
profile12(14), -- profile14 of 10PassTS
profile12(15), -- profile15 of 10PassTS
profile12(16), -- profile16 of 10PassTS
profile12(17), -- profile17 of 10PassTS
profile12(18), -- profile18 of 10PassTS
profile12(19), -- profile19 of 10PassTS
profile12(20), -- profile20 of 10PassTS
profile12(21), -- profile21 of 10PassTS
profile12(22) -- profile22 of 10PassTS
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"PME operating Profile. Possible values are:
activateFailure - link activation failure
noLink - link is down or initializing
profile0 - no match (individual PME params are
used)
profile1 - profile1 of 2BaseTL or 10PassTS
profile2 - profile2 of 2BaseTL or 10PassTS
profile3 - profile3 of 2BaseTL or 10PassTS
profile4 - profile4 of 2BaseTL or 10PassTS
profile5 - profile5 of 2BaseTL or 10PassTS
profile6 - profile6 of 2BaseTL or 10PassTS
profile7 - profile7 of 2BaseTL or 10PassTS
profile8 - profile8 of 2BaseTL or 10PassTS
profile9 - profile9 of 2BaseTL or 10PassTS
profile10 - profile10 of 2BaseTL or 10PassTS
profile11 - profile11 of 2BaseTL or 10PassTS
profile12 - profile12 of 2BaseTL or 10PassTS
profile12 - profile13 of 10PassTS
profile12 - profile14 of 10PassTS
profile12 - profile15 of 10PassTS
profile12 - profile16 of 10PassTS
profile12 - profile17 of 10PassTS
profile12 - profile18 of 10PassTS
profile12 - profile19 of 10PassTS
profile12 - profile20 of 10PassTS
profile12 - profile21 of 10PassTS
profile12 - profile22 of 10PassTS
Beili Expires December 22, 2004 [Page 21]
Internet-Draft EFMCu Interfaces MIB June 2004
The PME profile can be set by either writing to
efmCuPme2BProfile or efmCuPme10PProfile objects for
2BaseTL-O/10PassTS-O PMEs respectively, or by writing to the
individual PME parameters (e.g. efmCuPme2BRegion,
efmCuPme2BPower, efmCuPme2BDataRate and
efmCuPme2BConstellation for 2BaseTL-O PME).
This attribute partially maps to the aOperatingProfile
variable in Clause 30."
REFERENCE
"[802.3ah] 30.11.2.1.7"
::= { efmCuPmeEntry 5 }
efmCuPmeSnrMgn OBJECT-TYPE
SYNTAX Integer32(-127..128)
UNITS "dB"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The current Signal-to-Noise Ratio (SNR) margin with respect
to the received signal as perceived by the local PME.
This attribute maps to the aPMESNRMgn variable in Clause 30.
If a Clause 45 MDIO Interface is present, then this
attribute maps to the 10P/2B RX SNR margin register."
REFERENCE
"[802.3ah] 30.11.2.1.4, 45.2.1.16"
::= { efmCuPmeEntry 6 }
efmCuPmeRemoteSnrMgn OBJECT-TYPE
SYNTAX Integer32(-127..128)
UNITS "dB"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The current SNR margin in dB with respect to the received
signal, as perceived by the remote (link partner) PME.
This object is not supported by -R port subtypes.
If a Clause 45 MDIO Interface is present, then this
attribute maps to the 10P/2B link partner RX SNR margin
register."
REFERENCE
"[802.3ah] 45.2.1.17"
::= { efmCuPmeEntry 7 }
Beili Expires December 22, 2004 [Page 22]
Internet-Draft EFMCu Interfaces MIB June 2004
efmCuPmeLineAtn OBJECT-TYPE
SYNTAX Integer32(-127..128)
UNITS "dB"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The current Line Attenuation in dB as perceived by the local
PME.
If a Clause 45 MDIO Interface is present, then this
attribute maps to the Line Attenuation register"
REFERENCE
"[802.3ah] 45.2.1.18"
::= { efmCuPmeEntry 8 }
efmCuPmeRemoteLineAtn OBJECT-TYPE
SYNTAX Integer32(-127..128)
UNITS "dB"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The current Line Attenuation in dB as perceived by the remote
(link partner) PME.
This object is not supported by CPE port subtypes.
If a Clause 45 MDIO Interface is present, then this
attribute maps to the 20P/2B link partner Line Attenuation
register."
REFERENCE
"[802.3ah] 45.2.1.19"
::= { efmCuPmeEntry 9 }
efmCuPmeTCCodingErrors OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A number of 64/65-octet encapsulation errors. This counter is
incremented for each 64/65-octet encapsulation error detected
by the 64/65-octet receive function.
If a Clause 45 MDIO Interface to the PME TC is present, then
this attribute maps to the TC coding violations register
(see 45.2.6.12)."
REFERENCE
"[802.3ah] 61.3.3.1, 45.2.6.12"
::= { efmCuPmeEntry 10 }
Beili Expires December 22, 2004 [Page 23]
Internet-Draft EFMCu Interfaces MIB June 2004
efmCuPmeThreshLineAtn OBJECT-TYPE
SYNTAX Integer32(-127..128)
UNITS "dB"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"Desired Line Attenuation Threshold for the 2B/10P PME.
This object configures the line attenuation alarm threshold.
When the current value of Line Attenuation reaches
or exceeds this threshold, a efmCuPmeLineAtnCrossing
notification MAY be generated.
This object is writable for the CO subtype PMEs (-O).
It is read-only for the CPE subtype (-R).
Changing of the Line Attenuation Threshold must be performed
when the link is Down. Attempts to change this object MUST be
rejected with the error inconsistentValue, if the link is Up
or Initializing.
If a Clause 45 MDIO Interface to the PME is present, then this
attribute will map to the Loop attenuation threshold bits in
the 2B PMD line quality thresholds register"
REFERENCE
"[802.3ah] 45.2.1.36"
::= { efmCuPmeEntry 11 }
efmCuPmeThreshSnrMgn OBJECT-TYPE
SYNTAX Integer32(-127..128)
UNITS "dB"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"Desired SNR Margin Threshold for the 2B/10P PME.
This object configures the SNR margin alarm threshold.
When the current value of SNR Margin reaches
or exceeds this threshold, a efmCuPmeSnrMgnCrossing
notification MAY be generated.
This object is writable for the CO subtype PMEs
(2BaseTL-O/10PassTS-R). It is read-only for the CPE subtype
(2BaseTL-R/10PassTS-R).
Changing of the SNR Margin Threshold must be performed when
the link is Down. Attempts to change this object MUST be
rejected with the error inconsistentValue, if the link is Up
or Initializing.
Beili Expires December 22, 2004 [Page 24]
Internet-Draft EFMCu Interfaces MIB June 2004
If a Clause 45 MDIO Interface to the PME is present, then this
attribute will map to the SNR margin threshold bits in the
2B PMD line quality thresholds register"
REFERENCE
"[802.3ah] 45.2.1.36"
::= { efmCuPmeEntry 12 }
-- PME Notifications Group
efmCuPmeNotifications OBJECT IDENTIFIER ::= { efmCuPme 2 }
-- EdNote: Add more notificatoins here, for example
-- efmCuPmeTCCodingErrors,
-- efmCuPmePerfES,
-- efmCuPmePerfSES,
-- efmCuPmePerfCRCanomalies,
-- efmCuPmePerfLOSWS,
-- efmCuPmePerfUAS,
-- efmCuPmeDeviceFault,
-- efmCuPmeLocalPowerLoss
efmCuPmeLineDefect NOTIFICATION-TYPE
OBJECTS {
-- ifINdex is not needed here since we are under specific PME
efmCuPmeStatus
-- EdNote: should I add anything else here?
}
STATUS current
DESCRIPTION
"This notification indicates that a line defect (e.g.
lossOfSignal) has been detected by the PME, preventing it
from been operational.
Note that in case of PAF, PME line defect may not cause
the whole PHY to go down, it will just cause bandwidth
degradation."
-- EdNote: add throttling limitations here
::= { efmCuPmeNotifications 1 }
efmCuPmeLineAtnCrossing NOTIFICATION-TYPE
OBJECTS {
efmCuPmeLineAtn,
efmCuPmeThreshLineAtn
}
STATUS current
DESCRIPTION
"This notification indicates that the loop attenuation
threshold (as per the efmCuPmeThreshLineAtn
value) has been reached/exceeded for the 2Base-TL/10Pass-TS
Beili Expires December 22, 2004 [Page 25]
Internet-Draft EFMCu Interfaces MIB June 2004
PME."
-- EdNote: add throttling limitations here
::= { efmCuPmeNotifications 2 }
efmCuPmeRemoteLineAtnCrossing NOTIFICATION-TYPE
OBJECTS {
efmCuPmeRemoteLineAtn,
efmCuPmeThreshLineAtn
}
STATUS current
DESCRIPTION
"This notification indicates that the loop attenuation
threshold (as per the efmCuPmeThreshLineAtn
value) has been reached/exceeded for the 2Base-TL/10Pass-TS
PME link partner."
-- EdNote: add throttling limitations here
::= { efmCuPmeNotifications 3 }
efmCuPmeSnrMgnCrossing NOTIFICATION-TYPE
OBJECTS {
efmCuPmeSnrMgn,
efmCuPmeThreshSnrMgn
}
STATUS current
DESCRIPTION
"This notification indicates that the SNR margin threshold (as
per the efmCuPmeThreshSnrMgn value) has been
reached/exceeded for the 2Base-TL/10Pass-TS PME."
-- EdNote: add throttling limitations here
::= { efmCuPmeNotifications 4 }
efmCuPmeRemoteSnrMgnCrossing NOTIFICATION-TYPE
OBJECTS {
efmCuPmeRemoteSnrMgn,
efmCuPmeThreshSnrMgn
}
STATUS current
DESCRIPTION
"This notification indicates that the SNR margin threshold (as
per the efmCuPmeThreshSnrMgn value) has been
reached/exceeded for the 2Base-TL/10Pass-TS PME link partner."
-- EdNote: add throttling limitations here
::= { efmCuPmeNotifications 5 }
-- 2BaseTL specific PME group
efmCuPme2BTable OBJECT-TYPE
SYNTAX SEQUENCE OF EfmCuPme2BEntry
Beili Expires December 22, 2004 [Page 26]
Internet-Draft EFMCu Interfaces MIB June 2004
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Table for EFMCu 2BaseTL PMEs (modems)."
::= { efmCuPme 3 }
efmCuPme2BEntry OBJECT-TYPE
SYNTAX EfmCuPme2BEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the EFMCu 2BaseTL PME table."
AUGMENTS { efmCuPmeEntry }
::= { efmCuPme2BTable 1 }
EfmCuPme2BEntry ::=
SEQUENCE {
efmCuPme2BProfile BITS,
efmCuPme2BRegion INTEGER,
efmCuPme2BPower Integer32,
efmCuPme2BDataRate Integer32,
efmCuPme2BConstellation INTEGER
}
efmCuPme2BProfile OBJECT-TYPE
SYNTAX BITS { -- Rate Power Region Constellation
-- (Kbps) (dBm)
profile0(0), -- Undefined (individual PME params are used)
profile1(1), -- 5696 13.5 Annex A 32-TCPAM
profile2(2), -- 3072 13.5 Annex A 32-TCPAM
profile3(3), -- 2048 13.5 Annex A 16-TCPAM
profile4(4), -- 1024 13.5 Annex A 16-TCPAM
profile5(5), -- 704 13.5 Annex A 16-TCPAM
profile6(6), -- 512 13.5 Annex A 16-TCPAM
profile7(7), -- 5696 14.5 Annex B 32-TCPAM
profile8(8), -- 3072 14.5 Annex B 32-TCPAM
profile9(9), -- 2048 14.5 Annex B 16-TCPAM
profile10(10), -- 1024 13.5 Annex B 16-TCPAM
profile11(11), -- 704 13.5 Annex B 16-TCPAM
profile12(12) -- 512 13.5 Annex B 16-TCPAM
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"2BaseTL PME complete Profile bitmap, instantiating
individual PME parameters: efmCuPme2BRegion, efmCuPme2BPower,
efmCuPme2BDataRate and efmCuPme2BConstellation as specified in
802.3ah Annex 63A.
Beili Expires December 22, 2004 [Page 27]
Internet-Draft EFMCu Interfaces MIB June 2004
The value of profile0 is returned, when any of the individual
PME parameters are modified directly by modifying a
corresponding variable.
Up to 6 profiles can be specified simultaneously (belonging to
the same Annex. In case of multiple profiles the highest
attainable profile will be selected as operating profile.
This object is writable for the CO subtype PMEs (2BaseTL-O).
It is read-only for the CPE subtype (2BaseTL-R).
Changing PME profile must be performed when the link is
Down. Attempts to change this object MUST be rejected with
the error inconsistentValue, if the link is Up or
Initializing.
This attribute maps to aProfileSelect variable in Clause 30."
REFERENCE
"[802.3ah] Annex 63A, 30.11.2.1.6"
::= { efmCuPme2BEntry 1 }
efmCuPme2BRegion OBJECT-TYPE
SYNTAX INTEGER {
regionA(1), -- Annex A
regionB(2), -- Annex B
regionC(3) -- Annex C
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"Desired Power Spectral Density (PSD) Regional setting as
specified in Regional Annex of [ITU-T G.991.2] to operate
under.
This object is writable for the CO subtype PMEs (2BaseTL-O).
It is read-only for the CPE subtype (2BaseTL-R).
Possible values for this object are:
regionA -- Annex A
regionB -- Annex B
regionC -- Annex C
Changing Regional Annex must be performed when the link is
Down. Attempts to change this object MUST be rejected with
the error inconsistentValue, if the link is Up or
Initializing.
If a Clause 45 MDIO Interface to the PME is present, then this
attribute maps to the Region bits in the 2B general
parameter register."
REFERENCE
Beili Expires December 22, 2004 [Page 28]
Internet-Draft EFMCu Interfaces MIB June 2004
"[802.3ah] 45.2.1.42"
::= { efmCuPme2BEntry 2 }
efmCuPme2BPower OBJECT-TYPE
SYNTAX Integer32(10..42)
UNITS "0.5 dBm"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"Desired Signal Transmit Power. Multiple of 0.5dBm.
This object is writable for the CO subtype PMEs (2BaseTL-O).
It is read-only for the CPE subtype (2BaseTL-R).
Changing of the Signal Transmit Power must be performed when
the link is Down. Attempts to change this object MUST be
rejected with the error inconsistentValue, if the link is Up
or Initializing.
If a Clause 45 MDIO Interface to the PME is present, then this
attribute will map to the Power1 bits in the 2B PMD
parameters register"
REFERENCE
"[802.3ah] 45.2.1.43"
::= { efmCuPme2BEntry 3 }
efmCuPme2BDataRate OBJECT-TYPE
SYNTAX Integer32(0..5696)
UNITS "Kbps"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"Desired 2BaseTL PME Data Rate.
The rate is fixed when the value is n x 64Kbps, where n=3..60
for 16-TCPAM and n=12..89 for 32-TCPAM. The value of 0 means
that data rate is not fixed but is adaptive and should be set
to the maximum attainable rate during line probing.
This object is writable for the CO subtype PMEs (2BaseTL-O).
It is read-only for the CPE subtype (2BaseTL-R).
Changing of the Data Rate must be performed when the
link is Down. Attempts to change this object MUST be rejected
with the error inconsistentValue, if the link is Up or
Initializing.
If a Clause 45 MDIO Interface to the PME is present, then this
attribute maps to the Min/Max Data Rate1 bits in the 2B PMD
parameters register."
REFERENCE
Beili Expires December 22, 2004 [Page 29]
Internet-Draft EFMCu Interfaces MIB June 2004
"[802.3ah] 45.2.1.43"
::= { efmCuPme2BEntry 4 }
efmCuPme2BConstellation OBJECT-TYPE
SYNTAX INTEGER {
tcpam16(1), -- 16-TCPAM
tcpam32(2) -- 32-TCPAM
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"Desired TCPAM Constellation of the 2BaseTL PME.
This object is writable for the CO subtype PMEs (2BaseTL-O).
It is read-only for the CPE subtype (2BaseTL-R).
Changing Constellation must be performed when the link is
Down. Attempts to change this object MUST be rejected with
the error inconsistentValue, if the link is Up or
Initializing.
If a Clause 45 MDIO Interface to the PME is present, then this
attribute map to the Constellation1 bits in the 2B general
parameter register."
REFERENCE
"[802.3ah] 45.2.1.43"
::= { efmCuPme2BEntry 5 }
-- 10PassTS specific PME group
efmCuPme10PTable OBJECT-TYPE
SYNTAX SEQUENCE OF EfmCuPme10PEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Table for EFMCu 10PassTS PMEs (modems)."
::= { efmCuPme 4 }
efmCuPme10PEntry OBJECT-TYPE
SYNTAX EfmCuPme10PEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the EFMCu 10PassTS PME table."
AUGMENTS { efmCuPmeEntry }
::= { efmCuPme10PTable 1 }
EfmCuPme10PEntry ::=
SEQUENCE {
Beili Expires December 22, 2004 [Page 30]
Internet-Draft EFMCu Interfaces MIB June 2004
efmCuPme10PProfile INTEGER,
efmCuPme10PBandplanPSDMaskProfile INTEGER,
efmCuPme10PUPBOReferenceProfile INTEGER,
efmCuPme10PBandNotchProfiles BITS,
efmCuPme10PPayloadURateProfile INTEGER,
efmCuPme10PPayloadDRateProfile INTEGER,
efmCuPme10PElectricalLength Integer32
-- EdNote: To be continued
}
efmCuPme10PProfile OBJECT-TYPE
SYNTAX INTEGER {-- Bandplan UPBO BandNotch DRate URate
-- PSDMask# p# p# p# p#
profile0(0), -- Undefined (individual PME Params are used)
profile1(1), -- 1 3 2,6,10,11 20 20(default)
profile2(2), -- 13 5 0 20 20
profile3(3), -- 1 1 0 20 20
profile4(4), -- 16 0 0 100 100
profile5(5), -- 16 0 0 70 50
profile6(6), -- 6 0 0 50 10
profile7(7), -- 17 0 0 30 30
profile8(8), -- 8 0 0 30 5
profile9(9), -- 4 0 0 25 25
profile10(10), -- 4 0 0 15 15
profile11(11), -- 23 0 0 10 10
profile12(12), -- 23 0 0 5 5
profile13(13), -- 16 0 2,5,9,11 100 100
profile14(14), -- 16 0 2,5,9,11 70 50
profile15(15), -- 6 0 2,6,10,11 50 10
profile16(16), -- 17 0 2,5,9,11 30 30
profile17(17), -- 8 0 2,6,10,11 30 5
profile18(18), -- 4 0 2,6,10,11 25 25
profile19(19), -- 4 0 2,6,10,11 15 15
profile20(20), -- 23 0 2,5,9,11 10 10
profile21(21) -- 23 0 2,5,9,11 5 5
profile21(22) -- 30 0 0 200 50
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"10PassTS PME complete profile, instantiating
individual PME parameters: efmCuPme10PBandplanPSDMaskProfile,
efmCuPme10PUPBOReferenceProfile, efmCuPme10PBandNotchProfile,
efmCuPme10PUDataRateProfile and efmCuPme10PDRateProfile as
specified in 802.3ah Annex 62B.3.
The value of profile0 is returned, when any of the individual
PME parameters are modidifed directly by modifying a
corresponding variable.
Beili Expires December 22, 2004 [Page 31]
Internet-Draft EFMCu Interfaces MIB June 2004
This object is writable for the CO subtype PMEs (10PassTS-O).
It is read-only for the CPE subtype (10PassTS-R).
Changing PME profile must be performed when the link is
Down. Attempts to change this object MUST be rejected with
the error inconsistentValue, if the link is Up or
Initializing.
This attribute maps to the aProfileSelect variable in Clause
30."
REFERENCE
"[802.3ah] 62B.3, 30.11.2.1.6"
::= { efmCuPme10PEntry 1 }
efmCuPme10PBandplanPSDMaskProfile OBJECT-TYPE
SYNTAX INTEGER {-- PSD Mask Bands Bandplan
profile1(1), -- T1.424/T-U P1 FTTCab.M1 x/D/U/D/U A
profile2(2), -- T1.424/T-U P1 FTTEx.M1
profile3(3), -- T1.424/T-U P1 FTTCab.M2
profile4(4), -- T1.424/T-U P1 FTTEx.M2
profile5(5), -- T1.424/T-U P1 FTTCab.M1 D/D/U/D/U
profile6(6), -- T1.424/T-U P1 FTTEx.M1
profile7(7), -- T1.424/T-U P1 FTTCab.M2
profile8(8), -- T1.424/T-U P1 FTTEx.M2
profile9(9), -- T1.424/T-U P1 FTTCab.M1 U/D/U/D/x
profile10(10), -- T1.424/T-U P1 FTTEx.M1
profile11(11), -- T1.424/T-U P1 FTTCab.M2
profile12(12), -- T1.424/T-U P1 FTTEx.M2
profile13(13), -- TS1 101 270-1 Pcab.M1.A x/D/U/D/U B
profile14(14), -- TS1 101 270-1 Pcab.M1.B
profile15(15), -- TS1 101 270-1 Pex.P1.M1
profile16(16), -- TS1 101 270-1 Pex.P2.M1
profile17(17), -- TS1 101 270-1 Pcab.M2
profile18(18), -- TS1 101 270-1 Pex.P1.M2
profile19(19), -- TS1 101 270-1 Pex.P2.M2
profile20(20), -- TS1 101 270-1 Pcab.M1.A U/D/U/D/x
profile21(21), -- TS1 101 270-1 Pcab.M1.B
profile22(22), -- TS1 101 270-1 Pex.P1.M1
profile23(23), -- TS1 101 270-1 Pex.P2.M1
profile24(24), -- TS1 101 270-1 Pcab.M2
profile25(25), -- TS1 101 270-1 Pex.P1.M2
profile26(26), -- TS1 101 270-1 Pex.P2.M2
profile27(27), -- G.993.1 F.1.2.1 (VDSLoPOTS) x/D/U/D/U F
profile28(28), -- G.993.1 F.1.2.2 (VDSLoTCM-ISDN)
profile29(29) -- G.993.1 F.1.2.3 (PSD reduction)
}
MAX-ACCESS read-write
STATUS current
Beili Expires December 22, 2004 [Page 32]
Internet-Draft EFMCu Interfaces MIB June 2004
DESCRIPTION
"10PassTS PME Bandplan and PSD Mask profile,
as specified in 802.3ah Annex 62A.
This object is writable for the CO subtype PMEs (10PassTS-O).
It is read-only for the CPE subtype (10PassTS-R).
Changing PME Bandplan and PSD MAsk profile must be performed
when the link is Down. Attempts to change this object MUST be
rejected with the error inconsistentValue, if the link is Up
or Initializing.
This attribute maps to the aBandplanPSDMaskProfile variable
in Clause 30."
REFERENCE
"[802.3ah] Annex 62A, 30.5.1.1.22"
::= { efmCuPme10PEntry 2 }
efmCuPme10PUPBOReferenceProfile OBJECT-TYPE
SYNTAX INTEGER {-- Reference PSD
profile1(1), -- T1.424/T-U Noise A M1
profile2(2), -- T1.424/T-U Noise A M2
profile3(3), -- T1.424/T-U Noise F M1
profile4(4), -- T1.424/T-U Noise F M2
profile5(5), -- ETSI TS 101 270-1 Noise A&B
profile6(6), -- ETSI TS 101 270-1 Noise C
profile7(7), -- ETSI TS 101 270-1 Noise D
profile8(8), -- ETSI TS 101 270-1 Noise E
profile9(9) -- ETSI TS 101 270-1 Noise F
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"10PassTS PME Upstream Power Back-Off (UPBO) Reference PSD
Profile, as specified in 802.3ah Annex 62A.
This object is writable for the CO subtype PMEs (10PassTS-O).
It is read-only for the CPE subtype (10PassTS-R).
Changing UPBO Reference profile must be performed
when the link is Down. Attempts to change this object MUST be
rejected with the error inconsistentValue, if the link is Up
or Initializing.
This attribute maps to the aUPBOReferenceProfile variable
in Clause 30."
REFERENCE
"[802.3ah] Annex 62A.3.4, 30.5.1.1.23"
::= { efmCuPme10PEntry 3 }
Beili Expires December 22, 2004 [Page 33]
Internet-Draft EFMCu Interfaces MIB June 2004
efmCuPme10PBandNotchProfiles OBJECT-TYPE
SYNTAX BITS { -- G.991.3 T1.424/T-U TS101 270-1 StartF EndF
-- Table Table Table (MHz) (MHz)
profile0(0), -- no profile
profile1(1), -- F-5 #01 - - 1.810 1.825
profile2(2), -- 6-2 15-1 17 1.810 2.000
profile3(3), -- F-5 #02 - - 1.907 1.912
profile4(4), -- F-5 #03 - - 3.500 3.575
profile5(5), -- 6-2 - 17 3.500 3.800
profile6(6), -- - 15-1 - 3.500 4.000
profile7(7), -- F-5 #04 - - 3.747 3.754
profile8(8), -- F-5 #05 - - 3.791 3.805
profile9(9), -- 6-2 - 17 7.000 7.100
profile10(10),-- F-5 #06 15-1 - 7.000 7.300
profile11(11) -- 6-2 15-1 1 10.100 10.150
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"10PassTS PME Egress Control Band Notch Profile bitmap,
as specified in 802.3ah Annex 62A.
This object is writable for the CO subtype PMEs (10PassTS-O).
It is read-only for the CPE subtype (10PassTS-R).
Any combination of profiles can be specified by ORing
individual profiles, for example value of 0x0622 selects
profiles 2,6,10 and 11.
Changing Band Notch profiles must be performed when the link
is Down. Attempts to change this object MUST be rejected with
the error inconsistentValue, if the link is Up or
Initializing.
This attribute maps to the aBandNotchProfile variable
in Clause 30."
REFERENCE
"[802.3ah] Annex 62A.3.5, 30.5.1.1.19"
::= { efmCuPme10PEntry 4 }
efmCuPme10PPayloadURateProfile OBJECT-TYPE
SYNTAX INTEGER {-- Upstream Payload Rate (Mbps)
profile5(5), -- 2.5
profile10(10), -- 5
profile15(15), -- 7.5
profile20(20), -- 10
profile25(25), -- 12.5
profile30(30), -- 15
profile50(50), -- 25
profile70(70), -- 35
Beili Expires December 22, 2004 [Page 34]
Internet-Draft EFMCu Interfaces MIB June 2004
profile100(100) -- 50
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"10PassTS PME Upstream Payload Rate Profile,
as specified in 802.3ah Annex 62A.
This object is writable for the CO subtype PMEs (10PassTS-O).
It is read-only for the CPE subtype (10PassTS-R).
The SET operation sets a target for the PHY's Upstream Payload
Bitrate as seen at the MII. If the payload rate of the
selected profile cannot be achieved based on the loop
environment, bandplan and PSD mask, the PHY shall drop the
link.
Changing Upstream Payload Rate Profile must be performed
when the link is Down. Attempts to change this object MUST be
rejected with the error inconsistentValue, if the link is Up
or Initializing.
This attribute maps to the aPayloadRateProfileUpstream
variable in Clause 30."
REFERENCE
"[802.3ah] Annex 62A.3.6, 30.5.1.1.20"
::= { efmCuPme10PEntry 5 }
efmCuPme10PPayloadDRateProfile OBJECT-TYPE
SYNTAX INTEGER {-- Downstream Payload Rate (Mbps)
profile5(5), -- 2.5
profile10(10), -- 5
profile15(15), -- 7.5
profile20(20), -- 10
profile25(25), -- 12.5
profile30(30), -- 15
profile50(50), -- 25
profile70(70), -- 35
profile100(100), -- 50
profile140(140), -- 70
profile200(200) -- 100
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"10PassTS PME Downstream Payload Rate Profile,
as specified in 802.3ah Annex 62A.
This object is writable for the CO subtype PMEs (10PassTS-O).
It is read-only for the CPE subtype (10PassTS-R).
Beili Expires December 22, 2004 [Page 35]
Internet-Draft EFMCu Interfaces MIB June 2004
The SET operation sets a target for the PHY's Downstream
Payload Bitrate as seen at the MII. If the payload rate of
the selected profile cannot be achieved based on the loop
environment, bandplan and PSD mask, the PHY shall drop the
link.
Changing Downstream Payload Rate Profile must be performed
when the link is Down. Attempts to change this object MUST be
rejected with the error inconsistentValue, if the link is Up
or Initializing.
This attribute maps to the aPayloadRateProfileDownstream
variable in Clause 30."
REFERENCE
"[802.3ah] Annex 62A.3.6, 30.5.1.1.21"
::= { efmCuPme10PEntry 6 }
efmCuPme10PElectricalLength OBJECT-TYPE
SYNTAX Integer32(0..8192|65535)
UNITS "m"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Electrical Length in meters as perceived by the 10PassTS PME
after the link is established.
The value of 65535 is returned if the link is Down or
Initializing or the PME is unable to estimate the Electrical
Length.
If a Clause 45 MDIO Interface to the PME is present, then this
attribute maps to the 10P Electrical Length register"
REFERENCE
"[802.3ah] 45.2.1.21"
::= { efmCuPme10PEntry 7 }
-- efmCuAvailableStackTable for use in Discovery
efmCuAvailableStackTable OBJECT-TYPE
SYNTAX SEQUENCE OF EfmCuAvailableStackEntry
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 in
ifStackTable). In particular, it contains information on
Beili Expires December 22, 2004 [Page 36]
Internet-Draft EFMCu Interfaces MIB June 2004
which PCS ports (sub-layers) can possibly run 'on top of'
which PMEs (sublayers), as determined by cross-connect
capability of the EFMCu device, where each sub-layer
corresponds to a conceptual row in the ifTable. For example,
when the PCS port with ifIndex value x can be connected
to run on top of the PME with ifIndex value y, then this table
contains:
efmCuAvailableStackStatus.x.y=active
For each ifIndex value, I, which identifies a PCS or PME
interface, there are always at least two instantiated rows
in this table associated with I. For one of these rows, I
is the value of efmCuAvailableStackHigherLayer; for the other,
I is the value of efmCuAvailableStackLowerLayer.
Note that there's always at least on PCS for each PME and at
least one PME for each PCS in the EFMCu devices, with
efmCuPAFCapacity and efmCuRemotePAFCapacity indicating
maximum number of PMEs which can be aggregated by local and
remote PCS port respectively.
This table is ready only as it describes device capability"
REFERENCE
"ifStackTable of RFC 2863"
::= { efmCuObjects 3 }
efmCuAvailableStackEntry OBJECT-TYPE
SYNTAX EfmCuAvailableStackEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Information on a particular relationship between two sub-
layers, specifying that one sub-layer runs on 'top' of the
other sub-layer. Each sub-layer corresponds to a conceptual
row in the ifTable."
INDEX {
efmCuAvailableStackHigherLayer,
efmCuAvailableStackLowerLayer
}
::= { efmCuAvailableStackTable 1 }
EfmCuAvailableStackEntry ::=
SEQUENCE {
efmCuAvailableStackHigherLayer InterfaceIndexOrZero,
efmCuAvailableStackLowerLayer InterfaceIndexOrZero,
efmCuAvailableStackStatus RowStatus
}
efmCuAvailableStackHigherLayer OBJECT-TYPE
Beili Expires December 22, 2004 [Page 37]
Internet-Draft EFMCu Interfaces MIB June 2004
SYNTAX InterfaceIndexOrZero
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The value of ifIndex corresponding to the higher sub-layer
of the relationship, i.e., the sub-layer which runs on 'top'
of the sub-layer identified by the corresponding instance of
ifStackLowerLayer. If there is no higher sub-layer (below
the internetwork layer), then this object has the value 0."
::= { efmCuAvailableStackEntry 1 }
efmCuAvailableStackLowerLayer OBJECT-TYPE
SYNTAX InterfaceIndexOrZero
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The value of ifIndex corresponding to the lower sub-layer
of the relationship, i.e., the sub-layer which runs 'below'
the sub-layer identified by the corresponding instance of
ifStackHigherLayer. If there is no lower sub-layer, then
this object has the value 0."
::= { efmCuAvailableStackEntry 2 }
efmCuAvailableStackStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The status of the relationship between two sub-layers.
This object is read only, unlike ifStackStatus, as it
describes the device capability."
::= { efmCuAvailableStackEntry 3 }
--
-- Conformance Statements
--
efmCuGroups OBJECT IDENTIFIER ::= { efmCuConformance 1 }
efmCuCompliances OBJECT IDENTIFIER ::= { efmCuConformance 2 }
-- Object Groups
efmCuPortBasicGroup OBJECT-GROUP
OBJECTS {
Beili Expires December 22, 2004 [Page 38]
Internet-Draft EFMCu Interfaces MIB June 2004
efmCuStatus,
efmCuPortSide,
efmCuPAFSupported
}
STATUS current
DESCRIPTION
"A collection of objects required for all EFMCu ports."
::= { efmCuGroups 1 }
efmCuPAFGroup OBJECT-GROUP
OBJECTS {
efmCuPAFAdminState,
efmCuRemotePAFSupported,
efmCuPAFDiscoveryCode,
efmCuPAFRemoteDiscoveryCode,
efmCuAvailableStackStatus
}
STATUS current
DESCRIPTION
"A collection of objects supporting
optional Aggregation features on EFMCu ports."
::= { efmCuGroups 2 }
efmCuPmeGroup OBJECT-GROUP
OBJECTS {
efmCuPmeStatus,
efmCuPmeSubTypesSupported,
efmCuPmeSubType,
efmCuPmeSnrMgn,
efmCuPmeRemoteSnrMgn,
efmCuPmeLineAtn,
efmCuPmeRemoteLineAtn
}
STATUS current
DESCRIPTION
"A collection of objects providing information about
a 2BaseTL/10PassTS PME."
::= { efmCuGroups 3 }
efmCuPmeAlarmConfGroup OBJECT-GROUP
OBJECTS {
efmCuPmeThreshLineAtn,
efmCuPmeThreshSnrMgn
-- efmCuPmeThreshES,
-- efmCuPmethreshSES,
-- efmCuPmeThreshCRCanomalies,
-- efmCuPmeThreshLOSWS,
-- efmCuPmeThreshUAS
Beili Expires December 22, 2004 [Page 39]
Internet-Draft EFMCu Interfaces MIB June 2004
}
STATUS current
DESCRIPTION
"A collection of objects that allow configuration of alarm
thresholds for various performance parameters for 2B/10P PME."
::= { efmCuGroups 4 }
efmCuPmeNotificationGroup NOTIFICATION-GROUP
NOTIFICATIONS {
efmCuPmeLineDefect,
efmCuPmeLineAtnCrossing,
efmCuPmeRemoteLineAtnCrossing,
efmCuPmeSnrMgnCrossing,
efmCuPmeRemoteSnrMgnCrossing
-- efmCuPmePerfES,
-- efmCuPmePerfSES,
-- efmCuPmePerfCRCanomalies,
-- efmCuPmePerfLOSWS,
-- efmCuPmePerfUAS,
-- efmCuPmeDeviceFault,
-- efmCuPmeLocalPowerLoss
}
STATUS current
DESCRIPTION
"This group supports notifications of significant conditions
associated with EFMCu PMEs."
::= { efmCuGroups 5 }
efmCuPme2BGroup OBJECT-GROUP
OBJECTS {
efmCuPme2BProfile,
efmCuPme2BRegion,
efmCuPme2BPower,
efmCuPme2BDataRate,
efmCuPme2BConstellation
}
STATUS current
DESCRIPTION
"A collection of objects for configuration of a 2BaseTL PME."
::= { efmCuGroups 6 }
efmCuPme10PGroup OBJECT-GROUP
OBJECTS {
efmCuPme10PProfile,
efmCuPme10PBandplanPSDMaskProfile,
efmCuPme10PUPBOReferenceProfile,
efmCuPme10PBandNotchProfiles,
efmCuPme10PPayloadURateProfile,
Beili Expires December 22, 2004 [Page 40]
Internet-Draft EFMCu Interfaces MIB June 2004
efmCuPme10PPayloadDRateProfile,
efmCuPme10PElectricalLength
}
STATUS current
DESCRIPTION
"A collection of objects for conifguration of a 10PassTS PME."
::= { efmCuGroups 7 }
-- Compliance Statements
efmCuCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for 2BaseTL/10PassTS interfaces.
Compliance with the following external compliance statements
is prerequisite:
MIB Module Compliance Statement
---------- --------------------
IF-MIB ifCompliance3
IF-INVERTED-STACK-MIB ifInvCompliance
EtherLike-MIB dot3Compliance2
MAU-MIB mauModIfCompl3"
MODULE -- this module
MANDATORY-GROUPS {
efmCuPortBasicGroup,
efmCuPmeGroup,
efmCuPmeAlarmConfGroup,
efmCuPmeNotificationGroup
}
GROUP efmCuPme2BGroup
DESCRIPTION
"Support for this group is only required for implementations
supporting 2Base-TL Phy."
GROUP efmCuPme10PGroup
DESCRIPTION
"Support for this group is only required for implementations
supporting 10Pass-TS Phy."
GROUP efmCuPAFGroup
DESCRIPTION
"Support for this group is only required for implementations
supporting PME Aggregation Function."
OBJECT efmCuPmeSubTypesSupported
Beili Expires December 22, 2004 [Page 41]
Internet-Draft EFMCu Interfaces MIB June 2004
SYNTAX BITS {
ieee2BaseTL-O(1),
ieee2BaseTL-R(2),
ieee10PassTS-O(3),
ieee10PassTS-R(4)
}
DESCRIPTION
"Support for all subtypes is not required. However at least
one value SHALL be supported"
OBJECT efmCuPmeSubType
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required (needed only for PMEs
supporting more than a single subtype, e.g.
ieee2BaseTL-O and ieee2BaseTS-R or ieee2BaseTL-R and
ieee10PassTS-R)"
-- EdNote: To be Continued
::= { efmCuCompliances 1 }
END
5. Security Considerations
There is a number of managed objects defined in this MIB module that
have a MAX-ACCESS clause of read-write or read-create. Most objects
are writeable only when the link is Down. Writing to these objects
can have potentially disruptive effects on network operation, for
example:
o Changing of efmCuPortSide may lead to a potential locking of the
link, as same PHYs of the same sub-type may not be able to
exchange handshake messages.
o Changing of efmCuPAFAdminState to enabled may lead to a potential
locking of the link, if the peer Phy does not support PAF.
o Changing of efmCuPAFDiscoveryCode before the discovery operation
may lead to a wrongful discovery with possile multiple -O ports
connecting to the same -R (both -O ports have the same Discovery
register value) and similar cases.
o Changing any of the efmCuPmd2* or efmCuPmd10P* configuration may
lead to anything from link quality and rate degradation to a
complete disabling of the link.
Beili Expires December 22, 2004 [Page 42]
Internet-Draft EFMCu Interfaces MIB June 2004
o Finally activation of a PME can cause a severe degradation of
service for another EFMCu Phy whose PME(s) may be affected by the
cross-talk from the newly activated PME.
The user of this MIB module must therefore be aware that support for
SET operations in a non-secure environment without proper protection
can have a negative effect on network operations.
The readable objects in this MIB module (i.e., those with MAX-ACCESS
other than not-accessible) may be considered sensitive in some
environments since, collectively, they provide information about the
performance of network interfaces and can reveal some aspects of
their configuration. In particular since EFMCu can be carried over
Unshielded Twisted Pair (UTP) voice grade copper in a bundle with
other pairs belonging to another operator/customer, it is
theoretically possible to evasdrop to an EFMCu transmission simply by
"listening" to a cross-talk from an EFMCu pair, especially if the
parameters of the EFMCu link in question are known. In such
environments it is important to control even GET and NOTIFY access to
these objects and possibly even to encrypt their values when sending
them over the network via SNMP.
SNMP versions prior to SNMPv3 did not include adequate security.
Even if the network itself is secure (for example by using IPSec),
even then, there is no control as to who on the secure network is
allowed to access and GET/SET (read/change/create/delete) the objects
in this MIB module.
It is RECOMMENDED that implementers consider the security features as
provided by the SNMPv3 framework (see [RFC3410], section 8),
including full support for the SNMPv3 cryptographic mechanisms (for
authentication and privacy).
Further, deployment of SNMP versions prior to SNMPv3 is NOT
RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to
enable cryptographic security. It is then a customer/operator
responsibility to ensure that the SNMP entity giving access to an
instance of this MIB module is properly configured to give access to
the objects only to those principals (users) that have legitimate
rights to indeed GET or SET (change/create/delete) them.
6. Acknowledgments
Not yet.
7. References
Beili Expires December 22, 2004 [Page 43]
Internet-Draft EFMCu Interfaces MIB June 2004
7.1 Normative References
[802.3ah] IEEE, "Draft amendment to - 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 - Media Access Control Parameters,
Physical Layers and Management Parameters for subscriber
access networks", IEEE Draft P802.3ah/D3.3, April 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.
[RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
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,
"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.
7.2 Informative References
[I-D.ietf-adslmib-vdsl]
Ray, B. and R. Abbi, "Definitions of Managed Objects for
Very High Speed Digital Subscriber Lines (VDSL)",
draft-ietf-adslmib-vdsl-12 (work in progress), October
2003.
[I-D.ietf-hubmib-efm-epon-mib]
Khermosh, L., "Managed Objects for the Ethernet Passive
Optical Networks", draft-ietf-hubmib-efm-epon-mib-00 (work
in progress), December 2003.
Beili Expires December 22, 2004 [Page 44]
Internet-Draft EFMCu Interfaces MIB June 2004
[I-D.ietf-hubmib-efm-mib]
Squire, M., "Ethernet in the First Mile (EFM) Common MIB",
draft-squire-hubmib-efm-mib-00 (work in progress), October
2003.
[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.
[RFC3276] Ray, B. and R. Abbi, "Definitions of Managed Objects for
High Bit-Rate DSL - 2nd generation (HDSL2) and Single-Pair
High-Speed Digital Subscriber Line (SHDSL) Lines
Processing", RFC 3276, May 2002.
[RFC3635] Flick, J., "Definitions of Managed Objects for the
Ethernet-like Interface Types", RFC 3635, September 2003.
[RFC3636] Flick, J., "Definitions of Managed Objects for IEEE 802.3
Medium Attachment Units (MAUs)", RFC 3636, September 2003.
Author's Address
Edward Beili
Actelis Networks
Bazel 25
Petach-Tikva
Israel
Phone: +972-3-924-3491
EMail: [email protected]
Beili Expires December 22, 2004 [Page 45]
Internet-Draft EFMCu Interfaces MIB June 2004
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
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
[email protected].
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Beili Expires December 22, 2004 [Page 46]
efm-cu-mib.mib
(application/octet-stream, 65.4 KB) - not displayed