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.
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].
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.
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)
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.
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:
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.
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.
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.
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:
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.
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:
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:
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".
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.
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.
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.
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.
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.
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).
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.
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.
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.
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."
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}
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 }
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
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 }
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 }
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
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], clause 65.1.3.3.3, and contain the broadcast bit in the LLID and not the ONU's LLID (frame accepted) as defined in [802.3ah], clause 65. 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." ::= { dot3OmpEmulationStatEntry 7}
Khermosh Standards Track [Page 53]
RFC 4837 Managed Objects of EPON July 2007
dot3OmpEmulationOnuLLIDNotBroadcast 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 contain the ONU's LLID as defined in [802.3ah], clause 65. 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." ::= { dot3OmpEmulationStatEntry 8}
dot3OmpEmulationBroadcastBitPlusOnuLlid 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 contain the broadcast bit in the LLID and match the ONU's LLID (frame reflected) as defined in [802.3ah], clause 65. 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." ::= { dot3OmpEmulationStatEntry 9}
dot3OmpEmulationNotBroadcastBitNotOnuLlid OBJECT-TYPE SYNTAX Counter64 UNITS "frames" MAX-ACCESS read-only STATUS current
Khermosh Standards Track [Page 54]
RFC 4837 Managed Objects of EPON July 2007
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 do not contain the ONU's LLID as defined in [802.3ah], clause 65. 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." ::= { dot3OmpEmulationStatEntry 10}
dot3EponFecTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot3EponFecEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of dot3 EPON FEC management objects. The entries in the table are control and status objects and statistic counters for the FEC layer. 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)." ::= { dot3EponFecObjects 1 }
dot3EponFecEntry OBJECT-TYPE SYNTAX Dot3EponFecEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the dot3 EPON FEC 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
Khermosh Standards Track [Page 55]
RFC 4837 Managed Objects of EPON July 2007
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} ::= { dot3EponFecTable 1 }
dot3EponFecPCSCodingViolation OBJECT-TYPE SYNTAX Counter64 UNITS "octets" MAX-ACCESS read-only STATUS current DESCRIPTION "For a 100 Mbps operation, it is a count of the number of times an invalid code-group is received, other than the /H/ code-group. For a 1000 Mbps operation, it is a count of the number of times an invalid codegroup is received, other than the /V/ code-group. /H/ denotes a special 4b5b codeword of [802.3] 100 Mbps PCS layer (clause 24), and /V/ denotes a special 8b10b codeword of the [802.3] 1000 Mbps PCS layer (clause 36). 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.5.1.1.12." ::= { dot3EponFecEntry 1}
supported(2), unsupported(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "An object that indicates the support of operation of the optional FEC sublayer of the 1000BASE-PX PHY specified in [802.3ah], clause 65.2. unknown(1) value is assigned in the initialization, for non FEC support state or type not yet known. unsupported(3) value is assigned when the sublayer is not supported. supported(2) value is assigned when the sublayer is supported. This object is applicable for an OLT, with the same value for all virtual interfaces, and for an ONU. The FEC counters will have a zero value when the interface is not supporting FEC. The counters: dot3EponFecPCSCodingViolation - not affected by FEC ability. dot3EponFecCorrectedBlocks - has a zero value when dot3EponFecAbility is unknown(1) and unsupported(3). dot3EponFecUncorrectableBlocks - has a zero value when dot3EponFecAbility is unknown(1) and unsupported(3). dot3EponFecBufferHeadCodingViolation - has a zero value when dot3EponFecAbility is unknown(1) and unsupported(3)." REFERENCE "[802.3ah], 30.5.1.1.13." ::= { dot3EponFecEntry 2}
dot3EponFecMode OBJECT-TYPE SYNTAX INTEGER { unknown(1), disabled(2), enabled(3) } MAX-ACCESS read-write STATUS current DESCRIPTION "An object that defines the mode of operation of the optional FEC sublayer of the 1000BASE-PX PHY, specified in [802.3ah], clause 65.2, and reflects its state. A GET operation returns the current mode of operation of the PHY. A SET operation changes the mode of operation of the PHY to the indicated value. unknown(1) value is assigned in the initialization for non FEC support state or type not yet known.
Khermosh Standards Track [Page 57]
RFC 4837 Managed Objects of EPON July 2007
disabled(2) value is assigned when the FEC sublayer is operating in disabled mode. enabled(3) value is assigned when the FEC sublayer is operating in FEC mode. The write operation is not restricted in this document and can be done at any time. Changing dot3EponFecMode state can lead to disabling the Forward Error Correction on the respective interface, which can lead to a degradation of the optical link, and therefore may lead to an interruption of service for the users connected to the respective EPON interface. This object is applicable for an OLT and an ONU. At the OLT, it has a distinct value for each virtual interface. The counting of the FEC counters will stop when the FEC of the interface is disabled. The counters: dot3EponFecPCSCodingViolation - not affected by FEC mode. dot3EponFecCorrectedBlocks - stops counting when Rx_FEC is not enabled. (unknown(1) and disabled(2)). dot3EponFecUncorrectableBlocks - stops counting when Rx_FEC is not enabled (unknown(1) and disabled(2)). dot3EponFecBufferHeadCodingViolation - stops counting when Rx_FEC is not enabled (unknown(1) and disabled(2)). The object: dot3EponFecAbility - indicates the FEC ability and is not affected by the dot3EponFecMode object." REFERENCE "[802.3ah], 30.5.1.1.14." DEFVAL { unknown } ::= { dot3EponFecEntry 3}
dot3EponFecCorrectedBlocks OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "For 10PASS-TS, 2BASE-TL, and 1000BASE-PX PHYs, it is a count of corrected FEC blocks. This counter will not increment for other PHY Types. Increment the counter by one for each received block that is corrected by the FEC function in the PHY. 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
Khermosh Standards Track [Page 58]
RFC 4837 Managed Objects of EPON July 2007
ifCounterDiscontinuityTime object of the Interface MIB module." REFERENCE "[802.3ah], 30.5.1.1.15." ::= { dot3EponFecEntry 4}
dot3EponFecUncorrectableBlocks OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "For 10PASS-TS, 2BASE-TL, and 1000BASE-PX PHYs, it is a count of uncorrectable FEC blocks. This counter will not increment for other PHY Types. Increment the counter by one for each FEC block that is determined to be uncorrectable by the FEC function in the PHY. 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.5.1.1.16." ::= { dot3EponFecEntry 5}
dot3EponFecBufferHeadCodingViolation OBJECT-TYPE SYNTAX Counter64 UNITS "octets" MAX-ACCESS read-only STATUS current DESCRIPTION "For a 1000 Mbps operation, it is a count of the number of invalid code-group received directly from the link. The value has a meaning only in 1000 Mbps mode and it is zero otherwise. 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." ::= { dot3EponFecEntry 6}
dot3ExtPkgControlTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot3ExtPkgControlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of Extended package Control management objects. Entries in the table are control and status indication objects of an EPON interface, which are gathered in an extended package as an addition to the objects based on the [802.3ah], clause 30, attributes. 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)." ::= { dot3ExtPkgControlObjects 1 }
dot3ExtPkgControlEntry OBJECT-TYPE SYNTAX Dot3ExtPkgControlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the Extended package 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} ::= { dot3ExtPkgControlTable 1 }
dot3ExtPkgObjectReset OBJECT-TYPE SYNTAX INTEGER { running(1), reset(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "This object is used to reset the EPON interface. The interface may be unavailable while the reset occurs and data may be lost. Setting this object to running(1) will cause the interface to enter into running mode. Setting this object to reset(2) will cause the interface to go into reset mode. When getting running(1), the interface is in running mode. When getting reset(2), the interface is in reset mode. The write operation is not restricted in this document and can be done at any time. Changing dot3ExtPkgObjectReset state can lead to a reset of the respective interface, leading to an interruption of service for the users connected to the respective EPON interface. This object is applicable for an OLT and an ONU. At the OLT, it has a distinct value for each virtual interface. A reset for a specific virtual interface resets only this virtual interface and not the physical interface. Thus, a virtual link that is malfunctioning can be reset without affecting the operation of other virtual interfaces. The reset can cause Discontinuities in the values of the counters of the interface, similar to re-initialization of the management system. Discontinuity should be indicated by the ifCounterDiscontinuityTime object of the Interface MIB module." DEFVAL { running } ::= { dot3ExtPkgControlEntry 1 }
dot3ExtPkgObjectPowerDown OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION
Khermosh Standards Track [Page 61]
RFC 4837 Managed Objects of EPON July 2007
"This object is used to power down the EPON interface. The interface may be unavailable while the power down occurs and data may be lost. Setting this object to true(1) will cause the interface to enter into power down mode. Setting this object to false(2) will cause the interface to go out of power down mode. When getting true(1), the interface is in power down mode. When getting false(2), the interface is not in power down mode. The write operation is not restricted in this document and can be done at any time. Changing dot3ExtPkgObjectPowerDown state can lead to a power down of the respective interface, leading to an interruption of service of the users connected to the respective EPON interface. This object is applicable for an OLT and an ONU. At the OLT, it has a distinct value for each virtual interface. A power down/up of a specific virtual interface affects only the virtual interface and not the physical interface. Hence a virtual link, which needs a certain handling, can be powered down and then powered up without disrupting the operation of other virtual interfaces. The object is relevant when the admin state of the interface is active as set by the dot3MpcpAdminState." DEFVAL { false } ::= { dot3ExtPkgControlEntry 2 }
dot3ExtPkgObjectNumberOfLLIDs OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "A read only object that indicates the number of registered LLIDs. The initialization value is 0. This object is applicable for an OLT with the same value for all virtual interfaces and for an ONU. 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). At the ONU the number of LLIDs for an interface is one." ::= { dot3ExtPkgControlEntry 3 }
fecTxEnabled(2), fecRxEnabled(3), fecTxRxEnabled(4) } MAX-ACCESS read-write STATUS current DESCRIPTION "An object defining the FEC mode of operation of the interface, and indicating its state. The modes defined in this object are extensions to the FEC modes defined in the dot3EponFecMode object. When noFECEnabled(1), the interface does not enable FEC mode. When fecTxEnabled(2), the interface enables the FEC transmit mode. When fecRxEnabled(3), the interface enables the FEC receive mode. When fecTxRxEnabled(4), the interface enables the FEC transmit and receive mode. This object is applicable for an OLT and an ONU. At the OLT, it has a distinct value for each virtual interface. The FEC counters are referring to the receive path. The FEC counters will stop when the FEC receive mode of the interface is disabled, as defined by fecRxEnabled(3) and fecTxRxEnabled(4) values. The counters: dot3EponFecPCSCodingViolation - not affected by FEC mode. dot3EponFecCorrectedBlocks - stops counting when Rx_FEC is not enabled (noFecEnabled(1) and fecTxEnabled(2)). dot3EponFecUncorrectableBlocks - stops counting when Rx_FEC is not enabled (noFecEnabled(1) and fecTxEnabled(2)). dot3EponFecBufferHeadCodingViolation - stops counting when Rx_FEC is not enabled (noFecEnabled(1) and fecTxEnabled(2)). The objects: dot3EponFecAbility - indicates the FEC ability and is not affected by the FEC mode. dot3EponFecMode - indicates the FEC mode for combined RX and TX. The write operation is not restricted in this document and can be done at any time. Changing dot3ExtPkgObjectFecEnabled state can lead to disabling the Forward Error Correction on the respective interface, which can lead to a degradation of the optical link, and therefore may lead to an interruption of service for the
Khermosh Standards Track [Page 63]
RFC 4837 Managed Objects of EPON July 2007
users connected to the respective EPON interface." DEFVAL { noFecEnabled } ::= { dot3ExtPkgControlEntry 4 }
dot3ExtPkgObjectReportMaximumNumQueues OBJECT-TYPE SYNTAX Unsigned32 (0..7) MAX-ACCESS read-only STATUS current DESCRIPTION "An object, that defines the maximal number of queues in the REPORT message as defined in [802.3ah], clause 64. For further information please see the description of the queue table. This object is applicable for an OLT and an ONU. At the OLT, it has a distinct value for each virtual interface." DEFVAL { 0 } ::= { dot3ExtPkgControlEntry 5 }
dot3ExtPkgObjectRegisterAction OBJECT-TYPE SYNTAX INTEGER { none(1), register(2), deregister(3), reregister(4) } MAX-ACCESS read-write STATUS current DESCRIPTION "An object configuring the registration state of an interface, and indicating its registration state. Write operation changes the registration state to its new value. Read operation returns the value of the state. The registration state is reflected in this object and in the dot3MpcpRegistrationState object. none(1) indicates an unknown state, register(2) indicates a registered LLID, deregister(3) indicates a deregistered LLID, reregister(4) indicates an LLID that is reregistering. The following list describes the operation of the interface, as specified in the [802.3ah], when a write operation is setting a value. none(1) - not doing any action. register(2) - registering an LLID that has been requested for registration (The LLID is in registering mode. dot3MpcpRegistrationState - registering(2) ). deregister(3) - deregisters an LLID that is registered (dot3MpcpRegistrationState - registered(3) ).
Khermosh Standards Track [Page 64]
RFC 4837 Managed Objects of EPON July 2007
reregister(4) - reregister an LLID that is registered (dot3MpcpRegistrationState - registered(3) ). The behavior of an ONU and OLT interfaces, at each one of the detailed operation at each state, is described in the registration state machine of figure 64-22, [802.3ah]. This object is applicable for an OLT and an ONU. At the OLT, it has a distinct value for each virtual interface. The write operation is not restricted in this document and can be done at any time. Changing dot3ExtPkgObjectRegisterAction state can lead to a change in the registration state of the respective interface leading to a deregistration and an interruption of service of the users connected to the respective EPON interface." DEFVAL { none } ::= { dot3ExtPkgControlEntry 6 }
dot3ExtPkgQueueTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot3ExtPkgQueueEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of the extended package objects for queue management. The [802.3ah] MPCP defines a report message of the occupancy of the transmit queues for the feedback BW request from the ONUs. These queues serve the uplink transmission of the ONU and data is gathered there until the ONU is granted for transmission. The management table of the queues is added here mainly to control the reporting and to gather some statistics of their operation. This table is not duplicating existing management objects of bridging queues, specified in [802.1d], since the existence of a dedicated transmit queuing mechanism is implied in the [802.3ah], and the ONU may be a device that is not a bridge with embedded bridging queues. The format of the REPORT message, as specified in [802.3], is presented below: +-----------------------------------+ | Destination Address | +-----------------------------------+ | Source Address | +-----------------------------------+ | Length/Type | +-----------------------------------+ | OpCode | +-----------------------------------+
The 'Queue report' field reports the occupancy of each uplink transmission queue. The number of queue sets defines the number of the reported sets, as would be explained in the description of the dot3ExtPkgQueueSetsTable table. For each set the report bitmap defines which queue is present in the report, meaning that although the MPCP REPORT message can report up to 8 queues in a REPORT message, the actual number is flexible. The Queue table has a variable size that is limited by the dot3ExtPkgObjectReportMaximumNumQueues object, as an ONU can have fewer queues to report. The entries in the table are control and status indication objects for managing the queues of an EPON interface that are gathered in an extended package as an addition to the objects that are based on the [802.3ah] attributes. Each object has a row for every virtual link and for every queue in the report. The LLID field, as defined in the [802.3ah], is a 2-byte register (15-bit field and a broadcast bit) limiting the
Khermosh Standards Track [Page 66]
RFC 4837 Managed Objects of EPON July 2007
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). The number of queues is between 0 and 7 and limited by dot3ExtPkgObjectReportMaximumNumQueues." ::= { dot3ExtPkgControlObjects 2 }
dot3ExtPkgQueueEntry OBJECT-TYPE SYNTAX Dot3ExtPkgQueueEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the Extended package Queue table. At the OLT, the rows exist for each ifIndex and dot3QueueIndex. At the ONU, rows exist for the single ifIndex for each dot3QueueIndex. Rows in the table are created when the ifIndex of the link is created. A set of rows per queue are added for each ifIndex, denoted by the dot3QueueIndex. A set of rows per queue in the table, for an ONU interface, are created at the system initialization. A set of rows per queue in the table, corresponding to the OLT ifIndex and a set of rows per queue corresponding to the broadcast virtual link, are created at the system initialization. A set of rows per queue in the table, corresponding to the ifIndex of a virtual link, are created when the virtual link is established (ONU registers), and deleted when the virtual link is deleted (ONU deregisters)." INDEX { ifIndex, dot3QueueIndex } ::= { dot3ExtPkgQueueTable 1 }
dot3QueueIndex OBJECT-TYPE SYNTAX Unsigned32 (0..7) MAX-ACCESS not-accessible STATUS current DESCRIPTION
Khermosh Standards Track [Page 67]
RFC 4837 Managed Objects of EPON July 2007
"An object that identifies an index for the queue table reflecting the queue index of the queues that are reported in the MPCP REPORT message as defined in [802.3ah], clause 64. The number of queues is between 0 and 7, and limited by dot3ExtPkgObjectReportMaximumNumQueues." ::= { dot3ExtPkgQueueEntry 1 }
dot3ExtPkgObjectReportNumThreshold OBJECT-TYPE SYNTAX Unsigned32 (0..7) MAX-ACCESS read-write STATUS current DESCRIPTION "An object that defines the number of thresholds for each queue in the REPORT message as defined in [802.3ah], clause 64. Each queue_set reporting will provide information on the queue occupancy of frames below the matching Threshold. Read operation reflects the number of thresholds. Write operation sets the number of thresholds for each queue. The write operation is not restricted in this document and can be done at any time. Value cannot exceed the maximal value defined by the dot3ExtPkgObjectReportMaximumNumThreshold object. Changing dot3ExtPkgObjectReportNumThreshold can lead to a change in the reporting of the ONU interface and therefore to a change in the bandwidth allocation of the respective interface. This change may lead a degradation or an interruption of service of the users connected to the respective EPON interface. This object is applicable for an OLT and an ONU. At the OLT, it has a distinct value for each virtual interface and for each queue. At the ONU, it has a distinct value for each queue." DEFVAL { 0 } ::= { dot3ExtPkgQueueEntry 2 }
dot3ExtPkgObjectReportMaximumNumThreshold OBJECT-TYPE SYNTAX Unsigned32 (0..7) MAX-ACCESS read-only STATUS current DESCRIPTION "An object, that defines the maximal number of thresholds for each queue in the REPORT message as defined in [802.3ah], clause 64. Each queue_set reporting will provide information on the queue occupancy of frames below the matching Threshold.
Khermosh Standards Track [Page 68]
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 and for each queue. At the ONU, it has a distinct value for each queue." DEFVAL { 0 } ::= { dot3ExtPkgQueueEntry 3 }
dot3ExtPkgStatTxFramesQueue OBJECT-TYPE SYNTAX Counter64 UNITS "frames" MAX-ACCESS read-only STATUS current DESCRIPTION "A count of the number of times a frame transmission occurs from the corresponding 'Queue'. Increment the counter by one for each frame transmitted, which is an output of the 'Queue'. The 'Queue' marking matches the REPORT MPCP message Queue field 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 and for each queue. At the ONU, it has a distinct value for each queue. 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." ::= { dot3ExtPkgQueueEntry 4}
dot3ExtPkgStatRxFramesQueue OBJECT-TYPE SYNTAX Counter64 UNITS "frames" MAX-ACCESS read-only STATUS current DESCRIPTION "A count of the number of times a frame reception occurs from the corresponding 'Queue'. Increment the counter by one for each frame received, which is an input to the corresponding 'Queue'. The 'Queue' marking matches the REPORT MPCP message Queue field 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 and for each queue. At the ONU, it has a distinct value for each queue. Discontinuities of this counter can occur at
Khermosh Standards Track [Page 69]
RFC 4837 Managed Objects of EPON July 2007
re-initialization of the management system and at other times, as indicated by the value of the ifCounterDiscontinuityTime object of the Interface MIB module." ::= { dot3ExtPkgQueueEntry 5}
dot3ExtPkgStatDroppedFramesQueue OBJECT-TYPE SYNTAX Counter64 UNITS "frames" MAX-ACCESS read-only STATUS current DESCRIPTION "A count of the number of times a frame drop occurs from the corresponding 'Queue'. Increment the counter by one for each frame dropped from the corresponding 'Queue'. The 'Queue' marking matches the REPORT MPCP message Queue field 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 and for each queue. At the ONU, it has a distinct value for each queue. 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." ::= { dot3ExtPkgQueueEntry 6}
dot3ExtPkgQueueSetsTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot3ExtPkgQueueSetsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of Extended package objects used for the management of the queue_sets. Entries are control and status indication objects of an EPON interface, which are gathered in an extended package as an addition to the objects based on the [802.3ah] attributes. The objects in this table are specific for the queue_sets, which are reported in the MPCP REPORT message as defined in [802.3ah], clause 64. The [802.3ah] MPCP defines a report message of the occupancy of the transmit queues for the feedback BW request from the ONUs. These queues serve the uplink transmission of the ONU and data is gathered there until the ONU is granted for transmission.
Khermosh Standards Track [Page 70]
RFC 4837 Managed Objects of EPON July 2007
The management table of the queues_sets is added here mainly to control the reporting and to gather some statistics of their operation. This table is not duplicating existing management objects of bridging queues, specified in [802.1d], since the existence of a dedicated transmit queuing mechanism is implied in the [802.3ah], and the ONU may be a device that is not a bridge with embedded bridging queues. The format of the REPORT message, as specified in [802.3], is presented below: +-----------------------------------+ | Destination Address | +-----------------------------------+ | Source Address | +-----------------------------------+ | Length/Type | +-----------------------------------+ | OpCode | +-----------------------------------+ | TimeStamp | +-----------------------------------+ | Number of queue Sets | +-----------------------------------+ /|\ | Report bitmap | | +-----------------------------------+ | | Queue 0 report | | +-----------------------------------+ | repeated for | Queue 1 report | | every +-----------------------------------+ | queue_set | Queue 2 report | | +-----------------------------------+ | | Queue 3 report | | +-----------------------------------+ | | Queue 4 report | | +-----------------------------------+ | | Queue 5 report | | +-----------------------------------+ | | Queue 6 report | | +-----------------------------------+ | | Queue 7 report | | +-----------------------------------+ \|/ | Pad/reserved | +-----------------------------------+ | FCS | +-----------------------------------+
As can be seen from the message format, the ONU interface reports of the status of up to 8 queues
Khermosh Standards Track [Page 71]
RFC 4837 Managed Objects of EPON July 2007
and it can report in a single MPCP REPORT message of a few sets of queues. The number of queue_sets defines the number of the reported sets, and it can reach a value of up to 8. It means that an ONU can hold a variable number of sets between 0 and 7. The dot3ExtPkgQueueSetsTable table has a variable queue_set size that is limited by the dot3ExtPkgObjectReportMaximumNumThreshold object as an ONU can have fewer queue_sets to report. The 'Queue report' field reports the occupancy of each uplink transmission queue. The queue_sets can be used to report the occupancy of the queues in a few levels as to allow granting, in an accurate manner, of only part of the data available in the queues. A Threshold is defined for each queue_set to define the level of the queue that is counted for the report of the occupancy. The threshold is reflected in the queue_set table by the dot3ExtPkgObjectReportThreshold object. For each queue set, the report bitmap defines which queues are present in the report, meaning that although the MPCP REPORT message can report of up to 8 queues in a REPORT message, the actual number is flexible. The dot3ExtPkgQueueSetsTable table has a variable queue size that is limited by the dot3ExtPkgObjectReportMaximumNumQueues object as an ONU can have fewer queues to report. Each object has a row for every virtual link, for each queue in the report and for each queue_set in the queue. 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). The number of queues is between 0 and 7 and limited by dot3ExtPkgObjectReportMaximumNumQueues. The number of queues_sets is between 0 and 7 and limited by dot3ExtPkgObjectReportMaximumNumThreshold." ::= { dot3ExtPkgControlObjects 3 }
dot3ExtPkgQueueSetsEntry OBJECT-TYPE SYNTAX Dot3ExtPkgQueueSetsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the Extended package queue_set table. At
Khermosh Standards Track [Page 72]
RFC 4837 Managed Objects of EPON July 2007
the OLT, the rows exist for each ifIndex, dot3QueueSetQueueIndex and dot3QueueSetIndex. At the ONU, rows exist for the single ifIndex, for each dot3QueueSetQueueIndex and dot3QueueSetIndex. Rows in the table are created when the ifIndex of the link is created. A set of rows per queue and per queue_set are added for each ifIndex, denoted by dot3QueueSetIndex and dot3QueueSetQueueIndex. A set of rows per queue and per queue_set in the table, for an ONU interface are created at system initialization. A set of rows per queue and per queue_Set in the table, corresponding to the OLT ifIndex and a set of rows per queue and per queue_set, corresponding to the broadcast virtual link, are created at system initialization. A set of rows per queue and per queue_set in the table, corresponding to the ifIndex of a virtual link are created when the virtual link is established (ONU registers) and deleted when the virtual link is deleted (ONU deregisters)." INDEX { ifIndex, dot3QueueSetQueueIndex,dot3QueueSetIndex} ::= { dot3ExtPkgQueueSetsTable 1 }
dot3QueueSetQueueIndex OBJECT-TYPE SYNTAX Unsigned32 (0..7) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An object that identifies the queue index for the dot3ExtPkgQueueSetsTable table. The queues are reported in the MPCP REPORT message as defined in [802.3ah], clause 64. The number of queues is between 0 and 7, and limited by dot3ExtPkgObjectReportMaximumNumQueues. Value corresponds to the dot3QueueIndex of the queue table." ::= { dot3ExtPkgQueueSetsEntry 1 }
MAX-ACCESS not-accessible STATUS current DESCRIPTION "An object that identifies the queue_set index for the dot3ExtPkgQueueSetsTable table. The queues are reported in the MPCP REPORT message as defined in [802.3ah], clause 64. The number of queues_sets is between 0 and 7, and limited by dot3ExtPkgObjectReportMaximumNumThreshold." ::= { dot3ExtPkgQueueSetsEntry 2 }
dot3ExtPkgObjectReportThreshold OBJECT-TYPE SYNTAX Unsigned32 UNITS "TQ (16nsec)" MAX-ACCESS read-write STATUS current DESCRIPTION "An object that defines the value of a threshold report for each queue_set in the REPORT message as defined in [802.3ah], clause 64. The number of sets for each queue is dot3ExtPkgObjectReportNumThreshold. In the REPORT message, each queue_set reporting will provide information on the occupancy of the queues for frames below the matching Threshold. The value returned shall be in Time quanta (TQ), which is 16nsec or 2 octets increments. Read operation provides the threshold value. Write operation sets the value of the threshold. The write operation is not restricted in this document and can be done at any time. Changing dot3ExtPkgObjectReportThreshold can lead to a change in the reporting of the ONU interface and therefore to a change in the bandwidth allocation of the respective interface. This change may lead a degradation or an interruption of service for the users connected to the respective EPON interface. This object is applicable for an OLT and an ONU. At the OLT, it has a distinct value for each virtual interface, for each queue and for each queue_set. At the ONU, it has a distinct value for each queue and for each queue_set." DEFVAL { 0 } ::= { dot3ExtPkgQueueSetsEntry 3 }
--Optical Interface status tables
dot3ExtPkgOptIfTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot3ExtPkgOptIfEntry MAX-ACCESS not-accessible
Khermosh Standards Track [Page 74]
RFC 4837 Managed Objects of EPON July 2007
STATUS current DESCRIPTION "This table defines the control and status indication objects for the optical interface of the EPON interface. 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). Although the optical interface is a physical interface, there is a row in the table for each virtual interface. The reason for having a separate row for each virtual link is that the OLT has a separate link for each one of the ONUs. For instance, ONUs could be in different distances with different link budgets and different receive powers, therefore having different power alarms. It is quite similar to a case of different physical interfaces." ::= { dot3ExtPkgControlObjects 5}
dot3ExtPkgOptIfEntry OBJECT-TYPE SYNTAX Dot3ExtPkgOptIfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the optical interface table of the EPON 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 links is created when a virtual link is established (ONU registers) and deleted when the virtual link is deleted (ONU deregisters)." INDEX { ifIndex } ::= { dot3ExtPkgOptIfTable 1 }
dot3ExtPkgOptIfSuspectedFlag OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This object is a reliability indication. If true, the data in this entry may be unreliable. This object is applicable for an OLT and an ONU. At the OLT, it has a distinct value for each virtual interface." ::= { dot3ExtPkgOptIfEntry 1 }
dot3ExtPkgOptIfInputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The optical power monitored at the input. This object is applicable for an OLT and an ONU. At the OLT, it has a distinct value for each virtual interface." ::= { dot3ExtPkgOptIfEntry 2 }
dot3ExtPkgOptIfLowInputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The lowest optical power monitored at the input during the current 15-minute interval. This object is applicable for an OLT and an ONU. At the OLT, it has a distinct value for each virtual interface." ::= { dot3ExtPkgOptIfEntry 3 }
Khermosh Standards Track [Page 76]
RFC 4837 Managed Objects of EPON July 2007
dot3ExtPkgOptIfHighInputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The highest optical power monitored at the input during the current 15-minute interval. This object is applicable for an OLT and an ONU. At the OLT, it has a distinct value for each virtual interface." ::= { dot3ExtPkgOptIfEntry 4 }
dot3ExtPkgOptIfLowerInputPowerThreshold OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-write STATUS current DESCRIPTION "The lower limit threshold on input power. If dot3ExtPkgOptIfInputPower drops to this value or below, a Threshold Crossing Alert (TCA) should be sent. Reading will present the threshold value. Writing will set the value of the threshold. The write operation is not restricted in this document and can be done at any time. Changing dot3ExtPkgOptIfLowerInputPowerThreshold can lead to a Threshold Crossing Alert (TCA) being sent for the respective interface. This alert may be leading to an interruption of service for the users connected to the respective EPON interface, depending on the system action on such an alert. This object is applicable for an OLT and an ONU. At the OLT, it has a distinct value for each virtual interface." ::= { dot3ExtPkgOptIfEntry 5 }
dot3ExtPkgOptIfUpperInputPowerThreshold OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-write STATUS current DESCRIPTION "The upper limit threshold on input power. If dot3ExtPkgOptIfInputPower reaches or exceeds this value, a Threshold Crossing Alert (TCA) should be sent. Reading will present the threshold value. Writing will set the value of the threshold. The write operation is not restricted in this document and can be done at any time. Changing dot3ExtPkgOptIfUpperInputPowerThreshold can lead to a Threshold
Khermosh Standards Track [Page 77]
RFC 4837 Managed Objects of EPON July 2007
Crossing Alert (TCA) being sent for the respective interface. This alert may be leading to an interruption of service for the users connected to the respective EPON interface, depending on the system action on such an alert. This object is applicable for an OLT and an ONU. At the OLT, it has a distinct value for each virtual interface." ::= { dot3ExtPkgOptIfEntry 6 }
dot3ExtPkgOptIfOutputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The optical power monitored at the output. This object is applicable for an OLT and an ONU. At the OLT, it has a distinct value for each virtual interface." ::= { dot3ExtPkgOptIfEntry 7 }
dot3ExtPkgOptIfLowOutputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The lowest optical power monitored at the output during the current 15-minute interval. This object is applicable for an OLT and an ONU. At the OLT, it has a distinct value for each virtual interface." ::= { dot3ExtPkgOptIfEntry 8 }
dot3ExtPkgOptIfHighOutputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The highest optical power monitored at the output during the current 15-minute interval. This object is applicable for an OLT and an ONU. At the OLT, it has a distinct value for each virtual interface." ::= { dot3ExtPkgOptIfEntry 9 }
dot3ExtPkgOptIfLowerOutputPowerThreshold OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-write STATUS current
Khermosh Standards Track [Page 78]
RFC 4837 Managed Objects of EPON July 2007
DESCRIPTION "The lower limit threshold on output power. If dot3ExtPkgOptIfOutputPower drops to this value or below, a Threshold Crossing Alert (TCA) should be sent. Reading will present the threshold value. Writing will set the value of the threshold. The write operation is not restricted in this document and can be done at any time. Changing dot3ExtPkgOptIfLowerOutputPowerThreshold can lead to a Threshold Crossing Alert (TCA) being sent for the respective interface. This alert may be leading to an interruption of service for the users connected to the respective EPON interface, depending on the system action on such an alert. This object is applicable for an OLT and an ONU. At the OLT, it has a distinct value for each virtual interface." ::= { dot3ExtPkgOptIfEntry 10 }
dot3ExtPkgOptIfUpperOutputPowerThreshold OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-write STATUS current DESCRIPTION "The upper limit threshold on output power. If dot3ExtPkgOptIfOutputPower reaches or exceeds this value, a Threshold Crossing Alert (TCA) should be sent. Reading will present the threshold value. Writing will set the value of the threshold. The write operation is not restricted in this document and can be done at any time. Changing dot3ExtPkgOptIfUpperOutputPowerThreshold can lead to a Threshold Crossing Alert (TCA) being sent for the respective interface. This alert may be leading to an interruption of service of the users connected to the respective EPON interface, depending on the system action on such an alert. This object is applicable for an OLT and an ONU. At the OLT, it has a distinct value for each virtual interface." ::= { dot3ExtPkgOptIfEntry 11 }
dot3ExtPkgOptIfSignalDetect OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "When getting true(1), there is a valid optical signal at the receive that is above the optical power level for signal detection. When getting false(2) the optical signal at the receive is below the optical power level
Khermosh Standards Track [Page 79]
RFC 4837 Managed Objects of EPON July 2007
for signal detection. This object is applicable for an OLT and an ONU. At the OLT, it has a distinct value for each virtual interface." DEFVAL { false } ::= { dot3ExtPkgOptIfEntry 12 }
dot3ExtPkgOptIfTransmitAlarm OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "When getting true(1) there is a non-valid optical signal at the transmit of the interface, either a higher level or lower level than expected. When getting false(2) the optical signal at the transmit is valid and in the required range. This object is applicable for an OLT and an ONU. At the OLT, it has a distinct value for each virtual interface." DEFVAL { false } ::= { dot3ExtPkgOptIfEntry 13 }
dot3ExtPkgOptIfTransmitEnable OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "Setting this object to true(1) will cause the optical interface to start transmission (according to the control protocol specified for the logical interface). Setting this object to false(2) will cause the interface to stop the optical transmission. When getting true(1), the optical interface is in transmitting mode (obeying to the logical control protocol). When getting false(2), the optical interface is not in transmitting mode. The write operation is not restricted in this document and can be done at any time. Changing dot3ExtPkgOptIfTransmitEnable state can lead to a halt in the optical transmission of the respective interface leading to an interruption of service of the users connected to the respective EPON interface. The object is relevant when the admin state of the interface is active as set by the dot3MpcpAdminState. This object is applicable for an OLT and an ONU. At the OLT it, has a distinct value for each virtual interface." DEFVAL { false } ::= { dot3ExtPkgOptIfEntry 14 }
dot3MpcpGroupBase OBJECT-GROUP OBJECTS { dot3MpcpOperStatus, dot3MpcpAdminState, dot3MpcpMode, dot3MpcpSyncTime, dot3MpcpLinkID, dot3MpcpRemoteMACAddress, dot3MpcpRegistrationState, dot3MpcpMaximumPendingGrants, dot3MpcpTransmitElapsed, dot3MpcpReceiveElapsed, dot3MpcpRoundTripTime } STATUS current DESCRIPTION "A collection of objects of dot3 Mpcp Control entity state definition. Objects are per LLID." ::= { dot3EponGroups 1 }
dot3MpcpGroupStat OBJECT-GROUP OBJECTS { dot3MpcpMACCtrlFramesTransmitted, dot3MpcpMACCtrlFramesReceived, dot3MpcpDiscoveryWindowsSent, dot3MpcpDiscoveryTimeout, dot3MpcpTxRegRequest, dot3MpcpRxRegRequest, dot3MpcpTxRegAck, dot3MpcpRxRegAck, dot3MpcpTxReport, dot3MpcpRxReport, dot3MpcpTxGate, dot3MpcpRxGate, dot3MpcpTxRegister, dot3MpcpRxRegister } STATUS current DESCRIPTION "A collection of objects of dot3 Mpcp Statistics. Objects are per LLID." ::= { dot3EponGroups 2 }
} STATUS current DESCRIPTION "A collection of objects of dot3 OMP emulation entity state definition. Objects are per LLID." ::= { dot3EponGroups 3 }
dot3OmpeGroupStat OBJECT-GROUP OBJECTS { dot3OmpEmulationSLDErrors, dot3OmpEmulationCRC8Errors, dot3OmpEmulationBadLLID, dot3OmpEmulationGoodLLID, dot3OmpEmulationOnuPonCastLLID, dot3OmpEmulationOltPonCastLLID, dot3OmpEmulationBroadcastBitNotOnuLlid, dot3OmpEmulationOnuLLIDNotBroadcast, dot3OmpEmulationBroadcastBitPlusOnuLlid, dot3OmpEmulationNotBroadcastBitNotOnuLlid } STATUS current DESCRIPTION "A collection of objects of dot3 OMP emulation Statistics. Objects are per LLID." ::= { dot3EponGroups 4 }
dot3EponFecGroupAll OBJECT-GROUP OBJECTS { dot3EponFecPCSCodingViolation, dot3EponFecAbility, dot3EponFecMode, dot3EponFecCorrectedBlocks, dot3EponFecUncorrectableBlocks, dot3EponFecBufferHeadCodingViolation } STATUS current DESCRIPTION "A collection of objects of dot3 FEC group control and statistics. Objects are per LLID." ::= { dot3EponGroups 5 }
dot3ExtPkgObjectPowerDown, dot3ExtPkgObjectNumberOfLLIDs, dot3ExtPkgObjectFecEnabled, dot3ExtPkgObjectReportMaximumNumQueues, dot3ExtPkgObjectRegisterAction } STATUS current DESCRIPTION "A collection of objects of dot3ExtPkg control definition. Objects are per LLID." ::= { dot3EponGroups 6 }
dot3ExtPkgGroupQueue OBJECT-GROUP OBJECTS { dot3ExtPkgObjectReportNumThreshold, dot3ExtPkgObjectReportMaximumNumThreshold, dot3ExtPkgStatTxFramesQueue, dot3ExtPkgStatRxFramesQueue, dot3ExtPkgStatDroppedFramesQueue } STATUS current DESCRIPTION "A collection of objects of dot3ExtPkg Queue control. Objects are per LLID, per queue." ::= { dot3EponGroups 7 }
dot3ExtPkgGroupQueueSets OBJECT-GROUP OBJECTS { dot3ExtPkgObjectReportThreshold } STATUS current DESCRIPTION "A collection of objects of dot3ExtPkg queue_set control. Objects are per LLID, per queue, per queue_set." ::= { dot3EponGroups 8 }
dot3ExtPkgOptIfLowerOutputPowerThreshold, dot3ExtPkgOptIfUpperOutputPowerThreshold, dot3ExtPkgOptIfSignalDetect, dot3ExtPkgOptIfTransmitAlarm, dot3ExtPkgOptIfTransmitEnable } STATUS current DESCRIPTION "A collection of objects of control and status indication of the optical interface. Objects are per LLID." ::= { dot3EponGroups 9 }
dot3MPCPCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for Multi-Point Control Protocol interfaces."
MODULE -- this module MANDATORY-GROUPS { dot3MpcpGroupBase}
GROUP dot3MpcpGroupStat DESCRIPTION "This group is mandatory for all MPCP supporting interfaces for statistics collection." ::= { dot3EponCompliances 1}
dot3OmpeCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for OMPEmulation interfaces."
MODULE -- this module MANDATORY-GROUPS { dot3OmpeGroupID}
GROUP dot3OmpeGroupStat DESCRIPTION "This group is mandatory for all OMPemulation supporting interfaces for statistics collection."
::= { dot3EponCompliances 2}
dot3EponFecCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for FEC EPON interfaces.
Khermosh Standards Track [Page 84]
RFC 4837 Managed Objects of EPON July 2007
This group is mandatory for all FEC supporting interfaces for control and statistics collection."
MODULE -- this module MANDATORY-GROUPS { dot3EponFecGroupAll }
::= { dot3EponCompliances 3}
dot3ExtPkgCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for EPON Interfaces using the extended package." MODULE -- this module MANDATORY-GROUPS { dot3ExtPkgGroupControl }
GROUP dot3ExtPkgGroupQueue DESCRIPTION " This group is mandatory for all EPON interfaces supporting REPORT queue management of the extended package."
GROUP dot3ExtPkgGroupQueueSets DESCRIPTION " This group is mandatory for all EPON interfaces supporting REPORT queue_sets management of the extended package."
GROUP dot3ExtPkgGroupOptIf DESCRIPTION "This group is mandatory for all EPON interfaces supporting optical interfaces management, of the extended package."
This document is the result of the efforts of the HUBMIB Working Group. Some special thanks to Dan Romascanu, who was WG chair during most of the development of this document, and who carefully reviewed and commented on the initial versions of this document. Also, some special thanks to Bert Wijnen, who is the current WG chair, for his review and comments on the final stages of this document.
Special thanks are due to David Perkins for his detailed and helpful MIB Doctor review of this document.
Also, some special thanks to some of the IEEE802.3ah Working Group people for their contribution and additional reviews of the document.
There are number of managed objects defined in this MIB module that have a MAX-ACCESS clause of read-write or read-create. Writing to these objects can have potentially disruptive effects on network operation, including:
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.
Changing dot3EponFecMode state can lead to disabling the Forward Error Correction on the respective interface, which can lead to a degradation of the optical link, and therefore may lead to an interruption of service for the users connected to the respective EPON interface.
Changing dot3ExtPkgObjectReset state can lead to a reset of the respective interface leading to an interruption of service for the users connected to the respective EPON interface.
Changing dot3ExtPkgObjectPowerDown state can lead to a power down of the respective interface, leading to an interruption of service for the users connected to the respective EPON interface.
Changing dot3ExtPkgObjectFecEnabled state can lead to disabling the Forward Error Correction on the respective interface, which can lead to a degradation of the optical link, and therefore may lead to an interruption of service for the users connected to the respective EPON interface.
Khermosh Standards Track [Page 86]
RFC 4837 Managed Objects of EPON July 2007
Changing dot3ExtPkgObjectRegisterAction state can lead to a change in the registration state of the respective interface, leading to a deregistration and an interruption of service for the users connected to the respective EPON interface.
Changing dot3ExtPkgObjectReportNumThreshold can lead to a change in the reporting of the ONU interface and therefore to a change in the bandwidth allocation of the respective interface. This change may lead a degradation or an interruption of service for the users connected to the respective EPON interface.
Changing dot3ExtPkgObjectReportThreshold can lead to a change in the reporting of the ONU interface and therefore to a change in the bandwidth allocation of the respective interface. This change may lead a degradation or an interruption of service for the users connected to the respective EPON interface.
Changing dot3ExtPkgOptIfLowerInputPowerThreshold can lead to a Threshold Crossing Alert (TCA) being sent for the respective interface. This alert may be leading to an interruption of service for the users connected to the respective EPON interface, depending on the system action on such an alert.
Changing dot3ExtPkgOptIfUpperInputPowerThreshold can lead to a Threshold Crossing Alert (TCA) being sent for the respective interface. This alert may be leading to an interruption of service for the users connected to the respective EPON interface, depending on the system action on such an alert.
Changing dot3ExtPkgOptIfLowerOutputPowerThreshold can lead to a Threshold Crossing Alert (TCA) being sent for the respective interface. This alert may be leading to an interruption of service for the users connected to the respective EPON interface, depending on the system action on such an alert.
Changing dot3ExtPkgOptIfUpperOutputPowerThreshold can lead to a Threshold Crossing Alert (TCA) being sent for the respective interface. This alert may be leading to an interruption of service for the users connected to the respective EPON interface, depending on the system action on such an alert.
Changing dot3ExtPkgOptIfTransmitEnable state can lead to a halt in the optical transmission of the respective interface, leading to an interruption of service for the users connected to the respective EPON interface.
Khermosh Standards Track [Page 87]
RFC 4837 Managed Objects of EPON July 2007
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 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.
[802.1d] IEEE, "Institute of Electrical and Electronic Engineers, 802.1D-2004, IEEE Standard for Local and metropolitan area networks Media Access Control (MAC) Bridges.", June 2004.
[802.3] IEEE, "Institute of Electrical and Electronic Engineers, IEEE Std 802.3-2002, "IEEE Standard for Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications.", December 2002.
Khermosh Standards Track [Page 88]
RFC 4837 Managed Objects of EPON July 2007
[802.3ah] IEEE, "Institute of Electrical and Electronic Engineers, IEEE Std 802.3ah-2004. 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.
[ITU-T.G.975] ITU, "ITU-T, SERIES G: TRANSMISSION SYSTEMS AND MEDIA, DIGITAL SYSTEMS AND NETWORKS Digital sections and digital line system - Optical fibre submarine cable systems Forward error correction for submarine systems, ITU-T Recommendation G.975", October 2000.
[ITU-T.G.983] ITU, "ITU-T, SERIES G: TRANSMISSION SYSTEMS AND MEDIA, DIGITAL SYSTEMS AND NETWORKS, Digital transmission systems - Digital sections and digital line system - Optical line systems for local and access networks Broadband optical access systems based on Passive Optical Networks (PON), ITU-T Recommendation G.983.1", October 1998.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
[RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "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.
[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.
Khermosh Standards Track [Page 89]
RFC 4837 Managed Objects of EPON July 2007
[RFC3635] Flick, J., "Definitions of Managed Objects for the Ethernet-like Interface Types", RFC 3635, September 2003.
[RFC4836] Beili, E., "Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs)", RFC 4836, April 2007.
[RFC1525] Decker, E., McCloghrie, K., Langille, P., and A. Rijsinghani, "Definitions of Managed Objects for Source Routing Bridges", RFC 1525, September 1993.
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002.
[RFC4188] Norseth, K. and E. Bell, "Definitions of Managed Objects for Bridges", RFC 4188, September 2005.
[RFC4878] Squire, M., "Definitions and Managed Objects for Operations, Administration, and Maintenance (OAM) Functions on Ethernet-Like Interfaces", RFC 4878, June 2007.
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.
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, THE IETF TRUST 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.
Intellectual Property
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 ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the Internet Society.