Internet DRAFT - draft-savolainen-6man-optimal-transmission-window
draft-savolainen-6man-optimal-transmission-window
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]