Re: Break Link and Remote Fault
Osamu, et. al.
I am in complete agreement with you. Perhaps the only correction that
needs to be made to the LSS presentation on this issue is to do a global
replace of IPG with Idle. Here is my rationale:
IPG is associated with the MAC. IPG is passed to the MAC. Since LSS
information is never passed to the MAC, LSS is never really part of the
IPG.
Once the IPG leaves the MAC, it may be encoded in one or more fashions
to meet link protocol requirements of the various P802.3ae sublayers and
interfaces. In the case of P802.3ae, it's "more". For example, the IPG
is converted to a randomized AKR Idle sequence for transport over XAUI
and the 8B/10B PCS for WDM. At the remote link end, the randomized AKR
Idle sequence is converted to IPG before it is passed to the MAC. LSS
satisfies link protocol management objective and is proposed to be
seamlessly combined with PHY layer Idle codes.
Does this distinction of IPG and Idle help?
Best Regards,
Rich
--
Osamu ISHIDA wrote:
>
> Brad, Seto,
>
> Thanks for your suggestions for the LSS update, while I am not yet
> convinced that the argument about LSS in La Jolla is based on the
> sufficient technical understanding, and that we need any update.
>
> Here let me comment to your LSS update suggestion; restricting the
> BL/RF signaling during the pure idle stream alone, not using IPG.
>
> At 13:29 00/07/17 -0700, Booth, Bradley wrote:
> http://grouper.ieee.org/groups/802/3/10G_study/email/msg02900.html
> > A couple of options as I see it are the following:
> > * remove OAM&P and move the BL and RF signaling into the idle stream
> > * alter the LSS proposal to only use the idle stream for all signaling
>
> At 15:30 00/07/17 -0700, Seto, Koichiro wrote:
> http://grouper.ieee.org/groups/802/3/10G_study/email/msg02906.html
> > What I meant by 'not using IPG' was 'not mandating to send LSS signal
> > once in some SONET compatible period'. I have no problem with the idea,
> > but I thought many other did at the plenary. As Brad wrote, it is
> > common in Ethernet to send BL/LF signal during periods you don't
> > anticipate MAC to send packets. I thought many should not have a
> > problem with such a method.
>
> We have proposed the periodic Link Status (BL/RF) reporting
> just because it is believed to be the simplest solution.
> If we would restrict it during the pure IDLE stream alone,
> we should define/implement the excessive requirements for
> reliable Link Status notification.
>
> Assuming that PHY has been detecting Local Sync Down and
> has been sending the Link Status Code with RF_bit_On.
> If the Local Sync is re-established, then the PHY will
> send the Link Status Code with RF_bit_OFF. If we have to
> restrict the Link Status Code insertion during the pure
> Idle stream alone, we have to define how many times or
> how long we send it with RF_bit_OFF before we stop to send it.
>
> Another solution might be just stopping to send the Link
> Status Code itself if the Local Sync is re-established.
> However in this case, at the LS code receiving side, we
> have to define/implement the guard time that how many
> periods or how long we need until we recognize not
> receiving the LS code. The LS code may be discarded
> at the receiver side by a link bit error, so you need at
> least several periods for not receiving LS code before
> you recognize that the RF is de-asserted.
>
> I think that these alternative approaches are more complicated
> than just sending the LS code (RF/BL) periodically and simply
> rewrite the status register as it is detected at the receiver side;
> please see slide #9 in my La Jolla presentation;
> http://grouper.ieee.org/groups/802/3/ae/public/jul00/ishida_1_0700.pdf
> I also have emotional objection to these approaches since
> these remind me the Auto-Negotiation; defining special PHY
> status (no MAC frame) for Layer-1 RF/BL signaling.
>
> In summary, at present I don't see any reason to make things
> more complicated just for avoiding LS code in IPG, considering
> that there seems to be no reason to distinguish the IDLE columns of
> IPG from those in pure IDLE stream as described in my previous note;
> http://grouper.ieee.org/groups/802/3/10G_study/email/msg02914.html
>
> Any feedback on this matter would be greatly appreciated.
>
> Best Regards,
> Osamu
>
> ---------------------------------------
> Osamu Ishida,ishida@xxxxxxxxxxxxxxxxxxx
> NTT Network Innovation Laboratories
> TEL:+81-468-59-3263 FAX:+81-468-55-1282
> ---------------------------------------
-------------------------------------------------------
Richard Taborek Sr. Phone: 408-845-6102
Chief Technology Officer Cell: 408-832-3957
nSerial Corporation Fax: 408-845-6114
2500-5 Augustine Dr. mailto:rtaborek@xxxxxxxxxxx
Santa Clara, CA 95054 http://www.nSerial.com