Re: [8023-10GEPON] FEC Framing Adhoc - upstream synchronization
Jeff,
Then I believe there should be a reference saying that the method description is in the appendix. Sorry for the confusion - it was not so clear to me.
Best wishes
Marek Hajduczenia (141238)
SIEMENS Networks S.A. - IC COM D1 R
Rua Irmãos Siemens, 1
Ed. 1, Piso 1
Alfragide
2720-093 Amadora
Portugal
* Marek.Hajduczenia@siemens.com
http://marekhaj.easyisp.pl/index.php
(+351.21.416.7472 4+351.21.424.2082
-----Original Message-----
From: Jeff Mandin [mailto:Jeff_Mandin@pmc-sierra.com]
Sent: terça-feira, 12 de Dezembro de 2006 17:16
To: Hajduczenia, Marek; STDS-802-3-10GEPON@listserv.ieee.org
Subject: RE: [8023-10GEPON] FEC Framing Adhoc - upstream synchronization
> 1. slide 5: "Proposed method of two stage locking is relatively fast" -> what method ? There is no reference to any method before that - was something removed from the presentation ? The paer that was moved to
> the Annex should also therefore include current page 5 ... Here, we want only to mention that in general, the existing FEC locking methods working fine with continuous data stream are too slow to operate in the
> upstream channel for 10G systems ..
See the appendix. Frank supplied text on downstream algorithms to provide context on lock timing.
-----Original Message-----
From: Hajduczenia, Marek [mailto:marek.hajduczenia@SIEMENS.COM]
Sent: Tuesday, December 12, 2006 7:08 PM
To: STDS-802-3-10GEPON@listserv.ieee.org
Subject: Re: [8023-10GEPON] FEC Framing Adhoc - upstream synchronization
Dear all,
I had some time to look through the presentation and here are my comments (version updated by Jeff):
1. slide 5: "Proposed method of two stage locking is relatively fast" -> what method ? There is no reference to any method before that - was something removed from the presentation ? The paer that was moved to
the Annex should also therefore include current page 5 ... Here, we want only to mention that in general, the existing FEC locking methods working fine with continuous data stream are too slow to operate in the
upstream channel for 10G systems ..
2. pages >=7. I agree that the "burst leader" frame would probably solve a lot of problems in terms of FEC alignment etc. Regarding the issues with its lifecycle - correct me if I am wrong, but I think that in accordance with the Figure 64.10 "OLT Control Parser state diagram" in 802.3, upon reception of a properly formed data frame with the MAC_Control_type value in the Length/Type field, it is never passed to the MAC client and thus will never reach the upper network layers, thus cannot never get into the network beyond the EPON structure. I am not sure what happens at the 802.1D compliant bridges when a MAC_Control_type frame is received on one of the ports. From what I know, if a bridge receives sucha frame, it would not be relayed onto any of the output ports since it is transmitted with a broadcast target MAC address, thus it would be received by the MAC Control layer of the bridge and dropped eventually since the Opcode is not know to the bridge ..
There is one issue though - if we want to assure that such a frame dissapears at the PCS level, wouldn't it be a violation of the protocol stack ? The MAC_Control_type frames should be relayed in a transparent manner to the MAC control layer residing above MAC. Could You please clarify this point? Perhaps I am wrong ...
3. If I am not mistaken (again), introduction of new MPCP DUs would require revision of Annex31.A (and probably some more I am not aware of). Are we chartered to do that ?
4. page 10: I think the payload of a hypothetical "burst leader" frame should consist completely of an identifying sequence - the preamble should be sufficient for the synchronization for the OLT burst mode receiver and the 46 byte long payload should be rather devoted to carrying strictly identyfing sequence rather than 0x55 stream. Barker-like sequences are relatively short (the longest one has 13 characters only -> http://www.research.att.com/~njas/sequences/A091704) and we should have a look into longer sequences to assure large Hamming distance from any possible data patterns ...
Additionally, the size of the MPCP DU message (MAC_Control_type frame) is strictly defined and the size mentioned on slide 10 is larger than the currently valid MPCP size limit. Is there a problem with that ? 180 blocks x 64 bits = 1440 bytes ?? How was the value of 180 blocks derived ?
5. page 12 - the chart depicts the mean time to lost burst based on the formula depicted on page 11 ?
6. noob question: on page 13, it is said that "The 64 bit block that has maximal distance 31 from every shift of itself and the preamble is the 'Golden Block'" Could You clarify that ? I would like to understand that in more depth ... Is it simply based on shifting a copy of the block and counting the 1s after the XOR operation on the two blocks ??
7. page 14: "For delimiter with 2X+1 distance, apply following rule ..." - in previous slides, the N symbol was used to indicate the block sizes and distances ...
Thank You for Your time
Best wishes
Marek Hajduczenia (141238)
SIEMENS Networks S.A. - IC COM D1 R
Rua Irmãos Siemens, 1
Ed. 1, Piso 1
Alfragide
2720-093 Amadora
Portugal
* Marek.Hajduczenia@siemens.com
http://marekhaj.easyisp.pl/index.php
(+351.21.416.7472 4+351.21.424.2082
-----Original Message-----
From: Frank Effenberger [mailto:feffenberger@HUAWEI.COM]
Sent: segunda-feira, 11 de Dezembro de 2006 15:48
To: STDS-802-3-10GEPON@LISTSERV.IEEE.ORG
Subject: Re: [8023-10GEPON] FEC Framing Adhoc - upstream synchronization
Answered below.
-----Original Message-----
From: Jeff Mandin [mailto:Jeff_Mandin@PMC-SIERRA.COM]
Sent: Monday, December 11, 2006 9:13 AM
To: STDS-802-3-10GEPON@listserv.ieee.org
Subject: Re: [8023-10GEPON] FEC Framing Adhoc - upstream synchronization
Frank,
Thanks for this initial work. I like the general approach. Some questions:
1. What is intended by the statement that the signal on the fiber would include "IDLE blocks" at the start of a burst (slide 8)? Does this mean FEC codewords that consist entirely of 66b blocks which (in turn) consist solely of IDLEs??
>"Idle blocks" would be just 66b blocks containing all idle bytes. I
>tried
to always use "block" to mean 66b units, and 'codeword' to mean FEC units (data+parity). I may have made mistakes, of course.
2. Would the leader frame be a new MPCP type? Is it the case that the leader frame won't actually be passed to the receiving MAC?
>I suppose it could be a new type of MPCP type. It certainly needs some
special 'marking' so that if it somehow got onto a network, it would be discarded as not a real frame. It is true that the leader frame gets eaten by the receiving unit's PCS layer, so it doesn't arrive at the MAC. (I suppose the receiving PCS could re-generate the leader, since it is always the same content... I don't know if that is worth much of anything.
3. The transmitting PCS apparently performs special handling for the leader frame. Is it correct to say that the payload of the leader frame is "tailor-made" for the PCS framing/coding scheme and for the requirements of the PMD?
>Absolutely. The leader frame's sole purpose in life is to make the PCS
(and the PMA's and PMD's) life easier. Both the transmitting and receiving PCS treat the leader specially, in that they both synchronize their block and codeword clocks to the correlating pattern. Once that sync is done, the Tx and Rx go back to their 'ordinary' mode.
Best Regards,
- Jeff Mandin
-----Original Message-----
From: Jeff Mandin
Sent: Monday, December 11, 2006 3:43 PM
To: STDS-802-3-10GEPON@listserv.ieee.org
Subject: [8023-10GEPON] FEC Framing Adhoc - upstream synchronization
All,
1. I made minor changes to Frank Effenberger's ppt. (attached) ... slides now have numbers on them, and I moved the downstream synchronization slides to an appendix for later consideration (as it was primarily upstream issues that led to the adhoc). Some technical comments from me will follow shortly.
2. Telecon:
Can people attend a telecon this coming Wednesday/Thursday (Dec 13/14) at 1500 PST (2300 GMT, 0800 JST)?
3. Updated Adhoc participants list:
- Ryan Hirth
- Frank Effenberger
- Frank Chang
- Marek Hajduczenia
- Keiji Tanaka
- Piers Dawe
- Fumio Daido
- Glen Kramer
- Shoichiro Seno
Regards,
- Jeff Mandin
-----Original Message-----
From: EffenbergerFrank 73695 [mailto:feffenberger@HUAWEI.COM]
Sent: Tuesday, December 05, 2006 12:04 PM
To: STDS-802-3-10GEPON@listserv.ieee.org
Subject: Re: [8023-10GEPON] FEC Framing adhoc
Dear All,
Please find attached my draft contribution regarding delineation of FEC encoded 10G EPON signals. This considers both the continuous downstream and the burst upstream. I thought this way of discussing things was more logical, since we needed to know what the speed of locking of the continuous method was before we considered the burst mode problem.
Anyway, there it is.
On the issue of a conference call, I, too happen to be traveling in Asia (there is a conference in Hong Kong that many are attending). So, next week would be good for me as well.
Sincerely,
Frank Effenberger