DOT3-EPON-MIB Table View

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

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

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

This table defines the list of statistics counters of
          
[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).

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

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

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

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

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.