Re: [eman] Entity identification method

["Mouli Chandramouli (moulchan)" <[e-mail]>]

Hi Christian, 

Presently, the power measurement technology and instrumentation (power
sensors) exist for physical entities. 
While the MIBs in circulation attempt to provide power consumption by
physical components, cost of measurement sensors should be taken into
account. 

Clearly, the power cost of software features or virtual machines
(logical entities) should be determined, the technology/methodology is
work in progress as given in the research paper. 

Power measurement of virtual machines is still at research stage.

http://www.sigmetrics.org/sigmetrics2010/greenmetrics/greenMetrics10.Kri
shnan.pdf


On another point, it has been widely reported in several bench marking
studies that most of the power consumption is due to physical entities.
Clearly, this notion should be extended to logical entities as you have
pointed out. 

Thanks
Mouli


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of
Christian Groves
Sent: Monday, November 01, 2010 8:44 AM
To: [e-mail]
Subject: Re: [eman] Entity identification method

Hello Juergen,

I think distinguishing the two cases is the correct way to go.

I agree that reporting energy consumption for logical entities is a 
challenge and not straight forward. I guess there are a number of ways 
to look at this problem and how address the problem depends on the 
ambition level.

As you rightly mention where there is partial use of a physical resource

by a logical entity it is very difficult to have an exact figure.  
However I think the "grain size" of the measurement comes into play. For

example if we have a large gateway implementing several virtual gateways

if we take an overall measurement then we have the problem determining a

figure. If the however the virtual gateways were each assigned a 
physical rack and the measurements were taken at a rack level then we 
have a more precise estimate of contribution of each virtual gateway to 
the overall picture.

For me logical entities ultimately will be realised by physical 
hardware. The key is understanding the relationship between these 
entities. Thus I think virtualization can in some way be supported by 
allowing energy consumption reports for physical entities to indicate 
if/what logical entities they relate to. As they say information is 
power (pardon the pun :-) ).

Regards, Christian

