[8023-10GEPON] Feedback for Jeff's presentation
Disclaimer: I write this e-mail as a member of 10GEPON task force, not as
chair.
* * *
Jeff,
I have reviewed your presentation on FEC synchronization
(http://www.ieee802.org/3/av/public/2007_01/3av_0701_mandin_1.pdf).
I have a number of comments and questions about the approach you suggest. I
will go slide by slide.
Slide 4 "Upstream Burst Frame..."
-------------------------------
1) Why is Burst Delimiter should be multiple of 16 bit times? At which level
the bit times should be considered? MAC Control, PHY above FEC, PHY below
FEC? Can the delimiter be a single 66-bit block?
2) In the diagram on this slide, the "scrambler initial state" field is not
FEC-protected. This means, that if there is an error in this field, the
scrambler will not synchronize. What are the implications of this?
3) In the diagram on this slide the FEC codeword starts with a block
containing /S/. But the 10G Reconciliation Sublayer will not see a frame
delimiter if there is not at least one IDLE block before a block containing
/S/.
Slide 6 " Observations on the Scrambler"
-------------------------------------------
4) You write "Scrambler must therefore reinitialize for each burst into a
random state that is known both to the ONU and OLT".
Why would you need to stop and start scrambler at the ONU? In Frank's
presentation, the scrambler at the ONU runs continuously. This essentially
results in each burst starting with a new state and prevents "killer frame"
attacks. The OLT descrambler simply needs one scrambled IDLE to re-synch the
scrambler. Also this approach eliminates that special "Srambler Initial
State" field, which looks like a new mechanism for PHY-based messaging.
Slide 7 "PCS/Data Detector/Scrambler for 64b/66b code (ONU)"
-----------------------------------------------------------
5) You state "Natural location in the stack for the 10GEPON data detector
and syncing function is at the top of the PCS (just below the XGMII)."
I am very unclear how this would work. I see two problems:
a) The 66b encoder below the Data Detector may add or remove IDLEs to adjust
/S/ position. But the data detector located above would not know that the
first frame in the burst has moved. Therefore the laser_on signal from the
Data Detector would not be in sync with the actual data, potentially
resulting in the loss of the first frame (if the idles were removed in front
of the frame).
b) The last frame in the last FEC codeword in a burst may end in any of 29
payload blocks in this codeword. After the frame ended, all consequent
blocks will be idles, until some number of blocks later, a parity will be
inserted.
The problem here is that Data Detector is located above the FEC encoder and
never sees the parity. That means that it will start shutting down the laser
after the end of the frame, not after the end of the parity blocks.
If the Data Detector located below the FEC encoder, it sees the parity
blocks as non-IDLEs and starts shutting down the laser after the parity data
is sent.
Slide 8 "Placement of Data Detector/Synchronizer"
------------------------------------------------
6) The block diagram on this slide shows a line from Burst Mode Synchronizer
to PMA. The line is marked "Special Sync patterns For AGC/CDR/PCS
Synchronization". What exactly are these sync patterns?
If these are the 66b values that are being inserted in place of IDLE 66b
blocks, then these values should use the same data path as regular 66b
blocks. Perhaps, what you wanted to show is that these values bypass 66b
encoder and FEC encoder. As it looks now, the PMA should have two parallel
interfaces with the PCS.
Slides 9 and 10
--------------
Slides 9 and 10 are very unclear and I was not able to understand their
message after spending much time. I would strongly suggest you to make a
state diagram in the style we use in 802.3. That would make it much clearer.
Slide 13 "Option 1: Frame structure for DS..."
-------------------------------------------------
7) How is parity data formatted in this diagram? Does it look like 2 66-bit
blocks, or like a raw (unstructured) 128 bits?
8) Is it your proposal to use 66-bit blocks for upstream, but 65-bit block
for downstream?
If yes, does it mean that in symmetric 10G mode, either MAC or PHY will run
at different rates in the upstream and the downstream?
I wanted to give you this feedback now, so that you have a chance to prepare
responses or update slides before the presentation. I think the entire group
will benefit if you show a complete state machine for "Burst Mode
Synchronizer", including conditions for state transitions.
If anyone else could shed any light on the above questions, please jump in.
Regards,
Glen