Re: Link Status thoughts
Sharam,
It was a pleasure seeing you in Tampa. Sorry about not addressing this
issue with you in person there, I'm just now addressing the 500 or so
emails I haven't been able to address since the meetings started.
We have to be a little careful in discussing this issue. I believe that
your note addresses the case of link fault on one simplex link resulting
in the assertion of transmit disable on associated simplex link in the
opposite direction.
I view the two simplex links as being separate with the caveat that the
state of one simplex link only affects the associated simplex link in
the opposite direction via either protocol at the RS or link management
protocol associated with the two opposite direction simplex links
comprising the Ethernet full-duplex link.
When I say the a transmitter should be shut down if a receive link fault
is detected, I am referring to the detection of a condition and the
action at a transmitter along a single simplex link. An example is the
absence of electrical signal at the input to an optical transceiver
module, such as a GBIC, which results in the assertion of Transmit
Disable and the shutting down of the laser at the module output. I
believe that my scenario is significantly different than the one you
describe where the lack of optical signal at the input to an optical
module results in the assertion of Transmit Disable and the shutting
down of the laser at the module output, involving both simplex links. I
also do not endorse the optical module taking this action on it's own,
unless a management agent present in the module has instructions to
perform this action.
That said, you've hit on a philosophical issue which I feel is
independent of, and beyond the scope of, the 10GE Link Status
discussions.
The Link Status Reporting and Initialization proposal outlined in
taborek_2_1100.pdf which was accepted by the Task Group in Tampa as the
baseline for further development of mechanisms related to basic Link
Management.
Separately, with 10GE, and Ethernet in general, there exists a defacto
link architecture which suggests that Ethernet links are either
functional in full-duplex mode, or non-operational. By full-duplex, I
mean at the link-level, not at the MAC level. This is a moot point since
10GE does not support CSMA/CD. This means that if a 10GE simplex link is
down, that the Ethernet link is down. I agree with this philosophy and
believe that it makes Ethernet a stronger player for all applications
including multicast, broadcast and mission critical as well.
The purpose of Link Status Reporting and Initialization with respect to
link faults is to ensure that a fault condition detected anywhere along
a simplex link is recognized at the Reconciliation sublayer (RS) at the
end of that link. The recognition of the link fault condition causes the
condition Link Status=FAIL to be reflected in the Status Register bit
1.2 of the RS. Enter philosophy...
The Link Status=FAIL condition causes a sequence of events to occur on
the associate simplex link in the opposite direction. Let's say that the
Link Status=FAIL condition is set in Device A, and Device B is at the
other end of the link:
1) Device A ceases MAC frame transmission;
2) Device A reports a Remote Fault condition to Device B.
Device B may detect any of the following:
1) The Remote Fault report from Device A;
2) A Link Fault.
In either case, Device B sets Link Status=FAIL in its own RS and ceases
MAC frame transmission. The end result is that both simplex links of the
10GE full-duplex link are not available to the MAC to transmit frames.
The appropriate response by layers above the MAC would be to enable an
alternate path or perform link maintenance on the failed link.
Please tell me if I've addressed your issue adequately since the Task
Force needs to achieve consensus on 10GE link operation philosophy
before we get too far down the road.
Best Regards,
Rich
--
"Hakimi, Sharam (Sharam)" wrote:
>
> Rich,
> I agree with all the points made here. One thing I would like to see removed
> from this proposal is the requirement to shut down the transmitter if a
> receive link fault has been detected. As we are moving into the multimedia
> arena, it is useful to have the transmitter to continue while the receive
> path is being investigated. There are many multicast, broadcast applications
> that can benefit from this.
>
> What I am asking is the following options:
>
> Once a link fault has been detected:
>
> 1) Shut down transmission and transmit link fault message
> 2) Continue with transmission and also transmit link fault
> message
>
> Regards,
> Sharam
>
> > ----------
> > From: Rich Taborek[SMTP:rtaborek@xxxxxxxxxxxxx]
> > Reply To: rtaborek@xxxxxxxxxxxxx
> > Sent: Friday, November 03, 2000 9:37 PM
> > To: HSSG
> > Subject: Re: Link Status thoughts
> >
> >
> > Shimon,
> >
> > It sounds like we're all getting very close to a compromise solution.
> >
> > I agree with your point of not performing Link Initialization or Link
> > Status Reporting during normal data transfer. This point is almost
> > implied in the fact that Link Initialization only occurs upon power-on,
> > reset or link error. Similarly, most Link Status conditions will cause
> > Link Status to be reset and MAC packet transmission to cease until the
> > condition is cleared.
> >
> > It seems like we're converging on the following:
> >
> > 1) Local Fault and Remote Fault conditions;
> > 2) Local Fault and Remote Fault messages;
> > 3) Fault message Signaling by Signal or Sequence or something in between
> > which is EMI-friendly;
> > 4) No singaling during data transfer/packet;
> > 5) No need for Break Link as part of power-on reset or link
> > initialization;
> > 6) Weak requirement for a management initiated Break Link, which could
> > fire off a Remote Fault message.
> >
> > Did I miss anything?
> >
> > Best Regards,
> > Rich
> >
> > --
> >
> > Shimon Muller wrote:
> > >
> > > I have been trying to follow this discussion very closely, and at this
> > point
> > > I have to admit that I am getting pretty confused. Pat is right, when
> > the
> > > e-mails get this long and this frequent, it is time for a face-to-face
> > meeting.
> > > I will be arriving around 7:00pm on Sunday as well, and am pretty much
> > free
> > > until Tuesday morning, except for Geoff's show on Monday. If someone
> > wants to
> > > set a time and place for a get-together, I would be happy to
> > participate.
> > >
> > > Between now and Monday I would like you to think about the following:
> > > I find myself agreeing with many points made by both Pat and Rich.
> > Personally,
> > > I am open to any suggestion that will make my proposal simpler and more
> > robust.
> > > Even to the extent that the final solution doesn't look close to what I
> > have
> > > proposed. However, the one thing that I will have trouble accepting is
> > allowing
> > > this signalling, whatever it is, during normal data transfer. I truly
> > believe
> > > that this would be a recipe for disaster.
> > > If we can reach an agreement on this point, the rest is details, and I
> > would
> > > be happy to work on them.
> > >
-------------------------------------------------------
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