[Tfug] PoE supplies/injectors

Bexley Hall bexley401 at yahoo.com
Sun Feb 14 13:08:58 MST 2010


> >> I'm curious as to the type of *typical* support provided PoE.
> >> I assume legacy installations use midpoint injectors on
> >> *select* drops (to eliminate the cost of replacing existing
> >> switches)?
> > 
> > Correct.
> 
> As I say it, in the olden days there were not an abundance
> of devices that would use the power. So why bother?

I would assume they would "bother" if they were trying to
retrofit PoE devices onto the existing (wiring) infrastructure.
E.g., much easier to install a VoIP system if there are
already drops in each office/cubicle and all you have to
do is add PoE injectors (or replace the switch servicing
those drops of interest).

> >> Or, is it more typical for the switch to be replaced to
> >> provide PoE to *all* drops?
> 
> Depends on the application. If a PoE phone intallation is
> going in, the answer is yes.

To clarify:  to *all* drops or just the VoIP drops?

Stated another way, if you were installing network infrastructure
*today*, what criteria would you use to determine whether to
use PoE+nonPoE switches vs. all PoE switches vs. nonPoE switch
with midpoint injectors, etc.?  (given that you would likely
plan for "tomorrow")

> > Usually I've seen a small dedicated PoE switch installed in addition
> > to any existing switch.
> > 
> >> Are there any "smart" injectors (midpoint or endpoint) where
> >> "something" can control the delivery of power *to* the PD's?
> 
> Yes. See below.

The standard just refers to how the PSE "negotiates" (a misnomer
as it really isn't a fair negotiation) with the PD to determine
- that there *is* a device (PD or otherwise) on the end of the drop
- that the device on the end of the drop *is* a PD (and not
  something like a POTS station set plugged into the "wrong"
  connector)
- the power requirements of the PD
It doesn't describe any *particular* PSE's that have the added
capability of being "controllable" and *pollable*.

Note that the standard also doesn't provide any provisions for
"renegotiating" the power requirements of the PD.  Nor any
way of telling the PD if those requirements can/will be met.
(I guess you would have to do this ad-hoc with an inband
protocol  :< )

> > Some switches have a per-port PoE setting you can turn on and off.  If
> > the switch or power injector had a CLI you could probably script it so
> > that specific MAC addresses would get power, but...
> > 
> >> I.e., so that I can selectively apply/remove power from
> >> individual drops? And, ideally sense/control the class
> >> negotiated by the PD (i.e., so I can *manage* power instead
> >> of just providing it)?
> > 
> > In terms of being plug and play, and full autosense this is a
> > chicken/egg problem.  How does the switch known that the device
> > connected to it if said device has to be powered in order for it to
> > inform the switch that it needs power?
> 
> Maybe that's why they developed IEEE 802.3af and 802.3at
> 
> http://en.wikipedia.org/wiki/PoE#IEEE_802.3af_.2F_802.3at_Power_over_Ethernet

No.  The only way the PD can inform the PSE that it "needs" power
is to "connect" to the PSE (via the network drop).  And, this
protocol is only initiated at the time of the initial connection.

E.g., to move from a Class 1 to Class 3 requirement, the PD
would have to disconnect for about half a second (so the PSE
thinks it has been "unplugged") and then re-connect with a
different classification current during the "probe".  If the
PSE can't satisfy this requirement, the device would simply be
un-powered and, presumably, would have to disconnect, wait
and then reconnect with the original (lower) Class request
(and *hope* the PSE can still supply the requested power in
light of other PD's which may be competing for fixed resources
at that time).

Alternatively, I *think* you can request "the most" you will
need and then hope the PSE requests a throttle-back of power
("standby" mode).

> A problem is that older stuff especially has spotty
> compliance to said specs. But really, that is not the sort
> of thing one can anticipate and design for, IMO.

I am more concerned about what is likely to happen going
forwards and the capabilities that I can *buy* (vs. having
to design a custom PSE to give me the hooks that I need).
In that sense, I am interested in where the market appears
to be going (i.e., if these sorts of features will soon
materialize in product offerings or not)


      




More information about the tfug mailing list