Re: [8023-POEP] Power management discussions during ad-hoc - part II
Hi Hugh,
Sorry to be a pain but the one thing that I'm uncomfortable about in this
proposal is using the IEEE Std 802.3 OAM protocol when there doesn't seem
to have been much consideration of the alternative, IEEE Std 802.1AB Link
Layer Discover Protocol (LLDP) and it's extensions specified in TIA-1057
Link Layer Discovery Protocol for Media Endpoint Devices standard. I have
summarized my understanding of these below and CCed a couple of folk that
are experts in this area - please correct me if there are any errors there
- but for example the recently approved LLDP-MED standard provides a PD
the ability to indicate its DTE Power via MDI power requirements in 0.1W
increments in a ranged from 0 to 102.3 W.
I also fear that unless the IEEE P802.3at draft supports all the features
of TIA-1057 LLDP-MED, such as network policy configuration and location
identification, there will still be a demand from users for LLDP-MED.
Based on that, and assuming the use of the IEEE Std 802.3 OAM protocol in
IEEE P802.3at, I could see the situation where PSEs and some PDs could end
having to implement:
IEEE Std 802.1AB LLDP
TIA 1057 LLDP-MED
IEEE Std 802.3 OAM
Whatever we add for IEEE P802.3at
I would really like to avoid having to implement both IEEE Std 802.1AB and
IEEE Std 802.3 OAM protocols if that is possible. I think that due to
LLDP-MED the number of DTE Power via MDI devices that may implement LLDP
in the future is large, but as OAM is targeted at Ethernet in the First
Mile the number that would have to implement OAM in the future is small.
On that basis I would initially favour LLDP and as far as I am aware IEEE
Std 802.1AB was written to allow other SDOs to add extensions, TIA 1057
LLDP-MED is one such example, so couldn't IEEE P802.3at do the same.
I would also note that for a PD the use of the OAM protocols would seem to
involve implementing a MIB that is then interrogate through the OAM
protocol. With LLDP the PD just simply transmits its information and the
PSE become the repository for the information in its MIB, as well as being
able to use the information as it chooses. I don't know how much of an
overhead this really is for the OAM approach since the MIB in the PD
probably can only be interrogated through OAM but this, added to the
minimum set of function required to support the OAM protocol, does seem to
have some cost.
I guess what I am therefore really looking for is a list of requirements
for the Layer 2 classification protocol first and based on that a
selection of the protocol used to support it. I hope I'm not being unfair,
but to me so far all I have observed is a consensus that more granular
classification be performed through a Layer 2 protocol which LLDP-MED
already supports. The only objective in this area reads 'Research
potential extension of power classification to support PoEPlus modes.' [
http://www.ieee802.org/3/at/802_3_at_objectives.pdf#Page=9 ].
There have been some discussion of a PD advertising its average power or
similar and also the ability of the PD to dynamically request more power
from the PSE and the PSE either responding by supplying this extra power
or denying it. I believe it is the latter, if it is a requirement, that
may drive us away from LLDP towards OAM as. This is because, again if I
understand correctly, LLDP can only be used for totally stateless
operation. I would still ask however if there is no way LLDP can do this -
I understand that LLDP-MED enables the VALN to be configured in a PD at
start up without much delay - can the same approach be used for this type
of power request.
So in summary I just want to make sure we make a conscious decision as to
which protocol we are going to use as I believe the use of OAM does incur
some costs. Of course if that cost provides the only way to achieve a
particular need, such as the ability of a PD to dynamically request
additional power, then I will have no problem supporting the proposal to
use OAM. I just wonder if we have a clear agreement of what the needs are
at this point.
Best regards,
David Law
IEEE Std 802.1AB-2005 and LLDP
==============================
IEEE Std 802.1AB-2005 Station and Media Access Control Connectivity
Discovery specifies the Link Layer Discover Protocol (LLDP)
[http://standards.ieee.org/getieee802/download/802.1AB-2005.pdf]. The
protocol enables a device to advertises its configuration and abilities
through a number of Type Length Value tuples sent within a LLDP message.
The standards specifies both mandatory as well as optional TLVs. One such
optional TLV is the Power Via MDI TLV which maps to the information
provide in the DTE Power MIB. The provision was also made to allow other
Standard Development Organizations (SDOs), as well as Vendors, to specify
additional optional TLVs of their own. The LLDP-MED standard is one such
example of a SDO defining additional optional TLVs.
TIA-1057 LLDP-MED
=================
The LLDP-MED standard is a TIA (Telecommunications Industry Association)
Subcommittee TR-41.4, IP Telephony Infrastructures, specified extension to
IEEE Std 802.1AB-2005. That standards formal title is TIA 1057 LLDP-MED
Telecommunications - IP Telephony Infrastructure – Link Layer Discovery
Protocol for Media Endpoint Devices. Among may TVLs it specifies and
Extended Power-via-MDI TLV. This TLV contains Power Type (PSE or PD),
Power Source (PSE or Local), Power Priority (Low, High, Critical) and
Power value (in 0.1W increments from 0 to 102.3 W).
owner-stds-802-3-poep@xxxxxxxx wrote on 03/05/2006 00:24:38:
> Clay et al,
> Here is part 2 of my stateful power management proposal for discussion
> during power ad-hocs. This should be viewed as a follow on to the
> stateless vs stateful presentation - this is a detailed proposal of a
> stateful management mechanism.
> Thank you for your attention,
> Hugh.
> Hugh Barrass wrote:
> > Clay and others,
> >
> > Here is a mini-presentation to spur discussions on the merits of
> > stateful vs stateless management for PoEplus. Please feel free to
> > comment on this over the reflector as a prelude to discussion during
> > the ad-hoc call next week.
> >
> > Thanks,
> >
> > Hugh.
> >
>
Stateful_details_02.pdf