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

Re: 64/66 on SONET (RE: AIS (RE: WIS OH))




Ishida,

Please give details on how you think that you would be able to implement the three trouble reporting functions that I have
recommended through the use of the original proposal for the WAN compatible PHY.  There are a potential of additional functions
within that original proposal that have been ignored by the block coding cadre, mainly because they can not replicate that level of
functionality.

8B/10B was invented by the same company that invented SDLC, IBM, specifically for short, self contained communications that did not
have need of remote reporting functionality.  Some functionality has been added, but block coding remains severely handicapped,
because it was not invented to be used outside of a limited distance environment.  For extended distance communications IBM had
SDLC.  Granted, SDLC was designed to be used over unreliable analog transmission systems.  But the principal of reserved bytes for
command and control has remained.  Block coding does not have any place for reserved bytes for command and control.  Unless you want
to put all of the functionality back into the SONET overhead, I suggest that you re-think your support for block coding within the
WAN PHY.

Thank you,
Roy Bynum



----- Original Message -----
From: "Osamu ISHIDA" <ishida@ka2.so-net.ne.jp>
To: "Roy Bynum" <rabynum@mindspring.com>
Cc: <stds-802-3-hssg@ieee.org>
Sent: Sunday, June 11, 2000 3:42 AM
Subject: 64/66 on SONET (RE: AIS (RE: WIS OH))


> Roy,
>
> Thanks for your feedback, but your scenario looks like assuming
> WAN-PHY and is not directly related to my current concern about
> the stand-alone operation of LAN-PHY Attachment Unit.
> http://grouper.ieee.org/groups/802/3/10G_study/email/msg02648.html
>
> Therefore I take the liberty to change the thread for my comment
> to your proposal/concern.
>
> As I understand, you have proposed additional trouble-shooting
> capability other than SONET-compatible OAM&P by defining new
> payload mapping rule during the fault situations, assuming the
> Ether-on-SONET style packet delineation.  Also you claim 64B/66B
> on SONET could not support such a trouble-shooting capability.
>
> I am not yet convinced why we need such a trouble-shooting
> capability beyond SONET-compatible OAM&P.  However if the community
> agree to supporting it as WAN-PHY functionality, it is easy to be
> implemented even in 64B/66B on SONET; just defining another LSS
> control code.
> http://grouper.ieee.org/groups/802/3/ae/public/may00/ishida_1_0500.pdf
>
> Therefore I DO support 64B/66B on SONET.
>
> Best Regards,
> Osamu
>
> At 05:38 00/06/10 -0500, Roy Bynum wrote:
> http://grouper.ieee.org/groups/802/3/10G_study/email/msg02650.html
> > Part of my presentation in Ottawa covered just such a scenario without
> > the need for SONET overhead processing at the PHY.  Please see "local
> > and remote link failure indication" on page 9 of
> > http://grouper.ieee.org/groups/802/3/ae/public/may00/bynum_1_0500.pdf.
> > Unfortunately, 64B/66B will not support this.  Block coding can not
> > support any of the remote trouble shooting functionality that service
> > providers are used to have available.  Howard Frazier made a comment
> > to this effect at the Ottawa meeting.  This lack of functionality is
> > one of the primary reasons that I continue to not support 64B66B.
>
> ---------------------------------------
> Osamu Ishida,ishida@exa.onlab.ntt.co.jp
> NTT Network Innovation Laboratories
> TEL:+81-468-59-3263 FAX:+81-468-55-1282
> ---------------------------------------