Re: Break Link and Remote Fault
Shawn,
Thanks for bringing this point up. Use of the IPG to transport Break Link and
Remote Fault was definitely an argument against LSS. I'd like to address this
specific issues in this note.
LSS is a Layer 1 (i.e. Physical or PHY layer) protocol. LSS information may be
inserted into the PHY at some point in the transmit stream and removed by the
PHY prior to passing the IPG to Layer 2 (i.e. The Data Link layer which includes
the MAC).
The P802.3ae MAC is currently defined to generate an IPG which conveys only
timing information in the form of a packet to packet spacing with a granularity
of one octet. This is a Layer 2 protocol. Layer 1 protocols such as XAUI and
SUPI essentially modify the IPG in the same manner as does the LSS protocol in
that IPG Idles are converted to /A/K/R/ sequences or WAN PHY frames,
respectively. For both XAUI and SUPI, the IPG is restored intact except for
possible lengthening or shortening the IPG for clock tolerance compensation
purposes. Therefore, LSS uses the IPG in a manner even less intrusive than
either XAUI or SUPI!
Every Ethernet standard that I know of signals Remote Fault and Break Link at
Layer 1 only. Ethernet historians should correct me if necessary. Most existing
standards resort to dropping the link into a primitive or initialization (e.g.
Auto-Negotiation, etc.) level in order to signal Break Link or Remote Fault. For
P802.3ae, it has been deemed unnecessary to implement Auto-Negotiation or any
other primitive or initialization link protocol. It has been deemed sufficient
to initialize and maintain P802.3ae links with only an Idle sequence.
Furthermore, the IPG is defined to be an Idle sequence of a specific duration as
dictated by the MAC. LSS protocol takes advantage of these P802.3ae directions
to signal Break Link and Remote fault in an unintrusive and efficient manner.
There's nothing "fishy" going on here!
Break Link and Remote Fault are never indicated directly to Layer 2 for any
Ethernet standard I know of. Therefore, I feel that it is inappropriate to
transport this information at Layer 2 (e.g. in special MAC frames, etc.)
Best Regards,
Rich
--
> "Rogers, Shawn" wrote:
>
> I agree there was some FUD implying LSS was a form of AN, however the main
> point I heard against LSS was it's use of Inter Packet Gap (IPG). The 802.3
> has resisted the use of IPG for anything, time and time again. I do not see
> positive movement on supporting LSS as long as it is done in the IPG.
>
> If there was a way to take LSS out of the IPG - define a special MAC frame,
> say, it would likely gain favor.
>
> Shawn
>
> -----Original Message-----
> From: Devendra Tripathi [mailto:tripathi@xxxxxxxxxxx]
> Sent: Monday, July 17, 2000 11:42 AM
> To: stds-802-3-hssg@xxxxxxxx
> Subject: Re: Break Link and Remote Fault
>
> I agree with the comment. I think this is fairly simple. Moreover this
> mechanism is so easy to adopt for usage in dark fiber cases, if and
> when we want.
>
> Tripathi.
>
> At 11:34 PM 7/15/00 -0700, you wrote:
>
> >Ben,
> >
> >Thanks for taking this direction, I believe it's the right one. The LSS
> >proposal did very well at the La Jolla meeting in spite of the FUD
> >(Fear, Uncertainty and Doubt) use to confuse as significant number of
> >members of the P802.3ae committee. This is clearly evident in the voting
> >results on the LSS proposal: Yes: 55, No: 32, Abstain: 43. The voting
> >results show that 63.2% of 802.3 voters are in favor of the proposal and
> >33% of all voters abstaining. Also noteworthy is that the highest
> >abstention percentage for any other Logic track motion was on the SUPI
> >vote, for which 21.2% of all voters abstained.
> >
> >Among the FUD that targeted the LSS proposal was the comparison to
> >Auto-Negotiation. This can't be farther from the truth. Auto-Negotiation is a
> >handshake protocol including timeouts, acknowledgments, and multiple possible
> >responses to any request. LSS employs no handshakes whatsoever and employs
> >simple and continuous side A to side B signaling while a particular condition
> >exists..
> >
> >Another FUD element was the argument stating that there is no P802.3ae
> >objective for either Remote Fault or Break Link. I'd like to point out
> >that there is little correspondence between objectives and actual
> >functions and features. For example, there is no objective to perform link
> >initialization, but clearly this is a necessary function. I assume that
> >there is a desire to include Break Link and Remote Fault functionality in
> P802.3ae, objective or not.
> >
> >LSS employs simple word oriented signaling at the Physical layer and may be
> >transported by all LAN interfaces. In addition to Break Link and Remote Fault,
> >LSS possesses the flexibility to be used to transport LAN OAM&P
> >information. It just doesn't get much simpler than this. I strongly encourage
> >any simplifications to LSS protocol.
> >
> >Best Regards,
> >Rich
> >
> >--
> >
> >"Brown, Ben [BAY:NHBED:DS48]" wrote:
> > >
> > > Hi,
> > >
> > > The LSS proposal was not initially accepted to be part
> > > of draft D1.0. The opponents of this proposal felt that
> > > this was too complicated a method for reporting Break
> > > Link and Remote Fault. Since I've heard many times on
> > > this reflector and in the meetings that, if a proposal
> > > is going to be shot down a substitute should be made to
> > > take its place, I'd like to request just such a substitute.
> > >
> > > Another thing to remember. According to Jonathan's
> > > schedule, this was the "last new proposals" meeting.
> > > I'll be interested to hear proposals for break link
> > > and remote fault reporting that do not include major
> > > new ideas.
> > >
> > > Thanks,
> > > Ben Brown
> > > P802.3ae Logic Track Chair
> > >
> > > --
> > > -----------------------------------------
> > > Benjamin Brown
> > > Router Products Division
> > > Nortel Networks
> > > 1 Bedford Farms,
> > > Kilton Road
> > > Bedford, NH 03110
> > > 603-629-3027 - Work
> > > 603-624-4382 - Fax
> > > 603-798-4115 - Home
> > > bebrown@xxxxxxxxxxxxxxxxxx
> > > -----------------------------------------
> Best Regards,
>
> Devendra Tripathi
> Vitesse Semiconductor Corporation
> 3100 De La Cruz Boulevard
> Santa Clara, CA 95054
> Phone: (408) 986-4380 Ext 103
> Fax: (408) 986-6050
> ********************************************************************
>
> Web: http://www.vitesse.com
-------------------------------------------------------
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