Hi,
As I have promised in the IEEE meeting, I have put in another look at the FEC_overhead function to try to suggest a coherent behavior. These are my conclusions. Appreciate comments.
A bit of a history.
The FEC_overhead function is a legacy heritage from 802.3ah clause 64. The function appears in 3 places with 2 use cases.
Basically the function calculates the additional overhead that should be added to a packet due to the FEC. In the 802.3ah frame based FEC, this is a value per packet which depends only on the packet length.
1) OLT transmit state machine:
The overhead is used to add a delay after the packet, to stall the MPCP layer (which also inserts timestamp) to match the MAC transmission.
2) ONU transmit state machine.
The overhead appears in 2 places:
A) The overhead is used to check if the packet fits inside the remaining time for grant transmission.
B) The overhead is used to add a delay after the packet, to stall the MPCP layer (which also inserts timestamp) to match the MAC transmission.
3) Gate processing ONU activation state diagram
The overhead is used to reduce the window for the random delay.
Use in 802.3av
Currently the function was exported to the 802.3av, as is, in all state machines, just the formula was changed a bit.
However when checking, it seems that a different adaptation is needed due to the fact that the FEC is now stream based and not packet based.
Looks like it would be more convenient to divide the overhead into 2 functions for each use case in the state diagrams.
One function (FEC_Overhead_tx) to check if the packet fits the grant and the other (FEC_Overhead_delay) calculating the delay for the MAC.
(Basically the discovery calculation should use the first function however we can simply put in there a fixed value of single CW, as all values there are fixed and known (frame size is 64bytes) and have the random in CW granularity).
The FEC_Overhead_tx takes all worse case rounding scenarios. It includes rounding up of the current packet size into the nearest FEC codeword. (This what would happen if it is the last frame in the grant)
The FEC_Overhead_delay reflects the estimated delay required after a packet due to insertion of FEC overhead. So the average value for IPG (ie. 12) is used, and the packet size (plus the "balance" remaining from the previous packet) should be rounded down to the nearest FEC block. If the FEC block is not full then the there is no delay added.
The FEC overhead is a function of packet length, IPG and (localTime-beginTime).
(localTime-beginTime) defines the position of the packet in the FEC codeword's chain.
At the OLT - beginTime is the OLT init time.
At the ONU - beginTime is the start of the Fec codewords in the grant (start_time+laser_on+syn_time)
Please see the following diagram:
Inaccuracies:
There is an inherent inaccuracy in both functions since the MPCP layer works in TQs and not bytes.
Another inaccuracy is involving the IPG which should be added in the overhead. IPG changes in 10G between 9-15bytes due to the DIC functionality.
The state machines of the MPCP coordinates between the MAC and MAC control which are not aware of the DIC so we could have fixed IPG to 12bytes. However the function really should be aware of the line transmission so DIC should be accounted.
FEC_Overhead_tx can must ensure that the packet can be transmitted. So it either takes worse case for the IPG (15 bytes) or holds a DIC function like the RS and monitor the real IPG.
FEC_Overhead_delay can use the average of 12 bytes and MAC would be aligned. The data on the line will jitter in 3bytes (added to the RTT jitter).
.
Therefore the 2 FEC overhead functions are:
///////////////////////////////////////////////////////////////Functions to the text of the draft//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
FEC_Overhead_tx(length)
This function calculates the size of additional overhead, to be added by the FEC encoder, while encoding a frame of size length, using worst-case assumptions about FEC parity requirements for the frame. The function is used to check if the packet fits the grant.
This function is calculated at the beginning of the packet.
Parameter length represents the size of an entire frame including preamble, SFD, DA, SA, Length/Type, and FCS.
As described in Clause @@92.2.3@@, FEC encoder adds 32 parity octets for each block of 216 data or control octets.
The following formula is used to calculate the overhead:
Parameters:
IPG [bytes] - IPG =15
payloadBalance [bytes]
FEC_Overhead_tx [TQs]
length [bytes] - the length of a packet, not including IPG
beginTime [TQs]
localTime [TQs]
Initial conditions
OLT:
beginTime = start_of_time
payloadBalance =0
For the ONU the initial conditions are set at beginning of a grant:
beginTime = start_of grant_time + laser_on + sync_time
payloadBalance =0
The value for each packet:
payloadBalance = ((localTime – beginTime)*20)%248 + length + IPG
FEC_overhead_tx = round_up(((32+ 216) *round_up( payloadBalance / 216) - payloadBalance)/20)
FEC_Overhead_delay(length)
This function calculates the size of additional overhead to be added by the FEC encoder while encoding a frame of size length as the last frame in the grant.
The function provides the additional delay before the next packet to fit to the gap the FEC encoder needs for the parity bytes
This function is calculated at the beginning of the packet.
Parameter length represents the size of an entire frame including preamble, SFD, DA, SA, Length/Type, and FCS.
As described in Clause @@92.2.3@@, FEC encoder adds 32 parity octets for each block of 216 data or control octets.
The following formula is used to calculate the overhead:
Parameters:
IPG [bytes] - IPG =12
payloadBalance [bytes]
FEC_Overhead_tx [TQs]
length [bytes] - the length of a packet, not including IPG
beginTime [TQs]
localTime [TQs]
Initial conditions
OLT:
beginTime = start_of_time
payloadBalance =0
For the ONU the initial conditions are set at beginning of a grant:
beginTime = start_of grant_time + laser_on + sync_time
payloadBalance =0
The value for each packet:
payloadBalance = ((localTime – beginTime)*20)%248 + length + IPG
FEC_overhead_delay = round_up(32/20*round_down(payloadBalance / 216 ))
NOTE–The notation round_up(x) represents a ceiling function, which returns the value of its argument x rounded up to the nearest integer. The notation round_down(x) represents a flooring function, which returns the value of its argument x rounded down to the nearest integer. The notation a%b represents a modulo division of two numbers a and b.
//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
Another note is that currently as the draft is defined there is a potential condition that even though we do a compensation of the delay there can be the case that the PCS will not be ready for the next packet. This case happens when exactly the packet should be transmitted and the PCS transmits parity bytes of IPGs (this can happen if there is gaps between the packets which is above the minimal IPG). This will add a 2TQs jitter in the timestamp. The timestamp is added to the packet but the MAC will not start transmitting due to the feedback from the PCS (using PLS_CARRIER.indication(CARRIER_STATUS)) which delays the MAC. This feedback should be removed and the PCS should hold an elastic jitter FIFO to compensate with a maximal delay width and make it a fixed delay. Please note that both FEC_overhead_tx and FEC_overhead_delay will compensate for that in the MAC and should be accurate.
Best regards,
Lior Khermosh
PMC-SIERRA