RE: [802.3af] Link negotiation
From: Scott Burton@MITEL on 12/21/2001 06:46 PM
I was curious as to the lack of discussion as well. Has interest in this topic
faded due to some
decrease in interest in an alternate power removal detection scheme?
Scott
"Eric Lynskey" <elynskey@xxxxxxxxxxx> on 12/21/2001 11:22:00 AM
To: stds-802-3-pwrviamdi@xxxxxxxx
cc: (bcc: Scott Burton/Kan/Mitel)
Subject: RE: [802.3af] Link negotiation
I am somewhat concerned that I have yet to receive a single response to my
original email, or seen any discussion on the email that Scott Burton sent
out on the 11th. Does anyone have any other input on what to use as the
disconnect detection method, or to better explain the text currently
associated with this method? Is anyone planning to provide a comment
against the current draft? My guess is that at least one TR should be
submitted against this. Can anyone else offer some discussion?
-Eric
-----Original Message-----
From: owner-stds-802-3-pwrviamdi@xxxxxxxxxxxxxxxxxx
[mailto:owner-stds-802-3-pwrviamdi@xxxxxxxxxxxxxxxxxx]On Behalf Of Eric
Lynskey
Sent: Friday, December 07, 2001 2:23 PM
To: stds-802-3-pwrviamdi@xxxxxxxx
Subject: RE: [802.3af] Link negotiation
This is really the first time I've looked at the draft, but your email below
does bring up some interesting points. Any device that is properly
auto-negotiating will, upon reset, send nothing for 1.2 - 1.5 seconds. This
is referred to as break_link_timer. During the auto-negotiation process, a
device will be sending FLPs, but will not be in the LINK_UP state, and
therefore will not be providing PD_DATA_LINK to the PSE. The
auto-negotiation process does take several hundred milliseconds, and this is
prolonged if a device is negotiating a 1000BASE-T link. On average, if the
PD is reset, 2 to 3 seconds could elapse before it returns to the
PD_DATA_LINK state. The standard does not put a limit on the number of
pages that can be sent during the auto-negotiation process, and therefore it
would be hard to put an upper limit on this.
It's not clear from my reading of that section what exactly a PD should do
in order to stay powered. Does it send 10BASE-T link test pulses? Does it
send 100BASE-TX Idle? Does it have to be able to support both? What about
the PSE? Does it need to recognize all methods? If I have a PD, such as
the ethernet razor, it's not clear to me what I should be sending in order
to receive power. Presumably I need to have some knowledge of the PSE. Is
this correct? Do I need to know whether I'll be plugging into a 10, 100, or
10/100 port? This also applies for plugging into a 1000BASE-T port.
I'm just curious what the intent is supposed to be.
Eric Lynskey
-----Original Message-----
From: owner-stds-802-3-pwrviamdi@xxxxxxxxxxxxxxxxxx
[mailto:owner-stds-802-3-pwrviamdi@xxxxxxxxxxxxxxxxxx]On Behalf Of
Mike_S_McCormack@xxxxxxxxxxx
Sent: Monday, November 26, 2001 10:48 AM
To: stds-802-3-pwrviamdi@xxxxxxxx
Subject: [802.3af] Link negotiation
At the last plenary, we decided to allow PSE's to evaluate the
"PD_DATA_LINK"
variable as a qualified for the power request signature. We added the
requirement without modifying any of the timing parameters and at least need
to
provide a hold off time from power assertion to "link up" since we need to
recognize that PDs can't establish link without first getting power.
On return to my office I've checked with a few people more knowledgeable
than
myself and have been told that link negotiation, on a proper arrangement of
cable and equipment, of 600ms has been observed in the lab (100BASE-T.)
This
time to establish "link up" does not include such real world problems such
as
plugging two 10/100/1000 devices together via a 100m of CAT-3 cabling and
letting things go their course. I will take it upon myself to try to dig
timer
values out of the 802.3 specification so that we can bound what we are
already
committed to, but I'd like to hear form others with real world experience or
knowledge of what their PHYs were designed to.
There are other real world considerations, such as OSs which routinely reset
their MAC chips after the BIOS has already enabled them and cause "link" to
drop
out. It would also appear the my Windows98 PC resets the MAC when I run
Winipcfg and ask it to release and renew all (it looks like the link LED
flickers, I need to check with an analyzer.) These types of behavior would
cause units to get powered down in the middle of otherwise normal
operations.
I'd suggest we scrutinize what we have really done when we say that PDs must
maintain the "PD_DATA_LINK" variable.
Mike