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

Re: What is 802.3ae WAN-PHY?

I have sent another similar message to the reflector, that does not 
seems to be delivered.  This may be due to the large attached PDF 
file (68 kB), and hence I have requested Mr. David Law to post the 
file "XGENIE.pdf" to the "email_attach" directory at:
This is my second trial with smaller file "XGENIE07Apr00.pdf"(35 kB).
Hi Paul,

I am glad to hear from you, but please accept my apology for today 
responding to you halfway.  This evening my colleague and I will have 
a garden party to love cherry blossoms at their best here in Japan. 
We call it 'HANA-MI' (blossom watch), but its real purpose is, yes, 
to drink Kirin-Ichiban :-).

Thank you for your precise comments on SONET overhead bytes and 
its related issues.  Now I think we can discuss in more detail on 
the pros and cons of your SONET framer and my XGENIE.

To make things clear, I have modified my ad-lib pictures used for 
my private discussion with Rich.  Please check the attached PDF file 
first, and let me know if it includes wrong characters since I often 
encounter Japanese font issue in my PDF.

The first page shows the WAN-PHY connected with the ELTE (Ethernet 
Line Terminating Equipment); SONET framer approach (upper) and XGENIE 
approach (lower).  In both aproaches, I assume the Mr. Shimon Muller's 
open loop control slows the MAC rate at WAN-PHY to OC-192c payload 
rate.  I know you don't like 64/66 on SONET, but here please accept my 
assumption of it to make my comparison easy.

In your SONET-framer approach, you pack the STS Path at WAN-PHY with 
SONET-Lite framer.  Here you put the four overhead bytes; B3 and G1 
for end-end STS Path OAM&P and B1 and J0 for WAN-PHY to ELTE Section 
OAM&P.  In ELTE at Ethernet side, you terminate the Section and pick 
up the B1 and J0 bytes as well as open the SONET frame to pick up the 
STS Path without stripping off its B3 & G1 bytes.  The STS Path is 
transported by a vendor specific backboard interface to the SONET 
side of the ELTE.  You re-pack the STS Path into the SONET frame with 
a SONET clock (+/-20ppm at worse).  Here you put full SONET SECTION/
LINE overhead bytes into the frame to be compliant with full-SONET.  
Note that the SONET-framer is a power hungry circuits; our recent 
Line Terminating framer consumes about 3 W just for OC-48 (2.5 Gb/s).
(I do not think the four byte OAM&P is worth consuming these power.)

On the other hand, in our XGENIE approach, we insert the g1 and J0
ordered sets at the attachment unit of WAN-PHY (= LAN-PHY + XGENIE).
The g1 carries the same information as G1; the number of detected 
bit error for some time interval (around 125us) (REI: remote error 
indication) and the remote defect indication (RDI).  In ELTE at 
Ethernet side, we detect the bit error by using 64/66 code violation 
and use it as equivalence of b1 and b3.  Here we also pick up the g1 
ordered set and pass it to SONET framer to put it into the G1 byte.
We may also compensate B3 (BIP8) value if we have detected the code 
violation as b3.  This is to inform the bit error on path to the 
down stream.   If you don't like this loose mapping, you can use 
SDH tandem connection mechanism (G.707 Annex D) that inform the 
incoming bit error count and defect indication to the downstream 
by using N1 byte in the path overhead.  On the oppsite stream, 
we will perform the similar loose/precise mapping of (B3,G1,(N1)) 
to/from (b3, g1).

I know this is a kind of loose mapping.  However, my understanding 
of WAN-PHY is not a SONET but the Ethernet that supports the 
interoperability (OAM&P) of WAN connected to the SONET/SDH 
infrastructure.   I do not see any critical issues with this kind of 
loose mapping, since I see no requirement to know whether the bit 
error is occured in the same 125us frame or not.  

If you allow us these loose mapping, we can enjoy remarkable benefits;
we can use LAN-PHY attachment units instead of SONET-lite framers, 
we can use XAUI interface in the ELTE, even we can use CWDM solution 
for WAN-PHY.   

Wow, very sorry, but now I have to leave for drink....., no, loving 
the cherry blossomes.  I hope you can catch my point, and any feedback 
would be greately appreciated.

I also appreciate it if you kindly send me some feedback.

Best Regards,

At 10:40 AM -0700 00.4.6, Paul Bottorff wrote:
> Hi Osamu:
> The semantics of SONET management can not be preserved by the 10GENIE
> approach. Any transform performed by the ELTE will be approximate. Worse it
> will become the IEEE's problem to determine how to perform the transformation.
> IPG gaps do not occur at regular time intervals like SONET overheads. This
> means the timing relations in any management procedures will not be
> preserved. The results of timing shifts in the management information will
> require very careful consideration not only against specifications, but
> against implementations to assure they will work in practice.
> Here are some thoughts on the problem areas:
> B1- Just sending B1 to the WAN PHY does not help. How can the
> WAN PHY check the number of errors? This means that the ELTE
> will then need to report the number of errors to the WAN PHY
> instead.
> B3- Same problem as B1. ELTE needs to send the number of
> errors to the WAN PHY.
> G1- Who generates it? We want to terminate the PATH at the
> WAN PHY. Therefore all the detected defects would need to be
> reported to the WAN PHY, which would then send a G1 to
> the ELTE. Note that the WAN PHY would also report Loss of Packet
> delineation through G1. Loss of packet delineation can only
> be detected by the WAN PHY.
> J0, J1, C2, K1, K2, S1 - These octets have fixed values.
> The WAN PHY simply sends them to the ELTE.
> SONET timing considerations would need to be addressed
> correctly.
>    2a- How often can these overheads be sent to the ELTE?
>    2b- Does the WAN PHY guarantee enough IPGs to satisfy
>        SONET timing requirements?
>    2c- Can G1 report the defects on the last SPE in time?
> Path is no longer terminated end-to-end.
> The WAN PHY should terminate the PATH and not the ELTE. Routing
> the Path status through the WAN PHY does not make it the
> Path Terminating Equipment. Faults at the links between the
> WAN PHYs and ELTEs are not being covered by B1 and B3. The
> path is not terminated end-to-end.
> The solution using a SONET-format frame is easy. The management operations
> of the ELTE simply follow SONET rules which are understood by the teams
> developing the SONET sides.
> Cheers,
> Paul
> At 09:02 PM 4/6/00 +0900, Osamu ISHIDA wrote: