Managed Objects of Ethernet Passive Optical Networks (EPON)

For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to Section 7 of RFC 3410 . 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 ; STD 58, RFC 2579 ; and STD 58, RFC 2580 .

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 , 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 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 . 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 FEC - Forward Error Correction GMII - Gigabit Media Independent Interface LAN - Local Area Network LLID - Logical Link Identifier MAC - Media Access Control Mbps - Megabit per second MDI - Medium Dependent Interface MDIO - Management Data Input/Output MPCP - Multi-Point Control Protocol MP2PE - Multi-Point to Point Emulation OAM - Operation Administration Maintenance OLT - Optical Line Terminal (Server unit of the EPON) OMP - Optical Multi-Point ONU - Optical Network Unit (Client unit of the EPON) P2MP - Point-to-Multipoint P2PE - Point-to-Point Emulation PCS - Physical Coding Sublayer PHY - Physical Layer PMA - Physical Medium Attachment PMD - Physical Medium Dependent PON - Passive Optical Network RS - Reconciliation Sublayer RTT - Round Trip Time SLA - Service Level Agreement SLD - Start of LLID Delimiter TDM - Time Division Multiplexing TQ - Time Quanta

The EPON standard, as defined in , 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: The IEEE layering architecture of an EPON interface is defined in the diagram of Figure 56.2 . The following clauses in the define the corresponding layers of an EPON interface: clause 30 - Management clause 60 - PMD for EPON media (Burst PMD) clause 64 - MPCP (Multi-Point Control Protocol) - defines the Multi-Point architecture, and control protocol for the media access of EPON. clause 65 - a) Virtual links definition for the EPON b) FEC c) PMA for the EPON.

The specification of the EPON interface is based on the specification of the gigabit Ethernet interface as described in , 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.

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-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 , 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 . 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 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 is to partition the EPON link, in a virtual manner, between the ONUs. Each ONU has a dedicated virtual link to the OLT. The 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. The virtual links concept is also used to avoid a violation of the 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. 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 , 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.

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 improves the link budget has a benefit. The FEC code used is the RS(239,255,8), similar to the FEC code in , 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: The FEC is added in a separate layer between the PCS and PMA layers of the . The FEC layer introduces a fixed delay in receive path and transmit path. The FEC layer is optional.

Each one of the EPON layers is accompanied by a management interface that is controlled through clause 30 of the . As the 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.

The following diagram presents the relation of the MIB groups to the 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. 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: This device would have 3 entries in the IF table, and one IF stack entry; for example: ifIndex=1 - interface for 10 megabit interface ifIndex=2 - interface for the optical interface ifIndex=200 - interface for the ONU interface And then in the IF stack table: ifStackHigherLayer=200, ifStackLowerLayer=2 - map between the physical and the ONU The second device has three physical interfaces, is typically located at the provider's site, and may be called a "headend".

