Re: [8023-10GEPON] [FEC] Mandatory or Optional (was [FEC Superating] - kickoff preso)
Thomas,
Thank you for the good analysis of penalty associated with line rate
increase. I am as well leaning to keep PHY rate as it is, and slow down
the MAC (as is done in Ethernet in the past many times).
The following your question is somewhat different though, so I started a
new thread under the [FEC] tag.
> Finally in response to your point that if the FEC is mandatory, that
> another approach could be taken, why does the FEC have to be mandatory
> for this?
> For optional FEC couldn't one do the following (again stated from a
> FEC/PCS ignorant point of view). When FEC is turned on both
PCS(64B/66B,
> scrambling or other) and FEC are combined to deliver smaller combined
> overhead. When FEC function is turned of only PCS coding is enabled.
I should clarify that no final decision has been made by the task force
yet on whether FEC should be mandatory of optional, though a straw pall
in Monterey has indicated a preference for mandatory usage.
Unlike 1G EPON, which used a frame-based FEC, 10G is converging on a
stream-based approach. It is easier to do at high speed and with 64b/66b
coding, but the downside is that non-FEC-capable (or non-FEC-enabled)
devices would not understand the incoming data.
Because stream-based FEC changes format of the line data, it seems that
synchronization mechanisms would be different with and without FEC.
Thus, OLT and ONUs would have to implement two Tx and two Rx paths in
PCS, and enable only one at a time.
The question is how an ONU would start? Should it enable a sync machine
with FEC or without FEC? Should it start at normal rate or increased
rate, if super-rating is used? It maybe that all previously registered
ONUs are close enough and the OLT decided to turn the FEC off. But the
new ONU that tries to register is far away. How would it signal OLT to
turn the FEC back on? It is also very unclear if switching FEC on and
off on the fly would even be possible.
So, if we decide to make FEC optional, it probably would have to be a
static configuration, where a carrier decides in advance that all
devices attached to this particular EPON should be pre-configured to use
or not use FEC.
As far as I understand, carriers are not particularly fond of the idea
of having different configurations for different segments of their
networks. There is always a concern that an ONU with a wrong
configuration would be attached to a wrong EPON, etc. Also, monitoring
equipment and protocol analyzers need to be aware of what signal format
to look for.
I think that in reality, a carrier would keep the same configuration for
all EPONs, and if any of the ODNs require FEC, it will enable FEC for
all of them anyway. (Carriers - please comment.)
10GEPON leads to 1000% bandwidth increase compared to 1G EPON. I don't
think it would be such a detrimental thing for the adoption of the
technology if the bandwidth will increase "only" 930% due to always-on
FEC. On the other hand, it would make devices simpler (as well as
cheaper and probably consuming less power) as only one Rx and Tx path
will need to be implemented, and it will simplify configuration.
In other words, I see 10GEPON FEC as part of a new line coding, not as a
separate option. 1G uses 8b/10b with 20% overhead + separately 9% FEC
overhead. The new line coding in 10G EPON uses 10% (3%+7%) and includes
FEC.
Glen
------------------------------------------------------------------------
--
DISCLAIMER: This e-mail expresses my views as an individual contributor
to
the task force, not as task force chair.
------------------------------------------------------------------------
--