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/