Re: Interface reality check
Hi Birdy, Hi Roy,
As for XGENIE, I think both of you are correct and simply see the
different features. Sorry for my delay to figure out the comparison
between the SONET framer and XGENIE approaches; the unpredicted job in
my another daily work, it is a kind of developing SDH 'non-muxing LTE',
have pushed it on my weekend ;-(.
http://grouper.ieee.org/groups/802/3/10G_study/email/msg02221.html
I think Roy has pointed out the fact that XGENIE can not preserve
the strict 125us-framing of SONET Path, where the B3 byte for the
bit-interleaved parity (BIP) is the exact parity of the previous
STS-192c package of 150,336 bytes (=261*64*9). This has been
farsightedly pointed out by Mr. Paul Bottorff together with many
important aspects to be considered on XGENIE.
http://grouper.ieee.org/groups/802/3/10G_study/email/msg02127.html
No, XGENIE will not support these strict sense of BIP.
It will just support the way of monitoring the bit-error-rate.
Hence I have used the term 'loose mapping' in my previous mail.
http://grouper.ieee.org/groups/802/3/10G_study/email/msg02168.html
Note that here I assumed the path signaling would be loosely (you
can say it illegally with the SONET Std.) relayed from XGENIE to
SONET POH; this is inevitable if we adopt EOS or SLP on full-SONET
where IPG seems not to be allowed to be transparent.
On the other hand, there is another way to have end-end path by
using XGENIE if we adopt the Mr. Howard Frazier's Uni-PHY with
SONET-compliant output (+/-20ppm) at ELTE. This has already
been pointed out by Dae, Jonathan, and Rich.
http://grouper.ieee.org/groups/802/3/10G_study/email/msg02198.html
http://grouper.ieee.org/groups/802/3/10G_study/email/msg02233.html
http://grouper.ieee.org/groups/802/3/10G_study/email/msg02205.html
I think this is what Birdy has pointed out.
Yes, this is possible, and will works well. To this end, I have
changed my position to be supportive to Uni-PHY instead of the EOS.
http://grouper.ieee.org/groups/802/3/10G_study/email/msg01895.html
I would like to add one my personal comment to ALL;
supporting SONET-framed PHY with +/-100 ppm could be the choice of
this community, and I would pay regard to your consensus. However,
please be aware that there is at least one person in Telecom, me,
who feel like this is a 'JUMBO frame' in SONET. You may say that
this is not SONET. But you may be able to connect it directly to the
new active transponder. You may not be able to connect it directly
to the old active transponder.........
http://grouper.ieee.org/groups/802/3/10G_study/email/msg02257.html
I hope we will not see another JUMBO frame issue in the real world.
As I have stated in the previous mail, this might be based on my
wrong observation on +/-100ppm standard. Any disclosure
information on this matter would be greatly appreciated.
Best Regards,
Osamu
At 5:27 PM -0700 00.4.12, Bharadwaj S Amrutur wrote:
http://grouper.ieee.org/groups/802/3/10G_study/email/msg02286.html
> I believe, the XGENIE proposal envisions itself to be in between the
> XGXS (or is it RS ?) and the PCS - I might have got the layer names
> wrong, but essentially they want to avail of the inter packet gap and insert
> some control octets. Since this is before the PCS layer, 64/66 can code
> this up. You can refer to Rick Walkers posting on how he plans to do that -
> its buried somewhere in the morass of posting.
At 6:05 PM -0500 00.4.12, Roy Bynum wrote:
http://grouper.ieee.org/groups/802/3/10G_study/email/msg02281.html
> I may help with an observation. While the input of the 64B/66B encoding is
> a serial octet stream, the output is not. The output of 64B/66B encoding
> achieves octet alignment only on input data frames at 256 octet boundaries,
> which outputs to 264 octet boundaries. For a LAN only PHY which does not
> have framing boundaries, that is not an issue. For the WAN compatible PHY
> with a fixed synchronization frame payload, being on octet boundaries with
> the encoded data is an issue. This might also be an issue with XGENIE,
> which if I understood correctly, also used fixed octet payload boundaries.
>
>> ----- Original Message -----
>> From: Bharadwaj S Amrutur <bharadwaj_amrutur@xxxxxxxxxxx>
http://grouper.ieee.org/groups/802/3/10G_study/email/msg02274.html