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

RE: What is 802.3ae WAN-PHY?




See below

jonathan

> -----Original Message-----
> From: Osamu ISHIDA [mailto:ishida@xxxxxxxxxxxxxxxxxxx]
> Sent: Monday, April 10, 2000 2:05 AM
> To: Jonathan Thatcher; dykim@xxxxxxxxxxxxx
> Cc: stds-802-3-hssg@xxxxxxxx
> Subject: RE: What is 802.3ae WAN-PHY?
> 
> 
> Hi Dae, Hi Jonathan,
> 
> Thank you for your feedback.  Some of my comments are intersperced 
> bellow.  Sorry for my short reply, but I am now trying hard to figure 
> out pros and cons of the SONET framer approach and the XGENIE 
> approach 
> with the help of another valuable feedbacks from the SONET-framer side
> (my thanks to Paul, Dave, and Roy).  I think I will be able to post 
> the result in a few days.
> 
> At 1:16 PM -0700 00.4.8, Jonathan Thatcher wrote:
> http://grouper.ieee.org/groups/802/3/10G_study/email/msg02199.html
> > 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.
> 
> I think at least we will not need re-write ITU-T G774 series where 
> the management object of network element is defined.  As for ITU-T 
> G707 where the SDH overhead bytes are defined and allocated, we 
> need further investigation about how far we can make the mapping 
> simple.
> 
> > 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.
> 
> Good point.  If the SONET adopts the Ethernet packet adaptation with 
> IPG transparency such as 64b/66b on SONET by Uni-PHY, 
> Ethernet PHY can 
> enjoy end-end path signaling without any mapping.  This is your 
> muliple instatiations, right?
> 

Not exactly.

What I meant is that there would be a way to "enjoy end-end path signaling"
regardless of the location of the SONET framers.
SONET framers could exist in every PHY in the path, in no PHY's in the path,
or at arbitrary locations in the path. That is what I meant by "greater
flexibility..." above.

To me, this would imply a 1:1 mapping requirement.

One instantiation might be: a LAN PHY in the Ethernet box talking to a LAN
PHY in the ELTE which has a SONET framer. Why might this be good?

Assumption: the hold mechanism would work at a rate between that shown in
the UniPHY proposal and full rate.
1: It would eliminate 2 SONET framers in this segment (loosely used) of the
path.
2: There would be a common, interoperable mechanism to manage all paths
across all vendors / implementations.

Why might this not be good:
1: It will require at very least a complete analysis of the SONET overhead
byte definitions to see what the mapping would mean (my previous request).
2: It might well require additional hardware (e.g. error counters) in the
pure LAN implementation to support the mapping.
3: It might not be used anyway (preference for SNMP).
4: It would probably mean more work for P802.3ae.

jt

> >> -----Original Message-----
> http://grouper.ieee.org/groups/802/3/10G_study/email/msg02198.html
> >> From: Dae Young KIM [mailto:dykim@xxxxxxxxxxxxx]
> 
> >> 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.
> 
> I still reserve my final decision which would be supportive for 
> full-SONET; 64/66 or EOS.  The latter don't support IPG transparency 
> and hence here I provide the mapping.  
> 
> >> 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. 
> 
> As Rich has already responded, RS would be better than MAC for 
> the instantiation.  Preserving MAC is clearly stated in five 
> criteria.  
> http://grouper.ieee.org/groups/802/3/10G_study/email/msg02201.html
> 
> >> Osamu Ishida wrote:
> http://grouper.ieee.org/groups/802/3/10G_study/email/msg02168.html
> 
> Best Regards,
> Osamu
> 
> -----------------------------------------
> Osamu ISHIDA
> NTT Network Innovation Laboratories
> TEL +81-468-59-3263  FAX +81-468-55-1282
>