Network Working Group Y. Choi Internet-Draft S. Jeong Intended status: Informational ETRI Expires: October 30, 2014 April 28, 2014 Energy-efficient Management Framework draft-ychoi-eman-energy-efficient-management-01.txt Abstract Wireless network devices which have limited resources (e.g., power supply, memory, computing capabilities, and so on) should consider energy-efficient management. However, the existing network architectures for the network devices have some problems on energy management about device failures and errors. To improve the energy management problem, this document proposes energy-efficient management framework for the network devices. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on October 30, 2014. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of Choi & Jeong Expires October 30, 2014 [Page 1] Internet-Draft EEMF April 2014 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 3. Overview of Energy-efficient Management Framework . . . . . . 3 4. Requirements and Considerations of Energy Management Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4.1. Scenarios for Energy Consumption Analysis . . . . . . . . 4 4.2. Requirements and Considerations . . . . . . . . . . . . . 6 4.2.1. Separation of Control Plane and Data Plane . . . . . 6 4.2.2. Centralized Control Support . . . . . . . . . . . . . 6 4.2.3. Versatile and Programmable . . . . . . . . . . . . . 7 4.2.4. Remote Monitoring and Managements . . . . . . . . . . 7 4.2.5. Channel Support to Control Network Devices . . . . . 7 5. Reference Architecture of Energy-efficient Management Framework for Constrained Network Devices . . . . . . . . . . 7 5.1. Reference Architecture . . . . . . . . . . . . . . . . . 7 5.2. Functionalities . . . . . . . . . . . . . . . . . . . . . 8 5.2.1. Control Plane . . . . . . . . . . . . . . . . . . . . 8 5.2.2. Data Plane . . . . . . . . . . . . . . . . . . . . . 9 6. Procedures of Energy-efficient Management Framework . . . . . 9 6.1. Initialization Processing . . . . . . . . . . . . . . . . 9 6.2. On-demand Processing . . . . . . . . . . . . . . . . . . 10 6.3. Event-driven Processing . . . . . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 9.2. Informative References . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction Energy efficiency is one of the important issues for wireless constrained network devices, which have limited resources as low-cost and low-power devices, such as power supply, memory, computing capability, and so on. Therefore, this document specifies motivation and functional architecture of energy efficient management for such light weight low-cost network devices so that the network devices can reduce energy consumption. Then, it describe specification for network device control as follows: o Motivation for energy efficient management of network devices; Choi & Jeong Expires October 30, 2014 [Page 2] Internet-Draft EEMF April 2014 o Functional architecture and requirements of energy efficient management; o Operational procedures and messages for device delegation control protocol. 2. Conventions and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. Overview of Energy-efficient Management Framework Wireless network devices which have limited resources (e.g., power supply, memory, computing capabilities, and so on) should consider energy-efficient management as one of the important functions when they are designed for applications. However, the existing network architectures for resource-constrained network devices have some problems on energy management because they typically have architectures to support both control plane and data plane. For example, one of the network devices which gets in troubles on power supply, gives negative effects on energy waste of the other network devices to recover the errors. As the worst case, network overhead, such as message broadcasting, could be required. To improve such a problem, roles of network devices should be minimized for data obtaining and forwarding, and control plane, such as topology control and routing control, should be taken by the other entity, which do not have resource-constraint. Therefore, this document describes requirements and considerations for energy- efficient management framework based on general application scenarios of the existing network architectures. Then reference architectures for separation of control plane and data plane is stated, and also procedures for network initializing, on-demand, and event-driven process are specified. 4. Requirements and Considerations of Energy Management Framework This section provides a scenario to show an example of energy consumption in wireless low-power network devices which have light- weight and low-cost properties, then requirements and considerations to reduce energy consumption are analysed based on the scenario. Choi & Jeong Expires October 30, 2014 [Page 3] Internet-Draft EEMF April 2014 4.1. Scenarios for Energy Consumption Analysis There are two applications, such as target-tracking services and temperature reporting services, provided. In the network, there are two kinds of devices. One is to obtain temperature data, the other is for target-tracking. User Gateway Network Devices | | | | Request temperature info. | | |----------------------------->| Send msgs to discover devices| | |----------------------------->| | | Report info. of devices | | |<-----------------------------| | | | | | Deliver tasks | | |----------------------------->| | | | | | Obtain temperature data | | | | | Relay the temperature | | data to gateway | | | | | Report the obtiaining data | | |<-----------------------------| | | | | Data Processing for User | | | | | Reply tempertature info. | | |<-----------------------------| | | | | | Request modification for | | | temperature service | | |----------------------------->| | | Modify the temperature service | | | Send msg to modified tasks | | |----------------------------->| | | | Figure 1: Scenario of an application for temperature reporting services In Figure 1, a user wants to know current temperature of the network field, so the user requests temperature information to a gateway. The gateway should recognize which one of the deployed devices can be available in the field. The gateway starts message broadcasting to discover devices available, and the available devices reply to the gateway by hop-by-hop networking. If the number of the available Choi & Jeong Expires October 30, 2014 [Page 4] Internet-Draft EEMF April 2014 devices is satisfied for providing temperature information, the gateway delivers a task to gather temperature data to the available devices. The task is broadcasted to all of the devices. Whenever the devices obtain temperature data, the data is delivered to the gateway through hop-by-hop networking. When all of the temperature data obtained are collected to gateway, the data is processed to temperature information and provided to the user. User Gateway Network Devices Target | Req. | | | | target-tracking | Send messages to | | |----------------->| discover devices | | | |------------------->| | | | Report device info.| | | |<-------------------| | | | | | | | Deliver tasks | Sensing the target | | |------------------->| and obtaining data | | | |<------------------>| | | | | | | Report obtained | | | | data | Sensing the target | | |<-------------------| and obtaining data | | Data Processing for User |<------------------>| | | | | | Rep. target info.| Report obtained | | |<-----------------| data | | | |<-------------------| | | | | | | Data Processing for User | | | | | | | Rep. target info.| | | |<-----------------| | | | | | | Figure 2: Scenario of an application for target-tracking services Figure 2 shows another scenario, which is for target-tracking. A user wants to know current location information of a target in the network field, so the user requests target location information to a gateway. The gateway should recognize which one of the deployed devices can be available in the field. The gateway starts message broadcasting to discover devices available, and the available devices reply to the gateway by hop-by-hop networking. If the number of the available devices is satisfied for providing temperature information, the gateway delivers a task to gather temperature data to the available devices. The task is broadcasted to all of the devices. Whenever the target moves to another location, the devices obtain Choi & Jeong Expires October 30, 2014 [Page 5] Internet-Draft EEMF April 2014 location data of the target. Then the data is delivered to the gateway through hop-by-hop networking, and real-time location information of the target is provided to the user. In the two scenarios, the two different application services, such as temperature reporting and target-tracking, are provided in the same network. Some of the devices are involved into the temperature reporting, the others are involved into the target-tracking, but all devices commonly participated in message broadcasting, task broadcasting, and data delivering without regard to the types of application services. 4.2. Requirements and Considerations In the two scenarios, lots of possible situations of energy consumption exist while network devices are operated to provide application services. If such a network architecture is redesigned to improve inefficient energy consumption, several requirements and considerations need to be reflected as follows: 4.2.1. Separation of Control Plane and Data Plane In the scenarios, there are two kinds of devices; one is for the temperature reporting application, and the other is for target- tracking application. There is no devices for both of them. However, they should participate in message broadcasting, task broadcasting, and obtained data delivering to gateway. Especially, broadcasting messages and tasks is one of the most critical ways to inefficient energy consumption. To minimize the inefficient energy consumption, network devices should mainly participate in data delivering or data forwarding in data plane. Instead, control plane can be operated by the other centralized methodology, such as the gateway. Then such a broadcasting method can be reduced. 4.2.2. Centralized Control Support To discover neighbours and routing paths, typically all network devices should involve in processes in control plane. However, if an entity (i.e., a centralized controller) is aware of all the information (e.g., location, remaining energy levels, etc.) of the network devices in a local network, only the entity can computes and create routing paths and links among the network devices. In other words, the network devices can reduce energy consumption. The centralized entity can be a third party or gateway. Choi & Jeong Expires October 30, 2014 [Page 6] Internet-Draft EEMF April 2014 4.2.3. Versatile and Programmable If a network architecture is conveniently designed to apply for various application services, it gives a positive influence to efficient energy consumption. For example, requirements for service types, such as on-demand reporting, regularly reporting, and event- driven reporting, can be temporally changed in temperature reporting services. Therefore, energy managements need to be differently programed and changed for the service types. 4.2.4. Remote Monitoring and Managements To centrally control network devices, remotely monitoring and management are required. 4.2.5. Channel Support to Control Network Devices To remotely manage network devices, protocols for control plane is supported between network devices and centralized entity. 5. Reference Architecture of Energy-efficient Management Framework for Constrained Network Devices 5.1. Reference Architecture As above the requirements and considerations in Section 4.2, energy- efficient management framework is divided into three parts, such as applications, control plane, and data plane. Figure 3 shows a reference architecture of energy-efficient management framework for network devices. Applications are just described as examples so they are out of scope in this document. Choi & Jeong Expires October 30, 2014 [Page 7] Internet-Draft EEMF April 2014 +- Applications ----------------------------------------------+ | +-----------+ +----------+ +--------------+ +----------+ | | |Temperature| | Humidity | | Air Pollution| | Target- | | | | Reporting | | Reporting| | Monitoring | | tracking | | | +-----------+ +----------+ +--------------+ +----------+ | +-------------------------------------------------------------+ =========================== Open API ========================== +- Control Plane (Control Center) ----------------------------+ | +---------------------------------------------------------+ | | | Application Management | | | +---------------------------------------------------------+ | | +------------+ +------------------------+ +-------------+ | | | Topology | | Node Energy Monitoring | | Network | | | | Management | | and Management | | Operating | | | +------------+ +------------------------+ +-------------+ | +-------------------------------------------------------------+ ================= Open Channel and Protocol =================== +- Data Plane (Network Devices) ------------------------------+ | +-------------------+ +-----------------------------------+ | | | Ctl Plane Support | | Data Plane Support | | | +-------------------+ +-----------------------------------+ | | +-----++-----++-----+ +----++-----++----------++----------+ | | |Mobi-||Loca-||Power| |Sen-||Data ||In-network|| Data | | | |lity ||tion || | |sing||Cache||Processing||Forwarding| | | +-----++-----++-----+ +----++-----++----------++----------+ | +-------------------------------------------------------------+ Figure 3: Reference architecture of energy-efficient management framework for network devices According to the Section 4.2.1, the proposed framework have a separated structure of control plane and data plane. Control plane includes application management, device topology management, networking management, and device energy management. The control plane can be accomplished by gateway or the third party. On the other hand, data plane includes mobility control support, location control support, power control support, and data plane support. The data plane is only accomplished by network devices. 5.2. Functionalities 5.2.1. Control Plane o Application Management o Topology Management o Node Energy Monitoring and Management Choi & Jeong Expires October 30, 2014 [Page 8] Internet-Draft EEMF April 2014 5.2.2. Data Plane 5.2.2.1. Contol Plane Support o Mobility o Location Management o Power Management 5.2.2.2. Data Plane o Sensing o Data Cache o In-network Processing o Data Fowarding 6. Procedures of Energy-efficient Management Framework This section describes how to operate the energy-efficient management framework for devices. The energy-efficient management framework have three operations, such as network initialization, on-demand processing, and event-driven processing. 6.1. Initialization Processing Figure 4 shows how network initialization procedure is needed when application services are provided based on the energy-efficient management framework. (6) (4) +-------+ (3) +-------+ +------------+ |Network|-------------->|Control| (1) |Applications| |devices|<--------------|center |<--------------| (Users) | +-------+ (2), (5) +-------+ +------------+ Figure 4: Procedure for initialization processing (1) A user requests required application service results to a control server. (2) The control server creates a task and delivers the task message to all network devices. The task message includes what data should be obtained. Choi & Jeong Expires October 30, 2014 [Page 9] Internet-Draft EEMF April 2014 (3) When the network devices receive the task message, they decide whether to participate in the task or not. If so, they send their information (e.g., ID, location, remaining energy level, etc.) to the control server. (4) After all necessary information of network devices is received to satisfy the task, the control server creates networking information, such as routing paths, links, and so on, by analyzing all the information of involving network devices. (5) The networking information is delivered to the involving network devices. (6) The network devices does self-configuration for data gathering and forwarding. 6.2. On-demand Processing On-demand processing means a process to modify on-going application services according to demands on users as shown in Figure 5. (4) (2) +-------+ +-------+ +------------+ |Network| (3) |Control| (1) |Applications| |devices|<--------------|center |<--------------| (Users) | +-------+ +-------+ +------------+ Figure 5: Procedure for on-demand processing (1) A user requested for modification of the requested application service to a control server. (2) The control server evaluates which devices is related with the previously collected information of network devices, and the control server modifies the on-going task policy. (3) A task modification message is delivered to only related network devices. (4) When the network devices receive the task modification message, they does self-configuration again for data gathering and forwarding based on the modified task. (5) The network devices does self-configuration for data gathering and forwarding. Choi & Jeong Expires October 30, 2014 [Page 10] Internet-Draft EEMF April 2014 6.3. Event-driven Processing If a network device, which is involved in the on-going task, runs out of battery, the network device cannot participate in the task any more. Likewise, event-driven processing means a process to modify on-going application services according to network situation changes, such as node failures and errors, as shown in Figure 6. (1),(5) (3) +-------+ (2) +-------+ |Network|------------------------>|Control| |devices|<------------------------|center | +-------+ (4) +-------+ Figure 6: Procedure for event-driven processing (1) When energy level of a network device goes to lower limit or moves to another place, the network device is aware of network situation changes. (2) The network device sends a modification request message to the control server. (3) When the control server receives the message, it evaluates which other devices can be instead of the failed device with the previously collected information of network devices, and the control server modifies the on-going task policy. (4) A task modification message is delivered to only related network devices. (5) When the network devices receive the task modification message, they does self-configuration again for data gathering and forwarding based on the modified task. 7. Security Considerations [TBD] 8. IANA Considerations [TBD] 9. References Choi & Jeong Expires October 30, 2014 [Page 11] Internet-Draft EEMF April 2014 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 9.2. Informative References [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, February 2013. [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, February 2013. Authors' Addresses Younghwan Choi ETRI 218 Gajeongno, Yuseong Daejeon 305-700 Korea Phone: +82 42 860 1429 Email: yhc@etri.re.kr Sangjin Jeong ETRI 218 Gajeongno, Yuseong Daejeon 305-700 Korea Phone: +82 42 860 1877 Email: sjjeong@etri.re.kr Choi & Jeong Expires October 30, 2014 [Page 12]