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


   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",
   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

   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
      Reserved:    Reserved for the future, MUST be set to zero.
      Interval:    The time between optimal transmission windows, in
      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

   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

   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

   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


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-

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/

   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

              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.

              Chandra Sekhar Bontu and Ed Illidge, "DRX Mechanism for
              Power Saving in LTE", June 2009.

              Henry Haverinen, Jonne Siren, and Pasi Eronen, "Energy
              Consumption of Always-On Applications in WCDMA Networks",
              April 2007.

              Hartke, K., "Observing Resources in CoAP", draft-ietf-
              core-observe-11 (work in progress), October 2013.

              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

   [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
   Visiokatu 3
   Tampere  FI-33720

   Email: teemu.savolainen@nokia.com

Savolainen               Expires August 4, 2014                [Page 10]