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.
jonathan
> -----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
> http://ccl.cnu.ac.kr/~dykim/
>
>