Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Action item #32, aFecMode attribute

Dear colleagues,

 

I started looking at the action item #32, associated with the aFecMode attribute. The description calls for the following three sub-tasks:

 

  • #32.1 Change is needed to indicate new data rates.
  • #32.2 Default should be set to enabled.
  • #32.3 Also, FEC should be per ONU, not per LLID.

 

In reviewing the existing attributes, I noticed we have … an overlap in the attribute names. We have aFecMode attribute (0x07/0x01-3A, subclause 14.3.7.4), which represents the FEC operation on the PON port, and then we have another aFecMode attribute (0xDB/0x06-05, subclause 14.4.7.3), which seems to independently control the upstream and downstream FEC status. I focused first on the second instance i.e., 0xDB/0x06-05, subclause 14.4.7.3.

 

Changes to the 0xDB/0x06-05 attribute to address #32.2 and #32.3 sub-tasks would be as follows:

 

  • In aFecMode.sFecDown and aFecMode.sFecUp, change the default value from “disabled” to “enabled” (addresses #32.2)
  • Modify the existing text “The aFecMode attribute is associated with the LLID or the ONU object” to read “The aFecMode attribute is associated with the ONU object” (addresses #32.3)
  • Strike the following text: “If aFecMode attribute is associated with the downstream-only LLID object, the OLT and the ONU ignore the sub-attribute aFecMode.sFecUp.” (addresses #32.3)

 

However, the sub-task #32.1 got me looking into the 802.3ca to understand whether we even have a way to disable FEC in Nx25G-EPON. All Clause 45 register updates were focused on extending FEC-related counters i.e., corrected FEC codewords counter (Register 3.76, 3.77) and uncorrected FEC codewords counter (Register 3.78, 3.79), while leaving the FEC capability registers (FEC ability register (Register 3.74), FEC control register (Register 3.75)) unchanged. This tells me there was no expectation that the Nx25G-EPON system would be able to disable FEC in either direction. This puts the purpose of the aFecMode attribute (0xDB/0x06-05, subclause 14.4.7.3) into question, since FEC is always enabled for downstream and upstream, and the purpose of having an attribute that will always return “enabled” on read and fail on attempting to disable FEC is somewhat questionable.

 

I would therefore recommend we remove aFecMode (0xDB/0x06-05, subclause 14.4.7.3), which seems to be pretty much useless in Nx25G-EPON system, where FEC cannot be disabled.

 

Once that aFecMode (0xDB/0x06-05, subclause 14.4.7.3) attribute is gone, the value of the aFecMode (0x07/0x01-3A, subclause 14.3.7.4) attribute also becomes questionable, since it would always return “enabled”, given that it is not possible to disable the FEC at all.

 

I would therefore recommend we also remove aFecMode (0x07/0x01-3A, subclause 14.3.7.4), which adds no value at all, reporting always one and the same value of “enabled”.

 

My assumption is that (a) NMS systems will need to be updated to support Nx25G-EPON systems anyway, so adding logic to not check FEC status in Nx25G-EPON would not be disruptive at all in this case, and (b) even if the NMS was not updated and did query the ONU for this attribute, ONU is always able to respond with the “Unsupported” error code (0xA1) we already have in the standard. I think, therefore, that the removal of both of these attributes would be the cleanest way to move forward to address this Action Item.

 

Any feedback would be really welcome.

 

Regards

 

Marek

 

 

 

 

To unsubscribe from the STDS-1904-4-TF list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-1904-4-TF&A=1