U.S. patent application number 13/302544 was filed with the patent office on 2013-05-23 for system and method for network enabled wake for networks.
This patent application is currently assigned to Cisco Technology Inc.. The applicant listed for this patent is Tirthankar Ghose, Amber Imam, John D. Parello, Rachel Ross, Charles B. Schoening. Invention is credited to Tirthankar Ghose, Amber Imam, John D. Parello, Rachel Ross, Charles B. Schoening.
Application Number | 20130132745 13/302544 |
Document ID | / |
Family ID | 48428107 |
Filed Date | 2013-05-23 |
United States Patent
Application |
20130132745 |
Kind Code |
A1 |
Schoening; Charles B. ; et
al. |
May 23, 2013 |
SYSTEM AND METHOD FOR NETWORK ENABLED WAKE FOR NETWORKS
Abstract
A method is provided in one example embodiment and includes
receiving a message at a network element configured for routing
packets, where the message directs a network device to change its
power state; identifying the network device as being associated
with a network for which the network element has responsibility;
and communicating at least a portion of the message from the
network element to the network device.
Inventors: |
Schoening; Charles B.;
(Little Silver, NJ) ; Parello; John D.; (Campbell,
CA) ; Ghose; Tirthankar; (San Ramon, CA) ;
Ross; Rachel; (Austin, TX) ; Imam; Amber;
(Castro Valley, CA) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Schoening; Charles B.
Parello; John D.
Ghose; Tirthankar
Ross; Rachel
Imam; Amber |
Little Silver
Campbell
San Ramon
Austin
Castro Valley |
NJ
CA
CA
TX
CA |
US
US
US
US
US |
|
|
Assignee: |
Cisco Technology Inc.
|
Family ID: |
48428107 |
Appl. No.: |
13/302544 |
Filed: |
November 22, 2011 |
Current U.S.
Class: |
713/310 |
Current CPC
Class: |
G06F 1/3209
20130101 |
Class at
Publication: |
713/310 |
International
Class: |
G06F 1/26 20060101
G06F001/26; G06F 15/16 20060101 G06F015/16 |
Claims
1. A method, comprising: receiving a message at a network element
configured for routing packets, wherein the message directs a
network device to change its power state; identifying the network
device as being associated with a network for which the network
element has responsibility; and communicating at least a portion of
the message from the network element to the network device.
2. The method of claim 1, wherein an application program interface
(API) is leveraged in order to communicate the portion of the
message, which identifies a media access control (MAC) address
associated with the network device.
3. The method of claim 1, wherein the message includes filter
criteria to be used to identify the network device.
4. The method of claim 3, further comprising: searching a selection
criteria database to identify the network device identified by the
filter criteria.
5. The method of claim 3, wherein the filter criteria is used to
identify a group of network devices for which a subsequent message
for changing power states is intended.
6. The method of claim 1, wherein the network device is part of a
subnet associated with the network element.
7. The method of claim 1, further comprising: receiving a
subsequent message at the network element, wherein the subsequent
message directs a group of network devices to change their
respective power states; identifying priority characteristics
associated with the group of network devices; and communicating at
least a portion of the subsequent message to a certain subset of
the group of network devices based on their respective priority
characteristics.
8. Logic encoded in non-transitory media that includes code for
execution and when executed by a processor operable to perform
operations, comprising: receiving a message at a network element
configured for routing packets, wherein the message directs a
network device to change its power state; identifying the network
device as being associated with a network for which the network
element has responsibility; and communicating at least a portion of
the message from the network element to the network device.
9. The logic of claim 8, wherein an application program interface
(API) is leveraged in order to communicate the portion of the
message, which identifies a media access control (MAC) address
associated with the network device.
10. The logic of claim 8, wherein the message includes filter
criteria to be used to identify the network device.
11. The logic of claim 10, further comprising: searching a
selection criteria database to identify the network device
identified by the filter criteria.
12. The logic of claim 10, wherein the filter criteria is used to
identify a group of network devices for which a subsequent message
for changing power states is intended.
13. The logic of claim 8, wherein the network device is part of a
subnet associated with the network element.
14. The logic of claim 8, the operations further comprising:
receiving a subsequent message at the network element, wherein the
subsequent message directs a group of network devices to change
their respective power states; identifying priority characteristics
associated with the group of network devices; and communicating at
least a portion of the subsequent message to a certain subset of
the group of network devices based on their respective priority
characteristics.
15. An apparatus, comprising: a memory element; a processor
operable to execute instructions associated with electronic code;
and a module operable to interface with the processor such that the
apparatus is configured for: receiving a message at a network
element configured for routing packets, wherein the message directs
a network device to change its power state; identifying the network
device as being associated with a network for which the network
element has responsibility; and communicating at least a portion of
the message from the network element to the network device.
16. The apparatus of claim 15, wherein an application program
interface (API) is leveraged in order to communicate the portion of
the message, which identifies a media access control (MAC) address
associated with the network device.
17. The apparatus of claim 15, wherein the message includes filter
criteria to be used to identify the network device.
18. The apparatus of claim 17, the apparatus being further
configured for: searching a selection criteria database to identify
the network device identified by the filter criteria.
19. The apparatus of claim 17, wherein the filter criteria is used
to identify a group of network devices for which a subsequent
message for changing power states is intended.
20. The apparatus of claim 15, wherein the network device is part
of a subnet associated with the network element.
Description
TECHNICAL FIELD
[0001] This disclosure relates in general to the field of
communications and, more particularly, to a system and a method for
network enabled wake for networks.
BACKGROUND
[0002] Energy consumption has become a preeminent concern for
industrialized societies. Both consumers and businesses have become
aware of their energy usage. Whether motivated by altruistic
reasons, or by profitability concerns, individuals have come to
terms with the notion that energy is a finite commodity: a
commodity having accompanying costs that should be managed.
Administrators now focus on power usage and, more specifically, on
how to reduce those expenditures. In recent times, device
manufacturers have added instrumentation and features in the
network to quell these concerns. As network systems have become
more sophisticated, while energy demands have continued to
increase, architectures often fail in matching network capabilities
with more intelligent energy consumption.
BRIEF DESCRIPTION OF THE DRAWINGS
[0003] To provide a more complete understanding of the present
disclosure and features and advantages thereof, reference is made
to the following description, taken in conjunction with the
accompanying figures, wherein like reference numerals represent
like parts, in which:
[0004] FIG. 1 is a simplified block diagram of an energy management
system in accordance with one embodiment of the present
disclosure;
[0005] FIG. 2A is a simplified block diagram illustrating possible
example details associated with one embodiment of the present
disclosure;
[0006] FIG. 2B is a simplified block diagram illustrating possible
example details associated with one embodiment of the present
disclosure;
[0007] FIG. 3 is a simplified flow diagram illustrating potential
operations associated with one embodiment of the present
disclosure;
[0008] FIG. 4 is a simplified flow diagram illustrating potential
operations associated with one embodiment of the present
disclosure; and
[0009] FIG. 5 is a simplified flow diagram illustrating potential
operations associated with one embodiment of the present
disclosure.
DETAILED DESCRIPTION OF EXAMPLE EMBODIMENTS
Overview
[0010] A method is provided in one example embodiment and includes
receiving a message at a network element configured for routing
packets. The message directs a network device to change its power
state. The method also includes identifying the network device as
being associated with a network for which the network element has
responsibility, and communicating at least a portion of the message
from the network element to the network device.
[0011] In more specific implementations, an application program
interface (API) is leveraged in order to communicate the portion of
the message, which identifies a media access control (MAC) address
associated with the network device. In yet other embodiments, the
message includes filter criteria to be used to identify the network
device. In addition, the method may include searching a selection
criteria database to identify the network device identified by the
filter criteria. In more specific implementations, the filter
criteria is used to identify a group of network devices for which a
subsequent message for changing power states is intended. The
network device can be part of a subnet associated with the network
element.
Example Embodiments
[0012] FIG. 1 is a simplified block diagram of an energy management
system 10 in accordance with one example implementation of the
present disclosure. FIG. 1 includes a subnet 18, which can include
any number of network devices 32. Subnet 18 is typically a
logically visible subdivision of an internet protocol (IP) network;
however, subnet 18 can be any network that allows a switch to
communicate with, control, and/or manage network devices 32 in
subnet 18. A controller 20 can be provisioned in a network 22 in
order to execute certain power management activities discussed
herein. A number of switches 34 are also provisioned in network 22.
In certain implementations, each switch 34 may contain a
wake-on-local area network (LAN) module 26. Wake-on-LAN module 26
can be configured to send change power state requests to network
devices 32 at appropriate times. Additionally, a gateway 28 may be
provisioned in network 22 such that it can interface with
converging-IP devices 36, as is being illustrated in FIG. 1.
[0013] In this particular implementation of FIG. 1, the
infrastructure of subnet 18 can interact with a number of network
devices 32 (e.g., personal computers (PCs), building controllers,
wireless devices, telephones, lighting fixtures, HVAC systems,
video devices (e.g., Telepresence systems), etc). Certain network
devices 32 may be associated with IP devices having corresponding
Software Development Kit (SDK) elements. Similarly, gateway 28 may
operate as a parent SDK for its child endpoints (e.g., a plurality
of converging-IP devices 36). Subnet 18 is also coupled to a set of
power management applications 12, which may include elements such
as a LAN management element, etc. Management applications 12 can
operate to intelligently control (directly or indirectly) any of
the devices of FIG. 1.
[0014] In general terms, energy management system 10 is configured
to measure and monitor power for network devices 32 (e.g., phones,
AP's, PCs, building systems, etc.) and, further, provide command
and control for network devices 32. The activities of energy
management system 10 may include communicating messages to
individual network devices 32 for shifting from one power state to
a different power state (e.g., shifting from a normal operating
state to a hibernation state), as further detailed below.
[0015] In operation, energy management system 10 provides a
mechanism that understands the power consumption characteristics of
network devices 32 for which it has responsibility. This can
include understanding which network devices 32 can shift from one
power state (e.g., a normal operating state) to a different power
state (e.g., a hibernation, sleep mode, or shut down state).
Additionally, the architecture is configured to query for power
information using the network and, furthermore, implement
time-of-day policies to control network devices 32. In essence, the
network can operate as a control plane for controlling the energy
consumption/usage for one or more network devices 32 within subnet
18. In this sense, the network serves as a platform for intelligent
energy control. From a practical perspective, the smart loading
capabilities of the architecture allow for a tangible cost savings
for an associated enterprise.
[0016] For purposes of illustrating certain example techniques of
energy management system 10, it is important to understand how
energy management system 10 provides command and control functions
for network devices 32. The infrastructure of subnet 18 can
interact with a number of network devices 32 (e.g., a local storage
module, personal computers (PCs), building controllers, wireless
devices, telephones, lighting fixtures, HVAC systems, video devices
(e.g., Telepresence systems), etc.). The wake-on-LAN technology of
energy management system 10 can enable network devices 32 to be
remotely awaken from a hibernating or sleep state. In one
particular instance, the wake-on-LAN mechanism uses a management
station to broadcast a "magic packet" containing a media access
control (MAC) address of a target network device 32. The terms
wake-on-LAN, wake-on-LAN technology, wake-on-LAN requests, etc.
generally refer to any suitable request for the transition of a
device from one power state to a different power state. A network
card on a wake-on-LAN enabled network device 32 is kept powered so
when the network card sees its MAC address contained in a
wake-on-LAN message, the network card initiates a power-up of the
network device. However, the broadcast mechanism of directing
wake-on-LAN requests can be difficult to deploy in an enterprise
network because security policies in routers typically drop subnet
directed broadcasts, thus preventing wake-on-LAN messages from
being received. For this reason, wake-on-LAN is often restricted to
working on local area networks instead of working on other networks
(e.g., an enterprise wide area network (WAN)).
[0017] In one particular example involving the use of a proxy
model, the wake-on-LAN feature may be provided in enterprise WAN
networks. In such an example, one or more network devices 32 in a
subnet can remain powered on and run a special software agent,
which is used to locally broadcast a received wake-on-LAN payload
within the subnet. For example, one or more powered on network
devices 32 can receive a unicast transmission of a wake-on-LAN
message. In response, a wake-on-LAN message can be broadcast within
the subnet by one or more of the powered on network devices 32,
which effectively circumvents the problem of routers dropping
global broadcasts. However, while functional, the proxy model has
several disadvantages including the requirement of vendor software,
the installation of the vendors network devices' agent across the
enterprise, the necessity of dedicated network devices 32 to remain
powered on, and the failure issues when the agent is down or
otherwise unreachable. In addition, enterprises with many small
subnets may find leaving one or two network devices 32 active
(e.g., per subnet) can significantly diminish their energy savings
of reducing energy consumption for network devices 32 (e.g., to
sleep during off peak hours).
[0018] The architecture of FIG. 1 can overcome these shortcomings
(and others) in leveraging a network element (e.g., a switch) to be
utilized as a local broadcaster for a request to change power
states (e.g., a wake-on-LAN request). In at least one sense, the
network element (e.g., a switch, a router, a gateway, etc.)
receiving the message can have responsibility for one or more
network devices for which the message was intended (e.g., the
network element has an association with the network device, has a
relationship with the network device, has been entrusted to manage
the network device, has a geographical congruency with the network
device, shares some commonality with device, has been assigned
power management for the network device, shares a subnet with the
network device, etc.).
[0019] In more specific instances, this can involve using a
command-line interface (CLI), a simple network management protocol
(SNMP), or other available management application programming
interfaces (APIs). These mechanisms allow controller 20 to transmit
a change power state request for network device(s) 32 to switch 34,
which can then locally broadcast a change power state request to
network device(s) 32 in a local subnet 18 assigned to switch 34.
[Note that more than one subnet 18 may be assigned to switch
34].
[0020] In another example embodiment, a network domain of devices
may use a protocol (e.g., an EnergyWise protocol) to transmit a
change power state request based on a MAC address (or other
addresses) to switches 34 residing in the network domain. Each
switch 34, after checking certain filter criteria, can locally
broadcast the change power state request to network device(s) 32 in
the local subnet(s) assigned to switch 34. In this example, network
device(s) 32 matching the MAC address(es) in the change power state
request would be awoken. Additionally, filter criteria can be
specified to narrow the broadcasts (e.g., anywhere from each of
network devices 32 in the domain, to a single network device
specific to the switch). This feature would effectively allow a
change power state request to be tunneled over the underlying
protocol (e.g., EnergyWise protocol).
[0021] In yet another example embodiment, a network domain of
devices may use a protocol (e.g., EnergyWise protocol) to transmit
multiple change power state requests based on selection criteria
that does not include a MAC address. For example, the selection
criteria may include all network devices 32 in a specific
department or all network devices 32 that are at (or above) a
security level. In this model, the MAC address of the network
device(s) matching the selection criteria can be determined by
switch 34.
[0022] For example, if the selection criteria includes network
devices above a certain security level, then the switch can
determine the MAC address for the network devices assigned to the
switch that are above the certain security level. In this manner,
one or more network devices can be requested to change power states
with a single filter criterion. The network domain of devices may
include controller 20. While controller 20 can initiate the
request, controller 20 does not necessarily need to know the MAC
address of network devices 32, or which switches 34 are assigned to
each network device 32.
[0023] In operation, the architecture of energy management system
10 allows for the management of network devices (e.g., personal
computers (PCs)) connected to switches, wireless access point, etc.
using the network to monitor, control, and (ultimately) save
energy. The architecture has the ability to issue, distribute, and
deliver change power state requests (e.g., wake-on-LAN messages)
throughout energy management system 10. Any of the components of
energy management system 10 can readily communicate a broadcast
message that requests certain network devices to shift from one
power state to another power state. This broadcast message can be
triggered based on specific policies, based on administrator
preferences/provisioning, based on cost considerations, etc. No
that as used herein in this Specification, the broad term `message`
is inclusive of the previously mentioned items (e.g., requests to
change power state) and any other suitable network message that can
be communicated from one location to another. The actual message
can be received, and then forwarded (in its entirety, or at least a
part of the message) based on certain criteria, as discussed
herein.
[0024] Consider an example campus network deployment, where users
are not using their network devices 32 (e.g., at night). If a
message is received for network devices to enter into low power
state (e.g., a message indicating network devices 32 should enter
into a hibernation state), a broadcast message can be communicated
to each network device, where the broadcast message is
requesting/instructing the network devices to shift from a normal
operating state to a hibernation state. This would reduce the power
being consumed over this time interval.
[0025] Switch 34 is configured to send out appropriate messages to
network devices 32, to selected network devices 32, to selected
groups of network devices 32, etc. in order to instruct them that
they should switch power states. In one particular example, the
network devices are configured to interpret the broadcast messages
such that network devices 32 can readily switch power states. In
certain implementations, the broadcast messages received by network
devices 32 can include an assigned time interval for the network
devices to remain in the power state. Additional instructions can
indicate particular states for transitioning from the power state
(e.g., transitioning to a normal operating state after being in a
hibernation state for the requisite time interval).
[0026] Management applications 12 can communicate with designated
network devices 32 using various communication protocols. In one
example, the communication is delivered over a wired network. In
other instances, a wireless access point can deliver the
communication wirelessly via management frames in a corresponding
802.11 message. Note that in particular use cases, an Energy
Efficient Ethernet protocol (e.g., IEEE 802.3az) can be involved in
such messaging. Other protocols can include proprietary mechanisms,
unicasting activities, multicasting activities, simple TCP/IP
communications, user datagram protocol (UDP) communications,
appropriate discovery protocols, etc.
[0027] In one example operation, demand response broadcast messages
instruct the devices to shift into different power states. In
particular implementations involving personal computers, the
broadcast message can include a Windows.TM. PowerCfg command, which
instructs a network device to switch power states. Moreover,
existing protocols in network devices can be used as a mechanism to
affect the power state change. For example, `Desktop and mobile
Architecture for System Hardware` (DASH) and vPro (e.g., in Intel
environments) can be leveraged to achieve this activity. In other
instances, Windows Management Instrumentation (WMI) could be
leveraged for initiating the change. WMI is simply an API in the
Windows operating system that enables devices and systems in a
network (e.g., typically enterprise networks) to be managed and
controlled. Often utilizing common information model (CIM), WMI
allows network administrators to query and manage workstations,
applications, networks, etc.
[0028] Operationally, network devices 32 are configured to enter
into a different power state based on any number of potential
options. For example, one option may be associated with a timeout
message provided in the request to switch power states. The message
would indicate, for example, to switch to a hibernation state for
the next four hours. Another option would involve a second message
sent to instruct network devices 32 to enter into a new power state
(e.g., a normal operational power state after being in a
hibernation state). Still other options can involve default-timing
mechanisms (specific to each network device 32) such that network
devices 32 would automatically shift to their normal power state
after some predefined time interval (e.g., 60 minutes, etc.).
[0029] Note that certain infrastructure may be aware of whether
network devices 32 have the option of changing power states. For
example, in an EnergyWise.TM. domain, the switch to which network
devices 32 are connected would know that each network device 32 has
several different power states (power options). Other mechanisms
for knowing the power state options of network devices 32 (before
the power state change signals are sent) can involve simple
provisioning by an administrator, discovery mechanisms when network
devices 32 come online, querying activities involving individual
network devices 32, etc. The different power states may include a
normal operating power state, a reduced or low power state, a
hibernation power state, etc.
[0030] A number of advantages can be achieved by the architecture
of energy management system 10. For example, the architecture is
configured to intelligently control power from the network
perspective. Hence, the architecture of energy management system 10
allows network and network-attached equipment to take advantage of
a configuration that includes no central processing and no central
repository. Such a configuration also offers the advantage of
having no single point of failure. The group devices of a cloud
(i.e., the network) can be self-managed, where there is no central
control. Controller 20 can be representative of a single computing
device, which could be provisioned virtually anywhere in the
network, or a plurality of controllers 20 can be provisioned at
strategic locations in the network, as further described below.
[0031] Separately, the configuration of energy management system 10
is protocol agnostic, where various communication transports can be
used. The architecture also fosters cloud computing to be done to a
variable number of entities (all of which may have different types
of ASICS, OSs, etc.). Dynamically, network devices 32 can join and
leave the heterogeneous environment, where various types of network
devices 32 can be readily managed by energy management system
10.
[0032] As a stand-alone solution, energy management system 10
enables businesses to monitor and to control the electric
consumption of networking equipment. An administrator can monitor
devices like switches and routers, as well as LAN switch connected
Power over Ethernet (PoE) devices such as phones, access points, IP
security cameras, door access equipment, etc. Energy management
system 10 also has the ability to monitor and to control the energy
demands of AC powered devices such as smart power distribution
units, networked building systems, office equipment, etc. Energy
management system 10 also includes an open interface to allow 3rd
party management systems to participate in the framework. This
simplifies integration of power reporting and automation for
existing business practices.
[0033] Briefly discussing some of the possible signaling mechanisms
of the architecture, the system of FIG. 1 can leverage a simple
network management protocol (SNMP) and a secure socket layer (SSL)
protocol [as part of a management application program interface
(API)] to execute any of the functions of the present disclosure.
Management applications 12 can be tailored for particular
facilities, or configured for specific IT scenarios. Management
applications 12 can also be configured to correlate power data with
location, and then allocate power accordingly. Switches and routers
can readily communicate through a management API, where the network
can aggregate status and power information. In terms of a client
protocol mechanism, this element can communicate status and receive
policies.
[0034] In regards to the management API for management applications
12, there can be several methods for a management application to
communicate with the network (e.g., SNMP, SSL, etc.). A management
information base (MIB) can be available on each enabled network
device and, further, can include power usage, power policy, alarms,
etc. The MIB can also provide per-device information. Network
management systems interested in a network-wide query can use the
SSL interface. The SSL interface can allow a single switch to
query/set information from/to certain switches in a domain.
[0035] Turning to FIG. 2A, FIG. 2A is a simplified block diagram
illustrating one possible set of details associated with energy
management system 10. FIG. 2A includes controller 20, network 22,
switches 34, and subnets 18, which may include one or more network
devices (not shown for purposes of simplicity). Each switch 34 may
include an instance of wake-on-LAN module 26 to communicate change
power state requests to network devices 32. Wake-on-LAN module 26
may include a processor 40 and a network memory element 38, which
may include a selection criteria database 46.
[0036] Members of subnets 18 may include switches, routers, network
controllers, gateways, network appliances, or any other suitable
network infrastructure, which make up the data network proper (as
well as network devices 32 not shown). Subnets 18 are much like a
community in network management, where each subnet 18 can form a
unit of power management. Hence, subnets 18 can be viewed as a
logical group of entity devices. Additionally, managers (e.g.,
control applications) can be used to measure, monitor, and/or
manage power consumption.
[0037] In terms of relationships, subnet 18 members (e.g., the
switches and the routers) can operate as "neighbors" while
establishing "parent-child" relationships with network devices in
each subnet 18. Keywords can be used to tag devices in subnet 18
with labels to filter searches or queries. The keywords can be
stored in selection criteria database 46 of switch 34 (or at any
other suitable location), where these keywords can be used to
identify specific devices or groups of devices with common
attributes (e.g., devices in a building lobby, related to security,
etc.). The actual queries can determine energy usage, set power
levels and/or power states across the network. The actual power
level can indicate the power state of an entity. In regards to
importance (priority), devices can be differentiated by how they
would be affected by power state changes. For example, critical
devices (e.g., stairway lighting, HVAC, fire alarms, etc.) would
have a higher priority than noncritical devices (e.g., charging
laptops, courtesy phones provided a lobby, etc.).
[0038] Additionally, policies can be set with a network-based query
to make power state changes (e.g., return all devices on the first
three floors of a building to a normal operating state at 7:00
a.m.). The network query can be initiated by controller 20, sent to
one or more switch(s) 34, and then propagated across subnet(s) 18,
which contain the devices that satisfy the network query.
[0039] The ability to create tags or keywords is available in
energy management system 10, and these can be used to improve the
search capability of a network-based query. Any arbitrary set of
keywords can be defined per port, per network device, per subnet,
or using any other suitable criteria. For example, a given client
such as a PC can have specific keywords stored within the device
such that, as the client moves between ports or subnets 18, the
keywords can follow the device.
[0040] In an embodiment, controller 20 may determine which devices
in each subnet 18 should change power states. Controller 20 can
send a change power state request to each switch 34. Each switch 34
can then locally broadcast the change power state request to each
device (in subnet 18) that is associated with the switch.
Controller 20 does not need to know which devices (or how many
devices) are in each subnet 18 because that information can be
managed elsewhere (e.g., by wake-on-LAN module 26).
[0041] In another embodiment, controller 20 may determine that a
specific subnet or a specific device in a subnet should change
power state. Controller 20 can then send a change power state
request to each switch 34, where the change power state request can
include a specific MAC address, or set of MAC addresses. After
receiving the change power state request, each switch 34 can
determine if the MAC address matches a MAC address in selection
criteria database 46 for switch 34. If the MAC address matches a
MAC address in selection criteria database 46, then switch 34 can
locally broadcast the change power state request to the device that
is associated with the MAC address. A device matching the MAC
address in the change power state request can receive the change
power state request from switch 34.
[0042] In another embodiment, controller 20 may determine that a
specific group of devices should change power state. Controller 20
can then send a change power state request to each switch 34, where
the change power state request includes certain filter criteria
(e.g., only devices that are non-essential devices should change
power state, only devices that are located on a certain floor of a
building should change state, etc.). Each switch 34 can then
determine if the filter criteria matches data in selection criteria
database 46. Switch 34 can locally broadcast the change power state
request to the devices in subnet 18 that match the filter criteria.
Controller 20 does not need to know the MAC address of the devices,
or where the devices are located in the network, or which switches
control the devices that should change power state. If the filter
criteria matches filter criteria in selection criteria database 46
in switch 34, then the switch would determine the MAC address of
the network device(s) that should receive the change power state
request.
[0043] Controller 20 can maintain any number of data (e.g., tables,
lists, policies, etc.) that can be used in the management of the
architecture. For example, the data can reveal a given network
device's identification or ID, the network device's role, the
domain of the network device, the importance/priority of the
network device, the current state of the network device, a
respective management interface for the network device, any
keywords or filter criteria associated with the network device,
etc.
[0044] Power policies can be sent to each switch 34, where the
policies can be propagated to individual network devices. For
example, a policy could be propagated to switches 34 to indicate to
shut down phones in a building at 8 PM. Another example could
involve moving HVAC systems to certain levels after the workday has
concluded. Another example could involve switching to a hibernation
state for all PCs during a lunch hour (e.g., 12 PM-1 PM).
[0045] In one example implementation, controller 20 and/or
wake-on-LAN module 26 can include software to facilitate energy
management operations. For example, controller 20 and/or
wake-on-LAN module 26 may include software that is configured to
intelligently evaluate an opportune time for sending broadcast
messages to the network devices for switching between power states.
In example embodiments, network access can be leveraged to offer
the capability for an end user to control energy parameters in a
given domain.
[0046] Controller 20 is a network element configured to interact
with switches 34 in order to manage energy usage of network devices
32 in energy management system 10. Note that controller 20 can
readily be part of a server in certain embodiments of this
architecture, or provisioned in conjunction with management
applications 12, or provisioned in any other suitable device or
network location. As used herein in this Specification, the term
`network element` is meant to encompass proprietary devices,
servers, network appliances, routers, switches, management
appliances, gateways, bridges, loadbalancers, firewalls,
processors, modules, or any other suitable device, note,
proprietary component, element, or object operable to exchange
information in a network environment. Moreover, the network
elements may include any suitable hardware, software, components,
modules, interfaces, or objects that facilitate the operations
thereof. This may be inclusive of appropriate algorithms and
communication protocols that allow for the effective exchange of
data or information.
[0047] Software for providing intelligent energy management
functionalities can be provided at various locations. In one
example implementation, this software is resident in a network
element (e.g., provisioned in controller 20, wake-on-LAN module 26,
etc.). In other examples, this could involve combining domain
devices, controller 20 and/or switch 34 with an application server,
a firewall, a gateway, or some proprietary element, which could be
provided in (or be proximate to) these identified network elements,
or this could be provided in any other device being used in a given
network. In other embodiments, each network device 32, switch 34
(inclusive of wake-on-LAN module 26), and/or each instance of
controller 20 may include any suitable algorithms, hardware,
software, components, modules, interfaces, or objects that
facilitate these energy management operations. This may be
inclusive of appropriate communication protocols that allow for the
effective exchange of data or information for achieving energy
management in a network environment.
[0048] Logistically, certain items or elements can be provisioned
for the intelligent energy management system to function. For
example, network devices 32 can include an agent (for example, in
software) that allows network devices 32 to respond to broadcast
messages from the network. Note that the term `broadcast message`
as used herein in this Specification is meant to encompass any type
of signaling, packet information, messaging, short message service
(SMS) communications, instant messaging (IM), e-mail protocols, or
any other message type that can be delivered to a network device
such that it understands to switch between available power states.
In still other embodiments, the energy management features may be
provided externally to controller 20, switch 34, and/or network
devices 32, or included in some other network device, or in a
computer to achieve these intended functionalities.
[0049] Turning to FIG. 2B, FIG. 2B is a simplified block diagram
illustrating one possible set of details associated with energy
management system 10. FIG. 2B includes a number of subnets 18a-c,
which are coupled to switch 34. Each of subnets 18a-c can include
any number of network devices 32a-g (with accompanying
infrastructure) provisioned in any suitable computing environment.
Using selection criteria database 46, switch 34 can determine which
network devices 32a-g are associated with switch 34, specific
keywords associated with each network device 32a-g, the MAC address
of each network device 32a-g, etc. Energy management system 10 is
configured to leverage the network to enable monitoring and
controlling of connected network devices 32a-g through switch 34.
The architecture allows the network to form a control plane for
energy management and, further, offers IT organizations a tool for
managing energy more effectively.
[0050] Network devices 32a-g are representative of power consumers
of any kind. For example, network devices 32a-g can be
representative of PoE and non-PoE devices that can connect to the
network. Further, network devices 32a-g can include nontraditional
network devices such as facility controllers, lighting, heating
ventilation, and air conditioning (HVAC), etc. The term `network
device` can also be inclusive of devices used to initiate a
communication, such as a switch, a console, a proprietary endpoint,
a telephone, a bridge, a computer, a personal digital assistant
(PDA), a laptop or electronic notebook, an i-Phone, an iPad, a
Google Droid, any other type of smartphone, a Telepresence system,
an access point, a router, a switch, a gateway, a server, or any
other device, component, element, or object capable of facilitating
voice, audio, or data exchanges within energy management system
10.
[0051] Network devices 32a-g may also be inclusive of a suitable
interface to an end user, such as a microphone, a display, or a
keyboard or other terminal equipment. Network devices 32a-g may
also include any device that seeks to initiate a communication on
behalf of another entity or element, such as a program, a database,
or any other component, device, element, or object capable of
initiating a voice or a data exchange within energy management
system 10. Data, as used herein, refers to any type of video,
numeric, voice, packet, or script data, or any type of source or
object code, or any other suitable information in any appropriate
format that may be communicated from one point to another.
[0052] It should be noted that there are various protocols that can
change the energy state for a device (e.g., wake-up the device).
For example, example network protocols can include WakeOnLan, DASH,
SMASH, and VPRO. Separately, example non-network protocols can
include toggling power on a PoE port, PDU plug, and a virtual
circuit breaker. In operation, a switch or management station could
determine which protocol to use to wake up a device (e.g., based on
which protocol(s) the device supports).
[0053] The architecture of the present disclosure can use a
WakeOnNetwork protocol, which refers to the device capability to
support protocols such as WakeOnLan, SMASH, DASH, VPRO, or other
protocols, that effectively change energy state (e.g., wake-up a
device) such that the device transitions from a non-operational to
an operational state. Operational and non-operational levels can be
defined by power levels 0-10. Non-operational state could be, for
example, 0 shut off, 1 hibernate, 2 sleep. In addition, operational
states could be, for example, 3 standby, 4 ready, 5 low, 6 frugal,
7 medium, 8 reduced, 9 high, 10 full.
[0054] In specific implementations of the presence disclosure,
discovery packets received from endpoints can contain a
WakeOnNetwork (WoN) capability vector that indicates which types of
WoN protocols it supports. This data can be stored by the switch
for each endpoint. Based on the device's WakeOnNetwork capability
vector (and other configurable parameters), the switch can compose
a WoN packet. Separately, the switch can use the cached MAC
address, and send the WoN packet to the device.
[0055] A given device can be configured to inform the switch which
protocol(s) are supported and, based on this information, the
switch can compose the appropriate packet, or other mechanisms to
change the energy state of the device. The device can provide
configurations in addition to the WoN capability vector. The device
can also provide a UDP port number to be used when the switch
transmits WoN packets. In addition, the device may provide values
for certain power levels that are relevant to WoN, such as maximum
non-operational level, and minimum operational level. Such levels
can be used to determine if WakeOnNetwork is indicated for a
particular situation.
[0056] FIG. 3 is a simplified flowchart 300 illustrating example
activities of network enabled energy management provisioning for a
device. At 302, a network domain controller determines which
devices associated with a subnet should receive a change for a
power request. For example, controller 20 may determine which
network devices 32 should receive a change power state request. At
304, the change of power request can be communicated to a switch,
which is associated with each device that is to receive the change
power state request. For example, controller 20 may communicate the
change in power request to switch 34. At 306, the switch receives
the change power state request and communicates the change power
state request to the device. For example, switch 34 may communicate
the change of power request to each network device 32 in subnet 18.
At 308, the device can transition from one power state to a
different power state (e.g., a non-operable state to an operable
state).
[0057] FIG. 4 is a simplified flowchart 400 illustrating example
activities of network-enabled energy management provisioning for a
device. At 402, a change power request is received at a switch
associated with a subnet. For example, switch 34 may be associated
with subnet 18 and receive a switch power request from controller
20. At 404, the system determines if the change power request is
for the entire subnet. For example, switch 34 may determine if the
change power request is for the entire subnet 18. If the change
power request is for the entire subnet, then a change power request
is sent to the entire subnet, as illustrated in 408. If the change
power request is not for the entire subnet, then a change power
request is sent to the devices designated in the change power
request, as illustrated in 408. For example, switch 34 may send the
change power request to only network devices 32 designated in the
change power request (or switch 34 may use priority characteristics
to determine a subset of network devices for which the message
should be sent).
[0058] FIG. 5 is a simplified flowchart 500 illustrating example
activities of network-enabled energy management provisioning for a
device. At 502, a switch receives a change power request for a
device. For example, switch 34 may receive a change power request
from controller 20. At 504, the system determines if a keyword or
MAC address in the change power request matches a keyword or MAC
address in a database associated with the switch. For example,
switch 34 may determine if a keyword or MAC address in the change
power request matches a keyword or MAC address in selection
criteria database 46. If the keyword or MAC address does not match
a keyword or MAC address in the database associated with the
switch, then the change power request is ignored, as illustrated in
506. If the keyword or MAC address matches a keyword or MAC address
in the database associated with the switch, then the change power
request is sent to the device associated with the keyword or MAC
address, as illustrated in 508. For example, based on the keyword
or MAC address in the change power request matching information in
selection criteria database 46, specific network devices 32 may be
identified, and the change power request can be communicated to the
identified network devices 32.
[0059] As identified previously, a network element can include
software to achieve the energy management operations, as outlined
herein in this document. In certain example implementations, the
energy management functions outlined herein may be implemented by
logic encoded in one or more non-transitory tangible media (e.g.,
embedded code provided in an application specific integrated
circuit [ASIC], digital signal processor [DSP] instructions,
software [potentially inclusive of object code and source code] to
be executed by a processor [processor 40 shown in FIGS. 2A and 2B],
or other similar machine, etc.). In some of these instances, a
memory element [network memory element 38 shown in FIGS. 2A and 2B]
can store data used for the operations described herein. This
includes the memory element being able to store code (e.g., logic,
software, or processor instructions) executed to carry out the
activities described in this Specification. The processor can
execute any type of instructions associated with the data to
achieve the operations detailed herein in this Specification. In
one example, the processor could transform an element or an article
(e.g., data) from one state or thing to another state or thing. In
another example, the activities outlined herein may be implemented
with fixed logic or programmable logic (e.g., software/computer
instructions executed by the processor) and the elements identified
herein could be some type of a programmable processor, programmable
digital logic (e.g., a field programmable gate array [FPGA], an
erasable programmable read only memory (EPROM), an electrically
erasable programmable ROM (EEPROM)) or an ASIC that includes
digital logic, software, code, electronic instructions, or any
suitable combination thereof.
[0060] Any of these elements (e.g., the network elements, etc.) can
include memory elements for storing information to be used in
achieving the energy management activities as outlined herein.
Additionally, each of these devices may include a processor that
can execute software or an algorithm to perform the energy
management activities as discussed in this Specification. These
devices may further keep information in any suitable memory element
[random access memory (RAM), ROM, EPROM, EEPROM, ASIC, etc.],
software, hardware, or in any other suitable component, device,
element, or object where appropriate and based on particular needs.
Any of the memory items discussed herein (e.g., a database) should
be construed as being encompassed within the broad term `memory
element.` Similarly, any of the potential processing elements,
modules, and machines described in this Specification should be
construed as being encompassed within the broad term `processor.`
Each of the network elements can also include suitable interfaces
for receiving, transmitting, and/or otherwise communicating data or
information in a network environment.
[0061] Note the previous examples can involve identifying peak
power times in smoothing or time shifting the power usage in a
given environment. For example, a management application can
monitor power consumption and receive a peak power alert. A policy
can be created to minimize this peak consumption by leveraging
power states. Part of this policy may include identifying eligible
phones, laptops, and building HVAC systems that could be candidates
for shifting to a low power state or hibernation state. For
example, in the context of these identified devices, a laptop could
move to hibernation, eligible phones could also move to a low power
state, printers could move to a sleep mode or hibernation
state.
[0062] Note that with the examples provided above, interaction may
be described in terms of two, three, or four network elements.
However, this has been done for purposes of clarity and example
only. In certain cases, it may be easier to describe one or more of
the functionalities of a given set of flows by only referencing a
limited number of network elements. It should be appreciated that
energy management system 10 (and its teachings) are readily
scalable and, further, can accommodate a large number of
components, as well as more complicated/sophisticated arrangements
and configurations. Accordingly, the examples provided should not
limit the scope or inhibit the broad teachings of energy management
system 10, as potentially applied to a myriad of other
architectures.
[0063] It is also important to note that the steps in the preceding
FIGURES illustrate only some of the possible scenarios that may be
executed by, or within, energy management system 10. Some of these
steps may be deleted or removed where appropriate, or these steps
may be modified or changed considerably without departing from the
scope of the present disclosure. In addition, a number of these
operations have been described as being executed concurrently with,
or in parallel to, one or more additional operations. However, the
timing of these operations may be altered considerably. The
preceding operational flows have been offered for purposes of
example and discussion. Substantial flexibility is provided by
energy management system 10 in that any suitable arrangements,
chronologies, configurations, and timing mechanisms may be provided
without departing from the teachings of the present disclosure.
[0064] Although the present disclosure has been described in detail
with reference to particular arrangements and configurations, these
example configurations and arrangements may be changed
significantly without departing from the scope of the present
disclosure. For example, although the present disclosure has been
described with reference to particular communication exchanges
involving certain protocols (e.g., UDP, SSL, SNMP, etc.), energy
management system 10 may be applicable to other exchanges and
protocols in which data are exchanged in order to provide energy
management operations. In addition, although energy management
system 10 has been illustrated with reference to particular
elements and operations that facilitate the communication process,
these elements and operations may be replaced by any suitable
architecture or process that achieves the intended functionality of
energy management system 10.
[0065] Numerous other changes, substitutions, variations,
alterations, and modifications may be ascertained to one skilled in
the art and it is intended that the present disclosure encompass
all such changes, substitutions, variations, alterations, and
modifications as falling within the scope of the appended claims.
In order to assist the United States Patent and Trademark Office
(USPTO) and, additionally, any readers of any patent issued on this
application in interpreting the claims appended hereto, Applicant
wishes to note that the Applicant: (a) does not intend any of the
appended claims to invoke paragraph six (6) of 35 U.S.C. section
112 as it exists on the date of the filing hereof unless the words
"means for" or "step for" are specifically used in the particular
claims; and (b) does not intend, by any statement in the
specification, to limit this disclosure in any way that is not
otherwise reflected in the appended claims.
* * * * *