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

Re: [8023-POEP] Problems with remedy regarding PSE type 2 behaviour when it reads bad classification



One of the fundamental problems with .af is that there were a number of ways that non-compliant PDs (or non-PDs) could fool the 2-point detection schemes.
 
It would seem unlikely that a real PD would be trying to draw Iclass_lim.  However, a non-PD that fooled detection and tried to dram Iclas_lim should be rejected.
 
Basically, numerous solutions have found it easy enough to meet the PD requirements for Iclass.  And we should protect the future of a possible Class 5. 
 
I don't see an issue with a change in the PSE behavior between type 1 and type 2.  The type 1 behavior was an attempt to dictate what a PSE did under an error condition.  It was not a back-door PD specification.  That is, a PD that draws Iclass_max during classification does not meet the standard (is non-compliant).  There is no expectation that a non-compliant PD must be powered.
 
I vote for the "go to idle" when the PD draws Iclass_max.
 
Regards,
Martin
 

Martin Patoka
Systems Engineering Manager
Texas Instruments
O: 214-567-5487
mpatoka@ti.com

 


From: Chad Jones (cmjones) [mailto:cmjones@cisco.com]
Sent: Wednesday, May 21, 2008 1:05 PM
To: Darshan, Yair; Clay Stanford; Matthew Landry; Fred Schindler (frs); Patoka, Martin; Bill Delveaux (bdelveau); Anoop Vetteth (avetteth); McCormack, Michael; gthompso@nortelnetworks.com; Jetzt, John J (John); Reshef, Tamir; Feldman, Daniel; Rimboim, Pavlick
Cc: STDS-802-3-POEP@listserv.ieee.org
Subject: RE: Problems with remedy regarding PSE type 2 behaviour when it reads bad classification

We only have to guarantee interoperability for compliant devices.  A device that draw more than 51mA during classification is noncompliant. 
 
As I pointed out in my comment it was a mistake in AF to allow a PSE to power a device that has failed classification and that we should fix that in AT.  I'm not concerned that a device that is noncompliant will not get power from a Type 2 PSE. 
 
The other problem with your remedy is that there is a two layer slight of hand going on here.  If you allow a Type 2 PSE to assign this noncompliant PD class 0 there is another statement that says the Type 2 PSE can treat the class 0 PD as Class 4 and now we are back to the start.  You are allowing a noncompliant device to draw up to 30W, therefore enabling dumb PDs.  My opinion is this is completely unacceptable.  If I were a devious designer, I would just draw 60mA during class and then move on to drawing 30W. 
 
the only thing we have to be careful of is that we are not making all legacy PSEs noncompliant by removing their ability to power devices that fail classification as Class 0.  I would support your statement if it said:
 
If a PSE detects Iclass_lim, it may power the PD strictly at Class 0 levels or it may choose to enter the IDLE mode.  A Type 2 PSE that decides to power a PD that violates Iclass_lim shall limit Pport to 15.4W.  In this case, there is no allowance for the Type 2 PSE to power at Type 2 levels.
 
or some other equivalent but better wording.  I would want a shall statement that generates a PICS that would check that a PSE will police at 15.4W if it powers a noncompliant device.  Of course we would also have to figure out how to work this into the state diagram.
 
To me the easier solution is to make the decision to not power these devices.
 
-Chad
 


From: Darshan, Yair [mailto:YDarshan@microsemi.com]
Sent: Wednesday, May 21, 2008 10:05 AM
To: Chad Jones (cmjones); Clay Stanford; Matthew Landry; Fred Schindler (frs); Patoka, Martin; Bill Delveaux (bdelveau); Anoop Vetteth (avetteth); McCormack, Michael; gthompso@nortelnetworks.com; Jetzt, John J (John); Reshef, Tamir; Feldman, Daniel; Rimboim, Pavlick
Cc: STDS-802-3-POEP@listserv.ieee.org
Subject: Problems with remedy regarding PSE type 2 behaviour when it reads bad classification

Hi guys,

 

I have found a problem with the remedy on the above subject.

 

We have 3 cases in which we agree last meeting to return to IDLE state.

 

Case 1:

If PSE type 2 reads class 4 in 1st finger and other reading in 2nd finger, it will return to IDLE state.

The rational was that we don’t want to encourage someone using different coding so we can reserve it for future use.

So far it makes sense.

 

Case 2:

If PSE Type 2 pass detection successfully and fails to complete classification, it will return to IDLE state.

Rational:

Classification in Type 2 PSE and PD is mandatory. If it is not working then probably one of the two parts PSE or PD is non compliant or defective.

 

Case 3:

If PSE detects Iclass_lim, it will return to IDLE.

 

The problem is in Case 3.

Rational:

a) If PSE type 2 connected to PD type 1, and PSE reads Iclass_lim then according to last week change, PSE will return to IDLE state.

b) But If PSE type 1 connected to PD type 1, and PSE reads Iclass_lim, PSE is assign Class 0 which mean the PD will be operated.

 

Which means that in (a), PD type 1 will not work ever never with PSE type 2 under Iclass_lim and may work with PSE type 1.

This is violates backwards compatibility and creates interoperability problems between PSE type 1 and PSE type 2 connected to PD type 1 exhibiting Iclass_lim.

 

The solution for this problem is:

In Case 3 (and maybe also in case 2) , The PSE type 2 shall assign Class 0 as well as Type 1 PSE, if it detects Iclass_lim.

 

What is your opinion on these guys?

 

Yair

 

Darshan Yair
Chief R&D Engineer

Analog Mixed Signal Group

Microsemi Corporation

 

1 Hanagar St., P.O. Box 7220
Neve Ne'eman Industrial Zone
Hod Hasharon 45421, Israel
Tel:  +972-9-775-5100,

Cell: +972-54-4893019
Fax: +972-9-775-5111

 

E-mail: <mailto:ydarshan@microsemi.com>.