Dan et al:
802.3at is predicated on a PSE as a single port entity, even though reality is most PSE’s are multi-port entities with shared power resource.
The Power Denied state provides a “convenient” mechanism to allow for PSE’s that are “budgeting” power to cycle the state machine (in compliance) without ever
powering. If all PSE’s were truly single port devices, this would not be so important and might well be treated as a FAULT.
But reality should probably prevail and treat this as an “ordinary” behavior of a PSE. This includes the case where the PSE is making that decision after
furnishing power (the “D” tagged branch out of POWER_ON).
So I’d vote “NO FAULT”!
Regards,
Pete Johnson,
Sifos
Hi All,
In my work related to cleaning up the PSE state diagram as initiated at our last meeting, a drawing was put together by Dave Dwelley as a first stab of how one might break down the PSE diagram.
In this, (attached), the state "POWER_DENIED" was included in the "Delivering Power" group. As I proceeded on my task, I noted that POWER_DENIED could be considered a "Fault" condition depending on how you read the text.
I looked at the text and found the following;
33.5.1.2.4 Power Denied or Removed (12.12)
When read as a one, bit 12.12 indicates that power has been denied or has been removed due to a fault
condition. This bit shall be set to one when the PSE state diagram (Figure 33–9) enters the states
‘POWER_DENIED’ or ‘ERROR_DELAY.’ The Power Denied bit shall be implemented with latching high
behavior as defined in 33.5.1.
So it occurs to me that the text is somewhat ambiguous. If you read it "{has been denied or has been removed} due to a fault condition"... you read the condition as a fault for either. If you read it "has been denied or {has been removed due to a fault
condition}, then denial is not considered a fault, but removal due to a fault condition is a fault.
So, in order to move forward, I am going to consider the former for the basis of my effort. I will presume that denial of power is a "self-imposed fault" to advance this effort. If, due to consideration of the Task Force, its decided that this state should
not be within the Fault group, it will be relatively easy to redraw things.
Feedback appreciated. In the last meeting, we discussed using the reflector for this purpose, hence, I'm reflecting on this issue.
Regards,