RFC 4837 - Managed Objects of Ethernet Passive Optical Networks (EPON)
(Formats: TXT)
Network Working Group L. Khermosh
Request for Comments: 4837 PMC-SIERRA
Category: Standards Track July 2007
|
Managed Objects of Ethernet Passive Optical Networks (EPON)
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
This document defines a portion of the Management Information Base
(MIB) for use with network management protocols in TCP/IP based
Internets. In particular, it defines objects for managing interfaces
that conform to the Ethernet Passive Optical Networks (EPON) standard
as defined in the IEEE Std 802.3ah-2004, which are extended
capabilities to the Ethernet like interfaces.
Khermosh Standards Track [Page 1]
RFC 4837 Managed Objects of EPON July 2007
Table of Contents
1. The Internet-Standard Management Framework . . . . . . . . . . 3
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Terminology and Abbreviations . . . . . . . . . . . . . . 3
2.2. EPON Architecture Highlights . . . . . . . . . . . . . . . 5
2.2.1. Introduction . . . . . . . . . . . . . . . . . . . . . 5
2.2.2. Principles of Operation . . . . . . . . . . . . . . . 6
2.2.3. The Physical Media . . . . . . . . . . . . . . . . . . 7
2.2.4. PMD Specifications . . . . . . . . . . . . . . . . . . 8
2.2.5. Point-to-Point Emulation . . . . . . . . . . . . . . . 8
2.2.6. Principles of the MPCP . . . . . . . . . . . . . . . . 10
2.2.7. Forward Error Correction (FEC) . . . . . . . . . . . . 12
2.3. Management Architecture . . . . . . . . . . . . . . . . . 13
3. MIB Structure . . . . . . . . . . . . . . . . . . . . . . . . 17
4. Relation to Other MIB Modules . . . . . . . . . . . . . . . . 22
4.1. Relation to the Interfaces MIB and Ethernet-like
Interfaces MIB . . . . . . . . . . . . . . . . . . . . . . 22
4.2. Relation to the IEEE 802.3 MAU MIBs . . . . . . . . . . . 29
4.3. Relation to the EFM OAM MIB . . . . . . . . . . . . . . . 29
4.4. Relation to the Bridge MIB . . . . . . . . . . . . . . . . 30
5. Mapping of IEEE 802.3ah Managed Objects . . . . . . . . . . . 31
6. Definitions - The DOT3 EPON MIB Module . . . . . . . . . . . . 33
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 85
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 86
9. Security Considerations . . . . . . . . . . . . . . . . . . . 86
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 88
10.1. Normative References . . . . . . . . . . . . . . . . . . . 88
10.2. Informative References . . . . . . . . . . . . . . . . . . 90
Khermosh Standards Track [Page 2]
RFC 4837 Managed Objects of EPON July 2007
1. The Internet-Standard Management Framework
For a detailed overview of the documents that describe the current
Internet-Standard Management Framework, please refer to Section 7 of
RFC 3410 [RFC3410]. Managed objects are accessed via a virtual
information store, termed the Management Information Base or MIB.
MIB objects are generally accessed through the Simple Network
Management Protocol (SNMP). Objects in the MIB are defined using the
mechanisms defined in the Structure of Management Information (SMI).
This memo specifies a MIB module that is compliant to the SMIv2,
which is described in STD 58, RFC 2578 [RFC2578]; STD 58, RFC 2579
[RFC2579]; and STD 58, RFC 2580 [RFC2580].
2. Overview
This document defines a portion of the Management Information Base
(MIB) for use with network management protocols in TCP/IP based
Internets. In particular, it defines objects for managing interfaces
that conform to the Ethernet Passive Optical Networks (EPON) standard
as defined in [802.3ah], which are extended capabilities to the
Ethernet like interfaces. The document contains a list of management
objects based on the attributes defined in the relevant parts of
[802.3ah] Annex 30A, referring to EPON.
2.1. Terminology and Abbreviations
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 [RFC2119].
ACK - Acknowledge
BER - Bit Error Rate
BW - Bandwidth
CO - Central Office
CPE - Customer Premises Equipment
CRC - Cyclic Redundancy Check
EFM - Ethernet First Mile
EPON - Ethernet Passive Optical Network
FCS - Frame Check Sequence
Khermosh Standards Track [Page 3]
RFC 4837 Managed Objects of EPON July 2007
FEC - Forward Error Correction
GMII - Gigabit Media Independent Interface
LAN - Local Area Network
LLID - Logical Link Identifier
MAC - Media Access Control
Mbps - Megabit per second
MDI - Medium Dependent Interface
MDIO - Management Data Input/Output
MPCP - Multi-Point Control Protocol
MP2PE - Multi-Point to Point Emulation
OAM - Operation Administration Maintenance
OLT - Optical Line Terminal (Server unit of the EPON)
OMP - Optical Multi-Point
ONU - Optical Network Unit (Client unit of the EPON)
P2MP - Point-to-Multipoint
P2PE - Point-to-Point Emulation
PCS - Physical Coding Sublayer
PHY - Physical Layer
PMA - Physical Medium Attachment
PMD - Physical Medium Dependent
PON - Passive Optical Network
RS - Reconciliation Sublayer
RTT - Round Trip Time
SLA - Service Level Agreement
Khermosh Standards Track [Page 4]
RFC 4837 Managed Objects of EPON July 2007
SLD - Start of LLID Delimiter
TDM - Time Division Multiplexing
TQ - Time Quanta
2.2. EPON Architecture Highlights
2.2.1. Introduction
The EPON standard, as defined in [802.3ah], defines the physical
media (Layer 1) and media access (Layer 2) of the EPON interface.
The EPON is a variant of the Gigabit Ethernet protocol for the
Optical Access. The Optical Access topology is based on passive
optical splitting topology. The link of a Passive Optical Network
(PON) is based on a single, shared optical fiber with passive optical
splitters dividing the single fiber into separate subscribers.
The Optical Line Terminal (OLT) is the server unit of the network,
located at the Central Office (CO).
The Optical Network Unit (ONU) is the client unit of the network,
located at the Customer Premises Equipment (CPE).
The following diagram describes the PON topology:
Device with
one or more P2MP
interfaces such as OLT
for EPON An EPON IP host
------- OLT ONU "modem" --------
Other IEEE | | interface | interface ------ Other IEEE| |
interface | |-------\----------------| | interface | |
===========| | \ | |===========| |
| | \ ------ --------
| | \ ------ --------
. . \------------| | | |
| |------\ | |===========| |
| | \ ------ --------
------- \ etc
Khermosh Standards Track [Page 5]
RFC 4837 Managed Objects of EPON July 2007
The IEEE layering architecture of an EPON interface is defined in the
diagram of Figure 56.2 [802.3ah]. The following clauses in the
[802.3ah] define the corresponding layers of an EPON interface:
clause 30 - Management
clause 60 - PMD for EPON media (Burst PMD)
clause 64 - MPCP (Multi-Point Control Protocol) - defines the Multi-
Point architecture, and control protocol for the media access of
EPON.
clause 65 -
a) Virtual links definition for the EPON
b) FEC
c) PMA for the EPON.
2.2.2. Principles of Operation
The specification of the EPON interface is based on the specification
of the gigabit Ethernet interface as described in [802.3], clauses 35
and 36. The Ethernet MAC is working in gigabit rate. The media
interface to the MAC is through the GMII interface, as described in
clause 35, and the PCS layer is based on the gigabit Ethernet PCS as
described in clause 36. The special EPON layers are added to the
Ethernet layering in the following places:
The MPCP is placed in the MAC control layer, providing the EPON
control protocol. The Emulation layer, located at the RS
(Reconciliation Sublayer), creates virtual private path to each ONU.
The FEC layer is located between the PCS and PMA layers, enhancing
reach and split performance of the optical link.
Khermosh Standards Track [Page 6]
RFC 4837 Managed Objects of EPON July 2007
The following diagram describes the layering model of an EPON
interface:
+==========================================+
| Higher layers |
+==========================================+
| 802.1D Bridge |
+==========================================+
| MAC client| ... |MAC client|
+==========================================+
| MAC Control - (MPCP) | *NEW*
+==========================================+
| MAC | ... | MAC |
+==========================================+
| P2P Emulation (P2PE) | *NEW*
+==========================================+
| |
| GMII |
| |
+==========================================+
| PCS |
+==========================================+
| FEC | *NEW*
+==========================================+
| PMA | *Enhanced parameters
+==========================================+ for EPON*
| PMD | *Enhanced parameters
+==========================================+ for EPON*
| |
| MDI |
| |
/===================/
/ Media /
/===================/
2.2.3. The Physical Media
The physical link is a fiber optical link. The OLT and ONUs are
connected through passive optical splitters. Downlink denotes the
transmission from the OLT to the ONUs. Uplink denotes the
transmission from the ONUs to the OLT. Uplink and downlink are
multiplexed using separated wavelengths on the same fiber. The
downlink is a broadcast medium where the OLT transmits the data to
all ONUs. The uplink is a shared transmission medium for all of the
ONUs. The uplink access is based on time division multiplexing (TDM)
and the management of the TDM media access is defined by the Multi-
Khermosh Standards Track [Page 7]
RFC 4837 Managed Objects of EPON July 2007
Point Control Protocol (MPCP). The MPCP is a control protocol based
on an inband packet messaging. The OLT sends control messages (GATE
messages) allowing ONUs to transmit, defining when the transmission
occurs and what is its duration. These messages define the
transmission order and the amount of BW for each ONU. A scheduling
algorithm at the OLT, which is not defined in the [802.3ah], is
responsible for allocating the BW and controlling the delay of each
ONU according to its SLA.
2.2.4. PMD Specifications
PMD specifications select the same optical wavelength plan as the
[ITU-T.G.983]. The transceivers are derivatives of existing Ethernet
optical transceivers, with dual wavelength on a single fiber, and
extended burst capabilities for the uplink. The uplink burst
capability is the burst transmission functionality for the ONUs and
burst reception functionality for the OLT. The [802.3ah] selected
very relaxed burst parameters to reduce the device cost of EPON
products.
2.2.5. Point-to-Point Emulation
The downstream is a broadcast link, which means that the OLT
transmission is shared for all ONUs. The sharing of the transmission
of the OLT has some negative privacy aspects and should be limited to
broadcast traffic in nature only. The traffic dedicated to each ONU
should not be shared. The solution provided by [802.3ah] is to
partition the EPON link, in a virtual manner, between the ONUs. Each
ONU has a dedicated virtual link to the OLT. The [802.3ah] also
defines an additional link for broadcast transmission. The medium
becomes an aggregation of point-to-point tunnels. The OLT cannot
preserve its EPON interface as a single interface connected to N
devices (following the properties of the physical interface). The
EPON interface of the OLT is partitioned into separate virtual
interfaces; an interface for each virtual link. Hence, the OLT
behaves like a device with N virtual ports (and an additional port
for the broadcast transmission). The additional single-copy-
broadcast channel (tagged as all one LLID) is added to allow the
broadcast transmission within a single copy to all ONUs, preserving
the inherent advantage of BW efficiency of the PON shared media. The
ONUs filter the downlink traffic that is not intended for their
reception, according to the virtual link marking. An LLID tag is
attached at the preamble of the Ethernet packet denoting the virtual
link. The LLID marks the destination port in the downstream and
source port in the upstream.
Khermosh Standards Track [Page 8]
RFC 4837 Managed Objects of EPON July 2007
The virtual links concept is also used to avoid a violation of the
[802.1d] bridging rules for peer-to-peer traffic in the PON. Peer-
to-peer traffic is traffic between ONUs in the same PON. The OLT
cannot preserve the EPON interface as a single interface, connected
to N devices, and allow traffic between these devices without
violating the bridging rules. The source address and destination
address of the peer-to-peer traffic are behind the same port and
therefore the traffic should be discarded. The separation of the
ONUs into virtual links solves this issue. The OLT has N virtual
ports for the single physical EPON port. A bridge sees a single MAC
Client for every link pair.
The private paths concept solves the networking problems and provides
subscriber isolation.
As the tunneling is only a virtual tunneling, there is a single
physical interface and a single physical layer for the device so that
some attributes are shared. For example, the interface has a single
local MAC address.
The virtual tunneling for an OLT with 3 ONUs is illustrated in the
following diagram.
Khermosh Standards Track [Page 9]
RFC 4837 Managed Objects of EPON July 2007
Trunk Line
|
|
|
\|/
+===============================================+
| 802.1D Bridge |
+===============================================+
| MAC client1| ... |MAC client3|
+===============================================+
| MP2PE |
+===============================================+
| PHY |
=================================================
| | |
| | |
\|/ \|/ \|/
+============+ +============+ +============+
| PHY | | PHY | | PHY |
+============+ +============+ +============+
| MP2PE | | MP2PE | | MP2PE |
+============+ +============+ +============+
| MAC client | | MAC client | | MAC client |
+============+ +============+ +============+
| PHY | | PHY | | PHY |
+============+ +============+ +============+
/|\ /|\ /|\
| | |
| | |
| | |
Subscriber1 Subscriber2 Subscriber3
2.2.6. Principles of the MPCP
The EPON standard defines a media access control of an optical Access
network. The Access network has some substantial differences from
the legacy LAN for which the Ethernet was designed. The differences
lie mainly in the provisioning of the network. An Access network is
an administrated environment, with an operator providing the service
and subscribers consuming it. The operator is controlling the
network and managing its traffic. For instance, BW is controlled and
subscribers are billed for services. The MPCP protocol divides the
Ethernet interfaces into two unequal types of network units. The
first interface is an OLT interface, which is a server unit,
controlling the network. The second interface is an ONU interface,
which is a client unit, participating in the network.
Khermosh Standards Track [Page 10]
RFC 4837 Managed Objects of EPON July 2007
The OLT, which is the server unit, manages the network. The MPCP
controls the TDM transmission of the uplink. The MPCP is implemented
at the MAC control layer and the MPCP messages are MAC control
messages using the 0x8808 Ethertype. These messages are not
forwarded out of the MAC.
A concept of time must exist in the protocol in order to schedule the
uplink transmission. A timestamp, which is set by the OLT and
synchronized between the network units, is passed through the MPCP
messages. The timestamp is also used to measure the RTT of each ONU.
RTT is compensated by the OLT in the generation of the grants for the
uplink transmission. The difference of incoming timestamp to local
time allows the OLT to calculate the RTT. RTT compensation is needed
as the RTT in an Access network can have a significant value. The
standard allows the network to reach a 20 km distance, which is
equivalent to a 200 usec RTT (25 Kbytes of data).
The TDM control is done using GATE messages. These messages define,
for each ONU, the time for transmission and the length of
transmission. The RTT is reduced from the transmission time in the
GATE message to shift the transmission time of the ONU in the
opposite direction.
A scheduling algorithm at the OLT, which is not defined in the
[802.3ah], is responsible for dividing the BW and controlling the
transmission delay of each ONU according to its SLA. The MPCP
defines a closed loop operation in order for this algorithm to be
efficient. The MPCP allows the ONUs to report on the amount of BW
they require for transmission using a special REPORT message. This
allows allocating BW to an ONU only when requested, relying on the
statistical burst property of the traffic, and allowing different
peak BW for different ONUs at different times; hence, allowing
oversubscription of the BW. The REPORT message reports the amount of
data waiting in the ONU queues.
In addition, the MPCP defines a protocol of auto-discovery and
registration of ONUs.
Khermosh Standards Track [Page 11]
RFC 4837 Managed Objects of EPON July 2007
The registration process is defined in the diagram below:
OLT ONU
| |
| Discovery Gate message \|
|--------------------------------------------|
| /|
| |
|/ Register Request message |
|--------------------------------------------|
|\ |
| |
| Register message |
| (assigning LLID) \|
|--------------------------------------------|
| /|
| |
| Gate message \|
|--------------------------------------------|
| /|
| |
|/ Register ACK message |
|--------------------------------------------|
|\ |
| |
| |
A new ONU requests to register (sends a REG_REQUEST message) in a
special discovery grant, allocated for that by the OLT. During that
time, more than one ONU might try to register. A collision in
transmission might occur, as the RTT of the new ONUs is not yet
known. A random backoff mechanism of the transmission is used to
schedule the following registration requests to avoid these
collisions. When the OLT receives a REG_REQUEST message of an ONU
and approves this ONU, then it sends a REGISTER message to this ONU
defining its LLID. From that point, the ONU transmission is
scheduled by its LLID, knowing the RTT, and no collision can occur.
The ONU replies with a REGISTER_ACK message and the registration
process of the MPCP ends. Higher layer protocols may be needed to
authenticate the ONU and allow it to participate in the network.
2.2.7. Forward Error Correction (FEC)
The FEC is defined to enhance the link budget of the PON. As each
splitter attenuates the optical signal, the number of the splits and
the distance are limited by the link budget. Hence an FEC that
Khermosh Standards Track [Page 12]
RFC 4837 Managed Objects of EPON July 2007
improves the link budget has a benefit. The FEC code used is the
RS(239,255,8), similar to the FEC code in [ITU-T.G.975], improving
the BER from 1E-4 to 1E-12.
The FEC parity encapsulation is based on the framing of the Ethernet
packet. The Ethernet packets are spaced by MAC rate adaptation, and
the parity bytes are inserted after the packet in the provided space.
As the start and end of packet codewords also define the FEC
boundaries, and they are outside the FEC protection, they are
replaced by a series of symbols to reduce their vulnerability to
errors.
The following diagram presents an FEC-protected frame:
+-------------------------------------------------------------------+
| | | | | | | |
| S_FEC | Preamble/SFD | Frame | FCS | T_FEC | Parity | T_FEC |
| | | | | | | |
+-------------------------------------------------------------------+
The FEC is added in a separate layer between the PCS and PMA layers
of the [802.3].
The FEC layer introduces a fixed delay in receive path and transmit
path.
The FEC layer is optional.
2.3. Management Architecture
Each one of the EPON layers is accompanied by a management interface
that is controlled through clause 30 of the [802.3ah]. As the
[802.3ah] specification may be used for different applications, and
some of the clauses may be used separately, the IEEE management
clause allocates for each one of them a separate package. The MIB
document follows this partition.
Khermosh Standards Track [Page 13]
RFC 4837 Managed Objects of EPON July 2007
The following diagram presents the relation of the MIB groups to the
[802.3ah] layers:
+===========================+
| Higher layers |
+===========================+
| 802.1D Bridge |
+===========================+
|MAC client| ... |MAC client|
+===========================+ \ +=============================+
| MAC Control - (MPCP) |----- |MpcpObjects| ... |MpcpObjects|
+===========================+ / +=============================+
| MAC | ... | MAC |
+===========================+ \ +=============================+
| P2P Emulation (P2PE) |----- |OmpEmulat | |OmpEmulat |
+===========================+ / |ionObjects | ... |ionObjects |
| | +=============================+
| GMII |
| |
+===========================+
| PCS |
+===========================+ \ +=============================+
| FEC |----- |FecObjects | ... |FecObjects |
+===========================+ / +=============================+
| PMA |
+===========================+
| PMD |
+===========================+
| |
| MDI |
| |
/===============/
/ Media /
/===============/
The association is straightforward for the ONU interface. There is
one logical and one physical interface, and a single copy exists for
each layer that can be remotely queried by the OLT.
At the OLT there is a single physical interface and N virtual
interfaces for the virtual links of the ONUs (and another virtual
interface for the broadcast virtual link). As can be seen from the
layering diagram above, the MAC layer is virtually duplicated.
Therefore, in this document it was selected that the management of a
virtual interface is like a physical interface, an interface index is
allocated for each one of the virtual links, and an additional
interface index is allocated for the OLT.
Khermosh Standards Track [Page 14]
RFC 4837 Managed Objects of EPON July 2007
To illustrate the interface modeling consider two devices; the first
device has two physical interfaces, is typically located at a
consumer's site, and is called an "ONU modem".
An "ONU modem" is shown in the figure below:
--------
ONU interface | ONU | 10 megabit interface
--------------| modem |--------------------
---------
This device would have 3 entries in the IF table, and one IF stack
entry; for example:
ifIndex=1 - interface for 10 megabit interface
ifIndex=2 - interface for the optical interface
ifIndex=200 - interface for the ONU interface
And then in the IF stack table:
ifStackHigherLayer=200, ifStackLowerLayer=2 - map between the
physical and the ONU
The second device has three physical interfaces, is typically located
at the provider's site, and may be called a "headend".
A "headend" is shown in the figure below:
---------
1st OLT interface | Head | gigE interface
------------------| end |--------------------
| |
------------------| |
2nd OLT interface | |
---------
Khermosh Standards Track [Page 15]
RFC 4837 Managed Objects of EPON July 2007
This device would have 5 entries (when there are no attached ONUs) in
the IF table, for example:
ifIndex=1 - interface for gigE interface
ifIndex=2 - interface for 1st optical interface
ifIndex=3 - interface for 2nd optical interface
ifIndex=265535 - interface for the 1st OLT broadcast interface
ifIndex=365535 - interface for the 2nd OLT broadcast interface
And then in the IF stack table:
ifStackHigherLayer=265535, ifStackLowerLayer=2 - map between the 1st
physical and its broadcast interface
ifStackHigherLayer=365535, ifStackLowerLayer=3 - map between the 2nd
physical and its broadcast interface
If two ONUs connected to the first OLT interface, then for example,
the following entries would be added to the IF table:
ifIndex=200001 - interface for the 1st ONU of 1st OLT
ifIndex=200002 - interface for the 2nd ONU of 1st OLT
And in the IF stack table:
ifStackHigherLayer=200001, ifStackLowerLayer=2 - map between the 1st
physical and 1st ONU
ifStackHigherLayer=200002, ifStackLowerLayer=2 - map between the 1st
physical and 2nd ONU
For each physical interface, there would be an entry (ifIndex) in the
tables of the interface MIB module [RFC2863], MAU MIB module
[RFC4836], and Etherlike MIB module [RFC3635]. Additionally, there
would be entries (ifIndexes) for the virtual interfaces of the OLT
interface. The justification for the additional allocation of
indexes is that the virtual interfaces are quite well distinguished,
as they connect different physical ONUs from the OLT side. For
instance, there is a meaning for separate bad frames counter or bad
octets counter for each virtual link, as the ONUs can be differently
distanced. This is quite similar to a case of separate physical
interfaces.
Khermosh Standards Track [Page 16]
RFC 4837 Managed Objects of EPON July 2007
The same partition concept exists for the MIB module of this
document. Each row in the tables are indexed according to the
ifIndex; specifically, there is a row for each virtual link. There
are some control objects that are shared and are the same for the
virtual interfaces (and they should have the same value for each
ifIndex), but most of the objects have different values for N+1
logical interfaces at the OLT. This is done for each MIB group. It
is a bit different from the [802.3ah] layering diagram, which
presents the P2MP layer as a single layer, while duplicating the MAC
and MAC client layers (please see the diagram above). However, from
a management perspective, it is more convenient and neat to partition
the management of the layers for the virtual links, as the atomic
managed entity is the virtual link. It is also convenient to use the
interface index of the virtual link for that purpose, as it is
already used to index the rows of the virtual links at the Interface,
MAU, and etherLike interfaces MIBs.
3. MIB Structure
This document defines the DOT3 EPON MIB module. The DOT3 EPON MIB
module defines the objects used for management of the [802.3ah]
Point-to-Multipoint (P2MP) interfaces. These MIB objects are
included in four groups.
i) The Multi-Point Control Protocol (MPCP) MIB objects - MIB objects
related to [802.3ah], clause 64, Multi-Point Control Protocol
attributes. The following tables are presented in this group:
The dot3MpcpControlTable defines the objects used for the
configuration and status indication, which are per logical link, of
MPCP compliant interfaces.
The dot3MpcpStatTable defines the statistics objects that are per
logical link, of MPCP compliant interfaces.
The operational mode of an OLT/ONU for the tables is defined by the
dot3MpcpMode object in the dot3MpcpControlTable.
ii) The OMPEmulation MIB objects - MIB objects related to [802.3ah],
clause 65, point-to-point emulation attributes. The following tables
are presented in this group:
The dot3OmpEmulationTable defines the objects used for the
configuration and status indication, which are per logical links, of
OMPEmulation compliant interfaces.
The dot3OmpEmulationStatTable defines the statistics objects that are
per logical link, of OMPEmulation compliant interfaces.
Khermosh Standards Track [Page 17]
RFC 4837 Managed Objects of EPON July 2007
The operational mode of an OLT/ONU for the tables is defined by the
dot3OmpEmulationType object in the dot3OmpEmulationTable.
iii) The FEC MIB objects - MIB objects related to [802.3ah], clause
60 and clause 65, EPON FEC attributes. The following table is
presented in this group:
The dot3EponFecTable defines the objects used for the configuration
and status indication, which are per logical link, of FEC EPON
compliant interfaces.
iv) The EPON extended package MIB objects - MIB objects used for
configuration and status indication with extended capabilities of the
EPON interfaces. The following tables are presented in this group:
The dot3ExtPkgControlTable defines the objects, which are per logical
link, used for the configuration and status indication of EPON
compliant interfaces.
The dot3ExtPkgQueueTable defines the objects, which are per logical
link, and per queue, used for the configuration and status indication
of the ONU queues reported in the MPCP REPORT message, of EPON
compliant interfaces.
The dot3ExtPkgQueueSetsTable defines the objects, which are per
logical link, per queue, and per queue_set, used for the
configuration and status indication of the ONU queue_sets reported in
the MPCP REPORT message, of EPON compliant interfaces.
The dot3ExtPkgOptIfTable defines the objects, which are per logical
link, used for the control and status indication of the optical
interface of EPON compliant interfaces.
As described in the architecture section, each row in the tables is
indexed according to the ifIndex; specifically, there is a row for
each virtual link. There are a few control objects that are shared
and have the same value for the virtual interfaces (and they should
have the same value for each ifIndex), but most of the objects have
different values for N+1 logical interfaces at the OLT. This is done
for each MIB group. It is a bit different from the [802.3ah]
layering diagram, which presents the P2MP layer as a single layer
while duplicating the MAC and MAC client layers. However, from a
management perspective, it is more convenient and neat to partition
the management of the layers for the virtual links, as the atomic
managed entity is the virtual link. It is also convenient to use the
interface index of the virtual link for that purpose, as it is
already used to index the rows of the virtual links at the Interface,
MAU, and etherLike interfaces MIBs.
Khermosh Standards Track [Page 18]
RFC 4837 Managed Objects of EPON July 2007
For example, provided below are the values of the MPCP control table
of an OLT with 3 registered ONUs:
The table below presents the MPCP control table of ONU1 in working
mode. A single row exists in the table.
+---------------------------+-----------------+
| MPCP control MIB object | Value |
+---------------------------+-----------------+
| ifIndex | 100 |
| dot3MpcpOperStatus | true |
| dot3MpcpAdminState | true |
| dot3MpcpMode | onu |
| dot3MpcpSyncTime | 25 |
| dot3MpcpLinkID | 1 |
| dot3MpcpRemoteMACAddress | OLT_MAC_Address |
| dot3MpcpRegistrationState | registered |
| dot3MpcpTransmitElapsed | 10 |
| dot3MpcpReceiveElapsed | 10 |
| dot3MpcpRoundTripTime | 100 |
+---------------------------+-----------------+
Table 1
OLT_MAC_Address is the MAC address of the OLT EPON interface.
The creation of the rows of the ONU interface is done at
initialization.
For example, provided below are the values for the MPCP control table
of the ONU, after initialization, before registration.
Khermosh Standards Track [Page 19]
RFC 4837 Managed Objects of EPON July 2007
The table below presents the MPCP control table of ONU1 after
initialization. A single row exists in the table.
+---------------------------+-------------------+
| MPCP control MIB object | Value |
+---------------------------+-------------------+
| ifIndex | 100 |
| dot3MpcpOperStatus | true |
| dot3MpcpAdminState | true |
| dot3MpcpMode | onu |
| dot3MpcpSyncTime | 0 |
| dot3MpcpLinkID | 0 |
| dot3MpcpRemoteMACAddress | 00:00:00:00:00:00 |
| dot3MpcpRegistrationState | unregistered |
| dot3MpcpTransmitElapsed | 0 |
| dot3MpcpReceiveElapsed | 0 |
| dot3MpcpRoundTripTime | 0 |
+---------------------------+-------------------+
Table 2
Khermosh Standards Track [Page 20]
RFC 4837 Managed Objects of EPON July 2007
The table below presents the MPCP control table of the OLT in working
mode. Four rows exist in the table associated with the virtual
links.
+----------------+-----------+------------+------------+------------+
| MPCP control | Value | Value | Value | Value |
| MIB object | | | | |
+----------------+-----------+------------+------------+------------+
| ifIndex | 100001 | 100002 | 100003 | 165535 |
| dot3MpcpOperSt | true | true | true | true |
| atus | | | | |
| dot3MpcpAdminS | true | true | true | true |
| tate | | | | |
| dot3MpcpMode | olt | olt | olt | olt |
| dot3MpcpSyncTi | 25 | 25 | 25 | 25 |
| me | | | | |
| dot3MpcpLinkID | 1 | 2 | 3 | 65535 |
| dot3MpcpRemote | ONU1_MAC_ | ONU2_MAC_A | ONU3_MAC_A | BRCT_MAC_A |
| MACAddress | Address | ddress | ddress | ddress |
| dot3MpcpRegist | registere | registered | registered | registered |
| rationState | d | | | |
| dot3MpcpTransm | 10 | 10 | 10 | 10 |
| itElapsed | | | | |
| dot3MpcpReceiv | 10 | 10 | 10 | 10 |
| eElapsed | | | | |
| dot3MpcpRoundT | 100 | 60 | 20 | 0 |
| ripTime | | | | |
+----------------+-----------+------------+------------+------------+
Table 3
ONU1_MAC_Address is the MAC address of ONU1 EPON interface.
ONU2_MAC_Address is the MAC address of ONU2 EPON interface.
ONU3_MAC_Address is the MAC address of ONU3 EPON interface.
BRCT_MAC_Address is the MAC address of the broadcast EPON interface,
which is the OLT MAC address.
The creation of the rows of the OLT interface and the broadcast
virtual interface is done at initialization.
The creation of rows of the virtual interfaces at the OLT is done
when the link is established (ONU registers) and the deletion is done
when the link is deleted (ONU deregisters).
Khermosh Standards Track [Page 21]
RFC 4837 Managed Objects of EPON July 2007
For example, provided below are the values of the MPCP control table
of the OLT after initialization, before the ONUs register.
The table below presents the MPCP control table of the OLT after
initialization. A single row exists in this table associated with
the virtual broadcast link.
+---------------------------+------------------+
| MPCP control MIB object | Value |
+---------------------------+------------------+
| ifIndex | 165535 |
| dot3MpcpOperStatus | true |
| dot3MpcpAdminState | true |
| dot3MpcpMode | olt |
| dot3MpcpSyncTime | 25 |
| dot3MpcpLinkID | 65535 |
| dot3MpcpRemoteMACAddress | BRCT_MAC_Address |
| dot3MpcpRegistrationState | registered |
| dot3MpcpTransmitElapsed | 10 |
| dot3MpcpReceiveElapsed | 100000 |
| dot3MpcpRoundTripTime | 0 |
+---------------------------+------------------+
Table 4
BRCT_MAC_Address is the MAC address of the broadcast EPON interface,
which is the OLT MAC address.
4. Relation to Other MIB Modules
4.1. Relation to the Interfaces MIB and Ethernet-like Interfaces MIB
EPON interface is a kind of Ether-like interface. This MIB module
extends the objects of the Interface MIB and the Ether-like
Interfaces MIB for an EPON type interface.
Implementing this module therefore MUST require implementation of the
Interfaces MIB module [RFC2863] and the Ethernet-like Interfaces MIB
module [RFC3635].
Thus, each managed EPON interface would have a corresponding entry in
the mandatory tables of the Ether-like MIB module found in [RFC3635],
and likewise in the tables of the Interface MIB module found in
[RFC2863]. Also each managed virtual EPON interface would have a
corresponding entry in the mandatory tables of the Ether-like MIB
module found in [RFC3635], and likewise in the tables of the
Interface MIB module found in [RFC2863] with a dedicated ifIndex for
this interface.
Khermosh Standards Track [Page 22]
RFC 4837 Managed Objects of EPON July 2007
In this document, there is no replication of the objects from these
MIBs. Therefore, for instance, the document is defining
dot3MpcpRemoteMACAddress only while assuming that the local MAC
address object is already defined in [RFC3635].
The interface MIB module [RFC2863] defines the interface index
(ifIndex). Interface Index, as specified in [RFC2863], is used in
this MIB Module as an index to the EPON MIB tables. The ifIndex is
used to denote the physical interface and the virtual link interfaces
at the OLT. The OLT interface and the virtual link interfaces are
stacked using the ifStack table defined in [RFC2863], and the
ifInvStack defined in [RFC2864]. The OLT interface is the lower
layer of all other interfaces associated with the virtual links.
This document defines the specific EPON objects of an ONU interface
and an OLT interface. Information in the tables is per LLID. The
rows in the EPON MIB tables referring to the LLIDs are denoted with
the corresponding ifIndexes of the virtual link interfaces.
Please note that each virtual interface does not have a different
physical MAC address at the OLT, as the physical interface is the
same. It is specified in the [802.3ah], Section 64.1.2. The
corresponding object of the Ether-like interface MIB is duplicated
for all the virtual interfaces.
For example, the values of the Interface MIB objects are presented in
the following tables, for an OLT with 3 registered ONUs:
Khermosh Standards Track [Page 23]
RFC 4837 Managed Objects of EPON July 2007
The table below presents the objects of the Interface MIB of an ONU
in working mode.
+----------------------+--------------------------------+
| Interface MIB object | Value |
+----------------------+--------------------------------+
| ifIndex | 1 |
| ifDescr | "interface description" |
| ifType | ethernetCsmacd (6) 1000base-Px |
| ifMtu | MTU size (1522) |
| ifSpeed | 1000000000 |
| ifPhysAddress | ONU_MAC_Address |
| ifAdminStatus | up |
| ifOperStatus | Up |
| ifLastChange | ONUup_time |
| ifInOctets | ONU_octets_number |
| ifInUcastPkts | ONU_unicast_frame_number |
| ifInNUcastPkts | ONU_non_unicast_frame_number |
| ifInDiscards | ONU_discard_frame_number |
| ifInErrors | ONU_error_frame_number |
| ifInUnknownProtos | ONU_unknown_frame_number |
| ifOutOctets | ONU_octets_number |
| ifOutUcastPkts | ONU_unicast_frame_number |
| ifOutNUcastPkts | ONU_non_unicast_frame_number |
| ifOutDiscards | ONU_discard_frame_number |
| ifOutErrors | ONU_error_frame_number |
| ifOutQLen | ONU_queue_frame_number |
+----------------------+--------------------------------+
Table 5
ONU_MAC_Address is the MAC address of the ONU EPON interface.
Khermosh Standards Track [Page 24]
RFC 4837 Managed Objects of EPON July 2007
The table below presents the objects of the Interface MIB of the ONU
interface.
+----------------------+--------------------------------+
| Interface MIB object | Value |
+----------------------+--------------------------------+
| ifIndex | 100 |
| ifDescr | "interface description" |
| ifType | ethernetCsmacd (6) 1000base-Px |
| ifMtu | MTU size (1522) |
| ifSpeed | 1000000000 |
| ifPhysAddress | ONU_MAC_Address |
| ifAdminStatus | up |
| ifOperStatus | Up |
| ifLastChange | up_time |
| ifInOctets | ONU1_octets_number |
| ifInUcastPkts | ONU1_unicast_frame_number |
| ifInNUcastPkts | ONU1_non_unicast_frame_number |
| ifInDiscards | ONU1_discard_frame_number |
| ifInErrors | ONU1_error_frame_number |
| ifInUnknownProtos | ONU1_unknown_frame_number |
| ifOutOctets | ONU1_octets_number |
| ifOutUcastPkts | ONU1_unicast_frame_number |
| ifOutNUcastPkts | ONU1_non_unicast_frame_number |
| ifOutDiscards | ONU1_discard_frame_number |
| ifOutErrors | ONU1_error_frame_number |
| ifOutQLen | ONU1_queue_frame_number |
+----------------------+--------------------------------+
Table 6
ONU_MAC_Address is the MAC address of the ONU EPON interface.
The following values will be set in the ifStack and ifInvStack tables
related to this example.
ifStackTable:
ifStackHigherLayer=100, ifStackLowerLayer=1 - map between the
physical interface and the ONU
ifInvStackTable:
ifStackLowerLayer=1, ifStackHigherLayer=100,- map between the ONU and
the physical interface
Khermosh Standards Track [Page 25]
RFC 4837 Managed Objects of EPON July 2007
The table below presents the Interface MIB objects of an OLT
interface.
+----------------------+--------------------------------+
| Interface MIB object | Value |
+----------------------+--------------------------------+
| ifIndex | 2 |
| ifDescr | "interface description" |
| ifType | ethernetCsmacd (6) 1000base-Px |
| ifMtu | MTU size (1522) |
| ifSpeed | 1000000000 |
| ifPhysAddress | OLT_MAC_Address |
| ifAdminStatus | up |
| ifOperStatus | Up |
| ifLastChange | OLTup_time |
| ifInOctets | OLT_octets_number |
| ifInUcastPkts | OLT_unicast_frame_number |
| ifInNUcastPkts | OLT_non_unicast_frame_number |
| ifInDiscards | OLT_discard_frame_number |
| ifInErrors | OLT_error_frame_number |
| ifInUnknownProtos | OLT_unknown_frame_number |
| ifOutOctets | OLT_octets_number |
| ifOutUcastPkts | OLT_unicast_frame_number |
| ifOutNUcastPkts | OLT_non_unicast_frame_number |
| ifOutDiscards | OLT_discard_frame_number |
| ifOutErrors | OLT_error_frame_number |
| ifOutQLen | OLT_queue_frame_number |
+----------------------+--------------------------------+
Table 7
OLT_MAC_Address is the MAC address of the OLT EPON interface.
Khermosh Standards Track [Page 26]
RFC 4837 Managed Objects of EPON July 2007
The table below presents the Interface MIB objects of an OLT
interface, associated with the virtual link interfaces.
+----------+-------------+-------------+-------------+--------------+
| Interfac | Value | Value | Value | Value |
| eMIB | | | | |
| object | | | | |
+----------+-------------+-------------+-------------+--------------+
| ifIndex | 200001 | 200002 | 200003 | 265535 |
| ifDescr | "interface | "interface | "interface | "interface |
| | description | description | description | description" |
| | " | " | " | |
| ifType | ethernetCsm | ethernetCsm | ethernetCsm | ethernetCsma |
| | acd (6) | acd (6) | acd (6) | cd (6) |
| ifMtu | MTUsize(152 | MTUsize(152 | MTUsize(152 | MTUsize(1522 |
| | 2) | 2) | 2) | ) |
| ifSpeed | 1000000000 | 1000000000 | 1000000000 | 1000000000 |
| ifPhysAd | OLT_MAC_Add | OLT_MAC_Add | OLT_MAC_Add | OLT_MAC_Addr |
| dress | ress | ress | ress | ess |
| ifAdminS | up | up | up | up |
| tatus | | | | |
| ifOperSt | Up | Up | Up | Up |
| atus | | | | |
| ifLastCh | ONU1_up_tim | ONU2_up_tim | ONU3_up_tim | up_time |
| ange | e | e | e | |
| ifInOcte | ONU1_octets | ONU2_octets | ONU3_octets | BRCT_octets_ |
| ts | _number | _number | _number | number |
| ifInUcas | ONU1_unic_f | ONU2_unic_f | ONU3_unic_f | BRCT_unic_fr |
| tPkts | rame_num | rame_num | rame_num | ame_num |
| ifInNUca | ONU1_non_un | ONU2_non_un | ONU3_non_un | BRCT_non_uni |
| stPkts | ic_frame_nu | ic_frame_nu | ic_frame_nu | c_frame_num |
| | m | m | m | |
| ifInDisc | ONU1_disc_f | ONU2_disc_f | ONU3_disc_f | BRCT_disc_fr |
| ards | rame_num | rame_num | rame_num | ame_numr |
| ifInErro | ONU1_err_fr | ONU2_err_fr | ONU3_err_fr | BRCT_err_fra |
| rs | ame_num | ame_num | ame_num | me_num |
| ifInUnkn | ONU1_unknw_ | ONU2_unknw_ | ONU3_unknw_ | BRCT_unknw_f |
| ownProto | frame_num | frame_num | frame_num | rame_num |
| s | | | | |
| ifOutOct | ONU1_octets | ONU2_octets | ONU3_octets | BRCT_octets_ |
| ets | _number | _number | _number | number |
| ifOutUca | ONU1_unic_f | ONU2_unic_f | ONU3_unic_f | BRCT_unic_fr |
| stPkts | rame_num | rame_num | rame_num | ame_num |
| ifOutNUc | ONU1_non_un | ONU2_non_un | ONU3_non_un | BRCT_non_uni |
| astPkts | ic_frame_nu | ic_frame_nu | ic_frame_nu | c_frame_num |
| | m | m | m | |
Khermosh Standards Track [Page 27]
RFC 4837 Managed Objects of EPON July 2007
+----------+-------------+-------------+-------------+--------------+
| Interfac | Value | Value | Value | Value |
| eMIB | | | | |
| object | | | | |
+----------+-------------+-------------+-------------+--------------+
| ifOutDis | ONU1_disc_f | ONU2_disc_f | ONU3_disc_f | BRCT_disc_fr |
| cards | rame_num | rame_num | rame_num | ame_num |
| ifOutErr | ONU1_err_fr | ONU2_err_fr | ONU3_err_fr | BRCT_err_fra |
| ors | ame_num | ame_num | ame_num | me_num |
| ifOutQLe | ONU1_queue_ | ONU2_queue_ | ONU3_queue_ | BRCt_queue_f |
| n | frame_num | frame_num | frame_num | rame_num |
+----------+-------------+-------------+-------------+--------------+
Table 8
OLT_MAC_Address is the MAC address of the OLT EPON interface.
The following values will be set in the ifStack and ifInvStack tables
related to this example:
ifStackTable:
ifStackHigherLayer=265535, ifStackLowerLayer=2 - map between the OLT
physical interface and its broadcast virtual interface
ifStackHigherLayer=200001, ifStackLowerLayer=2 - map between the OLT
physical interface and its virtual interface of the 1st ONU
ifStackHigherLayer=200002, ifStackLowerLayer=2 - map between the OLT
physical interface and its virtual interface of the 2nd ONU
ifStackHigherLayer=200003, ifStackLowerLayer=2 - map between the OLT
physical interface and its virtual interface of the 3rd ONU
ifInvStackTable:
ifStackLowerLayer=2, ifStackHigherLayer=265535, - map between the
broadcast interface of the OLT and the OLT physical interface
ifStackLowerLayer=2, ifStackHigherLayer=200001 - map between the OLT
virtual interface of the 1st ONU and the OLT physical interface
ifStackLowerLayer=2, ifStackHigherLayer=200002 - map between the OLT
virtual interface of the 2nd ONU and the OLT physical interface
ifStackLowerLayer=2, ifStackHigherLayer=200003 - map between the OLT
virtual interface of the 3rd ONU and the OLT physical interface
Khermosh Standards Track [Page 28]
RFC 4837 Managed Objects of EPON July 2007
The rows for the ONU interface, the OLT interface, and the OLT
broadcast interface are created in initialization.
The creation of a row for a virtual link is done when the virtual
link is established (ONU registers), and deletion is done when the
virtual link is deleted (ONU deregisters).
The EPON MIB module also extends the Interface MIB module with a set
of counters, which are specific for the EPON interface. The EPON MIB
module implements the same handling of the counters when the
operation of the interface starts or stops. The interface MIB
document describes the possible behavior of counters when an
interface is re-initialized using the ifCounterDiscontinuityTime
indicator, indicating the discontinuity of the counters. Please see
[RFC2863], Section 3.1.5, page 11 for more information. The counters
of the EPON MIB should be handled in a similar manner.
4.2. Relation to the IEEE 802.3 MAU MIBs
The MAU types of the EPON Interface are defined in the amended MAU
MIB document. This document assumes the implementation of the MAU
MIB for this purpose and does not repeat the EPON MAU types.
Therefore, implementing this module MUST require implementation of
the MAU-MIB module [RFC4836].
The handling of the ifMAU tables for the EPON case is similar to the
handling described in the former section for the Interface and Ether-
like interface MIBs. A single row exists for the ONU in the
ifMauTable. A row for each virtual link (N+1 rows) exists at the
OLT, with a separate value of ifMauIfIndex for each virtual link.
As specified above, the rows for the ONU interface, the OLT
interface, and the OLT broadcast interface are created in
initialization.
The creation of a row for a virtual link is done when the virtual
link is established (ONU registers), and deletion is done when the
virtual link is deleted (ONU deregisters).
4.3. Relation to the EFM OAM MIB
The EPON interfaces are aimed to the optical access networks and most
probably will be accompanied with the implementation of the OAM
section of the [802.3ah]. Therefore, the EFM OAM MIB module
[RFC4878] MAY be implemented when this MIB module is implemented
defining managed objects for the OAM layer that are complementary to
the EFM EPON MIB module. As the OAM is defined for a point-to-point
link it is implemented in this case using the virtual links that are
Khermosh Standards Track [Page 29]
RFC 4837 Managed Objects of EPON July 2007
defined for the P2MP network, so that an instance is held for each
Logical Link Identifier (LLID) of the EPON. The corresponding
ifIndex of the virtual link is used as the ifIndex of the tables of
the OAM MIB module for this purpose.
4.4. Relation to the Bridge MIB
It is very probable that an EPON OLT will implement a bridging
functionality above the EPON interface layer, bridging between the
EPON users and the network. Bridge functionality is specified at
[802.1d]. In this scenario, the virtual ports of the EPON are
corresponding to the virtual bridge ports. There is a direct mapping
between the bridge ports and the LLIDs, which are virtual EPON
channels.
Therefore, the bridge MIB modules ([RFC4188] and [RFC1525]) MAY be
implemented when the EFM EPON MIB module is implemented for an EPON
OLT, defining managed objects for the bridge layer.
The values of dot1dBasePortIfIndex would correspond to the ifIndex of
the virtual port (1 for LLID1, 2 for LLID2, etc.).
The broadcast virtual EPON interface of the OLT has no direct mapping
to a virtual bridge port as it is not port specific but used for
broadcast traffic.
Khermosh Standards Track [Page 30]
RFC 4837 Managed Objects of EPON July 2007
5. Mapping of IEEE 802.3ah Managed Objects
This section contains the mapping between the managed objects defined
in this document and the attributes defined in [802.3ah], clause 30.
The tables are divided into relevant groups.
oMPCP managed object class (30.3.5)
+----------------------------+-------------------------+------------+
| dot3EPON MIB module object | IEEE802.3ah attribute | Reference |
+----------------------------+-------------------------+------------+
| ifIndex | aMPCPID | 30.3.5.1.1 |
| dot3MpcpOperStatus | aMPCPAdminState | 30.3.5.1.2 |
| dot3MpcpMode | aMPCPMode | 30.3.5.1.3 |
| dot3MpcpLinkID | aMPCPLinkID | 30.3.5.1.4 |
| dot3MpcpRemoteMACAddress | aMPCPRemoteMACAddress | 30.3.5.1.5 |
| dot3MpcpRegistrationState | aMPCPRegistrationState | 30.3.5.1.6 |
| dot3MpcpMACCtrlFramesTrans | aMPCPMACCtrlFramesTrans | 30.3.5.1.7 |
| mitted | mitted | |
| dot3MpcpMACCtrlFramesRecei | aMPCPMACCtrlFramesRecei | 30.3.5.1.8 |
| ved | ved | |
| dot3MpcpTxGate | aMPCPTxGate | 30.3.5.1.9 |
| dot3MpcpTxRegAck | aMPCPTxRegAck | 30.3.5.1.1 |
| | | 0 |
| dot3MpcpTxRegister | aMPCPTxRegister | 30.3.5.1.1 |
| | | 1 |
| dot3MpcpTxRegRequest | aMPCPTxRegRequest | 30.3.5.1.1 |
| | | 2 |
| dot3MpcpTxReport | aMPCPTxReport | 30.3.5.1.1 |
| | | 3 |
| dot3MpcpRxGate | aMPCPRxGate | 30.3.5.1.1 |
| | | 4 |
| dot3MpcpRxRegAck | aMPCPRxRegAck | 30.3.5.1.1 |
| | | 5 |
| dot3MpcpRxRegister | aMPCPRxRegister | 30.3.5.1.1 |
| | | 6 |
| dot3MpcpRxRegRequest | aMPCPRxRegRequest | 30.3.5.1.1 |
| | | 7 |
| dot3MpcpRxReport | aMPCPRxReport | 30.3.5.1.1 |
| | | 8 |
| dot3MpcpTransmitElapsed | aMPCPTransmitElapsed | 30.3.5.1.1 |
| | | 9 |
| dot3MpcpReceiveElapsed | aMPCPReceiveElapsed | 30.3.5.1.2 |
| | | 0 |
| dot3MpcpRoundTripTime | aMPCPRoundTripTime | 30.3.5.1.2 |
| | | 1 |
| dot3MpcpDiscoveryWindowsSe | aMPCPDiscoveryWindowsSe | 30.3.5.1.2 |
| nt | nt | 2 |
Khermosh Standards Track [Page 31]
RFC 4837 Managed Objects of EPON July 2007
+----------------------------+-------------------------+------------+
| dot3EPON MIB module object | IEEE802.3ah attribute | Reference |
+----------------------------+-------------------------+------------+
| dot3MpcpDiscoveryTimeout | aMPCPDiscoveryTimeout | 30.3.5.1.2 |
| | | 3 |
| dot3MpcpMaximumPendingGran | aMPCPMaximumPendingGran | 30.3.5.1.2 |
| ts | ts | 4 |
| dot3MpcpAdminState | aMPCPAdminControl | 30.3.5.2.1 |
| dot3MpcpSyncTime | SyncTime | 64.3.3.2 |
+----------------------------+-------------------------+------------+
Table 9
oOMPEmulation managed object class (30.3.7)
+-------------------------------------+-----------------+-----------+
| dot3EPON MIB module object | IEEE802.3ah | Reference |
| | attribute | |
+-------------------------------------+-----------------+-----------+
| ifIndex | aOMPEmulationID | 30.3.7.1. |
| | | 1 |
| dot3OmpEmulationType | aOMPEmulationTy | 30.3.7.1. |
| | pe | 2 |
| dot3OmpEmulationSLDErrors | aSLDErrors | 30.3.7.1. |
| | | 3 |
| dot3OmpEmulationCRC8Errors | aCRC8Errors | 30.3.7.1. |
| | | 4 |
| dot3OmpEmulationGoodLLID | aGoodLLID | 30.3.7.1. |
| | | 5 |
| dot3OmpEmulationOnuPonCastLLID | aONUPONcastLLID | 30.3.7.1. |
| | | 6 |
| dot3OmpEmulationOltPonCastLLID | aOLTPONcastLLID | 30.3.7.1. |
| | | 7 |
| dot3OmpEmulationBadLLID | aBadLLID | 30.3.7.1. |
| | | 8 |
| dot3OmpEmulationBroadcastBitNotOnuL | | |
| Lid | | |
| dot3OmpEmulationOnuLLIDNotBroadcast | | |
| dot3OmpEmulationBroadcastBitPlusOnu | | |
| Llid | | |
| dot3OmpEmulationNotBroadcastBitNotO | | |
| nuLlid | | |
+-------------------------------------+-----------------+-----------+
Table 10
Khermosh Standards Track [Page 32]
RFC 4837 Managed Objects of EPON July 2007
oMAU managed object class (30.5.1)
+--------------------------------+---------------------+------------+
| dot3EPON MIB module object | IEEE802.3ah | Reference |
| | attribute | |
+--------------------------------+---------------------+------------+
| dot3EponFecPCSCodingViolation | aPCSCodingViolation | 30.5.1.1.1 |
| | | 2 |
| dot3EponFecAbility | aFECAbility | 30.5.1.1.1 |
| | | 3 |
| dot3EponFecMode | aFECmode | 30.5.1.1.1 |
| | | 4 |
| dot3EponFecCorrectedBlocks | aFECCorrectedBlocks | 30.5.1.1.1 |
| | | 5 |
| dot3EponFecUncorrectableBlocks | aFECUncorrectableBl | 30.5.1.1.1 |
| | ocks | 6 |
| dot3EponFecBufferHeadCodingVio | | |
| lation | | |
+--------------------------------+---------------------+------------+
Table 11
6. Definitions - The DOT3 EPON MIB Module
DOT3-EPON-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, mib-2, OBJECT-TYPE, Counter32,
Integer32, Unsigned32, Counter64
FROM SNMPv2-SMI
TruthValue, MacAddress
FROM SNMPv2-TC
ifIndex
FROM IF-MIB
MODULE-COMPLIANCE, OBJECT-GROUP
FROM SNMPv2-CONF
;
dot3EponMIB MODULE-IDENTITY
LAST-UPDATED "200703290000Z" -- March 29, 2007
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
Khermosh Standards Track [Page 33]
RFC 4837 Managed Objects of EPON July 2007
In Body: subscribe your_email_address
Chair: Bert Wijnen
Postal: Lucent Technologies
Schagen 33
3461 GL Linschoten
Netherlands
Tel: +31-348-407-775
E-mail: bwijnen@lucent.com
Editor: Lior Khermosh
Postal: PMC-SIERRA
Kohav Hertzelia bldg,
4 Hasadnaot St.
Hertzliya Pituach 46120,
ISRAEL
P.O.Box 2089 Hertzliya Pituach 46120 Israel
Tel: +972-9-9628000 Ext: 302
E-mail: lior_khermosh@pmc-sierra.com"
DESCRIPTION
"The objects in this MIB module are used to manage the
Ethernet in the First Mile (EFM) Ethernet Passive Optical
Network (EPON) Interfaces as defined in IEEE P802.3ah
clauses 60, 64, and 65.
The following reference is used throughout this MIB module:
[802.3ah] refers 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 Std 802.3ah-2004, October 2004.
Of particular interest are clause 64 (Multi-Point Control
Protocol - MPCP), clause 65 (Point-to-Multipoint
Reconciliation Sublayer - P2MP RS), clause 60 (Ethernet
Passive Optical Network Physical Medium Dependent - EPON
PMDs), clause 30, 'Management', and clause 45, 'Management
Data Input/Output (MDIO) Interface'.
Copyright (C) The IETF Trust (2007). This version
of this MIB module is part of 4837; see the RFC itself for
full legal notices.
Key abbreviations:
BER - Bit Error Rate
BW - bandwidth
Khermosh Standards Track [Page 34]
RFC 4837 Managed Objects of EPON July 2007
CRC - Cyclic Redundancy Check
EFM - Ethernet First Mile
EPON - Ethernet Passive Optical Network
FEC - Forward Error Correction
LLID - Logical Link Identifier
MAC - Media Access Control
Mbps - Megabit per second
MDIO - Management Data Input/Output
MPCP - Multi-Point Control Protocol
OLT - Optical Line Terminal (Server unit of the EPON)
OMP - Optical Multi-Point
ONU - Optical Network Unit (Client unit of the EPON)
P2MP - Point-to-Multipoint
PHY - Physical Layer
PMD - Physical Medium Dependent
PON - Passive Optical Network
RTT - Round Trip Time
SLD - Start of LLID Delimiter
TQ - Time Quanta
"
REVISION "200703290000Z" -- March 29, 2007
DESCRIPTION "Initial version, published as RFC 4837."
::= { mib-2 155 }
dot3EponObjects OBJECT IDENTIFIER ::= { dot3EponMIB 1}
dot3EponConformance OBJECT IDENTIFIER ::= { dot3EponMIB 2}
-- MPCP MIB modules definitions ([802.3ah], clause 30.3.5)
dot3EponMpcpObjects
OBJECT IDENTIFIER ::= { dot3EponObjects 1 }
dot3MpcpControlTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot3MpcpControlEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A Table of dot3 Multi-Point Control Protocol (MPCP)
MIB objects. The entries in the table are control and
status objects of the MPCP.
Each object has a row for every virtual link denoted by
the corresponding ifIndex.
The LLID field, as defined in the [802.3ah], is a 2-byte
register (15-bit field and a broadcast bit) limiting the
number of virtual links to 32768. Typically the number
Khermosh Standards Track [Page 35]
RFC 4837 Managed Objects of EPON July 2007
of expected virtual links in a PON is like the number of
ONUs, which is 32-64, plus an additional entry for
broadcast LLID (with a value of 0xffff)."
::= { dot3EponMpcpObjects 1 }
dot3MpcpControlEntry OBJECT-TYPE
SYNTAX Dot3MpcpControlEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the dot3 MPCP Control table.
Rows exist for an OLT interface and an ONU interface.
A row in the table is denoted by the ifIndex of the link
and it is created when the ifIndex is created.
The rows in the table for an ONU interface are created
at system initialization.
The row in the table corresponding to the OLT ifIndex
and the row corresponding to the broadcast virtual link
are created at system initialization.
A row in the table corresponding to the ifIndex of a
virtual links is created when a virtual link is
established (ONU registers) and deleted when the virtual
link is deleted (ONU deregisters)."
INDEX { ifIndex }
::= { dot3MpcpControlTable 1}
Dot3MpcpControlEntry ::=
SEQUENCE {
dot3MpcpOperStatus TruthValue,
dot3MpcpAdminState TruthValue,
dot3MpcpMode INTEGER,
dot3MpcpSyncTime Unsigned32,
dot3MpcpLinkID Unsigned32,
dot3MpcpRemoteMACAddress MacAddress,
dot3MpcpRegistrationState INTEGER,
dot3MpcpTransmitElapsed Unsigned32,
dot3MpcpReceiveElapsed Unsigned32,
dot3MpcpRoundTripTime Unsigned32,
dot3MpcpMaximumPendingGrants Unsigned32
}
dot3MpcpOperStatus OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object reflects the operational state of the
Multi-Point MAC Control sublayer as defined in
Khermosh Standards Track [Page 36]
RFC 4837 Managed Objects of EPON July 2007
[802.3ah], clause 64. When the value is true(1), the
interface will act as if the Multi-Point Control Protocol
is enabled. When the value is false(2), the interface
will act as if the Multi-Point Control Protocol is
disabled. The operational state can be changed using the
dot3MpcpAdminState object.
This object is applicable for an OLT, with the same
value for all virtual interfaces, and for an ONU."
REFERENCE "[802.3ah], 30.3.5.1.2."
::= { dot3MpcpControlEntry 1 }
dot3MpcpAdminState OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object is used to define the admin state of the
Multi-Point MAC Control sublayer, as defined in
[802.3ah], clause 64, and to reflect its state.
When selecting the value as true(1), the Multi-Point
Control Protocol of the interface is enabled.
When selecting the value as false(2), the Multi-Point
Control Protocol of the interface is disabled.
This object reflects the administrative state of the
Multi-Point Control Protocol of the interface.
The write operation is not restricted in this document
and can be done at any time. Changing
dot3MpcpAdminState state can lead to disabling the
Multi-Point Control Protocol on the respective interface,
leading to the interruption of service for the users
connected to the respective EPON interface.
This object is applicable for an OLT, with the same
value for all virtual interfaces, and for an ONU."
REFERENCE "[802.3ah], 30.3.5.2.1."
DEFVAL { false }
::= { dot3MpcpControlEntry 2 }
dot3MpcpMode OBJECT-TYPE
SYNTAX INTEGER {
olt(1),
onu(2)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object is used to identify the operational
state of the Multi-Point MAC Control sublayer as
defined in [802.3ah], clause 64. Reading olt(1) for an
Khermosh Standards Track [Page 37]
RFC 4837 Managed Objects of EPON July 2007
OLT (server) mode and onu(2) for an ONU (client) mode.
This object is used to identify the operational mode
for the MPCP tables.
This object is applicable for an OLT, with the same
value for all virtual interfaces, and for an ONU."
REFERENCE "[802.3ah], 30.3.5.1.3."
DEFVAL { olt }
::= { dot3MpcpControlEntry 3 }
dot3MpcpSyncTime OBJECT-TYPE
SYNTAX Unsigned32
UNITS "TQ (16nsec)"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"An object that reports the 'sync lock time' of the
OLT receiver in increments of Time Quanta (TQ)-16ns
as defined in [802.3ah], clauses 60, 64, and 65. The
value returned shall be (sync lock time ns)/16. If
this value exceeds (2^32-1), the value (2^32-1) shall
be returned. This object is applicable for an OLT,
with the same value for all virtual interfaces, and
for an ONU."
REFERENCE "[802.3ah], 64.3.3.2."
::= { dot3MpcpControlEntry 4 }
dot3MpcpLinkID OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"An object that identifies the Logical Link
Identifier (LLID) associated with the MAC of the virtual
link as specified in [802.3ah], clause 65.1.3.2.2.
This object is applicable for an OLT and an ONU. At the
OLT, it has a distinct value for each virtual interface.
The ONU and the corresponding virtual MAC of the OLT,
for the same virtual link, have the same value.
Value is assigned when the ONU registers.
Value is freed when the ONU deregisters."
REFERENCE "[802.3ah], 30.3.5.1.4."
::= { dot3MpcpControlEntry 5 }
dot3MpcpRemoteMACAddress OBJECT-TYPE
SYNTAX MacAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
Khermosh Standards Track [Page 38]
RFC 4837 Managed Objects of EPON July 2007
"An object that identifies the source_address
parameter of the last MPCPDUs passed to the MAC Control.
This value is updated on reception of a valid frame with
1) a destination Field equal to the reserved multicast
address for MAC Control as specified in [802.3], Annex
31A; 2) the lengthOrType field value equal to the reserved
Type for MAC Control as specified in [802.3], Annex
31A; 3) an MPCP subtype value equal to the subtype
reserved for MPCP as specified in [802.3ah], Annex 31A.
This object is applicable for an OLT and an ONU. At the
OLT, it has a distinct value for each virtual interface.
The value reflects the MAC address of the remote entity
and therefore the OLT holds a value for each LLID, which
is the MAC address of the ONU; the ONU has a single
value that is the OLT MAC address."
REFERENCE "[802.3ah], 30.3.5.1.5."
::= { dot3MpcpControlEntry 6 }
dot3MpcpRegistrationState OBJECT-TYPE
SYNTAX INTEGER {
unregistered(1),
registering(2),
registered(3)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"An object that identifies the registration state
of the Multi-Point MAC Control sublayer as defined in
[802.3ah], clause 64. When this object has the
enumeration unregistered(1), the interface is
unregistered and may be used for registering a link
partner. When this object has the enumeration
registering(2), the interface is in the process of
registering a link-partner. When this object has the
enumeration registered(3), the interface has an
established link-partner.
This object is applicable for an OLT and an ONU. At the
OLT, it has a distinct value for each virtual interface."
REFERENCE "[802.3ah], 30.3.5.1.6."
::= { dot3MpcpControlEntry 7 }
dot3MpcpTransmitElapsed OBJECT-TYPE
SYNTAX Unsigned32
UNITS "TQ (16nsec)"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
Khermosh Standards Track [Page 39]
RFC 4837 Managed Objects of EPON July 2007
"An object that reports the interval from the last
MPCP frame transmission in increments of Time Quanta
(TQ)-16ns. The value returned shall be (interval from
last MPCP frame transmission in ns)/16. If this value
exceeds (2^32-1), the value (2^32-1) shall be returned.
This object is applicable for an OLT and an ONU. At the
OLT, it has a distinct value for each virtual interface."
REFERENCE "[802.3ah], 30.3.5.1.19."
::= { dot3MpcpControlEntry 8 }
dot3MpcpReceiveElapsed OBJECT-TYPE
SYNTAX Unsigned32
UNITS "TQ (16nsec)"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"An object that reports the interval from last MPCP frame
reception in increments of Time Quanta (TQ)-16ns. The
value returned shall be (interval from last MPCP frame
reception in ns)/16. If this value exceeds (2^32-1), the
value (2^32-1) shall be returned.
This object is applicable for an OLT and an ONU. At the
OLT, it has a distinct value for each virtual interface."
REFERENCE "[802.3ah], 30.3.5.1.20."
::= { dot3MpcpControlEntry 9 }
dot3MpcpRoundTripTime OBJECT-TYPE
SYNTAX Unsigned32 (0..'ffff'h)
UNITS "TQ (16nsec)"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"An object that reports the MPCP round trip time in
increments of Time Quanta (TQ)-16ns. The value returned
shall be (round trip time in ns)/16. If this value
exceeds (2^16-1), the value (2^16-1) shall be returned.
This object is applicable for an OLT and an ONU. At the
OLT, it has a distinct value for each virtual interface."
REFERENCE "[802.3ah], 30.3.5.1.21."
::= { dot3MpcpControlEntry 10 }
dot3MpcpMaximumPendingGrants OBJECT-TYPE
SYNTAX Unsigned32 (0..255)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"An object that reports the maximum number of grants
that an ONU can store for handling. The maximum number
Khermosh Standards Track [Page 40]
RFC 4837 Managed Objects of EPON July 2007
of grants that an ONU can store for handling has a
range of 0 to 255.
This object is applicable for an OLT and an ONU. At the
OLT, it has a distinct value for each virtual interface.
At the OLT, the value should be zero."
REFERENCE "[802.3ah], 30.3.5.1.24."
::= { dot3MpcpControlEntry 11 }
dot3MpcpStatTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot3MpcpStatEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table defines the list of statistics counters of
an interface implementing the [802.3ah], clause 64 MPCP.
Each object has a row for every virtual link denoted by
the corresponding ifIndex.
The LLID field, as defined in the [802.3ah], is a 2-byte
register (15-bit field and a broadcast bit) limiting the
number of virtual links to 32768. Typically the number
of expected virtual links in a PON is like the number of
ONUs, which is 32-64, plus an additional entry for
broadcast LLID (with a value of 0xffff)."
::= { dot3EponMpcpObjects 2 }
dot3MpcpStatEntry OBJECT-TYPE
SYNTAX Dot3MpcpStatEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the table of statistics counters of the
[802.3ah], clause 64, MPCP interface.
Rows exist for an OLT interface and an ONU interface.
A row in the table is denoted by the ifIndex of the link
and it is created when the ifIndex is created.
The rows in the table for an ONU interface are created
at system initialization.
The row in the table corresponding to the OLT ifIndex
and the row corresponding to the broadcast virtual link
are created at system initialization.
A row in the table corresponding to the ifIndex of a
virtual link is created when a virtual link is
established (ONU registers) and deleted when the virtual
link is deleted (ONU deregisters)."
INDEX { ifIndex}
::= { dot3MpcpStatTable 1 }
Dot3MpcpStatEntry ::=
Khermosh Standards Track [Page 41]
RFC 4837 Managed Objects of EPON July 2007
SEQUENCE {
dot3MpcpMACCtrlFramesTransmitted Counter64,
dot3MpcpMACCtrlFramesReceived Counter64,
dot3MpcpDiscoveryWindowsSent Counter32,
dot3MpcpDiscoveryTimeout Counter32,
dot3MpcpTxRegRequest Counter64,
dot3MpcpRxRegRequest Counter64,
dot3MpcpTxRegAck Counter64,
dot3MpcpRxRegAck Counter64,
dot3MpcpTxReport Counter64,
dot3MpcpRxReport Counter64,
dot3MpcpTxGate Counter64,
dot3MpcpRxGate Counter64,
dot3MpcpTxRegister Counter64,
dot3MpcpRxRegister Counter64
}
dot3MpcpMACCtrlFramesTransmitted OBJECT-TYPE
SYNTAX Counter64
UNITS "frames"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A count of MPCP frames passed to the MAC sublayer for
transmission. This counter is incremented when a
MA_CONTROL.request service primitive is generated within
the MAC control sublayer with an opcode indicating an
MPCP frame.
This object is applicable for an OLT and an ONU. At the
OLT it has a distinct value for each virtual interface.
Discontinuities of this counter can occur at
re-initialization of the management system, and at other
times as indicated by the value of the
ifCounterDiscontinuityTime object of the Interface MIB
module."
REFERENCE "[802.3ah], 30.3.5.1.7."
::= { dot3MpcpStatEntry 1 }
dot3MpcpMACCtrlFramesReceived OBJECT-TYPE
SYNTAX Counter64
UNITS "frames"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A count of MPCP frames passed by the MAC sublayer to the
MAC Control sublayer. This counter is incremented when a
ReceiveFrame function call returns a valid frame with
1) a lengthOrType field value equal to the reserved
Khermosh Standards Track [Page 42]
RFC 4837 Managed Objects of EPON July 2007
Type for 802.3_MAC_Control as specified in clause 31.4.1.3,
and
2) an opcode indicating an MPCP frame.
This object is applicable for an OLT and an ONU. At the
OLT, it has a distinct value for each virtual interface.
Discontinuities of this counter can occur at
re-initialization of the management system and at other
times, as indicated by the value of the
ifCounterDiscontinuityTime object of the Interface MIB
module."
REFERENCE "[802.3ah], 30.3.5.1.8."
::= { dot3MpcpStatEntry 2}
dot3MpcpDiscoveryWindowsSent OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A count of discovery windows generated. The counter is
incremented by one for each generated discovery window.
This object is applicable for an OLT and an ONU. At the
OLT, it has a distinct value for each virtual interface.
At the ONU, the value should be zero.
Discontinuities of this counter can occur at
re-initialization of the management system and at other
times, as indicated by the value of the
ifCounterDiscontinuityTime object of the Interface MIB
module."
REFERENCE "[802.3ah], 30.3.5.1.22."
::= { dot3MpcpStatEntry 3}
dot3MpcpDiscoveryTimeout OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A count of the number of times a discovery timeout
occurs. Increment the counter by one for each discovery
processing state-machine reset resulting from timeout
waiting for message arrival.
This object is applicable for an OLT and an ONU. At the
OLT, it has a distinct value for each virtual interface.
Discontinuities of this counter can occur at
re-initialization of the management system and at other
times, as indicated by the value of the
ifCounterDiscontinuityTime object of the Interface MIB
module."
REFERENCE "[802.3ah], 30.3.5.1.23."
Khermosh Standards Track [Page 43]
RFC 4837 Managed Objects of EPON July 2007
::= { dot3MpcpStatEntry 4}
dot3MpcpTxRegRequest OBJECT-TYPE
SYNTAX Counter64
UNITS "frames"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A count of the number of times a REGISTER_REQ MPCP
frame transmission occurs. Increment the counter by one
for each REGISTER_REQ MPCP frame transmitted as defined
in [802.3ah], clause 64.
This object is applicable for an OLT and an ONU. At the
OLT, it has a distinct value for each virtual interface.
At the OLT, the value should be zero.
Discontinuities of this counter can occur at
re-initialization of the management system and at other
times, as indicated by the value of the
ifCounterDiscontinuityTime object of the Interface MIB
module."
REFERENCE "[802.3ah], 30.3.5.1.12."
::= { dot3MpcpStatEntry 5}
dot3MpcpRxRegRequest OBJECT-TYPE
SYNTAX Counter64
UNITS "frames"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A count of the number of times a REGISTER_REQ MPCP
frame reception occurs.
Increment the counter by one for each REGISTER_REQ MPCP
frame received as defined in [802.3ah], clause 64.
This object is applicable for an OLT and an ONU. At the
OLT, it has a distinct value for each virtual interface.
At the ONU, the value should be zero.
Discontinuities of this counter can occur at
re-initialization of the management system and at other
times, as indicated by the value of the
ifCounterDiscontinuityTime object of the Interface MIB
module."
REFERENCE "[802.3ah], 30.3.5.1.17."
::= { dot3MpcpStatEntry 6}
dot3MpcpTxRegAck OBJECT-TYPE
SYNTAX Counter64
UNITS "frames"
MAX-ACCESS read-only
Khermosh Standards Track [Page 44]
RFC 4837 Managed Objects of EPON July 2007
STATUS current
DESCRIPTION
"A count of the number of times a REGISTER_ACK MPCP
frame transmission occurs. Increment the counter by one
for each REGISTER_ACK MPCP frame transmitted as defined
in [802.3ah], clause 64.
This object is applicable for an OLT and an ONU. At the
OLT, it has a distinct value for each virtual interface.
At the OLT, the value should be zero.
Discontinuities of this counter can occur at
re-initialization of the management system and at other
times, as indicated by the value of the
ifCounterDiscontinuityTime object of the Interface MIB
module."
REFERENCE "[802.3ah], 30.3.5.1.10."
::= { dot3MpcpStatEntry 7}
dot3MpcpRxRegAck OBJECT-TYPE
SYNTAX Counter64
UNITS "frames"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A count of the number of times a REGISTER_ACK MPCP
frame reception occurs.
Increment the counter by one for each REGISTER_ACK MPCP
frame received as defined in [802.3ah], clause 64.
This object is applicable for an OLT and an ONU. At the
OLT, it has a distinct value for each virtual interface.
At the ONU, the value should be zero.
Discontinuities of this counter can occur at
re-initialization of the management system and at other
times, as indicated by the value of the
ifCounterDiscontinuityTime object of the Interface MIB
module."
REFERENCE "[802.3ah], 30.3.5.1.15."
::= { dot3MpcpStatEntry 8}
dot3MpcpTxReport OBJECT-TYPE
SYNTAX Counter64
UNITS "frames"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A count of the number of times a REPORT MPCP frame
transmission occurs. Increment the counter by one for
each REPORT MPCP frame transmitted as defined in
[802.3ah], clause 64.
Khermosh Standards Track [Page 45]
RFC 4837 Managed Objects of EPON July 2007
This object is applicable for an OLT and an ONU. At the
OLT, it has a distinct value for each virtual interface.
At the OLT, the value should be zero.
Discontinuities of this counter can occur at
re-initialization of the management system and at other
times, as indicated by the value of the
ifCounterDiscontinuityTime object of the Interface MIB
module."
REFERENCE "[802.3ah], 30.3.5.1.13."
::= { dot3MpcpStatEntry 9}
dot3MpcpRxReport OBJECT-TYPE
SYNTAX Counter64
UNITS "frames"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A count of the number of times a REPORT MPCP frame
reception occurs.
Increment the counter by one for each REPORT MPCP frame
received as defined in [802.3ah], clause 64.
This object is applicable for an OLT and an ONU. At the
OLT, it has a distinct value for each virtual interface.
At the ONU, the value should be zero.
Discontinuities of this counter can occur at
re-initialization of the management system and at other
times, as indicated by the value of the
ifCounterDiscontinuityTime object of the Interface MIB
module."
REFERENCE "[802.3ah], 30.3.5.1.18."
::= { dot3MpcpStatEntry 10}
dot3MpcpTxGate OBJECT-TYPE
SYNTAX Counter64
UNITS "frames"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A count of the number of times a GATE MPCP frame
transmission occurs.
Increment the counter by one for each GATE MPCP frame
transmitted as defined in [802.3ah], clause 64.
This object is applicable for an OLT and an ONU. At the
OLT, it has a distinct value for each virtual interface.
At the ONU, the value should be zero.
Discontinuities of this counter can occur at
re-initialization of the management system and at other
times, as indicated by the value of the
Khermosh Standards Track [Page 46]
RFC 4837 Managed Objects of EPON July 2007
ifCounterDiscontinuityTime object of the Interface MIB
module."
REFERENCE "[802.3ah], 30.3.5.1.9."
::= { dot3MpcpStatEntry 11}
dot3MpcpRxGate OBJECT-TYPE
SYNTAX Counter64
UNITS "frames"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A count of the number of times a GATE MPCP frame
reception occurs.
Increment the counter by one for each GATE MPCP frame
received as defined in [802.3ah], clause 64.
This object is applicable for an OLT and an ONU. At the
OLT, it has a distinct value for each virtual interface.
At the OLT, the value should be zero.
Discontinuities of this counter can occur at
re-initialization of the management system and at other
times, as indicated by the value of the
ifCounterDiscontinuityTime object of the Interface MIB
module."
REFERENCE "[802.3ah], 30.3.5.1.14."
::= { dot3MpcpStatEntry 12}
dot3MpcpTxRegister OBJECT-TYPE
SYNTAX Counter64
UNITS "frames"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A count of the number of times a REGISTER MPCP frame
transmission occurs.
Increment the counter by one for each REGISTER MPCP
frame transmitted as defined in [802.3ah], clause 64.
This object is applicable for an OLT and an ONU. At the
OLT, it has a distinct value for each virtual interface.
At the ONU, the value should be zero.
Discontinuities of this counter can occur at
re-initialization of the management system and at other
times, as indicated by the value of the
ifCounterDiscontinuityTime object of the Interface MIB
module."
REFERENCE "[802.3ah], 30.3.5.1.11."
::= { dot3MpcpStatEntry 13}
dot3MpcpRxRegister OBJECT-TYPE
Khermosh Standards Track [Page 47]
RFC 4837 Managed Objects of EPON July 2007
SYNTAX Counter64
UNITS "frames"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A count of the number of times a REGISTER MPCP frame
reception occurs.
Increment the counter by one for each REGISTER MPCP
frame received as defined in [802.3ah], clause 64.
This object is applicable for an OLT and an ONU. At the
OLT, it has a distinct value for each virtual interface.
At the OLT, the value should be zero.
Discontinuities of this counter can occur at
re-initialization of the management system and at other
times, as indicated by the value of the
ifCounterDiscontinuityTime object of the Interface MIB
module."
REFERENCE "[802.3ah], 30.3.5.1.16."
::= { dot3MpcpStatEntry 14}
-- Optical Multi Point Emulation (OMPEmulation)
-- managed object definitions
dot3OmpEmulationObjects OBJECT IDENTIFIER ::={dot3EponObjects 2}
dot3OmpEmulationTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot3OmpEmulationEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A table of dot3 OmpEmulation MIB objects. The table
contain objects for the management of the OMPEmulation
sublayer.
Each object has a row for every virtual link denoted by
the corresponding ifIndex.
The LLID field, as defined in the [802.3ah], is a 2-byte
register (15-bit field and a broadcast bit) limiting the
number of virtual links to 32768. Typically the number
of expected virtual links in a PON is like the number of
ONUs, which is 32-64, plus an additional entry for
broadcast LLID (with a value of 0xffff)."
::= { dot3OmpEmulationObjects 1 }
dot3OmpEmulationEntry OBJECT-TYPE
SYNTAX Dot3OmpEmulationEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
Khermosh Standards Track [Page 48]
RFC 4837 Managed Objects of EPON July 2007
"An entry in the dot3 OmpEmulation table.
Rows exist for an OLT interface and an ONU interface.
A row in the table is denoted by the ifIndex of the link
and it is created when the ifIndex is created.
The rows in the table for an ONU interface are created
at system initialization.
The row in the table corresponding to the OLT ifIndex
and the row corresponding to the broadcast virtual link
are created at system initialization.
A row in the table corresponding to the ifIndex of a
virtual links is created when a virtual link is
established (ONU registers) and deleted when the virtual
link is deleted (ONU deregisters)."
INDEX { ifIndex }
::= { dot3OmpEmulationTable 1 }
Dot3OmpEmulationEntry ::=
SEQUENCE {
dot3OmpEmulationType INTEGER
}
dot3OmpEmulationType OBJECT-TYPE
SYNTAX INTEGER {
unknown(1),
olt(2),
onu(3)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"An object that indicates the mode of operation
of the Reconciliation Sublayer for Point-to-Point
Emulation (see [802.3ah], clause 65.1). unknown(1) value
is assigned in initialization; true state or type is not
yet known. olt(2) value is assigned when the sublayer is
operating in OLT mode. onu(3) value is assigned when the
sublayer is operating in ONU mode.
This object is applicable for an OLT, with the same
value for all virtual interfaces, and for an ONU."
REFERENCE "[802.3ah], 30.3.7.1.2."
::= { dot3OmpEmulationEntry 1}
dot3OmpEmulationStatTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot3OmpEmulationStatEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table defines the list of statistics counters of
Khermosh Standards Track [Page 49]
RFC 4837 Managed Objects of EPON July 2007
[802.3ah], clause 65, OMPEmulation sublayer.
Each object has a row for every virtual link denoted by
the corresponding ifIndex.
The LLID field, as defined in the [802.3ah], is a 2-byte
register (15-bit field and a broadcast bit) limiting the
number of virtual links to 32768. Typically the number
of expected virtual links in a PON is like the number of
ONUs, which is 32-64, plus an additional entry for
broadcast LLID (with a value of 0xffff)."
::= { dot3OmpEmulationObjects 2}
dot3OmpEmulationStatEntry OBJECT-TYPE
SYNTAX Dot3OmpEmulationStatEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the table of statistics counters of
[802.3ah], clause 65, OMPEmulation sublayer.
Rows exist for an OLT interface and an ONU interface.
A row in the table is denoted by the ifIndex of the link
and it is created when the ifIndex is created.
The rows in the table for an ONU interface are created
at system initialization.
The row in the table corresponding to the OLT ifIndex
and the row corresponding to the broadcast virtual link
are created at system initialization.
A row in the table corresponding to the ifIndex of a
virtual links is created when a virtual link is
established (ONU registers) and deleted when the virtual
link is deleted (ONU deregisters)."
INDEX { ifIndex}
::= { dot3OmpEmulationStatTable 1 }
Dot3OmpEmulationStatEntry::=
SEQUENCE {
dot3OmpEmulationSLDErrors Counter64,
dot3OmpEmulationCRC8Errors Counter64,
dot3OmpEmulationBadLLID Counter64,
dot3OmpEmulationGoodLLID Counter64,
dot3OmpEmulationOnuPonCastLLID Counter64,
dot3OmpEmulationOltPonCastLLID Counter64,
dot3OmpEmulationBroadcastBitNotOnuLlid Counter64,
dot3OmpEmulationOnuLLIDNotBroadcast Counter64,
dot3OmpEmulationBroadcastBitPlusOnuLlid Counter64,
dot3OmpEmulationNotBroadcastBitNotOnuLlid Counter64
}
dot3OmpEmulationSLDErrors OBJECT-TYPE
Khermosh Standards Track [Page 50]
RFC 4837 Managed Objects of EPON July 2007
SYNTAX Counter64
UNITS "frames"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A count of frames received that do not contain a valid
SLD field as defined in [802.3ah], clause 65.1.3.3.1.
This object is applicable for an OLT and an ONU. At the
OLT, it has a distinct value for each virtual interface.
Discontinuities of this counter can occur at
re-initialization of the management system and at other
times, as indicated by the value of the
ifCounterDiscontinuityTime object of the Interface MIB
module."
REFERENCE "[802.3ah], 30.3.7.1.3."
::= { dot3OmpEmulationStatEntry 1}
dot3OmpEmulationCRC8Errors OBJECT-TYPE
SYNTAX Counter64
UNITS "frames"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A count of frames received that contain a valid SLD
field, as defined in [802.3ah], clause 65.1.3.3.1, but do
not pass the CRC-8 check as defined in [802.3ah], clause
65.1.3.3.3.
This object is applicable for an OLT and an ONU. At the
OLT, it has a distinct value for each virtual interface.
Discontinuities of this counter can occur at
re-initialization of the management system and at other
times, as indicated by the value of the
ifCounterDiscontinuityTime object of the Interface MIB
module."
REFERENCE "[802.3ah], 30.3.7.1.4."
::= { dot3OmpEmulationStatEntry 2}
dot3OmpEmulationBadLLID OBJECT-TYPE
SYNTAX Counter64
UNITS "frames"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A count of frames received that contain a valid SLD
field, as defined in [802.3ah], clause 65.1.3.3.1, and
pass the CRC-8 check, as defined in [802.3ah], clause
65.1.3.3.3, but are discarded due to the LLID check as
defined in [802.3ah], clause 65.1.3.3.2.
Khermosh Standards Track [Page 51]
RFC 4837 Managed Objects of EPON July 2007
This object is applicable for an OLT and an ONU. At the
OLT, it has a distinct value for each virtual interface.
Discontinuities of this counter can occur at
re-initialization of the management system and at other
times, as indicated by the value of the
ifCounterDiscontinuityTime object of the Interface MIB
module."
REFERENCE "[802.3ah], 30.3.7.1.8."
::= { dot3OmpEmulationStatEntry 3}
dot3OmpEmulationGoodLLID OBJECT-TYPE
SYNTAX Counter64
UNITS "frames"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A count of frames received that contain a valid SLD
field, as defined in [802.3ah], clause 65.1.3.3.1, and
pass the CRC-8 check as defined in [802.3ah], clause
65.1.3.3.3.
This object is applicable for an OLT and an ONU. At the
OLT, it has a distinct value for each virtual interface.
Discontinuities of this counter can occur at
re-initialization of the management system and at other
times, as indicated by the value of the
ifCounterDiscontinuityTime object of the Interface MIB
module."
REFERENCE "[802.3ah], 30.3.7.1.5."
::= { dot3OmpEmulationStatEntry 4}
dot3OmpEmulationOnuPonCastLLID OBJECT-TYPE
SYNTAX Counter64
UNITS "frames"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A count of frames received that contain a valid SLD
field, as defined in [802.3ah], clause 65.1.3.3.1,
pass the CRC-8 check, as defined in [802.3ah], clause
65.1.3.3.3, and meet the rules of acceptance for an
ONU defined in [802.3ah], clause 65.1.3.3.2.
This object is applicable for an OLT and an ONU. At the
OLT, it has a distinct value for each virtual interface.
At the OLT, the value should be zero.
Discontinuities of this counter can occur at
re-initialization of the management system and at other
times, as indicated by the value of the
ifCounterDiscontinuityTime object of the Interface MIB
Khermosh Standards Track [Page 52]
RFC 4837 Managed Objects of EPON July 2007
module."
REFERENCE "[802.3ah], 30.3.7.1.6."
::= { dot3OmpEmulationStatEntry 5}
dot3OmpEmulationOltPonCastLLID OBJECT-TYPE
SYNTAX Counter64
UNITS "frames"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A count of frames received that contain a valid SLD
field, as defined in [802.3ah], clause 65.1.3.3.1,
pass the CRC-8 check, as defined in [802.3ah], clause
65.1.3.3.3, and meet the rules of acceptance for an
OLT defined in [802.3ah], 65.1.3.3.2.
This object is applicable for an OLT and an ONU. At the
OLT, it has a distinct value for each virtual interface.
At the ONU, the value should be zero.
Discontinuities of this counter can occur at
re-initialization of the management system and at other
times, as indicated by the value of the
ifCounterDiscontinuityTime object of the Interface MIB
module."
REFERENCE "[802.3ah], 30.3.7.1.7."
::= { dot3OmpEmulationStatEntry 6}
dot3OmpEmulationBroadcastBitNotOnuLlid OBJECT-TYPE
SYNTAX Counter64
UNITS "frames"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A count of frames received that contain a valid SLD
field, as defined in [802.3ah], clause
65.1.3.3.1, pass the CRC-8 check, as defined in
[802.3ah |
