6Lo Working Group T. Savolainen Internet-Draft Nokia Intended status: Standards Track January 31, 2014 Expires: August 4, 2014 Optimal Transmission Window Option for ICMPv6 Router Advertisement draft-savolainen-6lo-optimal-transmission-window-00 Abstract For a class of gateways an activation of an uplink network connection, such as cellular radio connection, incurs a fixed cost in form of consumed energy. For these gateways minimizing the number of uplink activations is of importance. This specification describes an Optimal Transmission Window option for ICMPv6 Router Advertisement that a gateway can use to communicate optimal transmission window for nodes it is serving, thus helping to group separate transmissions together and thereby reduce number of gateway's uplink connection activation events. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on August 4, 2014. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect Savolainen Expires August 4, 2014 [Page 1] Internet-Draft OTW January 2014 to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. Problem Description . . . . . . . . . . . . . . . . . . . . . 3 3. Solution Description . . . . . . . . . . . . . . . . . . . . 4 4. Optimal Transmission Window Option . . . . . . . . . . . . . 5 5. Gateway Behavior . . . . . . . . . . . . . . . . . . . . . . 5 6. Node Behavior . . . . . . . . . . . . . . . . . . . . . . . . 6 7. Protocol Constants . . . . . . . . . . . . . . . . . . . . . 7 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 11. Security Considerations . . . . . . . . . . . . . . . . . . . 8 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 12.1. Normative References . . . . . . . . . . . . . . . . . . 8 12.2. Informative References . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction In certain deployments gateways are very power constrained. A class of such gateways are battery powered cellular-using gateways that are sharing the wireless cellular connection to other nodes in wireless local area networks (LAN) such as IEEE 802.11, 802.15.4, or Bluetooth Low-Energy networks. Hosts in LANs may be, for example, personal computers, tablets, low-energy sensors and actuators, and alike. Use of the cellular uplink contributes significant power consumption for the gateway device, which provides motivation for minimizing time and frequency of cellular uplink usage. The causes for power consumption are discussed further in Section 2. This document describes an ICMPv6 Router Advertisement [RFC4861] Optimal Transmission Window option, which a gateway can use in an attempt to schedule and synchronize periodical communication activities of the nodes gateway provides forwarding services for. The option describes an optimal transmission window, during which nodes should perform periodic and time insensitive transmissions. This helps to minize the power consumption of the gateway by reducing numbers of cellular radio activation events. Savolainen Expires August 4, 2014 [Page 2] Internet-Draft OTW January 2014 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. Problem Description 3GPP cellular networks require establishment of a Packed Data Protocol (PDP) context or Evolved Packet System (EPS) bearer in order to transmit IP packets [RFC6459]. This establishment consumes energy, but for long-lived connections, such as always-on connections, the relative signifigance is small. The established cellular connection can then be shared to LAN by using DHCPv6 Prefix Delegation [RFC6459], by extending an IPv6 /64 prefix of the cellular connection [I-D.ietf-v6ops-64share], or by utilizing Network Address Translation (NAT) techniques. In order to save power and bandwidth, 3GPP cellular radio attempts to enter and stay in idle mode whenever there is nothing to transmit. During this idle mode the logical IP-connection is retained. Whenever data needs to be transmitted over 3GPP radio connection that is currently in idle mode, the connection has to be signaled active. Once the connection is active, actual user data can be transmitted. After the user data has been transmitted, the 3GPP connection is kept active for operator configurable time waiting for possible additional data. If no additional data is transmitted within this time, the radio is returned back to the idle mode. Total energy consumed for a transmission event consist of signaling required for activation of radio, transmission of the actual user data, keeping the radio active while waiting for possible additional data to be transmitted, and deactivation of the radio. Balasubramanian et al. refer with 'ramp energy' for energy spent on the radio activation and with 'tail energy' for the energy spent after the transmission of the user data [Balasubramanian2009]. The exact features of 3GPP radio for which the energy is consumed varies by the network generation. In 2G GPRS and EDGE networks setup and teardown of Temporary Block Flows (TBF) are responsible of big part of 'tail energy'. In 3G WCDMA, HSPA, transitions through Radio Resource Control (RRC) states before returning to idle are sources of 'tail energy' consumption [Haverinen2007]. In 4G LTE networks support and parameters of discontinuous reception (DRX) affect significantly on the power consumption [Bontu2009] . Savolainen Expires August 4, 2014 [Page 3] Internet-Draft OTW January 2014 While 3GPP cellular network technologies are used as an example herein, other radio technologies may have similar properties causing 'ramp energy' and 'tail energy' consumption. In case of small transactions, such as with keep-alive messaging or resource state updates, the 'ramp energy' and 'tail energy' contribute very significant part of the total energy consumption. For single device use-cases this is the state of art, and there is not much that can be optimized. However, in the scenario where a cellular-using gateway is serving multitude of devices in LAN, it can happen that significant energy is unnecessarily spent on 'ramp energy' and 'tail energy'. This happens when multiple devices in LAN are transmitting data seldomly and with such intervals that the cellular gateway has to separately activate the cellular radio for each transaction. I.e. in scenario where each transaction from devices in LAN causes 'ramp energy' and 'tail energy' costs for the gateway. Hence the problem is: how to optimize energy spent on 'ramp energy' and 'tail energy' in case of battery powered cellular-using gateway serving multitude of devices in LAN. 3. Solution Description To solve the problem described in Section 2, this document presents a method for a gateway to attempt grouping of seldom and periodic communications performed by nodes in the LAN. The solution does not help in power consumption caused by transmissions initiated from the Internet. The gateway performs transmission grouping by indicating to nodes in LAN optimal transmission window using option defined in Section 4. The nodes will then attempt to send data that is not time critical at the optimal times indicated by the gateway. This can work, for example, when nodes need to perform periodic keep-alive signaling, periodically poll or push data, or for example are using CoAP observe [I-D.ietf-core-observe] and need to send resource state updates that are not time critical. The algorithms and procedures for nodes to switch to utilize optimal transmission window, and the algorithms and procedures for the gateway to come up with interval and duration parameter values for optimal transmission window, are left for implementations to choose. Savolainen Expires August 4, 2014 [Page 4] Internet-Draft OTW January 2014 4. Optimal Transmission Window Option The Optimal Transmission Window is communicated from gateway to the nodes by including Optimal Transmission Window Option within ICMPv6 Router Advertisements [RFC4861]. The option is defined below. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length |R| SWF | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interval (ms) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next (ms) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Duration (ms) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: TBD Length: 2 R: If set, the optimal transmission window is open when the Router Advertisement was sent. If not set, the window may not be open. SWF: Decimal value indicating secondary transmission window timing as fractions of Interval. Value of zero indicates lack of secondary transmission windows. Other values are used as dividers for Interval. Default value is decimal 8 (binary '1000'). Reserved: Reserved for the future, MUST be set to zero. Interval: The time between optimal transmission windows, in milliseconds. Next: The time to the start of the next optimal transmission window in milliseconds. Duration: The time the optimal transmission window is open in milliseconds, for example, how long the gateway estimates the radio to be at least active. 5. Gateway Behavior A gateway that attempts to synchronize periodic transmission of nodes it serves SHOULD include Optimal Transmission Window option in all ICMPv6 Router Advertisement messages it originates. If the uplink radio is active at the time of sending the Router Advertisement, the gateway SHOULD set the R-bit on to indicate immediately suitable time for transmissions. Furthermore, in the event of uplink radio activation, a gateway MAY send otherwise Savolainen Expires August 4, 2014 [Page 5] Internet-Draft OTW January 2014 unscheduled Router Advertisement message with R-bit set in order to indicate unscheduled power efficient transmission opportunity for nodes. The gateway using this option MUST set the Interval-field to exactly match the optimal sending window, as some nodes receiving the ICMPv6 Router Advertisement can choose to go to sleep until the optimal transmission window opens. The value for the interval-field is gateway's implementation decision and depends on the deployment scenario. A default value of INTERVAL_DEFAULT (see Section 7) is defined for the cases where gateway has no better information. Interval field value of zero indicates transmission window to be always open. The SWF-field indicates presence and time of secondary transmission windows during one Interval. For example, default value of 8 indicates secondary transmission window to occur at every INTERVAL_DEFAULT/8. With the default values for INTERVAL_DEFAULT and SWF-field nodes have secondary transmission window every 100 seconds, which is enough in case host needs to refresh UDP mappings of NAT utilizing two minute expiration time (see section 4.3 of [RFC4787]). The Next-field MUST be always set to point to the moment of the next optimal transmission window. Even if the R-bit is set, the Next- field MUST nevertheless point to the start of the next optimal transmission window. The Duration-field MUST indicate the length of the window during which hosts should start their periodic transmissions. The length has to be at least MIN_WINDOW_DURATION (see Section 7). The secondary transmission window bitfield indicates possibly alternative, but still synchronized, times for hosts to transmit if the optimal sending window interval frequency is too low. If the gateway implements synchronization services for gateway's internal applications' periodical communications, the gateway MUST synchronize the internal applications to communicate during the same optimal transmission window. 6. Node Behavior A node implementing this specification SHOULD utilize the timing information received via Optimal Transmission Window option and time it's periodic transmissions accordingly when possible. Additionally, a node MAY use Router Advertisement with this option and R-bit set as trigger for communications. The node MUST refresh it's timing states Savolainen Expires August 4, 2014 [Page 6] Internet-Draft OTW January 2014 after every received Router Advertisement message having the Optimal Transmission Window option. The node MUST wait for a random period of time between the start of the optimal transmission window, or reception of a Router Advertisement with R-bit set, and COLLISION_AVOIDANCE_DURATION (see Section 7) in order to avoid collisions caused by multitude of nodes transmitting at the same time. Sometimes a node needs to perform time consuming operations on the link before transmitting to the Internet, such as performing Detecting Network Attachment-procedures [RFC6059] if the node has been asleep long enough. In such cases, the node SHOULD perform time consuming operations before the communications are scheduled to take place. The node does not have to transmit during every window, but SHOULD use the one right before the application's optimal periodic communication event would occur. If the node is running application that requires more frequent periodic messaging that what the optimal transmission window provides, the host SHOULD attempt to communicate during secondary transmission windows as configured via SWF-field. The node MUST only use timing values as learned from the Router Advertisement message that has been used for the highest priority default router configuration. If the node supports more-specific routes [RFC4191], the node SHOULD also record optimal transmission window schedules for each more-specific route. The node SHOULD provide an implementation specific application programming interface that applications can use to learn the optimal transmission window schedules. If the node maintains destination- specific optimal transmission window timing information, the application programming interface SHOULD allow applications to ask for the timing information specific to a destination. 7. Protocol Constants Following constants are defined for the operation of the Optimal Transmission Window option. INTERVAL_DEFAULT: 800 seconds MIN_WINDOW_DURATION: 500 milliseconds COLLISION_AVOIDANCE_DURATION: 100 milliseconds Savolainen Expires August 4, 2014 [Page 7] Internet-Draft OTW January 2014 8. Acknowledgements We ack. 9. Contributors Johanna Nieminen contributed to and was the second author of the first IETF contribution of this problem and solution (draft- savolainen-6man-optimal-transmission-window-00). 10. IANA Considerations This memo requests IANA to register a new Neighbor Discovery Option Type under the subregistry "IPv6 Neighbor Discovery Option Formats" of the "Internet Control Message Protocol version 6 (ICMPv6) Parameters" registry (http://www.iana.org/assignments/ icmpv6-parameters/icmpv6-parameters.xhtml). The type number can be the next available. The Description would be:"Optimal Transmission Window Option". 11. Security Considerations This document specifies that a node uses timing information only from the Router Advertisements the node accepts for configuring default and more-specific routes. This helps to mitigate against attacks that try to influence transmission schedules by sending malicious Router Advertisements. With this option it is not possible to hinder node's communications, as the option is a power saving optimization that help nodes to synchronize transmissions with each other, while still allowing transmissions at any time when necessary. Therefore, if the timing values sent in Router Advertisement do not make sense for a node, or it's applications, the values can be ignored. 12. References 12.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and More-Specific Routes", RFC 4191, November 2005. Savolainen Expires August 4, 2014 [Page 8] Internet-Draft OTW January 2014 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007. 12.2. Informative References [Balasubramanian2009] Niranjan Balasubramanian, Aruna Balasubramanian, and Arun Venkataramani, "Energy Consumption in Mobile Phones: A Measurement Study and Implications for Network Applications Energy Consumption of Always-On Applications in WCDMA Networks", November 2009. [Bontu2009] Chandra Sekhar Bontu and Ed Illidge, "DRX Mechanism for Power Saving in LTE", June 2009. [Haverinen2007] Henry Haverinen, Jonne Siren, and Pasi Eronen, "Energy Consumption of Always-On Applications in WCDMA Networks", April 2007. [I-D.ietf-core-observe] Hartke, K., "Observing Resources in CoAP", draft-ietf- core-observe-11 (work in progress), October 2013. [I-D.ietf-v6ops-64share] Byrne, C., Drown, D., and V. Ales, "Extending an IPv6 /64 Prefix from a 3GPP Mobile Interface to a LAN link", draft- ietf-v6ops-64share-09 (work in progress), October 2013. [RFC4787] Audet, F. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007. [RFC6059] Krishnan, S. and G. Daley, "Simple Procedures for Detecting Network Attachment in IPv6", RFC 6059, November 2010. [RFC6459] Korhonen, J., Soininen, J., Patil, B., Savolainen, T., Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation Partnership Project (3GPP) Evolved Packet System (EPS)", RFC 6459, January 2012. Savolainen Expires August 4, 2014 [Page 9] Internet-Draft OTW January 2014 Author's Address Teemu Savolainen Nokia Visiokatu 3 Tampere FI-33720 Finland Email: teemu.savolainen@nokia.com Savolainen Expires August 4, 2014 [Page 10]