idnits 2.17.1 draft-savolainen-6lo-optimal-transmission-window-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 date (January 31, 2014) is 3737 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-16) exists of draft-ietf-core-observe-11 == Outdated reference: A later version (-10) exists of draft-ietf-v6ops-64share-09 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6Lo Working Group T. Savolainen 3 Internet-Draft Nokia 4 Intended status: Standards Track January 31, 2014 5 Expires: August 4, 2014 7 Optimal Transmission Window Option for ICMPv6 Router Advertisement 8 draft-savolainen-6lo-optimal-transmission-window-00 10 Abstract 12 For a class of gateways an activation of an uplink network 13 connection, such as cellular radio connection, incurs a fixed cost in 14 form of consumed energy. For these gateways minimizing the number of 15 uplink activations is of importance. This specification describes an 16 Optimal Transmission Window option for ICMPv6 Router Advertisement 17 that a gateway can use to communicate optimal transmission window for 18 nodes it is serving, thus helping to group separate transmissions 19 together and thereby reduce number of gateway's uplink connection 20 activation events. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on August 4, 2014. 39 Copyright Notice 41 Copyright (c) 2014 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 58 2. Problem Description . . . . . . . . . . . . . . . . . . . . . 3 59 3. Solution Description . . . . . . . . . . . . . . . . . . . . 4 60 4. Optimal Transmission Window Option . . . . . . . . . . . . . 5 61 5. Gateway Behavior . . . . . . . . . . . . . . . . . . . . . . 5 62 6. Node Behavior . . . . . . . . . . . . . . . . . . . . . . . . 6 63 7. Protocol Constants . . . . . . . . . . . . . . . . . . . . . 7 64 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 65 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8 66 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 67 11. Security Considerations . . . . . . . . . . . . . . . . . . . 8 68 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 12.1. Normative References . . . . . . . . . . . . . . . . . . 8 70 12.2. Informative References . . . . . . . . . . . . . . . . . 9 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 73 1. Introduction 75 In certain deployments gateways are very power constrained. A class 76 of such gateways are battery powered cellular-using gateways that are 77 sharing the wireless cellular connection to other nodes in wireless 78 local area networks (LAN) such as IEEE 802.11, 802.15.4, or Bluetooth 79 Low-Energy networks. Hosts in LANs may be, for example, personal 80 computers, tablets, low-energy sensors and actuators, and alike. 82 Use of the cellular uplink contributes significant power consumption 83 for the gateway device, which provides motivation for minimizing time 84 and frequency of cellular uplink usage. The causes for power 85 consumption are discussed further in Section 2. 87 This document describes an ICMPv6 Router Advertisement [RFC4861] 88 Optimal Transmission Window option, which a gateway can use in an 89 attempt to schedule and synchronize periodical communication 90 activities of the nodes gateway provides forwarding services for. 91 The option describes an optimal transmission window, during which 92 nodes should perform periodic and time insensitive transmissions. 93 This helps to minize the power consumption of the gateway by reducing 94 numbers of cellular radio activation events. 96 1.1. Requirements Language 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in RFC 2119 [RFC2119]. 102 2. Problem Description 104 3GPP cellular networks require establishment of a Packed Data 105 Protocol (PDP) context or Evolved Packet System (EPS) bearer in order 106 to transmit IP packets [RFC6459]. This establishment consumes 107 energy, but for long-lived connections, such as always-on 108 connections, the relative signifigance is small. The established 109 cellular connection can then be shared to LAN by using DHCPv6 Prefix 110 Delegation [RFC6459], by extending an IPv6 /64 prefix of the cellular 111 connection [I-D.ietf-v6ops-64share], or by utilizing Network Address 112 Translation (NAT) techniques. 114 In order to save power and bandwidth, 3GPP cellular radio attempts to 115 enter and stay in idle mode whenever there is nothing to transmit. 116 During this idle mode the logical IP-connection is retained. 118 Whenever data needs to be transmitted over 3GPP radio connection that 119 is currently in idle mode, the connection has to be signaled active. 120 Once the connection is active, actual user data can be transmitted. 121 After the user data has been transmitted, the 3GPP connection is kept 122 active for operator configurable time waiting for possible additional 123 data. If no additional data is transmitted within this time, the 124 radio is returned back to the idle mode. 126 Total energy consumed for a transmission event consist of signaling 127 required for activation of radio, transmission of the actual user 128 data, keeping the radio active while waiting for possible additional 129 data to be transmitted, and deactivation of the radio. 130 Balasubramanian et al. refer with 'ramp energy' for energy spent on 131 the radio activation and with 'tail energy' for the energy spent 132 after the transmission of the user data [Balasubramanian2009]. 134 The exact features of 3GPP radio for which the energy is consumed 135 varies by the network generation. In 2G GPRS and EDGE networks setup 136 and teardown of Temporary Block Flows (TBF) are responsible of big 137 part of 'tail energy'. In 3G WCDMA, HSPA, transitions through Radio 138 Resource Control (RRC) states before returning to idle are sources of 139 'tail energy' consumption [Haverinen2007]. In 4G LTE networks 140 support and parameters of discontinuous reception (DRX) affect 141 significantly on the power consumption [Bontu2009] . 143 While 3GPP cellular network technologies are used as an example 144 herein, other radio technologies may have similar properties causing 145 'ramp energy' and 'tail energy' consumption. 147 In case of small transactions, such as with keep-alive messaging or 148 resource state updates, the 'ramp energy' and 'tail energy' 149 contribute very significant part of the total energy consumption. 150 For single device use-cases this is the state of art, and there is 151 not much that can be optimized. 153 However, in the scenario where a cellular-using gateway is serving 154 multitude of devices in LAN, it can happen that significant energy is 155 unnecessarily spent on 'ramp energy' and 'tail energy'. This happens 156 when multiple devices in LAN are transmitting data seldomly and with 157 such intervals that the cellular gateway has to separately activate 158 the cellular radio for each transaction. I.e. in scenario where each 159 transaction from devices in LAN causes 'ramp energy' and 'tail 160 energy' costs for the gateway. 162 Hence the problem is: how to optimize energy spent on 'ramp energy' 163 and 'tail energy' in case of battery powered cellular-using gateway 164 serving multitude of devices in LAN. 166 3. Solution Description 168 To solve the problem described in Section 2, this document presents a 169 method for a gateway to attempt grouping of seldom and periodic 170 communications performed by nodes in the LAN. The solution does not 171 help in power consumption caused by transmissions initiated from the 172 Internet. 174 The gateway performs transmission grouping by indicating to nodes in 175 LAN optimal transmission window using option defined in Section 4. 176 The nodes will then attempt to send data that is not time critical at 177 the optimal times indicated by the gateway. This can work, for 178 example, when nodes need to perform periodic keep-alive signaling, 179 periodically poll or push data, or for example are using CoAP observe 180 [I-D.ietf-core-observe] and need to send resource state updates that 181 are not time critical. 183 The algorithms and procedures for nodes to switch to utilize optimal 184 transmission window, and the algorithms and procedures for the 185 gateway to come up with interval and duration parameter values for 186 optimal transmission window, are left for implementations to choose. 188 4. Optimal Transmission Window Option 190 The Optimal Transmission Window is communicated from gateway to the 191 nodes by including Optimal Transmission Window Option within ICMPv6 192 Router Advertisements [RFC4861]. The option is defined below. 194 0 1 2 3 195 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 | Type | Length |R| SWF | Reserved | 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 | Interval (ms) | 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 | Next (ms) | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 | Duration (ms) | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 Type: TBD 207 Length: 2 208 R: If set, the optimal transmission window is open 209 when the Router Advertisement was sent. If not set, 210 the window may not be open. 211 SWF: Decimal value indicating secondary transmission 212 window timing as fractions of Interval. Value 213 of zero indicates lack of secondary transmission 214 windows. Other values are used as dividers for 215 Interval. Default value is decimal 8 (binary 216 '1000'). 217 Reserved: Reserved for the future, MUST be set to zero. 218 Interval: The time between optimal transmission windows, in 219 milliseconds. 220 Next: The time to the start of the next optimal 221 transmission window in milliseconds. 222 Duration: The time the optimal transmission window is open in 223 milliseconds, for example, how long the gateway 224 estimates the radio to be at least active. 226 5. Gateway Behavior 228 A gateway that attempts to synchronize periodic transmission of nodes 229 it serves SHOULD include Optimal Transmission Window option in all 230 ICMPv6 Router Advertisement messages it originates. 232 If the uplink radio is active at the time of sending the Router 233 Advertisement, the gateway SHOULD set the R-bit on to indicate 234 immediately suitable time for transmissions. Furthermore, in the 235 event of uplink radio activation, a gateway MAY send otherwise 236 unscheduled Router Advertisement message with R-bit set in order to 237 indicate unscheduled power efficient transmission opportunity for 238 nodes. 240 The gateway using this option MUST set the Interval-field to exactly 241 match the optimal sending window, as some nodes receiving the ICMPv6 242 Router Advertisement can choose to go to sleep until the optimal 243 transmission window opens. The value for the interval-field is 244 gateway's implementation decision and depends on the deployment 245 scenario. A default value of INTERVAL_DEFAULT (see Section 7) is 246 defined for the cases where gateway has no better information. 247 Interval field value of zero indicates transmission window to be 248 always open. The SWF-field indicates presence and time of secondary 249 transmission windows during one Interval. For example, default value 250 of 8 indicates secondary transmission window to occur at every 251 INTERVAL_DEFAULT/8. 253 With the default values for INTERVAL_DEFAULT and SWF-field nodes have 254 secondary transmission window every 100 seconds, which is enough in 255 case host needs to refresh UDP mappings of NAT utilizing two minute 256 expiration time (see section 4.3 of [RFC4787]). 258 The Next-field MUST be always set to point to the moment of the next 259 optimal transmission window. Even if the R-bit is set, the Next- 260 field MUST nevertheless point to the start of the next optimal 261 transmission window. 263 The Duration-field MUST indicate the length of the window during 264 which hosts should start their periodic transmissions. The length 265 has to be at least MIN_WINDOW_DURATION (see Section 7). 267 The secondary transmission window bitfield indicates possibly 268 alternative, but still synchronized, times for hosts to transmit if 269 the optimal sending window interval frequency is too low. 271 If the gateway implements synchronization services for gateway's 272 internal applications' periodical communications, the gateway MUST 273 synchronize the internal applications to communicate during the same 274 optimal transmission window. 276 6. Node Behavior 278 A node implementing this specification SHOULD utilize the timing 279 information received via Optimal Transmission Window option and time 280 it's periodic transmissions accordingly when possible. Additionally, 281 a node MAY use Router Advertisement with this option and R-bit set as 282 trigger for communications. The node MUST refresh it's timing states 283 after every received Router Advertisement message having the Optimal 284 Transmission Window option. 286 The node MUST wait for a random period of time between the start of 287 the optimal transmission window, or reception of a Router 288 Advertisement with R-bit set, and COLLISION_AVOIDANCE_DURATION (see 289 Section 7) in order to avoid collisions caused by multitude of nodes 290 transmitting at the same time. 292 Sometimes a node needs to perform time consuming operations on the 293 link before transmitting to the Internet, such as performing 294 Detecting Network Attachment-procedures [RFC6059] if the node has 295 been asleep long enough. In such cases, the node SHOULD perform time 296 consuming operations before the communications are scheduled to take 297 place. 299 The node does not have to transmit during every window, but SHOULD 300 use the one right before the application's optimal periodic 301 communication event would occur. If the node is running application 302 that requires more frequent periodic messaging that what the optimal 303 transmission window provides, the host SHOULD attempt to communicate 304 during secondary transmission windows as configured via SWF-field. 306 The node MUST only use timing values as learned from the Router 307 Advertisement message that has been used for the highest priority 308 default router configuration. If the node supports more-specific 309 routes [RFC4191], the node SHOULD also record optimal transmission 310 window schedules for each more-specific route. 312 The node SHOULD provide an implementation specific application 313 programming interface that applications can use to learn the optimal 314 transmission window schedules. If the node maintains destination- 315 specific optimal transmission window timing information, the 316 application programming interface SHOULD allow applications to ask 317 for the timing information specific to a destination. 319 7. Protocol Constants 321 Following constants are defined for the operation of the Optimal 322 Transmission Window option. 324 INTERVAL_DEFAULT: 800 seconds 326 MIN_WINDOW_DURATION: 500 milliseconds 328 COLLISION_AVOIDANCE_DURATION: 100 milliseconds 330 8. Acknowledgements 332 We ack. 334 9. Contributors 336 Johanna Nieminen contributed to and was the second author of the 337 first IETF contribution of this problem and solution (draft- 338 savolainen-6man-optimal-transmission-window-00). 340 10. IANA Considerations 342 This memo requests IANA to register a new Neighbor Discovery Option 343 Type under the subregistry "IPv6 Neighbor Discovery Option Formats" 344 of the "Internet Control Message Protocol version 6 (ICMPv6) 345 Parameters" registry (http://www.iana.org/assignments/ 346 icmpv6-parameters/icmpv6-parameters.xhtml). 348 The type number can be the next available. 350 The Description would be:"Optimal Transmission Window Option". 352 11. Security Considerations 354 This document specifies that a node uses timing information only from 355 the Router Advertisements the node accepts for configuring default 356 and more-specific routes. This helps to mitigate against attacks 357 that try to influence transmission schedules by sending malicious 358 Router Advertisements. 360 With this option it is not possible to hinder node's communications, 361 as the option is a power saving optimization that help nodes to 362 synchronize transmissions with each other, while still allowing 363 transmissions at any time when necessary. Therefore, if the timing 364 values sent in Router Advertisement do not make sense for a node, or 365 it's applications, the values can be ignored. 367 12. References 369 12.1. Normative References 371 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 372 Requirement Levels", BCP 14, RFC 2119, March 1997. 374 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 375 More-Specific Routes", RFC 4191, November 2005. 377 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 378 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 379 September 2007. 381 12.2. Informative References 383 [Balasubramanian2009] 384 Niranjan Balasubramanian, Aruna Balasubramanian, and Arun 385 Venkataramani, "Energy Consumption in Mobile Phones: A 386 Measurement Study and Implications for Network 387 Applications Energy Consumption of Always-On Applications 388 in WCDMA Networks", November 2009. 390 [Bontu2009] 391 Chandra Sekhar Bontu and Ed Illidge, "DRX Mechanism for 392 Power Saving in LTE", June 2009. 394 [Haverinen2007] 395 Henry Haverinen, Jonne Siren, and Pasi Eronen, "Energy 396 Consumption of Always-On Applications in WCDMA Networks", 397 April 2007. 399 [I-D.ietf-core-observe] 400 Hartke, K., "Observing Resources in CoAP", draft-ietf- 401 core-observe-11 (work in progress), October 2013. 403 [I-D.ietf-v6ops-64share] 404 Byrne, C., Drown, D., and V. Ales, "Extending an IPv6 /64 405 Prefix from a 3GPP Mobile Interface to a LAN link", draft- 406 ietf-v6ops-64share-09 (work in progress), October 2013. 408 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 409 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 410 RFC 4787, January 2007. 412 [RFC6059] Krishnan, S. and G. Daley, "Simple Procedures for 413 Detecting Network Attachment in IPv6", RFC 6059, November 414 2010. 416 [RFC6459] Korhonen, J., Soininen, J., Patil, B., Savolainen, T., 417 Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation 418 Partnership Project (3GPP) Evolved Packet System (EPS)", 419 RFC 6459, January 2012. 421 Author's Address 423 Teemu Savolainen 424 Nokia 425 Visiokatu 3 426 Tampere FI-33720 427 Finland 429 Email: teemu.savolainen@nokia.com