idnits 2.17.00 (12 Aug 2021) /tmp/idnits58779/draft-ychoi-eman-energy-efficient-management-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (April 28, 2014) is 2945 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'TBD' is mentioned on line 496, but not defined == Unused Reference: 'RFC6762' is defined on line 506, but no explicit reference was found in the text == Unused Reference: 'RFC6763' is defined on line 509, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Y. Choi 3 Internet-Draft S. Jeong 4 Intended status: Informational ETRI 5 Expires: October 30, 2014 April 28, 2014 7 Energy-efficient Management Framework 8 draft-ychoi-eman-energy-efficient-management-01.txt 10 Abstract 12 Wireless network devices which have limited resources (e.g., power 13 supply, memory, computing capabilities, and so on) should consider 14 energy-efficient management. However, the existing network 15 architectures for the network devices have some problems on energy 16 management about device failures and errors. To improve the energy 17 management problem, this document proposes energy-efficient 18 management framework for the network devices. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on October 30, 2014. 37 Copyright Notice 39 Copyright (c) 2014 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 56 3. Overview of Energy-efficient Management Framework . . . . . . 3 57 4. Requirements and Considerations of Energy Management 58 Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 4.1. Scenarios for Energy Consumption Analysis . . . . . . . . 4 60 4.2. Requirements and Considerations . . . . . . . . . . . . . 6 61 4.2.1. Separation of Control Plane and Data Plane . . . . . 6 62 4.2.2. Centralized Control Support . . . . . . . . . . . . . 6 63 4.2.3. Versatile and Programmable . . . . . . . . . . . . . 7 64 4.2.4. Remote Monitoring and Managements . . . . . . . . . . 7 65 4.2.5. Channel Support to Control Network Devices . . . . . 7 66 5. Reference Architecture of Energy-efficient Management 67 Framework for Constrained Network Devices . . . . . . . . . . 7 68 5.1. Reference Architecture . . . . . . . . . . . . . . . . . 7 69 5.2. Functionalities . . . . . . . . . . . . . . . . . . . . . 8 70 5.2.1. Control Plane . . . . . . . . . . . . . . . . . . . . 8 71 5.2.2. Data Plane . . . . . . . . . . . . . . . . . . . . . 9 72 6. Procedures of Energy-efficient Management Framework . . . . . 9 73 6.1. Initialization Processing . . . . . . . . . . . . . . . . 9 74 6.2. On-demand Processing . . . . . . . . . . . . . . . . . . 10 75 6.3. Event-driven Processing . . . . . . . . . . . . . . . . . 11 76 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 77 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 78 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 79 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 80 9.2. Informative References . . . . . . . . . . . . . . . . . 12 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 83 1. Introduction 85 Energy efficiency is one of the important issues for wireless 86 constrained network devices, which have limited resources as low-cost 87 and low-power devices, such as power supply, memory, computing 88 capability, and so on. Therefore, this document specifies motivation 89 and functional architecture of energy efficient management for such 90 light weight low-cost network devices so that the network devices can 91 reduce energy consumption. Then, it describe specification for 92 network device control as follows: 94 o Motivation for energy efficient management of network devices; 95 o Functional architecture and requirements of energy efficient 96 management; 98 o Operational procedures and messages for device delegation control 99 protocol. 101 2. Conventions and Terminology 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 105 document are to be interpreted as described in [RFC2119]. 107 3. Overview of Energy-efficient Management Framework 109 Wireless network devices which have limited resources (e.g., power 110 supply, memory, computing capabilities, and so on) should consider 111 energy-efficient management as one of the important functions when 112 they are designed for applications. However, the existing network 113 architectures for resource-constrained network devices have some 114 problems on energy management because they typically have 115 architectures to support both control plane and data plane. For 116 example, one of the network devices which gets in troubles on power 117 supply, gives negative effects on energy waste of the other network 118 devices to recover the errors. As the worst case, network overhead, 119 such as message broadcasting, could be required. 121 To improve such a problem, roles of network devices should be 122 minimized for data obtaining and forwarding, and control plane, such 123 as topology control and routing control, should be taken by the other 124 entity, which do not have resource-constraint. Therefore, this 125 document describes requirements and considerations for energy- 126 efficient management framework based on general application scenarios 127 of the existing network architectures. Then reference architectures 128 for separation of control plane and data plane is stated, and also 129 procedures for network initializing, on-demand, and event-driven 130 process are specified. 132 4. Requirements and Considerations of Energy Management Framework 134 This section provides a scenario to show an example of energy 135 consumption in wireless low-power network devices which have light- 136 weight and low-cost properties, then requirements and considerations 137 to reduce energy consumption are analysed based on the scenario. 139 4.1. Scenarios for Energy Consumption Analysis 141 There are two applications, such as target-tracking services and 142 temperature reporting services, provided. In the network, there are 143 two kinds of devices. One is to obtain temperature data, the other 144 is for target-tracking. 146 User Gateway Network Devices 147 | | | 148 | Request temperature info. | | 149 |----------------------------->| Send msgs to discover devices| 150 | |----------------------------->| 151 | | Report info. of devices | 152 | |<-----------------------------| 153 | | | 154 | | Deliver tasks | 155 | |----------------------------->| 156 | | | 157 | | Obtain temperature data 158 | | | 159 | | Relay the temperature 160 | | data to gateway 161 | | | 162 | | Report the obtiaining data | 163 | |<-----------------------------| 164 | | | 165 | Data Processing for User | 166 | | | 167 | Reply tempertature info. | | 168 |<-----------------------------| | 169 | | | 170 | Request modification for | | 171 | temperature service | | 172 |----------------------------->| | 173 | Modify the temperature service | 174 | | Send msg to modified tasks | 175 | |----------------------------->| 176 | | | 178 Figure 1: Scenario of an application for temperature reporting 179 services 181 In Figure 1, a user wants to know current temperature of the network 182 field, so the user requests temperature information to a gateway. 183 The gateway should recognize which one of the deployed devices can be 184 available in the field. The gateway starts message broadcasting to 185 discover devices available, and the available devices reply to the 186 gateway by hop-by-hop networking. If the number of the available 187 devices is satisfied for providing temperature information, the 188 gateway delivers a task to gather temperature data to the available 189 devices. The task is broadcasted to all of the devices. Whenever 190 the devices obtain temperature data, the data is delivered to the 191 gateway through hop-by-hop networking. When all of the temperature 192 data obtained are collected to gateway, the data is processed to 193 temperature information and provided to the user. 195 User Gateway Network Devices Target 196 | Req. | | | 197 | target-tracking | Send messages to | | 198 |----------------->| discover devices | | 199 | |------------------->| | 200 | | Report device info.| | 201 | |<-------------------| | 202 | | | | 203 | | Deliver tasks | Sensing the target | 204 | |------------------->| and obtaining data | 205 | | |<------------------>| 206 | | | | 207 | | Report obtained | | 208 | | data | Sensing the target | 209 | |<-------------------| and obtaining data | 210 | Data Processing for User |<------------------>| 211 | | | | 212 | Rep. target info.| Report obtained | | 213 |<-----------------| data | | 214 | |<-------------------| | 215 | | | | 216 | Data Processing for User | | 217 | | | | 218 | Rep. target info.| | | 219 |<-----------------| | | 220 | | | | 222 Figure 2: Scenario of an application for target-tracking services 224 Figure 2 shows another scenario, which is for target-tracking. A 225 user wants to know current location information of a target in the 226 network field, so the user requests target location information to a 227 gateway. The gateway should recognize which one of the deployed 228 devices can be available in the field. The gateway starts message 229 broadcasting to discover devices available, and the available devices 230 reply to the gateway by hop-by-hop networking. If the number of the 231 available devices is satisfied for providing temperature information, 232 the gateway delivers a task to gather temperature data to the 233 available devices. The task is broadcasted to all of the devices. 234 Whenever the target moves to another location, the devices obtain 235 location data of the target. Then the data is delivered to the 236 gateway through hop-by-hop networking, and real-time location 237 information of the target is provided to the user. 239 In the two scenarios, the two different application services, such as 240 temperature reporting and target-tracking, are provided in the same 241 network. Some of the devices are involved into the temperature 242 reporting, the others are involved into the target-tracking, but all 243 devices commonly participated in message broadcasting, task 244 broadcasting, and data delivering without regard to the types of 245 application services. 247 4.2. Requirements and Considerations 249 In the two scenarios, lots of possible situations of energy 250 consumption exist while network devices are operated to provide 251 application services. If such a network architecture is redesigned 252 to improve inefficient energy consumption, several requirements and 253 considerations need to be reflected as follows: 255 4.2.1. Separation of Control Plane and Data Plane 257 In the scenarios, there are two kinds of devices; one is for the 258 temperature reporting application, and the other is for target- 259 tracking application. There is no devices for both of them. 260 However, they should participate in message broadcasting, task 261 broadcasting, and obtained data delivering to gateway. Especially, 262 broadcasting messages and tasks is one of the most critical ways to 263 inefficient energy consumption. To minimize the inefficient energy 264 consumption, network devices should mainly participate in data 265 delivering or data forwarding in data plane. Instead, control plane 266 can be operated by the other centralized methodology, such as the 267 gateway. Then such a broadcasting method can be reduced. 269 4.2.2. Centralized Control Support 271 To discover neighbours and routing paths, typically all network 272 devices should involve in processes in control plane. However, if an 273 entity (i.e., a centralized controller) is aware of all the 274 information (e.g., location, remaining energy levels, etc.) of the 275 network devices in a local network, only the entity can computes and 276 create routing paths and links among the network devices. In other 277 words, the network devices can reduce energy consumption. The 278 centralized entity can be a third party or gateway. 280 4.2.3. Versatile and Programmable 282 If a network architecture is conveniently designed to apply for 283 various application services, it gives a positive influence to 284 efficient energy consumption. For example, requirements for service 285 types, such as on-demand reporting, regularly reporting, and event- 286 driven reporting, can be temporally changed in temperature reporting 287 services. Therefore, energy managements need to be differently 288 programed and changed for the service types. 290 4.2.4. Remote Monitoring and Managements 292 To centrally control network devices, remotely monitoring and 293 management are required. 295 4.2.5. Channel Support to Control Network Devices 297 To remotely manage network devices, protocols for control plane is 298 supported between network devices and centralized entity. 300 5. Reference Architecture of Energy-efficient Management Framework for 301 Constrained Network Devices 303 5.1. Reference Architecture 305 As above the requirements and considerations in Section 4.2, energy- 306 efficient management framework is divided into three parts, such as 307 applications, control plane, and data plane. Figure 3 shows a 308 reference architecture of energy-efficient management framework for 309 network devices. Applications are just described as examples so they 310 are out of scope in this document. 312 +- Applications ----------------------------------------------+ 313 | +-----------+ +----------+ +--------------+ +----------+ | 314 | |Temperature| | Humidity | | Air Pollution| | Target- | | 315 | | Reporting | | Reporting| | Monitoring | | tracking | | 316 | +-----------+ +----------+ +--------------+ +----------+ | 317 +-------------------------------------------------------------+ 318 =========================== Open API ========================== 319 +- Control Plane (Control Center) ----------------------------+ 320 | +---------------------------------------------------------+ | 321 | | Application Management | | 322 | +---------------------------------------------------------+ | 323 | +------------+ +------------------------+ +-------------+ | 324 | | Topology | | Node Energy Monitoring | | Network | | 325 | | Management | | and Management | | Operating | | 326 | +------------+ +------------------------+ +-------------+ | 327 +-------------------------------------------------------------+ 328 ================= Open Channel and Protocol =================== 329 +- Data Plane (Network Devices) ------------------------------+ 330 | +-------------------+ +-----------------------------------+ | 331 | | Ctl Plane Support | | Data Plane Support | | 332 | +-------------------+ +-----------------------------------+ | 333 | +-----++-----++-----+ +----++-----++----------++----------+ | 334 | |Mobi-||Loca-||Power| |Sen-||Data ||In-network|| Data | | 335 | |lity ||tion || | |sing||Cache||Processing||Forwarding| | 336 | +-----++-----++-----+ +----++-----++----------++----------+ | 337 +-------------------------------------------------------------+ 339 Figure 3: Reference architecture of energy-efficient management 340 framework for network devices 342 According to the Section 4.2.1, the proposed framework have a 343 separated structure of control plane and data plane. Control plane 344 includes application management, device topology management, 345 networking management, and device energy management. The control 346 plane can be accomplished by gateway or the third party. On the 347 other hand, data plane includes mobility control support, location 348 control support, power control support, and data plane support. The 349 data plane is only accomplished by network devices. 351 5.2. Functionalities 353 5.2.1. Control Plane 355 o Application Management 357 o Topology Management 359 o Node Energy Monitoring and Management 361 5.2.2. Data Plane 363 5.2.2.1. Contol Plane Support 365 o Mobility 367 o Location Management 369 o Power Management 371 5.2.2.2. Data Plane 373 o Sensing 375 o Data Cache 377 o In-network Processing 379 o Data Fowarding 381 6. Procedures of Energy-efficient Management Framework 383 This section describes how to operate the energy-efficient management 384 framework for devices. The energy-efficient management framework 385 have three operations, such as network initialization, on-demand 386 processing, and event-driven processing. 388 6.1. Initialization Processing 390 Figure 4 shows how network initialization procedure is needed when 391 application services are provided based on the energy-efficient 392 management framework. 394 (6) (4) 395 +-------+ (3) +-------+ +------------+ 396 |Network|-------------->|Control| (1) |Applications| 397 |devices|<--------------|center |<--------------| (Users) | 398 +-------+ (2), (5) +-------+ +------------+ 400 Figure 4: Procedure for initialization processing 402 (1) A user requests required application service results to a 403 control server. 405 (2) The control server creates a task and delivers the task message 406 to all network devices. The task message includes what data 407 should be obtained. 409 (3) When the network devices receive the task message, they decide 410 whether to participate in the task or not. If so, they send 411 their information (e.g., ID, location, remaining energy level, 412 etc.) to the control server. 414 (4) After all necessary information of network devices is received 415 to satisfy the task, the control server creates networking 416 information, such as routing paths, links, and so on, by 417 analyzing all the information of involving network devices. 419 (5) The networking information is delivered to the involving network 420 devices. 422 (6) The network devices does self-configuration for data gathering 423 and forwarding. 425 6.2. On-demand Processing 427 On-demand processing means a process to modify on-going application 428 services according to demands on users as shown in Figure 5. 430 (4) (2) 431 +-------+ +-------+ +------------+ 432 |Network| (3) |Control| (1) |Applications| 433 |devices|<--------------|center |<--------------| (Users) | 434 +-------+ +-------+ +------------+ 436 Figure 5: Procedure for on-demand processing 438 (1) A user requested for modification of the requested application 439 service to a control server. 441 (2) The control server evaluates which devices is related with the 442 previously collected information of network devices, and the 443 control server modifies the on-going task policy. 445 (3) A task modification message is delivered to only related network 446 devices. 448 (4) When the network devices receive the task modification message, 449 they does self-configuration again for data gathering and 450 forwarding based on the modified task. 452 (5) The network devices does self-configuration for data gathering 453 and forwarding. 455 6.3. Event-driven Processing 457 If a network device, which is involved in the on-going task, runs out 458 of battery, the network device cannot participate in the task any 459 more. Likewise, event-driven processing means a process to modify 460 on-going application services according to network situation changes, 461 such as node failures and errors, as shown in Figure 6. 463 (1),(5) (3) 464 +-------+ (2) +-------+ 465 |Network|------------------------>|Control| 466 |devices|<------------------------|center | 467 +-------+ (4) +-------+ 469 Figure 6: Procedure for event-driven processing 471 (1) When energy level of a network device goes to lower limit or 472 moves to another place, the network device is aware of network 473 situation changes. 475 (2) The network device sends a modification request message to the 476 control server. 478 (3) When the control server receives the message, it evaluates which 479 other devices can be instead of the failed device with the 480 previously collected information of network devices, and the 481 control server modifies the on-going task policy. 483 (4) A task modification message is delivered to only related network 484 devices. 486 (5) When the network devices receive the task modification message, 487 they does self-configuration again for data gathering and 488 forwarding based on the modified task. 490 7. Security Considerations 492 [TBD] 494 8. IANA Considerations 496 [TBD] 498 9. References 499 9.1. Normative References 501 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 502 Requirement Levels", BCP 14, RFC 2119, March 1997. 504 9.2. Informative References 506 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 507 February 2013. 509 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 510 Discovery", RFC 6763, February 2013. 512 Authors' Addresses 514 Younghwan Choi 515 ETRI 516 218 Gajeongno, Yuseong 517 Daejeon 305-700 518 Korea 520 Phone: +82 42 860 1429 521 Email: yhc@etri.re.kr 523 Sangjin Jeong 524 ETRI 525 218 Gajeongno, Yuseong 526 Daejeon 305-700 527 Korea 529 Phone: +82 42 860 1877 530 Email: sjjeong@etri.re.kr