Internet Engineering Task Force T. Savolainen Internet-Draft J. Nieminen Intended status: Standards Track Nokia Expires: December 20, 2012 June 18, 2012 Optimal Transmission Window Configuration Option for ICMPv6 Router Advertisement draft-savolainen-6man-optimal-transmission-window-00 Abstract This specification describes an ICMPv6 Router Advertisement option for a router to configure optimal transmission window for hosts transmitting packets through the router. 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 December 20, 2012. Copyright Notice Copyright (c) 2012 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 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. Savolainen & Nieminen Expires December 20, 2012 [Page 1]
Internet-Draft Optimal Transmission Window June 2012 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3 2. Optimal Transmission Window Option . . . . . . . . . . . . . . 4 3. Router Behavior . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Host Behavior . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Protocol Constants . . . . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 8.2. Informative References . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Savolainen & Nieminen Expires December 20, 2012 [Page 2]
Internet-Draft Optimal Transmission Window June 2012 1. Introduction This document describes an ICMPv6 Router Advertisement [RFC4861] option, which the router can use in an attempt to schedule and synchronize periodical communication activities of the hosts router provides routing services for. The option describes an optimal transmission window, during which hosts should perform periodic transmissions. In certain deployments routers are very power constrained. A class of such routers are battery powered cellular phones that are sharing the wireless cellular connection to wireless local area networks. Hosts in the local area networks may be, for example, personal computers or low-energy sensors. In 3GPP cellular networks the radio, once activated, stays on for some time based on network-specific timer values [Haverinen2007]. This means that, for example, a single packet originated by a host in a local area network and routed via a cellular handset can cause handset's uplink radio to be activated into a significantly power consuming state for tens of seconds. The power consumption problem is made worse if a router provides connectivity services for multitude of hosts and, in the case of cellular handset, also provides connectivity for internal applications as well. Potentially several different entities are sending keep-alive and/or other periodic messages at random times and by so doing causing router's uplink radio to be activated unnecessarily often. 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]. Savolainen & Nieminen Expires December 20, 2012 [Page 3]
Internet-Draft Optimal Transmission Window June 2012 2. Optimal Transmission Window Option 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 router estimates the radio to be at least active. 3. Router Behavior A router that attempts to synchronize periodic transmission of hosts it serves MUST 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, a router SHOULD set the R-bit on to indicate immediately suitable time for transmissions. Furthermore, in the event of uplink radio activation, a router MAY send otherwise unscheduled Router Advertisement message with R-bit set in order to indicate unscheduled power efficient transmission opportunity for hosts. Savolainen & Nieminen Expires December 20, 2012 [Page 4]
Internet-Draft Optimal Transmission Window June 2012 The router using this option MUST set the Interval-field to exactly match the optimal sending window, as some hosts receiving the ICMPv6 Router Advertisement can choose to go to sleep until the optimal transmission window opens. The value for the interval-field is router's implementation decision and depends on the deployment scenario. A default value of INTERVAL_DEFAULT (see Section 5) is defined for the cases where router 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 hosts 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 5). 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 router implements synchronization services for router's internal applications' periodical communications, the router MUST synchronize the internal applications to communicate during the same optimal transmission window. 4. Host Behavior A host MUST utilize the timing information received via Optimal Transmission Window option and time it's periodic transmissions accordingly, when possible. Additionally, a host MAY use Router Advertisement with this option and R-bit set as trigger for communications. The host MUST refresh it's timing states after every received Router Advertisement message. The host MUST wait for a random period of time between the start of the optimal transmission window, or reception of a Router Savolainen & Nieminen Expires December 20, 2012 [Page 5]
Internet-Draft Optimal Transmission Window June 2012 Advertisement with R-bit set, and COLLISION_AVOIDANCE_DURATION (see Section 5) in order to avoid collisions caused by multitude of hosts transmitting at the same time. Sometimes a host needs to perform time consuming operations on the link before transmitting to the Internet, such as performing Detecting Network Attachment-procedures [RFC6059] if the host has been asleep long enough. In such cases, the host SHOULD perform time consuming operations before the communications are scheduled to take place. The host does not have to transmit during every window, but SHOULD use the one right before the application's optimal periodic communication event. If the host 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 host MUST only use timing values as learned from the Router Advertisement message that has been used for the highest priority default router configuration. If a host supports more-specific routes [RFC4191], the host SHOULD also record optimal transmission window schedules for each more-specific route. The host SHOULD provide an implementation specific application programming interface that applications can use to learn the optimal transmission window schedules. If the host 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. The host does not have to transmit in every optimal sending window. 5. Protocol Constants Following constants are defined for the operation of the Optimal Transmission Window Configuration option. INTERVAL_DEFAULT: 800 seconds MIN_WINDOW_DURATION: 1000 milliseconds COLLISION_AVOIDANCE_DURATION: 100 milliseconds Savolainen & Nieminen Expires December 20, 2012 [Page 6]
Internet-Draft Optimal Transmission Window June 2012 6. IANA Considerations This memo requests IANA to allocate a type value from the "IPv6 Neighbor Discovery Option Formats" registry for the option defined at the Section 2. 7. Security Considerations This document specifies that a host uses timing information only from the Router Advertisements the host 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 host's communications, as the option is an optimization that help nodes to synchronize transmissions with each other, while allowing transmissions at any time when necessary. Therefore, if the timing values sent in Router Advertisement do not make sense for a host, or it's applications, the values will be ignored. 8. References 8.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. [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007. 8.2. Informative References [Haverinen2007] Henry Haverinen, Jonne Siren, and Pasi Eronen, "Energy Consumption of Always-On Applications in WCDMA Networks", April 2007. [RFC4787] Audet, F. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007. Savolainen & Nieminen Expires December 20, 2012 [Page 7]
Internet-Draft Optimal Transmission Window June 2012 [RFC6059] Krishnan, S. and G. Daley, "Simple Procedures for Detecting Network Attachment in IPv6", RFC 6059, November 2010. Authors' Addresses Teemu Savolainen Nokia Hermiankatu 12 D Helsinki FI-33720 Finland Email: teemu.savolainen@nokia.com Johanna Nieminen Nokia Itaemerenkatu 11-13 Helsinki FI-00180 Finland Email: johanna.1.nieminen@nokia.com Savolainen & Nieminen Expires December 20, 2012 [Page 8]