idnits 2.17.1 draft-ietf-lwig-energy-efficient-00.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 has text resembling RFC 2119 boilerplate text. -- The document date (March 21, 2014) is 3686 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'Announcementlayer' is defined on line 542, but no explicit reference was found in the text == Outdated reference: A later version (-30) exists of draft-ietf-6tisch-architecture-01 == Outdated reference: A later version (-21) exists of draft-ietf-6tisch-minimal-00 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Z. Cao 3 Internet-Draft China Mobile 4 Intended status: Informational C. Gomez 5 Expires: September 22, 2014 Universitat Politecnica de Catalunya/i2CAT 6 M. Kovatsch 7 ETH Zurich 8 H. Tian 9 China Academy of Telecommunication Research 10 X. He 11 Hitachi China R&D Corporation 12 March 21, 2014 14 Energy Efficient Implementation of IETF Constrained Protocol Suite 15 draft-ietf-lwig-energy-efficient-00 17 Abstract 19 This document summarizes the problems and current practices of energy 20 efficient protocol implementation on constrained devices, mostly 21 about how to make the protocols within IETF scope behave energy 22 friendly. This document also summarizes the impact of link layer 23 protocol power saving behaviors to the upper layer protocols, so that 24 they can coordinately make the system energy efficient. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on September 22, 2014. 43 Copyright Notice 45 Copyright (c) 2014 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 1.1. Conventions used in this document . . . . . . . . . . . . 3 62 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3. MAC and Radio Duty Cycling . . . . . . . . . . . . . . . . . 5 65 3.1. Power Save Services Provided by IEEE 802.11v . . . . . . 6 66 3.2. Power Save Services Provided by Bluetooth Low Energy . . 6 67 3.3. Power Save Services in IEEE 802.15.4 . . . . . . . . . . 7 68 4. IP Adaptation and Transport Layer . . . . . . . . . . . . . . 9 69 5. Routing Protocols . . . . . . . . . . . . . . . . . . . . . . 10 70 6. Application Layer . . . . . . . . . . . . . . . . . . . . . . 10 71 7. Cross Layer Optimization . . . . . . . . . . . . . . . . . . 11 72 8. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 73 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 74 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 75 11. Security Considerations . . . . . . . . . . . . . . . . . . . 12 76 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 77 12.1. Normative References . . . . . . . . . . . . . . . . . . 12 78 12.2. Informative References . . . . . . . . . . . . . . . . . 14 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 81 1. Introduction 83 In many scenarios, the network systems comprises many battery-powered 84 or energy-harvesting devices. For example, in an environmental 85 monitoring system or a temperature and humidity monitoring system in 86 the data center, there are no always-on and handy sustained power 87 supplies for the large number of small devices. In such deployment 88 environments, it is necessary to optimize the energy consumption of 89 the entire system, including computing, application layer behavior, 90 and lower layer communication. 92 Various research efforts have been spent on this "energy efficiency" 93 problem. Most of this research has focused on how to optimize the 94 system's power consumption regarding a certain deployment scenario or 95 how could an existing network function such as routing or security be 96 more energy-efficient. Only few efforts were spent on energy- 97 efficient designs for IETF protocols and standardized network stacks 98 for such constrained devices [I-D.kovatsch-lwig-class1-coap]. 100 The IETF has developed a suite of Internet protocols suitable for 101 such small devices, including 6LoWPAN ( [RFC6282],[RFC6775],[RFC4944] 102 ), RPL[RFC6550], and CoAP[I-D.ietf-core-coap]. This document tries 103 to summarize the design considerations of making the IETF protocol 104 suite as energy-efficient as possible. While this document does not 105 provide detailed and systematic solutions to the energy efficiency 106 problem, it summarizes the design efforts and analyzes the design 107 space of this problem. 109 After reviewing the energy-efficient design of each layer, an overall 110 conclusion is summarized. Though the lower layer communication 111 optimization is the key part of energy efficient design, the protocol 112 design at the network and application layers is also important to 113 make the device battery-friendly. 115 1.1. Conventions used in this document 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in [RFC2119] 121 1.2. Terminology 123 The terminologies used in this document can be referred to 124 [I-D.ietf-lwig-terminology]. 126 2. Overview 128 The IETF has developed multiple protocols to enable end-to-end IP 129 communication between constrained nodes and fully capable nodes. 130 This work has witnessed the evolution of the traditional Internet 131 protocol stack to a light-weight Internet protocol stack. As show in 132 Figure 1 below, the IETF has developed CoAP as the application layer 133 and 6LoWPAN as the adaption layer to run IPv6 over IEEE 802.15.4 and 134 Bluetooth Low-Energy, with the support of routing by RPL and 135 efficient neighbor discovery by 6LoWPAN-ND. 137 +-----+ +-----+ +-----+ +------+ 138 |http | | ftp | |SNMP | | COAP | 139 +-----+ +-----+ +-----+ +------+ 140 \ / / / \ 141 +-----+ +-----+ +-----+ +-----+ 142 | tcp | | udp | | tcp | | udp | 143 +-----+ +-----+ ===> +-----+ +-----+ 144 \ / \ / 145 +-----+ +------+ +-------+ +------+ +-----+ 146 | RTG |--| ipv6 |--|ICMP/ND| | ipv6 |---| rpl | 147 +-----+ +------+ +-------+ +------+ +-----+ 148 | | 149 +-------+ +-------+ +----------+ 150 |MAC/PHY| |6lowpan|--|6lowpan-nd| 151 +-------+ +-------+ +----------+ 152 | 153 +-------+ 154 |MAC/PHY| 155 +-------+ 157 Figure 1: Traditional and Light-weight Internet Protocol Stack 159 There are comprehensive measurements of wireless communication 160 [Powertrace]. Below we list the energy consumption profile of the 161 most common atom operations on a prevalent sensor node platform. The 162 measurement was based on the Tmote Sky with ContikiMAC as the radio 163 duty cycling algorithm. From the measurement, we can see that 164 optimized transmissions and reception consume almost the same amount 165 of energy. For IEEE 802.15.4 and UWB radios, transmitting is 166 actually even cheaper than receiving. Only for broadcast and non- 167 synchronized communication transmissions become costly in terms of 168 energy because they need to flood the medium for a long time. 170 +---------------------------------------+---------------+ 171 | Activity | Energy (uJ) | 172 +---------------------------------------+---------------+ 173 | Broadcast reception | 178 | 174 +---------------------------------------+---------------+ 175 | Unicast reception | 222 | 176 +---------------------------------------+---------------+ 177 | Broadcast transmission | 1790 | 178 +---------------------------------------+---------------+ 179 | Non-synchronized unicast transmission | 1090 | 180 +---------------------------------------+---------------+ 181 | Synchronized unicast transmission | 120 | 182 +---------------------------------------+---------------+ 183 | Unicast TX to awake receiver | 96 | 184 +---------------------------------------+---------------+ 186 Figure 2: Power consumption of atom operations on the Tmote Sky with 187 ContikiMAC 189 3. MAC and Radio Duty Cycling 191 In low-power wireless networks, communication and power consumption 192 are intertwined. The communication device is typically the most 193 power-consuming component, but merely refraining from transmissions 194 is not enough to attain a low power consumption: the radio consumes 195 as much power in listen mode as when actively transmitting, as show 196 in Figure 2 . To reduce power consumption, the radio must be switched 197 completely off -- duty-cycled -- as much as possible. ContikiMAC is 198 a very typical Radio Duty Cycling (RDC) protocol [ContikiMAC]. 200 From the perspective of MAC&RDC, all upper layer protocols, such as 201 routing, RESTful communication, adaptation, and management flows, are 202 all applications. Since the duty cycling algorithm is the key to 203 energy-efficiency of the wireless medium, it synchronizes the TX/RX 204 request from the higher layer. 206 The MAC&RDC are not in the scope of the IETF, yet lower layer 207 designers and chipset manufactures take great care of the problem. 208 For the IETF protocol designers, however, it is good to know the 209 behaviors of lower layers so that the designed protocols can work 210 perfectly with them. 212 Once again, the IETF protocols we are going to talk about in the 213 following sections are the customers of the lower layer. If they 214 want to get better service in a cooperative way, they should be 215 considerate and understand each other. 217 3.1. Power Save Services Provided by IEEE 802.11v 219 IEEE 802.11v [IEEE80211v] defines mechanisms and services for power 220 save of stations/nodes that include flexible multicast service (FMS), 221 proxy ARP advertisement, extended sleep modes, traffic filtering. It 222 would be useful if upper layer protocols knows such capabilities 223 provided by the lower layer, so that they can coordinate with each 224 other. 226 These services include: 228 Proxy ARP: The Proxy ARP capability enables an Access Point (AP) to 229 indicate that the non-AP station (STA) will not receive ARP frames. 230 The Proxy ARP capability enables the non-AP STA to remain in power- 231 save for longer periods of time. 233 Basic Service Set (BSS) Max Idle Period management enables an AP to 234 indicate a time period during which the AP does not disassociate a 235 STA due to non-receipt of frames from the STA. This supports 236 improved STA power saving and AP resource management. 238 FMS: A service in which a non-access point (non-AP) station (STA) can 239 request a multicast delivery interval longer than the delivery 240 traffic indication message (DTIM) interval for the purposes of 241 lengthening the period of time a STA may be in a power save state. 243 Traffic Filtering Service (TFS): A service provided by an access 244 point (AP) to a non-AP station (STA) that can reduce the number of 245 frames sent to the non-AP STA by not forwarding individually 246 addressed frames addressed to the non-AP STA that do not match 247 traffic filters specified by the non-AP STA. 249 Using the above services provided by the lower layer, the constrained 250 nodes can achieve either client initiated power save (via TFS) or 251 network assisted power save (Proxy-ARP, BSS Max Idel Period and FMS). 253 Upper layer protocols would better synchronize with the parameters 254 such as FMS interval and BSS MAX Idle Period, so that the wireless 255 transmissions are not triggered periodically. 257 3.2. Power Save Services Provided by Bluetooth Low Energy 259 Bluetooth Low Energy (BT-LE) is a wireless low-power communications 260 technology that is the hallmark component of the Bluetooth 4.0 261 specification. BT-LE has been designed for the goal of ultra-low- 262 power consumption. Currently, it is possible to run IPv6 over BT-LE 263 networks by using a 6LoWPAN variant adapted to BT-LE 264 [I-D.ietf-6lowpan-btle]. 266 BT-LE networks comprise a master and one or more slaves which are 267 connected to the master. The BT-LE master is assumed to be a 268 relatively powerful device, whereas a slave is typically a 269 constrained device (e.g. a class 1 device). 271 Medium access in BT-LE is based on a TDMA scheme which is coordinated 272 by the master. This device determines the start of connection 273 events, in which communication between the master and a slave takes 274 place. At the beginning of a connection event, the master sends a 275 poll message, which may encapsulate data, to the slave. The latter 276 must send a response, which may also contain data. The master and 277 the slave may continue exchanging data until the end of the 278 connection event. The next opportunity for communication between the 279 master and the slave will be in the next connection event scheduled 280 for the slave. 282 The time between consecutive connection events is defined by the 283 connInterval parameter, which may range between 7.5 ms and 4 s. The 284 slave may remain in sleep mode since the end of its last connection 285 event until the beginning of its next connection event. Therefore, 286 BT-LE is duty-cycled by nature. Furthermore, after having replied to 287 the master, a slave is not required to listen to the master (and thus 288 may keep the radio in sleep mode) for connSlaveLatency consecutive 289 connection events. connSlaveLatency is an integer parameter between 0 290 and 499 which should not cause link inactivity for more than 291 connSupervisionTimeout time. The connSupervisionTimeout parameter is 292 in the range between 100 ms and 32 s. 294 Upper layer protocols should take into account the medium access and 295 duty-cycling behavior of BT-LE. In particular, connInterval, 296 connSlaveLatency and connSupervisionTimeout determine the time 297 between two consecutive connection events for a given slave. The 298 upper layer packet generation pattern and rate should be consistent 299 with the settings of the aforementioned parameters (and vice versa). 301 3.3. Power Save Services in IEEE 802.15.4 303 IEEE 802.15.4 is a family of standard radio interfaces for low-rate, 304 low-power wireless networking. Since the publication of its first 305 version in 2003, IEEE 802.15.4 has become the de-facto choice for a 306 wide range of constrained node network application domains and has 307 been a primary target technology of various IETF working groups such 308 as 6LoWPAN [RFC6282],[RFC6775],[RFC4944] and 6TiSCH 309 [I-D.ietf-6tisch-architecture]. IEEE 802.15.4 specifies PHY and MAC 310 layer functionality. 312 IEEE 802.15.4 defines three roles called device, coordinator and PAN 313 coordinator. The device role is adequate for nodes that do not 314 implement the complete IEEE 802.15.4 functionality, and is mainly 315 targeted for constrained nodes with a limited energy source. The 316 coordinator role includes synchronization capabilities and is 317 suitable for nodes that do not suffer severe constraints (e.g. a 318 mains-powered node). The PAN coordinator is a special type of 319 coordinator that acts as a principal controller in an IEEE 802.15.4 320 network. 322 IEEE 802.15.4 has mainly defined two types of networks depending on 323 their configuration: beacon-enabled and nonbeacon-enabled networks. 324 In the first network type, coordinators periodically transmit 325 beacons. The time between beacons is divided in three main parts: 326 the Contention Access Period (CAP), the Contention Free Period (CFP) 327 and an inactive period. In the first period, nodes use slotted CSMA/ 328 CA for data communication. In the second one, a TDMA scheme controls 329 medium access. During the idle period, communication does not take 330 place, thus the inactive period is a good opportunity for nodes to 331 turn the radio off and save energy. The coordinator announces in 332 each beacon the list of nodes for which data will be sent in the 333 subsequent period. Therefore, devices may remain in sleep mode by 334 default and wake up periodically to listen to the beacons sent by 335 their coordinator. If a device wants to transmit data, or learns 336 from a beacon that it is an intended destination, then it will 337 exchange messages with the coordinator and will thus consume energy. 338 An underlying assumption is that when a message is sent to a 339 coordinator, the radio of the latter will be ready to receive the 340 message. 342 The beacon interval and the duration of the beacon interval active 343 portion (i.e. the CAP and the CFP), and thus the duty cycle, can be 344 configured. The parameters that control these times are called 345 macBeaconOrder and macSuperframeOrder, respectively. As an example, 346 when IEEE 802.15.4 operates in the 2.4 GHz PHY, both times can be 347 (independently) set to values in the range between 15.36 ms and 251.6 348 s. 350 In the beaconless mode, nodes use unslotted CSMA/CA for data 351 transmission. The device may be in sleep mode by default and may 352 activate its radio to either i) request to the coordinator whether 353 there is pending data for the device, or ii) to transmit data to the 354 coordinator. The wake-up pattern of the device, if any, is out of 355 the scope of IEEE 802.15.4. 357 Communication between the two ends of an IEEE 802.15.4 link may also 358 take place in a peer-to-peer configuration, whereby both link ends 359 assume the same role. In this case, data transmission can happen at 360 any moment. Nodes must have their radio in receive mode, and be 361 ready to listen to the medium by default (which for battery-enabled 362 nodes may lead to a quick battery depletion), or apply 363 synchronization techniques. The latter are out of the scope of IEEE 364 802.15.4. 366 The main MAC layer IEEE 802.15.4 amendment to date is IEEE 802.15.4e. 367 This amendment includes various new MAC layer modes, some of which 368 include mechanisms for low energy consumption. Among these, the 369 Time-Slotted Channel Hopping (TSCH) is an outstanding mode which 370 offers robust features for industrial environments, among others. In 371 order to provide the functionality needed to enable IPv6 over TSCH, 372 the 6TiSCH working group has been recently created. TSCH is based on 373 a TDMA schedule whereby a set of time slots are used for frame 374 transmission and reception, and other time slots are unscheduled. 375 The latter time slots may be used by a dynamic scheduling mechanism, 376 otherwise nodes may keep the radio off during the unscheduled time 377 slots, thus saving energy. The minimal schedule configuration 378 specified in [I-D.ietf-6tisch-minimal] comprises 101 time slots, 379 whereby 95 of these time slots are unscheduled and the time slot 380 duration is 15 ms. 382 4. IP Adaptation and Transport Layer 384 6LoWPAN is the adaption layer to run IPv6 over IEEE 802.15.4 MAC&PHY. 385 It was born to fill the gap that the IPv6 layer does not support 386 fragmentation and assembly of <1280-byte packets while IEEE 802.15.4 387 only supports a MTU of 127 bytes. 389 IPv6 is the basis for the higher layer protocols, including both TCP/ 390 UDP transport and applications. So they are quite ignorant of the 391 lower layers, and are almost neutral to the energy-efficiency 392 problem. 394 What the network stack can optimize is to save the computing power. 395 For example the Contiki implementation has multiple cross layer 396 optimizations for buffers and energy management, e.g., the computing 397 and validation of UDP/TCP checksums without the need of reading IP 398 headers from a different layer. These optimizations are software 399 implementation techniques, and out of the scope of IETF and the LWIG 400 working group. 402 The 6LoWPAN contributes to the energy-efficiency problem in two ways. 403 First of all, it swaps computing with communication. 6LoWPAN applies 404 compression of the IPv6 header. This means less amount of data will 405 be handled by the lower layer, but both the sender and receiver 406 should spend more computing power on the compression and 407 decompression of the packets over the air. Secondly, the 6LoWPAN 408 working group developed the energy-efficient Neighbor Discovery 409 called 6LoWPAN-ND, which is an energy efficient replacement of the 410 IPv6 ND in constrained environments. IPv6 Neighbor Discovery was not 411 designed for non-transitive wireless links, as its heavy use of 412 multicast makes it inefficient and sometimes impractical in a low- 413 power and lossy network. 6LoWPAN-ND describes simple optimizations to 414 IPv6 Neighbor Discovery, its addressing mechanisms, and duplicate 415 address detection for Low-power Wireless Personal Area Networks and 416 similar networks. However, 6LoWPAN ND does not modify Neighbor 417 Unreachability Detection (NUD) timeouts, which are very short (by 418 default three transmissions spaced one second apart). NUD timeout 419 settings should be tuned taking into account the latency that may be 420 introduced by duty-cycled mechanisms at the link layer, or 421 alternative, less impatient NUD algorithms should be considered 422 [I-D.ietf-6man-impatient-nud]. 424 5. Routing Protocols 426 The routing protocol designed by the IETF for constrained 427 environments is called RPL [RFC6550]. As a routing protocol, RPL has 428 to exchange messages periodically and keep routing states for each 429 destination. RPL is optimized for the many-to-one communication 430 pattern, where network nodes primarily send data towards the border 431 router, but has provisions for any-to-any routing as well. 433 The authors of the Powertrace tool [Powertrace] studied the power 434 profile of RPL. It divides the routing protocol into control and 435 data traffic. The control channel uses ICMP messages to establish 436 and maintain the routing states. The data channel is any application 437 that uses RPL for routing packets. The study has shown that the 438 power consumption of the control traffic goes down over time and data 439 traffic stays relatively constant. The study also reflects that the 440 routing protocol should keep the control traffic as low as possible 441 to make it energy-friendly. The amount of RPL control traffic can be 442 tuned by setting the Trickle algorithm parameters (i.e. Imin, Imax 443 and k) to adequate values. However, there exists a trade-off between 444 energy consumption and other performance parameters such as network 445 convergence time and robustness. 447 Todo: more discussion of energy efficient routing. 449 6. Application Layer 451 CoAP [I-D.ietf-core-coap]was designed as a RESTful application 452 protocol, connecting the services of smart devices to the World Wide 453 Web. CoAP is not a chatty protocol, it provides basic communication 454 services such as service discovery and GET/POST/PUT/DELETE methods 455 with a binary header. 457 The energy-efficient design is implicitly included in the CoAP 458 protocol design. To reduce regular and frequent queries of the 459 resources, CoAP provides an observe mode, in which the requester 460 registers its interest of a certain resource and the responder will 461 report the value whenever it was updated. This reduces the request 462 response roundtrip while keeping information exchange a ubiquitous 463 service. 465 CoAP offers mechanisms for reliable communication between two CoAP 466 endpoints. A CoAP message may be signaled as a confirmable (CON) 467 message, and an acknowledgment (ACK) is issued by the receiver if the 468 CON message is correctly received. The sender starts a 469 Retransmission TimeOut (RTO) for every CON message sent. The initial 470 RTO value is chosen randomly between 2 and 3 s. If an RTO expires, 471 the new RTO value is doubled (unless a limit on the number of 472 retransmissions has been reached). Since duty-cycling at the link 473 layer may lead to long latency (i.e. even greater than the initial 474 RTO value), CoAP RTO parameters should be tuned accordingly in order 475 to avoid spurious RTOs which would unnecessarily waste node energy 476 and other resources. 478 7. Cross Layer Optimization 480 The cross layer optimization is a technique used in many 481 scenarios.There are some technologies for power efficient 482 optimization via PHY to Routing cross layer design 483 [Cross-layer-Optimization]. In this research, cross-layer 484 optimization frameworks have been developed to minimize the total 485 power consumption or to maximize the utility-power trade-off using 486 cooperative diversity. 488 Also a cross-layer design in multihop wireless networks is proposed 489 for congestion control, routing and scheduling - in transport, 490 network and link layers into a coherent framework 491 [Cross-layer-design]. This method and thinking could be applied to 492 the implementation of energy effective cross layer design. 494 Todo: more discussion of Cross layer issues. 496 8. Summary 498 We find a summary section necessary although most IETF documents do 499 not contain it. The points we would like to summarize are as 500 follows. 502 a. All Internet protocols, which are in the scope of the IETF, are 503 customers of the lower layers (PHY, MAC, and Duty-cycling). In 504 order to get a better service, the designers of higher layers 505 should know them better. 507 b. The IETF has developed multiple protocols for constrained 508 networked devices. A lot of implicit energy efficient design 509 principles have been used in these protocols. 511 c. The power trace analysis of different protocol operations showed 512 that for radio-duty-cycled networks broadcasts should be avoided. 513 Saving unnecessary states maintenance is also an effective method 514 to be energy-friendly. 516 9. Acknowledgments 518 Carles Gomez has been supported by Ministerio de Economia y 519 Competitividad and FEDER through project TEC2012-32531. 521 Authors would like to thank the review and feedback from a number of 522 experts in this area: Carsten Bormann, Ari Keranen. 524 The text of this document was improved based on IESG Document Editing 525 session during IETF87. Thank Ted Lemon, Joel Jaeggli, and efforts to 526 initiate this facilities. 528 10. IANA Considerations 530 This document has no IANA requests. 532 11. Security Considerations 534 This document discusses the energy efficient protocol design, and 535 does not incur any changes or challenges on security issues besides 536 what the protocol specifications have analyzed. 538 12. References 540 12.1. Normative References 542 [Announcementlayer] 543 Dunkels, A., "The Announcement Layer: Beacon Coordination 544 for the Sensornet Stack. In Proceedings of EWSN 2011", . 546 [ContikiMAC] 547 Dunkels, A., "The ContikiMAC Radio Duty Cycling Protocol, 548 SICS Technical Report T2011:13", December 2011. 550 [Cross-layer-Optimization] 551 Le, and Hossain, "Cross-Layer Optimization Frameworks for 552 Multihop Wireless Networks Using Cooperative Diversity", 553 July 2008. 555 [Cross-layer-design] 556 Chen, , Low, , and Doyle, "Cross-layer design in multihop 557 wireless networks", 2011. 559 [I-D.ietf-6lowpan-btle] 560 Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., 561 Shelby, Z., and C. Gomez, "Transmission of IPv6 Packets 562 over BLUETOOTH Low Energy", draft-ietf-6lowpan-btle-12 563 (work in progress), February 2013. 565 [I-D.ietf-6man-impatient-nud] 566 Nordmark, E. and I. Gashinsky, "Neighbor Unreachability 567 Detection is too impatient", draft-ietf-6man-impatient- 568 nud-07 (work in progress), October 2013. 570 [I-D.ietf-6tisch-architecture] 571 Thubert, P., Watteyne, T., and R. Assimiti, "An 572 Architecture for IPv6 over the TSCH mode of IEEE 573 802.15.4e", draft-ietf-6tisch-architecture-01 (work in 574 progress), February 2014. 576 [I-D.ietf-6tisch-minimal] 577 Vilajosana, X. and K. Pister, "Minimal 6TiSCH 578 Configuration", draft-ietf-6tisch-minimal-00 (work in 579 progress), November 2013. 581 [I-D.ietf-core-coap] 582 Shelby, Z., Hartke, K., and C. Bormann, "Constrained 583 Application Protocol (CoAP)", draft-ietf-core-coap-18 584 (work in progress), June 2013. 586 [I-D.ietf-lwig-terminology] 587 Bormann, C., Ersue, M., and A. Keranen, "Terminology for 588 Constrained Node Networks", draft-ietf-lwig-terminology-07 589 (work in progress), February 2014. 591 [I-D.kovatsch-lwig-class1-coap] 592 Kovatsch, M., "Implementing CoAP for Class 1 Devices", 593 draft-kovatsch-lwig-class1-coap-00 (work in progress), 594 October 2012. 596 [IEEE80211v] 597 IEEE, , "Part 11: Wireless LAN Medium Access Control (MAC) 598 and Physical Layer (PHY) specifications, Amendment 8: IEEE 599 802.11 Wireless Network Management.", February 2012. 601 [Powertrace] 602 Dunkels, , Eriksson, , Finne, , and Tsiftes, "Powertrace: 603 Network-level Power Profiling for Low-power Wireless 604 Networks", March 2011. 606 12.2. Informative References 608 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 609 Requirement Levels", BCP 14, RFC 2119, March 1997. 611 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 612 "Transmission of IPv6 Packets over IEEE 802.15.4 613 Networks", RFC 4944, September 2007. 615 [RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6 616 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 617 September 2011. 619 [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., 620 Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. 621 Alexander, "RPL: IPv6 Routing Protocol for Low-Power and 622 Lossy Networks", RFC 6550, March 2012. 624 [RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann, 625 "Neighbor Discovery Optimization for IPv6 over Low-Power 626 Wireless Personal Area Networks (6LoWPANs)", RFC 6775, 627 November 2012. 629 Authors' Addresses 631 Zhen Cao (Ed.) 632 China Mobile 633 Xuanwumenxi Ave. No.32 634 Beijing 100871 635 P.R.China 637 Email: zehn.cao@gmail.com, caozhen@chinamobile.com 638 Carles Gomez 639 Universitat Politecnica de Catalunya/i2CAT 640 C/Esteve Terradas, 7 641 Castelldefels 08860 642 Spain 644 Email: carlesgo@entel.upc.edu 646 Matthias Kovatsch 647 ETH Zurich 648 Universitaetstrasse 6 649 Zurich, CH-8092 650 Switzerland 652 Email: kovatsch@inf.ethz.ch 654 Hui Tian 655 China Academy of Telecommunication Research 656 Huayuanbeilu No.52 657 Beijing, Haidian District 100191 658 China 660 Email: tianhui@mail.ritt.com.cn 662 Xuan He 663 Hitachi China R&D Corporation 664 301, Tower C North, Raycom, 2 Kexuyuan Nanlu, Haidian District 665 Beijing 100190 666 P.R.China 668 Email: xhe@hitachi.cn