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

RE: What is 802.3ae WAN-PHY?

The approach that Osamu is pursuing is interesting to me due the potential
I foresee in being able to concatenate any number of LAN-PHY or WAN-PHY
segments together in any order and still manage these with using existing
tools nearly transparently. If this is possible, it would be beyond cool.

I assume the following from what I have seen thus far:
1. To adopt this might not require 802.3ae to write a new set of
line/path/etc management primitives.
2. A direct mapping would allow the "WAN" and the "LAN" systems to link in
a more direct way at, effectively, a lower level.
3. It permits greater flexibility in where we might choose to architect the
SONET framer in order to optimize the solution. It might even permit
multiple instantiations.

I am still curious about the details for the mapping and the data flow.


> -----Original Message-----
> From: Dae Young KIM [mailto:dykim@xxxxxxxxxxxxx]
> Sent: Saturday, April 08, 2000 7:41 AM
> To: stds-802-3-hssg@xxxxxxxx
> Subject: Re: What is 802.3ae WAN-PHY?
> Osamu-san,
> You're doing greate jobs, and let me give comments in two pieces:
> (A):
> Life would be easier if we'd abandon hiararchical management 
> and regard all XENIE
> instances are peer-to-peer over each hop. This leaves us 
> considering each XENIE hop
> as a section if we keep using the SONET terminology.
> Then we might not have to worry about mapping the SONET 
> Section Overhead bytes into
> XENIE and vice versa.
> This way, you need far less bytes for your management. 
> Because you have enough
> room, you may collapse some SONET-wise Path Overheads into 
> this as you did with G1.
> Anyway, these bytes are only XENIE specific and imbedded into 
> IPG. No mapping to
> SONET overheads. XENIE management bytes are transferred 
> trasparently over SONET to
> the other end until you meet another XENIE.
> SONET will do its own SOH/LOH processing independently of 
> what XENIE will do.
> Path/Section-collapsed XENIE bytes will take care of any end-node or
> intermediate-node equipements(which are 10GbE swithces) on 
> the way over the
> long-haul to reach your far-end partner.
> This way your ELTE would become simpler, wouldn't it?
> (B):
> Please allow me one more line:
> If you could somehow manage to push your XENIE (or only its 
> features) into MAC or
> RS(Reconciliation Layer), then thus management-enforced 
> Ethernet MAC frames would
> be able to be poured  directly into the SONET frame. The 
> effect is the three PHY
> boxes in your XENIE approach diagram will collapse into one 
> piece and the collased
> box will look like:
>         MAC
>         RS
>         XGMII
>         XFXS(8b10b encoder)
>         XAUI
>         XGXS(8b10b decoder)
>         SONET Fr.
>         SERDES
>         PMD
> resulting in a full SONET card direct onto this side of the 
> 10GbE port.
> The hard yet worthwhile part of this approach is that we have 
> to ask the committe
> to define new MAC control (management) words.
> I'm not a SONET expert afrer all, and I might be seriously 
> misteken in revising
> your idea.
> Anyway, I do support your effort to enforce the 10GbE with 
> (minimal) managemnt
> capability.
> (How was your party? Our cherry blossomes is next week and 
> ... with Jinro Shoju.
> :-))
> Osamu Ishida wrote:
> > 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).
> --
> Regards,
> Dae Young