Re: [8023-10GEPON] FEC Framing Adhoc - upstream synchronization
>> 2. What kind of transmission delay in the FEC layer is acceptable for 10G system ? I remember reading about 20 bit times for stack transition in 1G EPONs but I have no idea about the respective value for the 10G system ...
>This hasn't been discussed as far as I know. However it seems that the same time limits as for 1G are sufficient ie. 16ns maximum PHY delay. I think we should reduce the guard times from their 1G values but
>they are already quite large.
_Actually_ the 16 bit times maximum is of course for delay variation, not for delay (64.3.2.4).
-----Original Message-----
From: Jeff Mandin
Sent: Thursday, December 14, 2006 3:52 PM
To: 'Hajduczenia, Marek'; STDS-802-3-10GEPON@listserv.ieee.org
Subject: RE: FEC Framing Adhoc - upstream synchronization
> 1. Is the data at the FEC sub-layer received in a serialized form or in complete 66 bit wide codewords ?
We've been assuming that FEC receives scrambled 66b blocks from PCS.
> Where to look for such information ? Havring read the whole standard, all the clauses are still intermixed in my mind ...
Clause 74 describes FEC for 10GBASE-R standards. That would seem to include 10GEPON, so my guess is that we will describe it there.
> 2. What kind of transmission delay in the FEC layer is acceptable for 10G system ? I remember reading about 20 bit times for stack transition in 1G EPONs but I have no idea about the respective value for the 10G system ...
This hasn't been discussed as far as I know. However it seems that the same time limits as for 1G are sufficient ie. 16ns maximum PHY delay. I think we should reduce the guard times from their 1G values but they are already quite large.
- Jeff
-----Original Message-----
From: Hajduczenia, Marek [mailto:marek.hajduczenia@siemens.com]
Sent: Thursday, December 14, 2006 3:37 PM
To: Jeff Mandin; STDS-802-3-10GEPON@listserv.ieee.org
Subject: FEC Framing Adhoc - upstream synchronization
Dear all ...
Just two simple questions:
1. Is the data at the FEC sub-layer received in a serialized form or in complete 66 bit wide codewords ? Where to look for such information ? Havring read the whole standard, all the clauses are still intermixed in my mind ...
2. What kind of transmission delay in the FEC layer is acceptable for 10G system ? I remember reading about 20 bit times for stack transition in 1G EPONs but I have no idea about the respective value for the 10G system ...
Thank You
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: quinta-feira, 14 de Dezembro de 2006 10:15
To: STDS-802-3-10GEPON@listserv.ieee.org
Subject: [8023-10GEPON] FW: Bridge details
Moving this discussion back to the main reflector.
-----Original Message-----
From: Fumio Daido [mailto:daido-fumio@sei.co.jp]
Sent: Thursday, December 14, 2006 12:11 PM
To: glen.kramer@teknovus.com
Cc: 'Frank Effenberger'; Jeff Mandin; kj-tanaka@kddilabs.jp; marek.hajduczenia@siemens.com; 'Ryan Hirth'; 'Frank Chang'; piers.dawe@AVAGOTECH.COM; 'Shoichiro Seno'; k-shiraishi@bq.jp.nec.com
Subject: Re: Bridge details
Glen,
I reviewed proposals after FEC adhoc tel conference. I will show you my concern as follows.
Could you estimate how many 66 bits correlator to detect 66B boundary are needed for instant lock of 66B block? I think pararel implementaion is needed for quick lock. I am concerned about size of hardware for detecting 66B block boundary.
If 64 bits delimiter (exclude 2bit sync bits) is large, 64 bits delimeter can be divided into 32 or 16 bits delimeter.
Regards,
Fumio Daido
Glen Kramer wrote:
> Frank,
>
>> I think Glen and I can work on a joint presentation next week, if
>> he's willing.
>
> I'll be delighted to. I may be traveling next week, but should be
> online somewhat regularly.
>
> I am not very clear how to do a single-stage locking. Maybe we could
> start with that discussion.
>
> Glen
>
>
>
>> -----Original Message-----
>> From: Frank Effenberger [mailto:feffenberger@huawei.com]
>> Sent: Wednesday, December 13, 2006 3:41 PM
>> To: 'Jeff Mandin'; kj-tanaka@kddilabs.jp;
>> marek.hajduczenia@siemens.com; 'Ryan Hirth'; 'Frank Chang';
>> daido-fumio@sei.co.jp; piers.dawe@AVAGOTECH.COM; 'Glen Kramer';
>> 'Shoichiro Seno'; k- shiraishi@bq.jp.nec.com
>> Subject: RE: Bridge details
>>
>> Sorry about that - what can I say, it's not exactly the first-world, yet.
>>
>> Anyway, continue on without me. My position in a nutshell is this:
>>
>> 1. Leader-frame vs. data-detector insertion: I agree with Glen. His
>> approach is must simpler and better.
>>
>> 2. Pattern: I strongly favor a pattern of 0x55's, followed by a
>> single- stage delimiter block. This is different from what Glen
>> proposes.
>>
>> 3. Two-stage locking is for the downstream, because we don't have any
>> strong delimiter there. But in the upstream, it is not needed.
>>
>> I think Glen and I can work on a joint presentation next week, if
>> he's willing.
>>
>> Regards,
>> Frank E.
>>
>>
>>
>>