| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Paul, The RequestShutDown for the calling device is already in the protocol as Power request with a level of 0. Power level 1 is communications power only. This functionality will need to be optional. Devices that do not implement this capability will just ignore any such requests/commands. The ability to control specific other devices is, I believe, the point of Steve’s suggestion/request. I believe this has great merit and we need to figure out how to do it. Needed elements: Ability to identify devices by a unique identifier. Ability to message that specific device. Ability for that device to make determination of conditions for shutdown. Ability to restart that device when needed by any resource. Security for the transaction. A printer is a case where it may be used by the laptop, but could also be used by other devices on the power system. The relationship between the requestor and the device may not be unique. Many device could be using the printer. The printer would need to decide who it is servicing, possibly many devices, and if it can shut down. It may have its own service queue. Unique Identifier: This is the reason for the EUI. This will work even with many like devices. Looking up vendor/model/serialnumber would be hard to keep in a list of these properties as a queue. Specific device: We will need to build a tree/grid of all devices in the local environment. This could be a small as 2 for the simple adapter/sink connection or more elaborate for multi-output adapters with hub/adapters and other power sources such as solar/wind/etc. This mapping will provide the path to any element and the identifier for that element. We have the message structure for this. Conditions for shutdown: Each device capable of this remote control will need to keep a list of devices being services or logical attachments. It would be capable of shutting down as long as the logical attachment list has become empty. Ability to restart: Turn on only requires the addition to the logical attachment list of the device. This list now may be one long or longer. This could work to bring the entire system on line with messages to each effected, or dependent, device. Discovery of new devices will need to be addressed. Security: As Piotr pointed out, we would like to have the ability to ensure a rogue device, possibly with malicious intent, could cause a very disruptive shutdown, of power up for unauthorized access. This would need to be an additional optional feature. A possibility is to equip each capable device with an a PKE set into the device and have some of the power messages, as well as other messages, encrypted. As the messages are short and infrequent is should be less demanding computationally, but stills requires the storage space. A possibility would be something like the very well known SSH system. This could lead to 3 levels of implementation: 0 – no implementation – it is on or off 1 – simple command set with physical security being used 2 – a more secure system with encrypted messages. The design and the standard would need to allow, and work with, a mixed set. I believe this is a great concept and should be part of what we are doing. What will need to be in the standard to allow it to be implemented? Respectfully; Bob Davis Summit Computer Systems, Inc. bobd@xxxxxxxx 408.857.1273 From: upamd@xxxxxxxx [mailto:upamd@xxxxxxxx] On Behalf Of Paul Panepinto Hello Stephen: In my view, this is application level functionality outside the scope of the UPAMD spec. What is important is that UPAMD provides primitives so that any vendor wishing to implement this clever on/off energy-saving feature can do so. That said, we may want to consider a message type RequestShutDown. While we can clearly implement a scheme where the power hub shuts down power to peripheral devices when the PC shuts down without the need for exchanging messages, it would be nice to be more collaborative to give the peripherals a more graceful shutdown option or to refuse shutdown if needed. Best regards, Paul (970) 461-3077 Skype: ppanepinto Green Plug - Digital Power From: upamd@xxxxxxxx [mailto:upamd@xxxxxxxx] On Behalf Of stephen.sedio@xxxxxxxxxxx
|