RE: Break Link and Remote Fault
Seto,
I think that you're on the right track, but let's not forget that in the
scenario of Break Link, 1000BASE-X doesn't give a damn about what is being
transmitted. In other words, BL can be signaled in the middle of a packet,
IPG or idle stream. In 1000BASE-X, Remote Fault plays by similar rules. I
say similar rules because the BL of auto-negotiation is required to initiate
an auto-negotiation process which passes the RF information. The other big
issue with 1000BASE-X is that RF is optional. I think LSS addresses this by
making it mandatory.
I think that the LSS version of BL and RF performed a better job of these
functions by at least waiting until the end of packet. If either BL or RF
is transmitted, then there is a very good chance that the MAC will have
stopped transmitting. In the case of BL, the DTE is breaking the link and
therefore will stop transmissions. In the case of RF, the DTE is unlikely
to continue to send data if it is reporting an error in the system.
So, I think the biggest issue was with the OAM&P capabilities of LSS. A
couple of options as I see it are the following:
* remove the optional OAM&P from the LSS proposal
* 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 OAM&P
* alter the LSS proposal to only use the idle stream for all signaling
Comments?
Cheers,
Brad
-----Original Message-----
From: Seto, Koichiro [mailto:seto@xxxxxxxxxxxxxxxxxxxx]
Sent: Monday, July 17, 2000 2:18 PM
To: stds-802-3-hssg@xxxxxxxx
Subject: Re: Break Link and Remote Fault
[Date: 07/17/2000 From Seto]
Shawn,
I think using MAC frame means a big change to existing MAC,
thus not a
good idea.
LSS is a very solid link signaling proposal. I think we
should start
>from LSS. The issue is whether we should use IPG or not.
- 1000BASE-X uses Configuration order set (code set) to
communicate Link
Failure, but not during IPG.
- 100BASE-FX uses special code sequence to communicate
Remote Fault, but
not during IPG.
I'd like to take a straw poll how many would support LSS if
it does not
mandate to use IPG. ;-)
Sincerely,
Seto
>
>
> Shawn,
>
> This is a possible replacement for the OAM&P features of
> LSS. How can we use packets to report break link and
remote
> fault?
>
> Ben
>
> "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
> > > > -----------------------------------------
> > >
> > >-------------------------------------------------------
> > >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
> >
> > 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
>
>
> --
> -----------------------------------------
> 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
> -----------------------------------------
>