Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: Interface reality check


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@xxxxxxxxxxxxxxxxxxx>
To: Bharadwaj S Amrutur <bharadwaj_amrutur@xxxxxxxxxxx>; Roy Bynum
Cc: <stds-802-3-hssg@xxxxxxxx>
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 ;-(.
> 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.
> 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.
> 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.
> 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.
> 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.........
> 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:
> > 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
> > 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:
> > I may help with an observation.  While the input of the 64B/66B encoding
> > a serial octet stream, the output is not.   The output of 64B/66B
> > achieves octet alignment only on input data frames at 256 octet
> > which outputs to 264 octet boundaries.   For a LAN only PHY which does
> > have framing boundaries, that is not an issue.  For the WAN compatible
> > with a fixed synchronization frame payload, being on octet boundaries
> > the encoded data is an issue.  This might also be an issue with XGENIE,
> > which if I understood correctly, also used fixed octet payload
> >
> >> ----- Original Message -----
> >> From: Bharadwaj S Amrutur <bharadwaj_amrutur@xxxxxxxxxxx>