A "headend" is shown in the figure below: 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 , MAU MIB module , and Etherlike MIB module . 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. 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 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 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 , 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 , 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. 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 , 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 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. For example, provided below are the values of the MPCP control table of an OLT with 3 registered ONUs: The table below presents the MPCP control table of ONU1 in working mode. A single row exists in the table. MPCP control MIB object Value ifIndex 100 dot3MpcpOperStatus true dot3MpcpAdminState true dot3MpcpMode onu dot3MpcpSyncTime 25 dot3MpcpLinkID 1 dot3MpcpRemoteMACAddress OLT_MAC_Address dot3MpcpRegistrationState registered dot3MpcpTransmitElapsed 10 dot3MpcpReceiveElapsed 10 dot3MpcpRoundTripTime 100 OLT_MAC_Address is the MAC address of the OLT EPON interface. The creation of the rows of the ONU interface is done at initialization. For example, provided below are the values for the MPCP control table of the ONU, after initialization, before registration. The table below presents the MPCP control table of ONU1 after initialization. A single row exists in the table. MPCP control MIB object Value ifIndex 100 dot3MpcpOperStatus true dot3MpcpAdminState true dot3MpcpMode onu dot3MpcpSyncTime 0 dot3MpcpLinkID 0 dot3MpcpRemoteMACAddress 00:00:00:00:00:00 dot3MpcpRegistrationState unregistered dot3MpcpTransmitElapsed 0 dot3MpcpReceiveElapsed 0 dot3MpcpRoundTripTime 0 The table below presents the MPCP control table of the OLT in working mode. Four rows exist in the table associated with the virtual links. MPCP control MIB object Value Value Value Value ifIndex 100001 100002 100003 165535 dot3MpcpOperStatus true true true true dot3MpcpAdminState true true true true dot3MpcpMode olt olt olt olt dot3MpcpSyncTime 25 25 25 25 dot3MpcpLinkID 1 2 3 65535 dot3MpcpRemoteMACAddress ONU1_MAC_Address ONU2_MAC_Address ONU3_MAC_Address BRCT_MAC_Address dot3MpcpRegistrationState registered registered registered registered dot3MpcpTransmitElapsed 10 10 10 10 dot3MpcpReceiveElapsed 10 10 10 10 dot3MpcpRoundTripTime 100 60 20 0 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). For example, provided below are the values of the MPCP control table of the OLT after initialization, before the ONUs register. The table below presents the MPCP control table of the OLT after initialization. A single row exists in this table associated with the virtual broadcast link. MPCP control MIB object Value ifIndex 165535 dot3MpcpOperStatus true dot3MpcpAdminState true dot3MpcpMode olt dot3MpcpSyncTime 25 dot3MpcpLinkID 65535 dot3MpcpRemoteMACAddress BRCT_MAC_Address dot3MpcpRegistrationState registered dot3MpcpTransmitElapsed 10 dot3MpcpReceiveElapsed 100000 dot3MpcpRoundTripTime 0 BRCT_MAC_Address is the MAC address of the broadcast EPON interface, which is the OLT MAC address.

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 and the Ethernet-like Interfaces MIB module . Thus, each managed EPON interface would have a corresponding entry in the mandatory tables of the Ether-like MIB module found in , and likewise in the tables of the Interface MIB module found in . Also each managed virtual EPON interface would have a corresponding entry in the mandatory tables of the Ether-like MIB module found in , and likewise in the tables of the Interface MIB module found in with a dedicated ifIndex for this interface. 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 . The interface MIB module defines the interface index (ifIndex). Interface Index, as specified in , 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 , and the ifInvStack defined in . 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 , 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: The table below presents the objects of the Interface MIB of an ONU in working mode. Interface MIB object Value ifIndex 1 ifDescr "interface description" ifType ethernetCsmacd (6) 1000base-Px ifMtu MTU size (1522) ifSpeed 1000000000 ifPhysAddress ONU_MAC_Address ifAdminStatus up ifOperStatus Up ifLastChange ONUup_time ifInOctets ONU_octets_number ifInUcastPkts ONU_unicast_frame_number ifInNUcastPkts ONU_non_unicast_frame_number ifInDiscards ONU_discard_frame_number ifInErrors ONU_error_frame_number ifInUnknownProtos ONU_unknown_frame_number ifOutOctets ONU_octets_number ifOutUcastPkts ONU_unicast_frame_number ifOutNUcastPkts ONU_non_unicast_frame_number ifOutDiscards ONU_discard_frame_number ifOutErrors ONU_error_frame_number ifOutQLen ONU_queue_frame_number ONU_MAC_Address is the MAC address of the ONU EPON interface. The table below presents the objects of the Interface MIB of the ONU interface. Interface MIB object Value ifIndex 100 ifDescr "interface description" ifType ethernetCsmacd (6) 1000base-Px ifMtu MTU size (1522) ifSpeed 1000000000 ifPhysAddress ONU_MAC_Address ifAdminStatus up ifOperStatus Up ifLastChange up_time ifInOctets ONU1_octets_number ifInUcastPkts ONU1_unicast_frame_number ifInNUcastPkts ONU1_non_unicast_frame_number ifInDiscards ONU1_discard_frame_number ifInErrors ONU1_error_frame_number ifInUnknownProtos ONU1_unknown_frame_number ifOutOctets ONU1_octets_number ifOutUcastPkts ONU1_unicast_frame_number ifOutNUcastPkts ONU1_non_unicast_frame_number ifOutDiscards ONU1_discard_frame_number ifOutErrors ONU1_error_frame_number ifOutQLen ONU1_queue_frame_number ONU_MAC_Address is the MAC address of the ONU EPON interface. The following values will be set in the ifStack and ifInvStack tables related to this example. ifStackTable: ifStackHigherLayer=100, ifStackLowerLayer=1 - map between the physical interface and the ONU ifInvStackTable: ifStackLowerLayer=1, ifStackHigherLayer=100,- map between the ONU and the physical interface The table below presents the Interface MIB objects of an OLT interface. Interface MIB object Value ifIndex 2 ifDescr "interface description" ifType ethernetCsmacd (6) 1000base-Px ifMtu MTU size (1522) ifSpeed 1000000000 ifPhysAddress OLT_MAC_Address ifAdminStatus up ifOperStatus Up ifLastChange OLTup_time ifInOctets OLT_octets_number ifInUcastPkts OLT_unicast_frame_number ifInNUcastPkts OLT_non_unicast_frame_number ifInDiscards OLT_discard_frame_number ifInErrors OLT_error_frame_number ifInUnknownProtos OLT_unknown_frame_number ifOutOctets OLT_octets_number ifOutUcastPkts OLT_unicast_frame_number ifOutNUcastPkts OLT_non_unicast_frame_number ifOutDiscards OLT_discard_frame_number ifOutErrors OLT_error_frame_number ifOutQLen OLT_queue_frame_number OLT_MAC_Address is the MAC address of the OLT EPON interface. The table below presents the Interface MIB objects of an OLT interface, associated with the virtual link interfaces. Interface MIB object Value Value Value Value ifIndex 200001 200002 200003 265535 ifDescr "interface description" "interface description" "interface description" "interface description" ifType ethernetCsmacd (6) ethernetCsmacd (6) ethernetCsmacd (6) ethernetCsmacd (6) ifMtu MTUsize(1522) MTUsize(1522) MTUsize(1522) MTUsize(1522) ifSpeed 1000000000 1000000000 1000000000 1000000000 ifPhysAddress OLT_MAC_Address OLT_MAC_Address OLT_MAC_Address OLT_MAC_Address ifAdminStatus up up up up ifOperStatus Up Up Up Up ifLastChange ONU1_up_time ONU2_up_time ONU3_up_time up_time ifInOctets ONU1_octets_number ONU2_octets_number ONU3_octets_number BRCT_octets_number ifInUcastPkts ONU1_unic_frame_num ONU2_unic_frame_num ONU3_unic_frame_num BRCT_unic_frame_num ifInNUcastPkts ONU1_non_unic_frame_num ONU2_non_unic_frame_num ONU3_non_unic_frame_num BRCT_non_unic_frame_num ifInDiscards ONU1_disc_frame_num ONU2_disc_frame_num ONU3_disc_frame_num BRCT_disc_frame_numr ifInErrors ONU1_err_frame_num ONU2_err_frame_num ONU3_err_frame_num BRCT_err_frame_num ifInUnknownProtos ONU1_unknw_frame_num ONU2_unknw_frame_num ONU3_unknw_frame_num BRCT_unknw_frame_num ifOutOctets ONU1_octets_number ONU2_octets_number ONU3_octets_number BRCT_octets_number ifOutUcastPkts ONU1_unic_frame_num ONU2_unic_frame_num ONU3_unic_frame_num BRCT_unic_frame_num ifOutNUcastPkts ONU1_non_unic_frame_num ONU2_non_unic_frame_num ONU3_non_unic_frame_num BRCT_non_unic_frame_num ifOutDiscards ONU1_disc_frame_num ONU2_disc_frame_num ONU3_disc_frame_num BRCT_disc_frame_num ifOutErrors ONU1_err_frame_num ONU2_err_frame_num ONU3_err_frame_num BRCT_err_frame_num ifOutQLen ONU1_queue_frame_num ONU2_queue_frame_num ONU3_queue_frame_num BRCt_queue_frame_num 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 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 . 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 . Therefore, the EFM OAM MIB module 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 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 . 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 ( and ) 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 , clause 30. The tables are divided into relevant groups. oMPCP managed object class (30.3.5) dot3EPON MIB module object IEEE802.3ah attribute Reference ifIndex aMPCPID 30.3.5.1.1 dot3MpcpOperStatus aMPCPAdminState 30.3.5.1.2 dot3MpcpMode aMPCPMode 30.3.5.1.3 dot3MpcpLinkID aMPCPLinkID 30.3.5.1.4 dot3MpcpRemoteMACAddress aMPCPRemoteMACAddress 30.3.5.1.5 dot3MpcpRegistrationState aMPCPRegistrationState 30.3.5.1.6 dot3MpcpMACCtrlFramesTransmitted aMPCPMACCtrlFramesTransmitted 30.3.5.1.7 dot3MpcpMACCtrlFramesReceived aMPCPMACCtrlFramesReceived 30.3.5.1.8 dot3MpcpTxGate aMPCPTxGate 30.3.5.1.9 dot3MpcpTxRegAck aMPCPTxRegAck 30.3.5.1.10 dot3MpcpTxRegister aMPCPTxRegister 30.3.5.1.11 dot3MpcpTxRegRequest aMPCPTxRegRequest 30.3.5.1.12 dot3MpcpTxReport aMPCPTxReport 30.3.5.1.13 dot3MpcpRxGate aMPCPRxGate 30.3.5.1.14 dot3MpcpRxRegAck aMPCPRxRegAck 30.3.5.1.15 dot3MpcpRxRegister aMPCPRxRegister 30.3.5.1.16 dot3MpcpRxRegRequest aMPCPRxRegRequest 30.3.5.1.17 dot3MpcpRxReport aMPCPRxReport 30.3.5.1.18 dot3MpcpTransmitElapsed aMPCPTransmitElapsed 30.3.5.1.19 dot3MpcpReceiveElapsed aMPCPReceiveElapsed 30.3.5.1.20 dot3MpcpRoundTripTime aMPCPRoundTripTime 30.3.5.1.21 dot3MpcpDiscoveryWindowsSent aMPCPDiscoveryWindowsSent 30.3.5.1.22 dot3MpcpDiscoveryTimeout aMPCPDiscoveryTimeout 30.3.5.1.23 dot3MpcpMaximumPendingGrants aMPCPMaximumPendingGrants 30.3.5.1.24 dot3MpcpAdminState aMPCPAdminControl 30.3.5.2.1 dot3MpcpSyncTime SyncTime 64.3.3.2 oOMPEmulation managed object class (30.3.7) dot3EPON MIB module object IEEE802.3ah attribute Reference ifIndex aOMPEmulationID 30.3.7.1.1 dot3OmpEmulationType aOMPEmulationType 30.3.7.1.2 dot3OmpEmulationSLDErrors aSLDErrors 30.3.7.1.3 dot3OmpEmulationCRC8Errors aCRC8Errors 30.3.7.1.4 dot3OmpEmulationGoodLLID aGoodLLID 30.3.7.1.5 dot3OmpEmulationOnuPonCastLLID aONUPONcastLLID 30.3.7.1.6 dot3OmpEmulationOltPonCastLLID aOLTPONcastLLID 30.3.7.1.7 dot3OmpEmulationBadLLID aBadLLID 30.3.7.1.8 dot3OmpEmulationBroadcastBitNotOnuLLid dot3OmpEmulationOnuLLIDNotBroadcast dot3OmpEmulationBroadcastBitPlusOnuLlid dot3OmpEmulationNotBroadcastBitNotOnuLlid oMAU managed object class (30.5.1) dot3EPON MIB module object IEEE802.3ah attribute Reference dot3EponFecPCSCodingViolation aPCSCodingViolation 30.5.1.1.12 dot3EponFecAbility aFECAbility 30.5.1.1.13 dot3EponFecMode aFECmode 30.5.1.1.14 dot3EponFecCorrectedBlocks aFECCorrectedBlocks 30.5.1.1.15 dot3EponFecUncorrectableBlocks aFECUncorrectableBlocks 30.5.1.1.16 dot3EponFecBufferHeadCodingViolation

IANA has allocated a single object identifier for the MODULE-IDENTITY of the DOT3-EPON-MIB module under the MIB-2 tree. The MIB module in this document uses the following IANA-assigned OBJECT IDENTIFIER values recorded in the SMI Numbers registry:

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. 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. 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.