Design and Evaluation of Power Management Support for UPnP Devices
description
Transcript of Design and Evaluation of Power Management Support for UPnP Devices
11
Design and Evaluation of Power
Management Support for UPnP Devices
Masters Defense – June 7, 2005 (Tampa, Florida)
Jakob Klamra and Martin Olsson Department of Communication Systems
Lund Institute of TechnologyLund, SWEDEN
22
Acknowledgments
Thanks to:
Dr. Christensen, USF
Dr. Nyberg, LTH
Dr. Labrador and Dr. Rundus, USF
Bruce Nordman, LBNL
Chamara Gunaratne, USF
33
Topics
Introduction
Analysis
Design
Implementation
Validation
Energy Savings Estimate
Conclusions and Future Work
44
Introduction
Problem: increased energy use by IT equipment More devices in US households IT equipment use 280 kWh/year per US household
• Adds up to $ 2240 million
Problem: IT equipment always on, even when idle Required by some protocols Universal Plug and Play (UPnP) has this problem
Our work solves the problem for UPnP Investigate the use of a power management proxy
55
Introduction continued
UPnP is for automatic device configuration Network analogy of Microsoft plug-and-play Control points and services Discovery, eventing and control
Standardized by UPnP Forum More than 700 vendors, Microsoft, Intel, Nokia
UPnP uses Simple Service Discovery Protocol SSDP is the key issue
66
Introduction continued
SSDP – message exchange Discovery SSDP:discover
• Answered by HTTP OK
Control Point
Service
Service
Service
SSDP:d
iscove
r
HTTP O
K
SSDP:discoverHTTP OK
SSDP:discoverHTTP OK
77
Introduction continued
SSDP – message exchange (continued) Notification SSDP:alive
• Sent out periodically
Control Point
Service
Service
Service
SSDP:a
live
SSDP:alive
SSDP:alive
88
Introduction continued
UPnP foundation, the stack
UPnP Vendor Specific
UPnP Forum Specific
UPnP Device Architecture
HTTP-MU
SSDP
HTTP-U
SSDP
HTTP
GENA
SOAP
GENA
UDP TCP
IP
Eventing and control use TCP
SSDP use UDP Our work is done here
99
Analysis
Requirements for power management solutions:
R1 – Enable UPnP devices to enter power sleep
R2 - Not interfere with existing UPnP functionality
R3 - Be robust
R4 - Work for wired and wireless
R5 - Handle many devices
R6 - Be possible for us to implement
1010
Analysis continued
Low power proxy Acts (answers and speaks) for sleeping devices Wakes up sleeping devices when they are needed
Proxy
Control Point Service
1. Service in power sleep
4. Service powered up
3. Wake
up
SLEEP2. Request for service
New
1111
Analysis continued
Possible solutions to UPnP power management
Three categories:
Centralized proxy, no change to devices• Invisible proxy
Centralized proxy, minor change to devices• Cooperating proxy
No proxy, major change to devices• Proxying NICs
1212
Design
Selection of the solutions All requirements must be fulfilled
Desirable properties• As much power sleep as possible• As little configuration as possible• As little changes to UPnP protocol as possible• …
Our design decision Invisible proxy Cooperating proxy
1313
Design continued
Design of invisible proxy
Proxy Control point
TCP SYN
Wake On Lan
Forward
TCP SYN TCP SYN
ACK
Timeout
start proxy
SSDP:discover
ST = Printer
(Spoofed) HTTP OKST=Printer
Service
SLEEP
1414
Design continued
Invisible proxy FSM
CHECK PROXY CACHE TCP P4
CHECK PROXY CACHE DISCOVERY P3
LISTENING P1
P12 Timeout
PROXY DEVICE P2
P23 SSDP:discover
P32b S in proxy cacheDiscovery answer
P24 TCP from CP
P45 S in proxy cacheWOL to S
WAIT FOR ALIVE P5
P51a SSDP:alive from SP55 Timeout
Forward packet from CP
CP = Control point, S = Service, WOL = Wake On Lan
1515
Design continued
Design of cooperating proxyProxy Control point
Service
SSDP:discover ST = Printer
HTTP OK (Spoofed)ST=Printer
TCP SYN
GENA Powermgmt
= SLEEP
HTTP OK
Wake On Lan
Forward TCP SYN TC
P SYN ACK
SLEEP
GENA Powermgmt =
POWER
1616
Design continued
Cooperating proxy FSM
CHECK PROXY CACHE TCP P4
PROXY DEVICE P2
CHECK PROXY CACHE DISCOVERY P3
P23 SSDP:discover
P32a S in proxy cacheDiscovery answer
P24 TCP from CP
P45 S in proxy cacheWOL to S
FORWARD PACKET P5
P51a GENA, Power mgmt=POWER
HTTP OKForward packet from CP
LISTENING P1
P12 GENA,Power mgmt=SLEEPHTTP OK
P51a GENA Power mgmt=POWERHTTP OK, Forward packet from CP
CP = Control point, S = Service, WOL = Wake On Lan
1717
Implementation
Development Tools
Programming environment• Dev-C++
Packet handling routines• NETWIB libraries
Packet capture and decoding• Ethereal
UPnP device toolkit• Intel software for UPnP technologies
1818
Implementation continued
Data structure for proxies
Device Cache
All devices on the network
UPnP Device
UPnP Device
UPnP Device
UPnP Device
Proxy Cache
All devices proxy is answering for
UPnP Device
UPnP Device
UPnP Device
UPnP Device
1919
Implementation continued
UPnP DeviceName Description
ip IP address
eth Ethernet address
service All services of the device
server Server name
location Location
last_activity Time for last activity from the device
Service
Service
Service
Service
2020
Implementation continued
Implementation of invisible proxyMain thread
Proxy cache update
Notification
Discover devices and build cache
Start threads
Main loop
Sniff packets
Process packets
Send answer and update caches
Check devices in Device Cache
Update Proxy Cache
Check Proxy Cache
If needed send SSDP:alive
Main loop Proxy cache update
Notification
Sniff packets
Process packets
Send answer and update caches
Check devices in Device Cache
Update Proxy Cache
Check Proxy Cache
If needed send SSDP:alive
2121
Implementation continued
Implementation of cooperating proxy
Main Thread
Discover power management services and build cache
Start threads
Main loopCache update
Notification
Read event socket
Sniff packets
Process packets
Answer and update caches
Check Device cache
Update Device cache
Check Proxy cache
Send SSDP:alive
Read and parse incoming events
Update Proxy cache
Main loopCache update
Notification
Read event socket
Sniff packets
Process packets
Answer and update caches
Check Device cache
Update Device cache
Check Proxy cache
Send SSDP:alive
Read and parse incoming events
Update Proxy cache
2222
Validation
Validation – design and implementation must meet requirements
Known shortcomings TCP forwarding not implemented Cannot detect crashed devices
Test cases 7 tests for each solution 3 tests not executed because lack of equipment
2323
Validation continued
Validation of invisible proxy 1 test passed 3 partially failed
• No unexpected behavior
Validation of cooperating proxy 2 tests passed 2 partially failed
• No unexpected behavior
2424
Energy saving estimation
Estimates made for US residential IT equipment
Estimates made for: Stock, power consumption, usage patterns
Calculations made for: Total energy and economic savings in 2008
Estimates from work by Energy Analysis Program at Lawrence Berkley National Laboratory Bruce Nordman
2525
Energy saving estimation continued
Background, stocks
11.3 11.9 6.3Laser printers
10210754.9Inkjets
42.4 44.717.3Notebooks
NetworkConnected
devices 2008
Devices2008 Devices 2001Device
82.8 89.367.9Desktops
(all figures are in million)
2626
Energy saving estimation continued
Results
3560 20%
High estimation
890 5%
Low estimation
Savings inGWh/year
(8 cents/kWh)
285
71
Savings in milliondollars per year
2727
Conclusions and future work
Conclusions Power management in UPnP achieved
• Proved by implementation and validation $71 - $285 million saved in American households
using UPnP by 2008
Contributions First to design and implement power management
proxy for UPnP Energy savings estimate motivates our work Member and contributors to UPnP Forum
UPnP power management problem solved
2828
Conclusions and future work continued
Shortcomings of the design
Long response time • TCP connection between service and control point
not established
Proxy can crash • Lost information about sleeping devices
Proxy not discoverable
Need to support several medium • UPnP is media independent
2929
Conclusion and future work continued
Future work
UPnP power management standard
Smart NIC • NIC with proxy capability • Distributed solution
Extended proxy functionality• Automatic configuration of power management• Routing of services
3030
References
In order of importance:[20] M. Jeronimo and J. Weast, UPnP Design by Example, Volume 1, April 2003
[26] B. Nordman and A. Meier, Energy Consumption of Home Information Technology, July 2004
[2] Y. Y. Goland, T. Cai, P. Leach and Y. Gu, Simple Service Discovery Protocol/1.0 Operating without an Arbiter, draft-cai-ssdp-v1-03.txt, IETF draft, October 1999
[5] UPnP Forum, http://www.upnp.org/, May 2005
[27] K. Christensen, B. Nordman and A. George, The Next Frontier for Communications Networks: Power Management, Computer Communications, Volume 27, Number 18, pages 1758-1770, December 2004
[3] D. Box, G. Kakivaya, A. Layman, S. Thatte and D. Winer, SOAP: Simple Object Access Protocol, draft-box-http-soap-01.txt, IETF draft, November 1999
[4] J. Cohen, S. Aggarwal and Y. Y. Goland, General Event Notification Architecture Base: Client to Arbiter, draft-cohen-gena-p-base-01.txt, IETF draft, September 2000
3131
Thank youJakob [email protected]
Martin [email protected]
Project homepage:www.csee.usf.edu/~jklamra/upnp