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

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,

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 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:
> 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>