Re: [8023-10GEPON] [FEC] Notes to 12/2/07 Telecon and Next Steps
Glen,
Thanks for these remarks. My responses are below. As well, I've posted revised notes.
1. As we discussed on the call, even though the MAC obviously doesn't insert IDLEs (rather it backs off from frame transmission so that the RS inserts the IDLEs), MAC Control presumably needs to know how this is done so that it can compute the FEC overhead (as is done in clause 64.2.2.4 for GEPON). So MAC Control "deals with" IDLE insertion even though the IDLEs themselves can't possibly be exposed to the MAC. This was the intent of the original remark about "deal(ing) with IDLE insertion at the MPCP layer". Anyway the revised notes say "RS" to address your concern.
2. >
>This statement requires some clarification. On the call we have discussed two reasons for IDLE insertion/deletion:
>
> 1) To adjust start of the first frame in a burst to lane 0 (in one proposal). This manipulation is not related to sub-rating and it is indeed should be done at or above 66b encoder.
>
Actually the alignment of the first frame to lane 0 does not make use of IDLE insertion/deletion. In both proposals, the PCS makes switches from transmission of the initialization patterns (ie. 1010..) to the Barker delimiter to transmission of "real" 66b blocks. One proposal intends to make this switch at the top of the PCS (by examining XGMII words), the other at the bottom of the PCS (by examining 66b sync headers). One consequence of using XGMII words is that the first frame in a burst is aligned to lane 0 (ie. compared to the other scheme the 1010. pattern will persist for a time equivalent to an additional XGMII word).
> 2) To remove IDLE 66b blocks in order to make space for parity 66b blocks, i.e., for the sub-rating case.
> This removal, as we discussed on the call, should happen before the Scrambler (so that self-synchronization is preserved), but not necessarily before the 66b encoder.
It seems that the main issue is whether the function will go above the 66b encoder or below. Since there's no consensus on that, the sentence in question has been deleted in the revised notes (which is fine since the discussion just got started). Thank you (and Frank) for this correction.
BRs,
- Jeff
-----Original Message-----
From: Glen Kramer [mailto:glen.kramer@teknovus.com]
Sent: Thursday, February 15, 2007 12:29 AM
To: Jeff Mandin; STDS-802-3-10GEPON@listserv.ieee.org
Subject: RE: [8023-10GEPON] [FEC] Notes to 12/2/07 Telecon and Next Steps
Jeff,
Thank you for the minutes and outlining next steps. Also, on behalf of all call participants, thank you for staying up that late to accommodate other geographic regions.
A few small notes on the minutes below.
> Glen suggested expanding the scope
> of the adhoc to deal with IDLE insertion at the MPCP layer.
On the call, I mentioned that there exist several methods to slow down the MAC, including one method specified at MPCP layer. I explicitly emphasized that MAC Control sublayer and MPCP cannot and should not deal with IDLEs, which are generated at a lower sublayer.
On the call I outlined a possible way to use Reconciliation sublayer to toggle CS line to an Annex 4A MAC and count/mark IDLEs. But I did not suggest expanding the scope of the ad hoc or making the IDLEs somehow exposed to MAC Control.
Also, concerning the following statement:
> 3) How to perform IDLE insertion/deletion in the subrating case.
> There is agreement that the IDLE deletion function belongs above the
66b
> encoder.
This statement requires some clarification. On the call we have discussed two reasons for IDLE insertion/deletion:
1) To adjust start of the first frame in a burst to lane 0 (in one proposal). This manipulation is not related to sub-rating and it is indeed should be done at or above 66b encoder.
2) To remove IDLE 66b blocks in order to make space for parity 66b blocks, i.e., for the sub-rating case.
This removal, as we discussed on the call, should happen before the Scrambler (so that self-synchronization is preserved), but not necessarily before the 66b encoder.
I hope these corrections will make the call record more accurate. If anyone who attended the conf. call disagrees or notices something else, please jump in.
Thank you,
Glen
> -----Original Message-----
> From: Jeff Mandin [mailto:Jeff_Mandin@PMC-SIERRA.COM]
> Sent: Wednesday, February 14, 2007 1:19 PM
> To: STDS-802-3-10GEPON@listserv.ieee.org
> Subject: [8023-10GEPON] [FEC] Notes to 12/2/07 Telecon and Next Steps
>
> Attendees:
> ---------------
>
> Frank Effenberger
> Brian Holden
> Eric Lynskey
> Glen Kramer
> Frank Chang
> Feng Dongning
> Shoichiro Seno
> Jeff Mandin
>
>
> Notes:
> ---------
>
> Jeff presented his slides on upstream burst initialization
> (http://www.ieee802.org/3/10GEPON_study/email/msg00426.html).
>
> Discussion continued for 90 minutes or so (til 0230 my time)... There
was
> not time for a proper wrap-up - so please see "next steps" section
below.
>
> As in the last call, there was some discussion on topics such as
whether
> it's better for the spec to have one FSM vs. having more than one FSM
with
> communication between etc. but we agreed to focus on the issues with
real
> technical impact.
>
> Among the topics discussed:
>
> 1) Whether the burst initialization sequence should align the
66b
> encoder to the start of the first frame of the burst (ie. just as it
> aligns the FEC codeword to the first 66b block of the burst). Or
whether
> alternatively the alignment should stay as it was when the laser was
off.
> It has been suggested that this has ramifications for MPCP.
>
> 1a) Relatedly: whether the Data Detector (and burst
initialization
> sequence more generally) should look at the content of the XGMII words
-
> or instead determine the start and end of the burst implicitly from
the
> synchronization headers of 66b blocks with scrambled payloads.
>
> 2) Subrating vs. Superrating. Pending the decision of the
appointed
> adhoc group, the FEC group prefers for now to orient its scheme for
the
> subrating option. Subrating seemed to be the preference of all the
FEC
> participants who expressed an opinion.
>
> 3) How to perform IDLE insertion/deletion in the subrating case.
> There is agreement that the IDLE deletion function belongs above the
66b
> encoder. Aside from that there are several broadly different ideas
about
> what should be done (eg. having the RS send CRS to the MAC and somehow
> mark the southbound inserted IDLEs). Glen suggested expanding the
scope
> of the adhoc to deal with IDLE insertion at the MPCP layer.
>
>
> Summary + Next Steps
> --------------------------------------
>
> There has been agreement for a while on the high-level flow for
upstream
> initialization. The primary architectural difference between the 2
> schemes on the table is whether to identify, frame, and align the
burst
> on the basis of 32-bit XGMII words or on the basis of 66b blocks (as
> detailed in item 1 above). If this issue is settled soon, we should
be
> able to work out the other issues and submit a consensus baseline
proposal
> on the upstream for Orlando.
>
> The following is my suggestion of how to proceed:
>
> * Let's continue the focus on the upstream. If there is time before
> Orlando after completing a baseline proposal then we should move to
the
> downstream.
>
> * With respect to the alignment issue: I will prepare a summary the
> points raised on both sides, and also address the suggestion that
there
> could be a difficulty in using the existing 66b encoder FSM to align
at
> the start of burst. I'll distribute this by the end of Monday
> (hopefully). Anyone else is of course welcome to present their views
on
> this topic.
>
> * In parallel, I suggest that we prepare presentations to elaborate
on
> the ideas for IDLE insertion/deletion that were mentioned this week.
> Please let me know if you interested in putting something together on
> this. I'd like do this particularly if our work is going to be
described
> to 802.3 in Orlando.
>
>
> Next Telecon
> -------------------
>
> The next telecon is current scheduled for Tues/Wed. Feb 20/21 at 1500
PST/
> 2300 GMT/ 0800 JST. Bridge details are the same as last time.
>
>
> BRs,
>
> - Jeff