Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [8023-POEP] My thoughts on L2 protocol for PoE

Title:
Steve,

If you want to communicate through the Layer 2,
there's an extremely easy and, at the same time,
standard mechanism: LLC type 1 protocol (IEEE 802.2).

Do not hesitate to contact me for further information.

Best,

Jose Morales Barroso


Steve Robbins wrote: 
David,

Your drawing is essentially correct.  I've attached a more detailed one.

One of my problems is that I'm not a real network expert and I don't
understand a lot of the terminology. But I'm learning.  So please excuse me
if this is a dumb idea, but I thought it was worth a try.

Steve

-----Original Message-----
From: owner-stds-802-3-poep@xxxxxxxx [mailto:owner-stds-802-3-poep@xxxxxxxx]
On Behalf Of David Law
Sent: Wednesday, June 21, 2006 5:31 AM
To: STDS-802-3-POEP@xxxxxxxxxxxxxxxxx
Subject: Re: [8023-POEP] My thoughts on L2 protocol for PoE

Hi Steve,

I wanted to make sure I understood what you are suggesting. I think what 
you are describing is that the PDs would communicate with the Management 
entity in the Endpoint PSE through the Layer 2 protocol. There would then 
be a dedicated Ethernet link between the Endpoint and the Midspan and this 
would allow the Management entity in the Endpoint PSE communicate with the 
Management entity in the Midspan PSE. Note that this is required since the 
OAM packets being suggested for L2 power management will not pass through 
a switch. I have illustrated the configuration below.

Endpoint    Midspan      PDs
+------+    +------+
|      |    | PSE  |     +----+
| PSE -+----+--+---+-----+ PD |
|      |    |      |     +----+
|      |    |      |
|      |    | PSE  |     +----+
| PSE -+----+--+---+-----+ PD |
|      |    |      |     +----+
|      |    |      |
|      |    | PSE  |     +----+
| PSE -+----+--+---+-----+ PD |
|      |    |      |     +----+
|      |    |      |
| MGMT +----+ MGMT |
|      |    |      |
+------+    +------+

I guess the question I have is what level of interoperability are you 
looking for here, for example are you suggesting that standard needs to 
ensure that any combinations of Endpoint and Midspan PSE will be able to 
manage the aggregate power supplied to a single PD. The fundamental issue 
I would have with that is it would require the specification of the 
protocol that would run between the Endpoint and Midspan PSEs and even 
then would only operate with a number of configuration constraints such 
that all the ports from a single Endpoint PSE have to pass through the 
same Midspan PSE.

Regards,
  David



 
 -----Original Message-----

  
From: Steve Robbins <steven_robbins@xxxxxxxxxxxxx>
Date:         Tue, 20 Jun 2006 15:18:55
To:STDS-802-3-POEP@xxxxxxxxxxxxxxxxx
Subject: [8023-POEP] My thoughts on L2 protocol for PoE
    

  
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:
    

  
* Main power supply                                50%
* Housing                                                15%
* Bare boards                                           7%
* Labor (assy & test)                                13%
* Port circuitry, including magnetics          12%
* Other circuitry (microprocessor, etc.)       3%
    

  
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 Watts", 
and the midspan could allocate the additional power, but if the 
midspan port is unkown, then how would it know when to deallocate 
the extra negotiated power when the PD is disconnected?  How would 
the midspan do power-policing if it doesn't know which PDs have 
power allocations different from their L1 classification levels?
    

  
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
    

begin:vcard
fn:Jose Morales Barroso
n:Morales Barroso;Jose
org:L&M Data Communications
adr:;;Ctra. Pozuelo a Humera, 63 - Ch.39;Madrid;;28224;Spain
email;internet:jmb@xxxxxxxxx
title:Director
tel;work:+ 34 91 352 41 31
x-mozilla-html:TRUE
url:http://www.lmdata.es
version:2.1
end:vcard