RE: What is 802.3ae WAN-PHY?

["David Martin" <dwmartin@xxxxxxxxxxxxxxxxxx>]

Title: RE: What is 802.3ae WAN-PHY?

Osamu,

The presentation I made in Albuquerque:

http://grouper.ieee.org/groups/802/3/ae/public/mar00/martin_2_0300.pdf

clarified requirements for a WAN-compatible PHY. This considered ongoing activities
in other standards bodies such as ANSI/ITU. Our WAN-compatible PHY proposal:

http://grouper.ieee.org/groups/802/3/10G_study/public/nov99/figueira_2_1199.pdf

meets the above requirements. A key benefit of this approach is that P802.3ae does
not need to be concerned with steering work in other standards bodies to ensure an
ELTE will support 10GE. Your proposal would require P802.3ae to drive work in
ANSI/ITU in order to define a XGENIE/ELTE mapping. I don't believe such an effort
is within the scope of P802.3ae. At a minimum, our March 2002 target would be
dependent on progress in other standards bodies. Note that the XGENIE OAM bytes
attempt to duplicate a portion of the existing management capabilities of SONET/SDH.
Not only does this appear to "reinvent the wheel", but it begs the question of
Distinct Identity?

...Dave

David W. Martin
Nortel Networks
+1 613 765-2901  
+1 613 763-2388 (fax)
dwmartin@xxxxxxxxxxxxxxxxxx

========================

-----Original Message-----
From:   Osamu ISHIDA [SMTP:ishida@xxxxxxxxxxxxxxxx]
Sent:   Friday, April 07, 2000 2:40 PM
To:     stds-802-3-hssg@xxxxxxxx
Subject:        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:
http://grouper.ieee.org/groups/802/3/10G_study/public/email_attach/
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.

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

Best Regards,
Osamu

At 10:40 AM -0700 00.4.6, Paul Bottorff wrote:
http://grouper.ieee.org/groups/802/3/10G_study/email/msg02127.html
> 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:
http://grouper.ieee.org/groups/802/3/10G_study/email/msg02121.html
>>http://grouper.ieee.org/groups/802/3/10G_study/email/msg01965.html
>>  http://grouper.ieee.org/groups/802/3/10G_study/email/msg01968.html
>>  http://grouper.ieee.org/groups/802/3/10G_study/email/msg01971.html << File: XGENIE07Apr00.pdf >>