On 29/10/2010 12:48 PM, Juergen Quittek wrote:
> Hi Christian,
>
> Thank you for this interesting comment.
>
> It looks like we have to distinguish two cases: power state monitoring
and
> energy consumption monitoring.
>
> For a logical entity and a virtual machine it may be well possible to
report
> on their power state. However, reporting their energy consumption
seems to
> be a tough challenge at least if be base it on real measurements.
>
> It is well feasible to measure energy consumption of physical
entities, but
> if you have a logical entity that consumes only partial resources of a
> physical entity, then precise measurement of the energy consumption
will be
> hardly possible. Estimations may be possible based on a model of the
logical
> entity, but I don't know how good such models can be.
>
> Thanks,
>
>      Juergen
>
>
> On 29.10.10 03:25  "Christian Groves"<[e-mail]>
wrote:
>
>> Hello
>>
>> I've just started to digest the various drafts of the eman wg and I
see
>> the comment below on logical entities. It's not clear to me how/if
>> network virtualization is intended on being handled in the eman work.
>>
>> In networks there's now a trend towards network virtualization and
cloud
>> computing with the different "X" as a service models (i.e. Amazon EC2
>> "platform as a service" running different server instances). Even in
>> today's networks we have physical gateways that are virtualized into
>> different logical gateways. For example: H.248/Megaco virtual MG
(VMG)
>> concept.
>>
>> I think it would be advantageous to be able to assess the energy
>> consumption of the VMGs or instances (which are logical entities)
>> independent of the physical gateway so that a customers energy use
may
>> be recording. Will this sort of functionality be allowed?
>>
>> Regards, Christian
>>
>> On 29/10/2010 1:22 AM, Juergen Quittek wrote:
>>> Hi Chris,
>>>
>>> I think it may become very difficult if we want to assess energy
consumption
>>> of logical entities. It seems to be reasonable and practical to
limit energy
>>> consumption measurements to physical entities. The ENERGY AWARE MIB
module
>>> (draft-parello-eman-energy-aware-mib) and the POWER MIB
>>> (draft-quittek-power-mib-02) went this way.
>>>
>>> Just using entPhysicalIndex solves some of the problem you
mentioned.
>>> Particularly, you don't need a mapping table to entities if you
restrict
>>> Yourself to entPhysicalIndex.
>>>
>>> Thanks,
>>>
>>>       Juergen
>>>
>>> On 28.10.10 13:34  "Chris Verges"<[e-mail]>
wrote:
>>>
>>>> Hi Jurgen and all,
>>>>
>>>> The more I've been thinking about these scenarios, the more
something
>>>> doesn't seem quite right.  I'll try to explain my thought process
behind
>>>> this and see if my concerns/confusions get captured.
>>>>
>>>> ENTITY-MIB provides enumerated lists of physical and logical
entities on
>>>> the system.  The indices in both lists are maintained separately,
so
>>>> there is not a single, unique identifier provided.  Because of
this, the
>>>> MIBs being discussed by the EMAN WG must only reference to one type
>>>> (physical or logical) and are limited to that without additional
work.
>>>> At some point in my mind, I'm asking myself the question, "What's
the
>>>> point of linking to ENTITY-MIB?"
>>>>
>>>> More on that question in later scenarios below ...
>>>>
>>>> One possibility would be to create a separate mapping table that
gives a
>>>> guaranteed unique index based on all entities, regardless of type.
The
>>>> physical vs. logical extensions would then become sparse tables
that
>>>> augment this.  For example:
>>>>
>>>>     ENTITY-MIB : entityGeneral.entGeneralTable.entGeneralEntry
>>>>     +-----------------+-----------------+-----+
>>>>     | entGeneralIndex | entGeneralDescr | ... |
>>>>     +-----------------+-----------------+-----+
>>>>     |        1        | PDU Chassis     |     |
>>>>     +-----------------+-----------------+-----+
>>>>     |        2        | Meter #1        |     |
>>>>     +-----------------+-----------------+-----+
>>>>     |        3        | Meter #2        |     |
>>>>     +-----------------+-----------------+-----+
>>>>     |        4        | Remote Meter #1 |     |
>>>>     +-----------------+-----------------+-----+
>>>>
>>>>     ENTITY-MIB : entityPhysical.entPhysicalTable.entPhysicalEntry
>>>>     +-----------------+-----------------+-----+
>>>>     | entGeneralIndex | entVendorType   | ... |
>>>>     +-----------------+-----------------+-----+
>>>>     |        1        | enterprises.foo |     |
>>>>     +-----------------+-----------------+-----+
>>>>     |        2        | enterprises.foo |     |
>>>>     +-----------------+-----------------+-----+
>>>>     |        3        | enterprises.foo |     |
>>>>     +-----------------+-----------------+-----+
>>>>
>>>>     ENTITY-MIB : entityLogical.entLogicalTable.entLogicalEntry
>>>>     +-----------------+----------------------+-----+
>>>>     | entGeneralIndex | entLogicalCommunity  | ... |
>>>>     +-----------------+----------------------+-----+
>>>>     |        4        | remote-power-group-1 |     |
>>>>     +-----------------+----------------------+-----+
>>>>
>>>> It seems like this 'entGeneralIndex' concept is what's missing from
the
>>>> current ENTITY-MIB, and is causing problems when thinking about
local
>>>> and remote power data being reported by the same agent.
>>>>
>>>> Another possibility would be to choose one -- entLogicalIndex, most
>>>> likely -- and require that anyone who wants to implement the EMAN
WG
>>>> MIBs to always create an entLogicalEntry for the power data.  In
this
>>>> context, the entLogicalTable fills the role of entGeneralTable as
>>>> described above.  For all entPhysicalTable entries, there would
need to
>>>> be a corresponding entry in entLogicalTable with a 1:1 mapping
between
>>>> them.  For all remote entries, there would be a unique entry in
>>>> entLogicalTable.  Of course, this would add some additional
overhead on
>>>> the part of the implementer, but isn't too overburdening.
>>>>
>>>> A third possibility is that ENTITY-MIB just doesn't do what we need
in
>>>> its present form and we need to think about enumerating power
sensors
>>>> separately from other components/sensors on the system.  It seems
like
>>>> entPhysicalTable gives a good starting template for a new
>>>> 'POWER-ENTITY-MIB', but can be extended to include support for
remote
>>>> agents.  The difference would be a clean break from the legacy
>>>> ENTITY-MIB structure.
>>>>
>>>> And with that, I look forward to others' feedback and ideas on
solving
>>>> this problem!
>>>>
>>>> Thanks,
>>>> Chris
>>>>
>>>> -----Original Message-----
>>>> From: [e-mail] [mailto:[e-mail]] On
Behalf Of
>>>> Chris Verges
>>>> Sent: Tuesday, October 26, 2010 9:26 PM
>>>> To: Juergen Quittek; Benoit Claise; eman mailing list
>>>> Subject: Re: [eman] Entity identification method (was: EMAN
chartered
>>>> itemsversus drafts)
>>>>
>>>> Hi Juergen and all,
>>>>
>>>> Agreed that a common ID method makes sense, and ENTITY-MIB seems to
be a
>>>> good choice.  In case (c) from your list, wouldn't the remote agent
>>>> condition be handled by ENTITY-MIB supporting a logical entity that
is
>>>> the remote agent iself?  Since the logical entity is in the
ENTITY-MIB
>>>> table, it would be given a unique ID mixed amongst the other
logical and
>>>> physical entities.
>>>>
>>>> At that point, should all of the MIBs being discussed in the EMAN
WG be
>>>> sparse table augmentations of ENTITY-MIB?
>>>>
>>>> Thanks,
>>>> Chris
>>>>
>>>> -----Original Message-----
>>>> From: [e-mail] [mailto:[e-mail]] On
Behalf Of
>>>> Juergen Quittek
>>>> Sent: Tuesday, October 26, 2010 6:01 AM
>>>> To: Benoit Claise; eman mailing list
>>>> Subject: [eman] Entity identification method (was: EMAN chartered
items
>>>> versus drafts)
>>>>
>>>> Hi Benoit and all,
>>>>
>>>> I agree that we should find a common identification method for
entities
>>>> used by all MIB modules. This does not apply to the POWER MIB only,
but
>>>> to all MIB modules in the eman WG.
>>>> The modules will use an entity ID as index for their tables.
>>>> Which entity is identified by the index can be resolved by other
MIB
>>>> modules, such as the POWER AWARE MIB module
>>>> (draft-parello-eman-energy-aware-mib) or the ENTITY MIB module (RFC
>>>> 4133).
>>>>
>>>> I see three basic scenarios for the entity identification:
>>>>
>>>>     a) a device just reports on its own power state and energy
>>>>        consumption and it reports on its own as a single unit.
>>>>
>>>>        Then we have a single index only stating "it's me".
>>>>        Such a device usually does not need further identification
>>>>        of itself, because typically there are sufficient other
>>>>        MIB modules for this purpose running in the same SNMP
engine,
>>>>        that provide information about the device's IP address,
>>>>        manufacturer, operating system, etc. In such a case a
>>>>        'trivial' index, such as '0' should be used in order to
>>>>        keep it simple in this most simple case.
>>>>
>>>>     b) a device reports on its own but not just as a single unit
>>>>        but it reports power states and energy consumption for its
>>>>        individual components, for example it may report separately
>>>>        on contained hard drives, line cards, back planes,
>>>>        processor boards, etc.
>>>>
>>>>        In such a case, identification of these components as
>>>>        individual entities would be required. The ENTITY MIB
>>>>        module was designed for this purpose and would be a good
>>>>        choice here. Also the POWER AWARE MIB module would be
>>>>        useful in this case.
>>>>
>>>>     c) a device reports on energy consumption of other, remote
>>>>        devices. Then remote devices (and potentially also their
>>>>        contained components need to be identified. For
>>>>        identifying remote components there is the POWER AWARE MIB
>>>>        module that has been designed for this purpose. As far as
>>>>        I understand, the ENTITY MIB module is not applicable to
>>>>        remote devices.
>>>>
>>>> In summary,
>>>>     - if you need to report on remote entities (case c)),
>>>>       you need the POWER AWARE MIB module,
>>>>     - if you report only on entities locally contained
>>>>       in the reporting device (case b)), you can use
>>>>       the POWER AWARE MIB or the ENTITY MIB
>>>>     - if you report just on your own as a single device
>>>>       (case a)), identification is trivial
>>>>
>>>> Hence, my recommendation (stated for POWER-STATE MIB and ENERGY MIB
in
>>>> draft-quittek-power-mib-02) would be:
>>>>
>>>> If there is an implementation of the POWER AWARE MIB module
instantiated
>>>> in the local SNMP engine, then you SHOULD (or MUST?) use it for
indexing
>>>> (pmIndex).
>>>> If this is not the case but there is an ENTITY MIB instance
available,
>>>> then you SHOULD use this one (entPhysicalIndex).
>>>> If neither of this MIB modules is available you should use index 0
only
>>>> and be limited to report on the local device as a single entity
only.
>>>>
>>>> That's just my view. Certainly, there are more ways of entity
>>>> identification. I look forward to discussing them.
>>>>
>>>> Thanks,
>>>>
>>>>       Juergen
>>>>
>>>>
>>>> On 26.10.10 11:44  "Benoit Claise"<[e-mail]>   wrote:
>>>>
>>>>> Hi Juergen,
>>>>>
>>>>> Thanks for the clarification.
>>>>>
>>>>> Something key is to agree on the Power Monitor index for all MIB
>>>>> modules, which IMHO should be part of the Energy-aware Networks
and
>>>>> Devices MIB module, but reuse in the other MIB modules.
>>>>>
>>>>> Regards, Benoit.
>>>>>> Hi Benoit,
>>>>>>
>>>>>> Thanks for checking all drafts.
>>>>>>
>>>>>> I don't think that draft-quittek-power-mib-02 makes significant
>>>>>> contributions to the Energy-aware Networks and Devices MIB.
>>>>>> It just covers the Power and Energy Monitoring MIB and the
Battery
>>>> MIB.
>>>>>> Thanks,
>>>>>>        Juergen
>>>>>>
>>>>>>
>>>>>> On 26.10.10 08:22  "Benoit Claise"<[e-mail]>    wrote:
>>>>>>
>>>>>>> Dear all,
>>>>>>>
>>>>>>> I went through the exercise of mapping the existing six
chartered
>>>>>>> items with the existing draft content.
>>>>>>>
>>>>>>> _Energy Management Requirements_
>>>>>>>
http://tools.ietf.org/html/draft-quittek-power-monitoring-requiremen
>>>>>>> ts-02
https://datatracker.ietf.org/doc/draft-norwin-energy-consider/
>>>>>>> _
>>>>>>> Energy Management Framework_
>>>>>>> http://tools.ietf.org/html/draft-claise-power-management-arch-02
>>>>>>>
>>>>>>> _Energy-aware Networks and Devices MIB_
>>>>>>>
http://tools.ietf.org/html/draft-parello-eman-energy-aware-mib-00
>>>>>>> http://tools.ietf.org/html/draft-quittek-power-mib-02
>>>>>>>
>>>>>>> _Power and Energy Monitoring MIB_
>>>>>>> http://tools.ietf.org/html/draft-claise-energy-monitoring-mib-06
>>>>>>> http://tools.ietf.org/html/draft-quittek-power-mib-02
>>>>>>>
>>>>>>> _Battery MIB_
>>>>>>> http://tools.ietf.org/html/draft-quittek-power-mib-02
>>>>>>>
>>>>>>> _Energy Management Applicability_
>>>>>>>
http://datatracker.ietf.org/doc/draft-tychon-eman-applicability-stat
>>>>>>> ement/
>>>>>>>
>>>>>>> Please let me know if I made any mistakes or if I missed any
draft?
>>>>>>>
>>>>>>> Regards, Benoit.
>>>>>>> _______________________________________________
>>>>>>> eman mailing list
>>>>>>> [e-mail]
>>>>>>> https://www.ietf.org/mailman/listinfo/eman
>>>> _______________________________________________
>>>> eman mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/eman
>>>
>>> _______________________________________________
>>> eman mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/eman
>> _______________________________________________
>> eman mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/eman
>
>
> _______________________________________________
> eman mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/eman
_______________________________________________
eman mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/eman