Re: Interface reality check
Osamu,
Am I to interpret you are now supporting "UniPHY" because it IS
non-deterministic? For someone who represents a Telo this is a very strange
position. It would mean that you may not be able to provide an SLA on the
transport payload.
Thank you,
Roy Bynum
----- Original Message -----
From: Osamu ISHIDA <ishida@exa.onlab.ntt.co.jp>
To: Bharadwaj S Amrutur <bharadwaj_amrutur@agilent.com>; Roy Bynum
<rabynum@mindspring.com>
Cc: <stds-802-3-hssg@ieee.org>
Sent: Thursday, April 13, 2000 2:20 AM
Subject: 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@agilent.com>
> http://grouper.ieee.org/groups/802/3/10G_study/email/msg02274.html