Thread Links | Date Links | ||||
---|---|---|---|---|---|
Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Guys, I have some thoughts regarding the proposed Layer 2 power
management scheme. Basically, the more I think about it, the more I’m
convinced the midspans need to implement L2, not just the endspans. The reason is that, if dynamic power negotiation is actually
going to be used, then both PSE need L2 capability because endspan-only
negotiation seems too limited to be useful. So I think we either mandate
that the midspans also do L2, or we drop the dynamic power negotiation idea all
together. Of course the problem is cost. I did my own crude cost
estimates, and here is what I came up with. I estimated the total costs
of a 12-port 802.3af midspan to break down as follows:
Obviously, I don’t make midspans, so I’m
guessing. But I think these numbers are in the ball park. (If
anyone thinks these are way off, please let me know. I’m
interested.) Next, I looked at what it would cost to add a PHY/MAC and
10/100 magnetics to each port, and an Ethernet switch so that the micro could
talk to all ports. I estimate the additional circuitry would cost about
as much as the existing port circuitry (PSE controller, associated discretes, magnetics
for power injection). So item 5 above is essentially doubled, which would
increase the total system cost by approx 12%. But this doesn’t
count the additonal assy or test labour. So the actual impact may be more
like 14%. But I have an idea how we could add L2 capability to
midspans without extra hardware. Suppose the PD negotiates with the
midspan indirectly. Packets from the PD would pass thru the endspan into
the LAN, and then into the management port on the midspan. All PDs
connected to the midspan would take the same path, so just one Ethernet management
port is required instead of one PHY/MAC for each midspan port. The problem is that we loose some info this way. The
port associations, which are inherant if every midspan port has a PHY, are lost
in this scheme. For example, if we don’t know that port-N on the
endspan is powering the same PD as port-M on the midspan, then we can’t do
dynamic power negotiation. The endspan could tell the midspan via the
management port “some PD needs 5 more So my idea is, somehow encapsulate the port mappings into
the MIB. For example, the sys admin could enter (via command line or GUI)
the info as the midspan-to-endspan cables are connected during intial system
setup. When a PD requests more power from endspan port-N, the N=M
association stored in the MIB would tell the endspan to copy the packets to the
midspan via the management port, and the midspan would know that it’s
talking about port-M. Any comments? Steve |