Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-lwig-energy-efficient-08.txt Reviewer: Acee Lindem Review Date: 01/18/17 IETF LC End Date: Finished - Telechat on 01/25/18 Intended Status: Informational Summary: I have some minor concerns about this document that I think should be resolved before publication. Additionally, the document is somewhat hard to read if one is not very familiar with the subject matter. Comments: The document provides an overview of lower-level techniques for reducing power consumption and then discusses how transport, routing, and one application, CoAP can use lower layer awareness to reduce energy consumption. Since the draft surveys so many different lower layer technologies and IETF protocols, its main value may the introduction and references for further understanding. Major Issues: No major issues found. Minor Issues: I have the following minor questions and issues. 1. The document should define early what constitutes a lower layer versus a higher layer. For example, does lower layer always imply physical or link layer? 2. In section 3.1, the section on channel sampling refers to a preamble of given duration. However, packets are measured in bits and bytes as opposed to a time interval. 3. In section 3.3, the first paragraph refers to "such networks" when the statement is in the context of applications. 4. In sections 4 and 5, are any situations where transport and routing tuning parameters are derived directly from cross-layer communications? I guess I was disappointed that I didn't see this. Nits: Section 3 is very hard for a someone who is not familiar with RDC techniques to read. Below are a number of editorial suggestions. Note that I've used the RFC Style for punctuation including the additional of the Oxford comma. ACEE-M-G2HR:Desktop acee$ diff -c draft-ietf-lwig-energy-efficient-08.txt.orig draft-ietf-lwig-energy-efficient-08.txt *** draft-ietf-lwig-energy-efficient-08.txt.orig 2018-01-15 14:04:20.000000000 -0500 --- draft-ietf-lwig-energy-efficient-08.txt 2018-01-18 19:44:31.000000000 -0500 *************** *** 118,131 **** supplies for the potentially large number of constrained devices. In such deployment scenarios, it is necessary to optimize the energy consumption of the constrained devices. In this document we describe ! techniques that are in common use at Layer 2 and at Layer 3, and we indicate the need for higher-layer awareness of lower-layer features. Many research efforts have studied this "energy efficiency" problem. Most of this research has focused on how to optimize the system's power consumption in certain deployment scenarios, or how an existing network function such as routing or security could be more energy- ! efficient. Only few efforts have focused on energy-efficient designs for IETF protocols and standardized network stacks for such constrained devices [I-D.kovatsch-lwig-class1-coap]. --- 118,131 ---- supplies for the potentially large number of constrained devices. In such deployment scenarios, it is necessary to optimize the energy consumption of the constrained devices. In this document we describe ! techniques that are in common use at Layer 2 and Layer 3, and we indicate the need for higher-layer awareness of lower-layer features. Many research efforts have studied this "energy efficiency" problem. Most of this research has focused on how to optimize the system's power consumption in certain deployment scenarios, or how an existing network function such as routing or security could be more energy- ! efficient. Only a few efforts have focused on energy-efficient designs for IETF protocols and standardized network stacks for such constrained devices [I-D.kovatsch-lwig-class1-coap]. *************** *** 144,150 **** layers. Cross-layer interaction is therefore considered in this document from this specific point of view. Providing further design recommendations that go beyond the layered protocol architecture is ! out of the scope of this document. After reviewing the energy-efficient designs of each layer, we summarize the document by presenting some overall conclusions. --- 144,150 ---- layers. Cross-layer interaction is therefore considered in this document from this specific point of view. Providing further design recommendations that go beyond the layered protocol architecture is ! beyond the scope of this document. After reviewing the energy-efficient designs of each layer, we summarize the document by presenting some overall conclusions. *************** *** 300,306 **** the wireless medium, it synchronizes transmission and/or reception requests from the higher layers. ! MAC and RDC are not in the scope of the IETF, yet lower layer designers and chipset manufacturers take great care to save energy. By knowing the behaviors of these lower layers, IETF engineers can design protocols that work well with them. The IETF protocols to be --- 300,306 ---- the wireless medium, it synchronizes transmission and/or reception requests from the higher layers. ! MAC and RDC are not in the scope of the IETF, yet lower-layer designers and chipset manufacturers take great care to save energy. By knowing the behaviors of these lower layers, IETF engineers can design protocols that work well with them. The IETF protocols to be *************** *** 315,328 **** a) Channel sampling. In this solution, the radio interface of a device periodically monitors the channel for very short time ! intervals (i.e. with a low duty cycle) with the aim of detecting incoming transmissions. In order to make sure that a receiver can correctly receive a transmitted data unit, the sender may prepend a preamble of a duration at least the sampling period to the data unit to be sent. Another option for the sender is to repeatedly transmit the data unit, instead of sending a preamble before the data unit. Once a transmission is detected by a receiver, the receiver may stay ! awake until the complete reception of the data unit. Examples of radio technologies that use preamble sampling include ContikiMAC, the Coordinated Sampled Listening (CSL) mode of IEEE 802.15.4e, and the Frequently Listening (FL) mode of ITU-T G.9959 [G9959]. --- 315,328 ---- a) Channel sampling. In this solution, the radio interface of a device periodically monitors the channel for very short time ! intervals (i.e., with a low duty cycle) with the aim of detecting incoming transmissions. In order to make sure that a receiver can correctly receive a transmitted data unit, the sender may prepend a preamble of a duration at least the sampling period to the data unit to be sent. Another option for the sender is to repeatedly transmit the data unit, instead of sending a preamble before the data unit. Once a transmission is detected by a receiver, the receiver may stay ! awake until the reception of the data unit is completed. Examples of radio technologies that use preamble sampling include ContikiMAC, the Coordinated Sampled Listening (CSL) mode of IEEE 802.15.4e, and the Frequently Listening (FL) mode of ITU-T G.9959 [G9959]. *************** *** 345,351 **** example of a radio technology based on this mechanism. c) Listen after send. This technique allows a node to remain in ! sleep mode by default, wake up and poll a sender (which must be ready to receive a poll message) for pending transmissions. After sending the poll message, the node remains in receive mode, ready for a potential incoming transmission. After a certain time interval, the --- 345,351 ---- example of a radio technology based on this mechanism. c) Listen after send. This technique allows a node to remain in ! sleep mode by default, and wake up and poll a sender (which must be ready to receive a poll message) for pending transmissions. After sending the poll message, the node remains in receive mode, ready for a potential incoming transmission. After a certain time interval, the *************** *** 367,373 **** On the other hand, due to the latency increase of duty-cycling, a sender waiting for a transmission opportunity may need to store subsequent outgoing packets in a buffer, increasing memory ! requirements and potentially incurring queuing waiting time that contributes to the packet's overall delay and increases the probability of buffer overflow, leading to losses. --- 367,373 ---- On the other hand, due to the latency increase of duty-cycling, a sender waiting for a transmission opportunity may need to store subsequent outgoing packets in a buffer, increasing memory ! requirements and potentially incurring queue waiting time that contributes to the packet's overall delay and increases the probability of buffer overflow, leading to losses. *************** *** 401,407 **** requirements. On the other hand, upper layers should take into account the expected latency and/or throughput behavior due to RDC. The next subsection provides details on key parameters controlling ! RDC mechanisms, and thus fundamental trade-offs, for various examples of relevant low-power radio technologies. 3.5. Packet bundling --- 401,407 ---- requirements. On the other hand, upper layers should take into account the expected latency and/or throughput behavior due to RDC. The next subsection provides details on key parameters controlling ! RDC mechanisms, and thus, fundamental trade-offs for various examples of relevant low-power radio technologies. 3.5. Packet bundling *************** *** 409,415 **** Another technique that may be useful to increase communication energy efficiency is packet bundling. This technique, which is available in several radio interfaces (e.g. LTE and some 802.11 variants), allows ! to aggregate several small packets into a single large packet. Header and communication overhead is therefore reduced. 3.6. Power save services available in example low-power radios --- 409,415 ---- Another technique that may be useful to increase communication energy efficiency is packet bundling. This technique, which is available in several radio interfaces (e.g. LTE and some 802.11 variants), allows ! aggregation of several small packets into a single large packet. Header and communication overhead is therefore reduced. 3.6. Power save services available in example low-power radios *************** *** 429,435 **** Listen Interval (which can be a multiple of the Beacon Interval) in order to receive beacons. The AP signals in the beacon whether there is data pending for the station or not. If there are not frames to ! be sent to the station, the latter may get back to sleep mode. Otherwise, the station may send a message requesting the transmission of the buffered data and stay awake in receive mode. --- 429,435 ---- Listen Interval (which can be a multiple of the Beacon Interval) in order to receive beacons. The AP signals in the beacon whether there is data pending for the station or not. If there are not frames to ! be sent to the station, the latter may go back to sleep mode. Otherwise, the station may send a message requesting the transmission of the buffered data and stay awake in receive mode. *************** *** 472,495 **** Using the above services provided by the lower layer, the constrained nodes can achieve either client initiated power save (via TFS) or ! network assisted power save (Proxy-ARP, BSS Max Idel Period and FMS). ! Upper layer protocols should synchronize with the parameters such as FMS interval and BSS MAX Idle Period, so that the wireless transmissions are not triggered periodically. 3.6.2. Power Save Services Provided by Bluetooth LE ! Bluetooth LE is a wireless low-power communications technology that is the hallmark component of the Bluetooth 4.0, 4.1, and 4.2 ! specifications [Bluetooth42]. BT-LE has been designed for the goal ! of ultra-low-power consumption. IPv6 can be run IPv6 over Bluetooth LE networks by using a 6LoWPAN variant adapted to BT-LE [RFC7668]. Bluetooth LE networks comprise a master and one or more slaves which are connected to the master. The Bluetooth LE master is assumed to be a relatively powerful device, whereas a slave is typically a ! constrained device (e.g. a class 1 device). Medium access in Bluetooth LE is based on a Time Division Multiple Access (TDMA) scheme which is coordinated by the master. This device --- 472,495 ---- Using the above services provided by the lower layer, the constrained nodes can achieve either client initiated power save (via TFS) or ! network-assisted power save (Proxy-ARP, BSS Max Idel Period and FMS). ! Upper layer protocols should synchronize the parameters such as FMS interval and BSS MAX Idle Period, so that the wireless transmissions are not triggered periodically. 3.6.2. Power Save Services Provided by Bluetooth LE ! Bluetooth LE (BT-LE) is a wireless low-power communications technology that is the hallmark component of the Bluetooth 4.0, 4.1, and 4.2 ! specifications [Bluetooth42]. BT-LE has been designed with the goal ! of ultra-low-power consumption. IPv6 can be run over Bluetooth LE networks by using a 6LoWPAN variant adapted to BT-LE [RFC7668]. Bluetooth LE networks comprise a master and one or more slaves which are connected to the master. The Bluetooth LE master is assumed to be a relatively powerful device, whereas a slave is typically a ! constrained device (e.g., a class 1 device). Medium access in Bluetooth LE is based on a Time Division Multiple Access (TDMA) scheme which is coordinated by the master. This device *************** *** 512,518 **** The time between consecutive connection events is defined by the connInterval parameter, which may range between 7.5 ms and 4 s. The ! slave may remain in sleep mode since the end of its last connection event until the beginning of its next connection event. Therefore, Bluetooth LE is duty-cycled by design. Furthermore, after having replied to the master, a slave is not required to listen to the --- 512,518 ---- The time between consecutive connection events is defined by the connInterval parameter, which may range between 7.5 ms and 4 s. The ! slave may remain in sleep mode from the end of its last connection event until the beginning of its next connection event. Therefore, Bluetooth LE is duty-cycled by design. Furthermore, after having replied to the master, a slave is not required to listen to the *************** *** 525,535 **** Upper layer protocols should take into account the medium access and duty-cycling behavior of Bluetooth LE. In particular, connInterval, ! connSlaveLatency and connSupervisionTimeout determine the time between two consecutive connection events for a given slave. The upper layer packet generation pattern and rate should be consistent with the settings of the aforementioned parameters (and vice versa). ! For example, assume connInterval=4 seconds, connSlaveLatency=7 and connSupervisionTimeout=32 seconds. With these settings, communication opportunities between a master and a slave will occur during a given interval every 32 seconds. Duration of the interval --- 525,535 ---- Upper layer protocols should take into account the medium access and duty-cycling behavior of Bluetooth LE. In particular, connInterval, ! connSlaveLatency, and connSupervisionTimeout determine the time between two consecutive connection events for a given slave. The upper layer packet generation pattern and rate should be consistent with the settings of the aforementioned parameters (and vice versa). ! For example, assume connInterval=4 seconds, connSlaveLatency=7, and connSupervisionTimeout=32 seconds. With these settings, communication opportunities between a master and a slave will occur during a given interval every 32 seconds. Duration of the interval *************** *** 546,555 **** the de-facto choice for a wide range of constrained node network application domains and has been a primary target technology of various IETF working groups such as 6LoWPAN [RFC6282], [RFC6775], ! [RFC4944] and 6TiSCH [I-D.ietf-6tisch-architecture]. IEEE 802.15.4 specifies a variety of related PHY and MAC layer functionalites. ! IEEE 802.15.4 defines three roles called device, coordinator and Personal Area Network (PAN) coordinator. The device role is adequate for nodes that do not implement the complete IEEE 802.15.4 functionality, and is mainly targeted for constrained nodes with a --- 546,555 ---- the de-facto choice for a wide range of constrained node network application domains and has been a primary target technology of various IETF working groups such as 6LoWPAN [RFC6282], [RFC6775], ! [RFC4944], and 6TiSCH [I-D.ietf-6tisch-architecture]. IEEE 802.15.4 specifies a variety of related PHY and MAC layer functionalites. ! IEEE 802.15.4 defines three roles called device, coordinator, and Personal Area Network (PAN) coordinator. The device role is adequate for nodes that do not implement the complete IEEE 802.15.4 functionality, and is mainly targeted for constrained nodes with a *************** *** 563,569 **** capabilities and is suitable for nodes that do not suffer severe ! constraints (e.g. a mains-powered node). The PAN coordinator is a special type of coordinator that acts as a principal controller in an IEEE 802.15.4 network. --- 563,569 ---- capabilities and is suitable for nodes that do not suffer severe ! constraints (e.g., a mains-powered node). The PAN coordinator is a special type of coordinator that acts as a principal controller in an IEEE 802.15.4 network. *************** *** 571,583 **** configuration: beacon-enabled and nonbeacon-enabled networks. In the first network type, coordinators periodically transmit beacons. The time between beacons is divided in three main parts: the Contention ! Access Period (CAP), the Contention Free Period (CFP) and an inactive period. In the first period, nodes use slotted Carrier Sense Multiple Access / Collision Avoidance (CSMA/CA) for data communication. In the second one, a TDMA scheme controls medium access. During the idle period, communication does not take place, ! thus the inactive period is a good opportunity for nodes to turn the ! radio off and save energy. The coordinator announces in each beacon the list of nodes for which data will be sent in the subsequent period. Therefore, devices may remain in sleep mode by default and wake up periodically to listen to the beacons sent by their --- 571,583 ---- configuration: beacon-enabled and nonbeacon-enabled networks. In the first network type, coordinators periodically transmit beacons. The time between beacons is divided in three main parts: the Contention ! Access Period (CAP), the Contention Free Period (CFP), and an inactive period. In the first period, nodes use slotted Carrier Sense Multiple Access / Collision Avoidance (CSMA/CA) for data communication. In the second one, a TDMA scheme controls medium access. During the idle period, communication does not take place, ! thus the inactive period is a good opportunity for nodes to turn their ! radios off and save energy. The coordinator announces in each beacon the list of nodes for which data will be sent in the subsequent period. Therefore, devices may remain in sleep mode by default and wake up periodically to listen to the beacons sent by their *************** *** 589,595 **** the message. The beacon interval and the duration of the beacon interval active ! portion (i.e. the CAP and the CFP), and thus the duty cycle, can be configured. The parameters that control these times are called macBeaconOrder and macSuperframeOrder, respectively. As an example, when IEEE 802.15.4 operates in the 2.4 GHz PHY, both times can be --- 589,595 ---- the message. The beacon interval and the duration of the beacon interval active ! portion (i.e., the CAP and the CFP), and thus the duty cycle, can be configured. The parameters that control these times are called macBeaconOrder and macSuperframeOrder, respectively. As an example, when IEEE 802.15.4 operates in the 2.4 GHz PHY, both times can be *************** *** 598,604 **** In the beaconless mode, nodes use unslotted CSMA/CA for data transmission. The device may be in sleep mode by default and may ! activate its radio to either i) request to the coordinator whether there is pending data for the device, or ii) to transmit data to the coordinator. The wake-up pattern of the device, if any, is out of the scope of IEEE 802.15.4. --- 598,604 ---- In the beaconless mode, nodes use unslotted CSMA/CA for data transmission. The device may be in sleep mode by default and may ! activate its radio to either i) to query the coordinator whether there is pending data for the device, or ii) to transmit data to the coordinator. The wake-up pattern of the device, if any, is out of the scope of IEEE 802.15.4. *************** *** 631,640 **** schedule whereby a set of time slots are used for frame transmission and reception, and other time slots are unscheduled. The latter time slots may be used by a dynamic scheduling mechanism, otherwise nodes ! may keep the radio off during the unscheduled time slots, thus saving energy. The minimal schedule configuration specified in [I-D.ietf-6tisch-minimal] comprises 101 time slots; 95 of these time ! slots are unscheduled and the time slot duration is 15 ms. The previously mentioned CSL and RIT are also 802.15.4e modes designed for low energy. --- 631,640 ---- schedule whereby a set of time slots are used for frame transmission and reception, and other time slots are unscheduled. The latter time slots may be used by a dynamic scheduling mechanism, otherwise nodes ! may keep their radios off during the unscheduled time slots, thus saving energy. The minimal schedule configuration specified in [I-D.ietf-6tisch-minimal] comprises 101 time slots; 95 of these time ! slots are unscheduled. The time slot duration is 15 ms. The previously mentioned CSL and RIT are also 802.15.4e modes designed for low energy. *************** *** 648,654 **** operate on special power optimized silicon, but can connect to a DECT Gateway supporting traditional DECT / CAT-iq for cordless telephony and data as well as the DECT ULE extensions. IPv6 can be run over ! DECT ULE by using a 6LoWPAN variant [I-D.ietf-6lo-dect-ule]. DECT defines two major roles: the Portable Part (PP) is the power constrained device, while the Fixed Part (FP) is the Gateway or base --- 648,654 ---- operate on special power optimized silicon, but can connect to a DECT Gateway supporting traditional DECT / CAT-iq for cordless telephony and data as well as the DECT ULE extensions. IPv6 can be run over ! DECT ULE using a 6LoWPAN variant [I-D.ietf-6lo-dect-ule]. DECT defines two major roles: the Portable Part (PP) is the power constrained device, while the Fixed Part (FP) is the Gateway or base *************** *** 656,666 **** reserved frequency bands based on TDMA/FDMA and TDD using dynamic channel allocation for interference avoidance. It provides good indoor (~50 m) and outdoor (~300 m) coverage. It uses a frame length ! of 10 ms divided into 24 timeslots, and it supports connection ! oriented, packet data and connection-less services. The FP usually transmits a so-called dummy bearer (beacon) that is ! used to broadcast synchronization, system and paging information. The slot/carrier position of this dummy bearer can automatically be reallocated in order to avoid mutual interference with other DECT signals. --- 656,666 ---- reserved frequency bands based on TDMA/FDMA and TDD using dynamic channel allocation for interference avoidance. It provides good indoor (~50 m) and outdoor (~300 m) coverage. It uses a frame length ! of 10 ms divided into 24 timeslots. It supports connection ! oriented, packet data, and connection-less services. The FP usually transmits a so-called dummy bearer (beacon) that is ! used to broadcast synchronization, system, and paging information. The slot/carrier position of this dummy bearer can automatically be reallocated in order to avoid mutual interference with other DECT signals. *************** *** 674,705 **** Internet-Draft Lwig Energy Efficient October 2017 ! At the MAC level DECT ULE communications between FP and PP are ! initiated by the PP. A FP can initiate communication indirectly by sending paging signal to a PP. The PP determines the timeslot and ! frequency on which the communication between FP and PP takes place. The PP verifies the radio timeslot/frequency position is unoccupied before it initiates its transmitter. An access-request message, which usually carries data, is sent to the FP. The FP sends a confirm message, which also may carry data. More data can be sent in subsequent frames. A MAC level automatic retransmission scheme significantly improves data transfer reliability. A segmentation and ! reassembly scheme supports transfer of larger higher layer SDUs and provides data integrity check. The DECT ULE packet data service ensures data integrity, proper sequencing, duplicate protection, but ! not guaranteed delivery. Higher layers protocols have to take this into consideration. The FP may send paging information to PPs to trigger connection setup ! and indicate the required service type. The interval between paging information to a specific PP can be defined in range 10 ms to 327 seconds. The PP may enter sleep mode to save power. The listening interval is defined by the PP application. For short sleep intervals ! (below ~10 seconds) the PP may be able to retain synchronization to ! the FP dummy bearer and only turn on the receiver during the expected ! timeslot. For longer sleep intervals the PP can't keep synchronization and has to search for and resynchronize to the FP ! dummybearer. Hence, longer sleep interval reduces the average energy consumption, but adds a energy consumption penalty for acquiring synchronization to the FP dummy bearer. The PP can obtain all information to determine paging and acquire synchronization --- 674,705 ---- Internet-Draft Lwig Energy Efficient October 2017 ! At the MAC level, DECT ULE communications between FP and PP are ! initiated by the PP. An FP can initiate communication indirectly by sending paging signal to a PP. The PP determines the timeslot and ! frequency at which communication between the FP and PP takes place. The PP verifies the radio timeslot/frequency position is unoccupied before it initiates its transmitter. An access-request message, which usually carries data, is sent to the FP. The FP sends a confirm message, which also may carry data. More data can be sent in subsequent frames. A MAC level automatic retransmission scheme significantly improves data transfer reliability. A segmentation and ! reassembly scheme supports transfer of larger higher-layer SDUs and provides data integrity check. The DECT ULE packet data service ensures data integrity, proper sequencing, duplicate protection, but ! not guaranteed delivery. Higher-layer protocols have to take this into consideration. The FP may send paging information to PPs to trigger connection setup ! and indicate the required service type. The interval between sending paging information to a specific PP can be defined in range 10 ms to 327 seconds. The PP may enter sleep mode to save power. The listening interval is defined by the PP application. For short sleep intervals ! (below ~10 seconds), the PP may be able to retain synchronization to ! the FP dummy bearer and only turn on its receiver during the expected ! timeslot. For longer sleep intervals, the PP can't keep synchronization and has to search for and resynchronize to the FP ! dummy bearer. Hence, longer sleep interval reduces the average energy consumption, but adds a energy consumption penalty for acquiring synchronization to the FP dummy bearer. The PP can obtain all information to determine paging and acquire synchronization *************** *** 711,724 **** about 10 ms by doing energy consuming RSSI scanning in advance. In the direction from FP to PP the latency is usually increased by the used paging interval and the sleep interval. The MAC layer can ! piggyback commands to improve efficiency (reduce latency) of higher layer protocols. Such commands can instruct the PP to initiate a new packet transfer in N frames without the need for resynchronization and listening to paging or instruct the PP to stay in a higher duty cycle paging detection mode. The DECT ULE technology allows per PP configuration of paging ! interval, MTU size, reassembly window size and higher layer service negotiation and protocol. --- 711,724 ---- about 10 ms by doing energy consuming RSSI scanning in advance. In the direction from FP to PP the latency is usually increased by the used paging interval and the sleep interval. The MAC layer can ! piggyback commands to improve efficiency (reduce latency) of higher- layer protocols. Such commands can instruct the PP to initiate a new packet transfer in N frames without the need for resynchronization and listening to paging or instruct the PP to stay in a higher duty cycle paging detection mode. The DECT ULE technology allows per PP configuration of paging ! interval, MTU size, reassembly window size, and higher-layer service negotiation and protocol. *************** *** 736,742 **** IEEE 802.15.4. 6LoWPAN affects the energy-efficiency problem in three aspects, as follows. ! First, 6LoWPAN provides one fragmentation and reassembly mechanism which is aimed at solving the packet size issue in IPv6 and could also affect energy-efficiency. IPv6 requires that every link in the internet have an MTU of 1280 octets or greater. On any link that --- 736,742 ---- IEEE 802.15.4. 6LoWPAN affects the energy-efficiency problem in three aspects, as follows. ! First, 6LoWPAN provides a fragmentation and reassembly mechanism which is aimed at solving the packet size issue in IPv6 and could also affect energy-efficiency. IPv6 requires that every link in the internet have an MTU of 1280 octets or greater. On any link that *************** *** 749,765 **** the IP layer will produce more IP packets, each one carrying its own IP header. However, performance can be severely affected if, after IP layer fragmentation, then 6LoWPAN fragmentation happens as well ! (e.g. when the upper layer is not aware of the existence of the fragmentation at the 6LoWPAN layer). One solution is to require ! higher layers awareness of lower layer features and generate small enough packets to avoid fragmentation. In this regard, the Block option in CoAP can be useful when CoAP is used at the application layer [RFC 7959]. Secondly, 6LoWPAN swaps computing with communication. 6LoWPAN applies compression of the IPv6 header. Subject to the packet size limit of ! IEEE 802.15.4, 40 octets long IPv6 header and 8 octets or 20 octets ! long UDP and TCP header will consume even more packet space than the data itself. 6LoWPAN provides IPv6 and UDP header compression at the adaptation layer. Therefore, a lower amount of data will be handled by the lower layers, whereas both the sender and receiver will spend --- 749,765 ---- the IP layer will produce more IP packets, each one carrying its own IP header. However, performance can be severely affected if, after IP layer fragmentation, then 6LoWPAN fragmentation happens as well ! (e.g., when the upper layer is not aware of the existence of the fragmentation at the 6LoWPAN layer). One solution is to require ! higher-layer awareness of lower-layer features and generate small enough packets to avoid fragmentation. In this regard, the Block option in CoAP can be useful when CoAP is used at the application layer [RFC 7959]. Secondly, 6LoWPAN swaps computing with communication. 6LoWPAN applies compression of the IPv6 header. Subject to the packet size limit of ! IEEE 802.15.4, a 40-octets IPv6 header and an 8-octet or 20-octet ! UDP or TCP header will consume even more packet space than the data itself. 6LoWPAN provides IPv6 and UDP header compression at the adaptation layer. Therefore, a lower amount of data will be handled by the lower layers, whereas both the sender and receiver will spend *************** *** 788,807 **** one second apart). NUD timeout settings should be tuned taking into account the latency that may be introduced by duty-cycled mechanisms ! at the link layer, or alternative, less impatient NUD algorithms should be considered [I-D.ietf-6man-impatient-nud]. ! IPv6 underlies the higher layer protocols, including both TCP/UDP transport and applications. By design, the higher-layer protocols do not typically have specific information about the lower layers, and thus cannot solve the energy-efficiency problem. The network stack can be designed to save computing power. For ! example the Contiki implementation has multiple cross layer optimizations for buffers and energy management, e.g., the computing and validation of UDP/TCP checksums without the need of reading IP headers from a different layer. These optimizations are software ! implementation techniques, and out of the scope of IETF and the LWIG working group. 5. Routing Protocols --- 788,807 ---- one second apart). NUD timeout settings should be tuned taking into account the latency that may be introduced by duty-cycled mechanisms ! at the link layer, or as an alternative, less impatient NUD algorithms should be considered [I-D.ietf-6man-impatient-nud]. ! IPv6 underlies the higher-layer protocols, including both TCP/UDP transport and applications. By design, the higher-layer protocols do not typically have specific information about the lower layers, and thus cannot solve the energy-efficiency problem. The network stack can be designed to save computing power. For ! example, the Contiki implementation has multiple cross-layer optimizations for buffers and energy management, e.g., the computing and validation of UDP/TCP checksums without the need of reading IP headers from a different layer. These optimizations are software ! implementation techniques, and out of the scope of the IETF and the LWIG working group. 5. Routing Protocols *************** *** 816,836 **** The authors of the Powertrace tool [Powertrace] studied the power profile of RPL. Their analysis divides the routing protocol into control and data traffic. The control plane carries ICMP messages to ! establish and maintain the routing states. The data plane carries any application that uses RPL for routing packets. The study has ! shown that the power consumption of the control traffic goes down ! over time in a relatively stable network. The study also reflects that the routing protocol should keep the control traffic as low as possible to make it energy-friendly. The amount of RPL control traffic can be tuned by setting the Trickle [RFC6206] algorithm ! parameters (i.e. Imin, Imax and k) to appropriate values. However, there exists a trade-off between energy consumption and other performance parameters such as network convergence time and robustness. RFC 6551 [RFC6551] defines routing metrics and constraints to be used by RPL in route computation. Among others, RFC 6551 specifies a Node ! Energy object that allows to provide information related to node energy, such as the energy source type or the estimated percentage of remaining energy. Appropriate use of energy-based routing metrics --- 816,836 ---- The authors of the Powertrace tool [Powertrace] studied the power profile of RPL. Their analysis divides the routing protocol into control and data traffic. The control plane carries ICMP messages to ! establish and maintain routing states. The data plane carries any application that uses RPL for routing packets. The study has ! shown that the power consumption of control traffic goes down ! over time in a relatively stable network. The study also recommends that the routing protocol should keep the control traffic as low as possible to make it energy-friendly. The amount of RPL control traffic can be tuned by setting the Trickle [RFC6206] algorithm ! parameters (i.e., Imin, Imax, and k) to appropriate values. However, there exists a trade-off between energy consumption and other performance parameters such as network convergence time and robustness. RFC 6551 [RFC6551] defines routing metrics and constraints to be used by RPL in route computation. Among others, RFC 6551 specifies a Node ! Energy object that provides information related to node energy, such as the energy source type or the estimated percentage of remaining energy. Appropriate use of energy-based routing metrics *************** *** 843,849 **** may help to balance energy consumption of network nodes, minimize ! network partitioning and increase network lifetime. 6. Application Layer --- 843,849 ---- may help to balance energy consumption of network nodes, minimize ! network partitioning, and increase network lifetime. 6. Application Layer *************** *** 856,869 **** binary header. Energy efficiency is part of the CoAP protocol design. CoAP uses a ! fixed-length binary header of only four bytes that may be followed by binary options. To reduce regular and frequent queries of the resources, CoAP provides an observe mode, in which the requester ! registers its interest of a certain resource and the responder will ! report the value whenever it was updated. This reduces the request response round trips while keeping information exchange a ubiquitous service; an energy-constrained server can remain in sleep mode during ! the period between observe notification transmissions. Furthermore, [RFC7252] defines CoAP proxies which can cache resource representations previously provided by sleepy CoAP servers. The --- 856,869 ---- binary header. Energy efficiency is part of the CoAP protocol design. CoAP uses a ! fixed-length binary header of only four octets that may be followed by binary options. To reduce regular and frequent queries of the resources, CoAP provides an observe mode, in which the requester ! registers its interest in a certain resource and the responder will ! report the value whenever it was updated. This reduces the request/ response round trips while keeping information exchange a ubiquitous service; an energy-constrained server can remain in sleep mode during ! the period between observe-notification transmissions. Furthermore, [RFC7252] defines CoAP proxies which can cache resource representations previously provided by sleepy CoAP servers. The *************** *** 874,887 **** CoAP proxy and cache functionality may also be used to perform data aggregation. This technique allows a node to receive data messages ! (e.g. carrying sensor readings) from other nodes in the network, perform an operation based on the content in those messages, and transmit the result of the operation. Such operation may simply be intended to use one packet to carry the readings transported in several packets (which reduces header and transmission overhead), or it may be a more sophisticated operation, possibly based on ! mathematical, logical or filtering principles (which reduces the ! payload size to be transmitted). 6.2. Sleepy node support --- 874,887 ---- CoAP proxy and cache functionality may also be used to perform data aggregation. This technique allows a node to receive data messages ! (e.g., carrying sensor readings) from other nodes in the network, perform an operation based on the content in those messages, and transmit the result of the operation. Such operation may simply be intended to use one packet to carry the readings transported in several packets (which reduces header and transmission overhead), or it may be a more sophisticated operation, possibly based on ! mathematical, logical, or filtering principles (which reduces the ! transmitted payload size). 6.2. Sleepy node support *************** *** 898,911 **** Internet-Draft Lwig Energy Efficient October 2017 ! mechanisms) in a scenario with sleepy devices has been described [I-D.ietf-lwig-crypto-sensors]. Approaches to support sleepy nodes include exploiting the use of proxies, leveraging the Resource ! Directory [I-D.ietf-core-resource-directory] or signaling when a node is awake to the interested nodes. Recent work defines publish- subscribe and message queuing extensions to CoAP and the Resource Directory in order to support devices that spend most of their time ! in asleep [I-D.ietf-core-coap-pubsub]. Notably, this work has been adopted by the CoRE Working Group. In addition to the work within the scope of CoAP to support sleepy --- 898,911 ---- Internet-Draft Lwig Energy Efficient October 2017 ! mechanisms) in a scenario with sleepy devices has been described in [I-D.ietf-lwig-crypto-sensors]. Approaches to support sleepy nodes include exploiting the use of proxies, leveraging the Resource ! Directory [I-D.ietf-core-resource-directory], or signaling when a node is awake to the interested nodes. Recent work defines publish- subscribe and message queuing extensions to CoAP and the Resource Directory in order to support devices that spend most of their time ! asleep [I-D.ietf-core-coap-pubsub]. Notably, this work has been adopted by the CoRE Working Group. In addition to the work within the scope of CoAP to support sleepy *************** *** 929,939 **** RTO value is chosen randomly between 2 and 3 s. If an RTO expires, the new RTO value is doubled (unless a limit on the number of retransmissions has been reached). Since duty-cycling at the link ! layer may lead to long latency (i.e. even greater than the initial RTO value), CoAP RTO parameters should be tuned accordingly in order to avoid spurious RTOs which would unnecessarily waste node energy and other resources. On the other hand, note that CoAP can also run ! on top of TCP [I-D.ietf-core-coap-tcp-tls]. In that case, similar guidance applies to TCP timers, albeit with greater motivation to carefully configure TCP RTO parameters, since [RFC6298] reduced the default initial TCP RTO to 1 second, which may interact more --- 929,939 ---- RTO value is chosen randomly between 2 and 3 s. If an RTO expires, the new RTO value is doubled (unless a limit on the number of retransmissions has been reached). Since duty-cycling at the link ! layer may lead to long latency (i.e., even greater than the initial RTO value), CoAP RTO parameters should be tuned accordingly in order to avoid spurious RTOs which would unnecessarily waste node energy and other resources. On the other hand, note that CoAP can also run ! on top of TCP [I-D.ietf-core-coap-tcp-tls]. In this case, similar guidance applies to TCP timers, albeit with greater motivation to carefully configure TCP RTO parameters, since [RFC6298] reduced the default initial TCP RTO to 1 second, which may interact more *************** *** 943,949 **** Another method intended to reduce the size of the data units to be communicated in constrained-node networks is data compression, which ! allows to encode data using less bits than the original data representation. Data compression is more efficient at higher layers, particularly before encryption is used. In fact, encryption --- 943,949 ---- Another method intended to reduce the size of the data units to be communicated in constrained-node networks is data compression, which ! allows encoding data using less bits than the original data representation. Data compression is more efficient at higher layers, particularly before encryption is used. In fact, encryption *************** *** 969,979 **** reduce power consumption, it is recommended that Layer 3 designs should operate based on awareness of lower-level parameters rather than treating the lower layer as a black box (Sections 4, ! 5 and 6). b. It is always useful to compress the protocol headers in order to reduce the transmission/reception power. This design principle ! has been employed by many protocols in 6Lo and CoRE working group (Sections 4 and 6). c. Broadcast and non-synchronized transmissions consume more than --- 969,979 ---- reduce power consumption, it is recommended that Layer 3 designs should operate based on awareness of lower-level parameters rather than treating the lower layer as a black box (Sections 4, ! 5, and 6). b. It is always useful to compress the protocol headers in order to reduce the transmission/reception power. This design principle ! has been employed by many protocols in the 6Lo and CoRE working group (Sections 4 and 6). c. Broadcast and non-synchronized transmissions consume more than Thanks, Acee