One document matched: draft-savolainen-6man-optimal-transmission-window-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC4191 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4191.xml">
<!ENTITY RFC4787 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4787.xml">
<!ENTITY RFC4861 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4861.xml">
<!ENTITY RFC6059 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6059.xml">
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-savolainen-6man-optimal-transmission-window-00" ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200902,
or pre5378Trust200902
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="Optimal Transmission Window">Optimal Transmission Window Configuration Option for ICMPv6 Router Advertisement</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author initials='T.S' surname="Savolainen" fullname='Teemu Savolainen'>
<organization abbrev="Nokia">Nokia</organization>
<address>
<postal>
<street>Hermiankatu 12 D</street>
<code>FI-33720</code>
<city>Helsinki</city>
<country>Finland</country>
</postal>
<email>teemu.savolainen@nokia.com</email>
</address>
</author>
<author initials='J.N.' surname="Nieminen" fullname='Johanna Nieminen'>
<organization abbrev="Nokia">Nokia</organization>
<address>
<postal>
<street>Itaemerenkatu 11-13</street>
<code>FI-00180</code>
<city>Helsinki</city>
<country>Finland</country>
</postal>
<email>johanna.1.nieminen@nokia.com</email>
</address>
</author>
<date year="2012" />
<!-- If the month and year are both specified and are the current ones, xml2rfc will fill
in the current day for you. If only the current year is specified, xml2rfc will fill
in the current day and month for you. If the year is not the current one, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
purpose of calculating the expiry date). With drafts it is normally sufficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>General</area>
<workgroup>Internet Engineering Task Force</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>template</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>This specification describes an ICMPv6 Router Advertisement option for
a router to configure optimal transmission window for hosts transmitting packets
through the router.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>This document describes an ICMPv6 Router Advertisement <xref target="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.</t>
<t>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.</t>
<t>In 3GPP cellular networks the radio, once activated, stays on for
some time based on network-specific timer values <xref target="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.</t>
<t>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.</t>
<section title="Requirements Language">
<t>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 <xref
target="RFC2119">RFC 2119</xref>.</t>
</section>
</section>
<section title="Optimal Transmission Window Option" anchor="optionFormat">
<figure align="center">
<artwork align="left"><![CDATA[
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.
]]></artwork>
</figure>
</section>
<section title="Router Behavior">
<t>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.</t>
<t>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.</t>
<t>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 <xref target="protocolConstants"/>)
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.</t>
<t>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 <xref target="RFC4787"/>).</t>
<t>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.</t>
<t>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 <xref target="protocolConstants"/>).</t>
<t>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.</t>
<t>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.</t>
</section>
<section title="Host Behavior">
<t>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.</t>
<t>The host 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 <xref target="protocolConstants"/>)
in order to avoid collisions caused by multitude of hosts transmitting at the same time.</t>
<t>Sometimes a host needs to perform time consuming operations on the link before transmitting to the Internet, such as performing
Detecting Network Attachment-procedures <xref target="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.</t>
<t>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.</t>
<t>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 <xref target="RFC4191"/>, the host SHOULD
also record optimal transmission window schedules for each more-specific route.</t>
<t>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. </t>
<t>The host does not have to transmit in every optimal sending window.</t>
</section>
<section title="Protocol Constants" anchor="protocolConstants">
<t>Following constants are defined for the operation of
the Optimal Transmission Window Configuration option.</t>
<t>INTERVAL_DEFAULT: 800 seconds</t>
<t>MIN_WINDOW_DURATION: 1000 milliseconds</t>
<t>COLLISION_AVOIDANCE_DURATION: 100 milliseconds</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This memo requests IANA to allocate a type value
from the "IPv6 Neighbor Discovery Option Formats" registry
for the option defined at the <xref target="optionFormat"/>.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>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.</t>
<t>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.</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<references title="Normative References">
<!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
&RFC2119;
&RFC4191;
&RFC4861;
</references>
<references title="Informative References">
<!-- Here we use entities that we defined at the beginning. -->
<reference anchor='Haverinen2007'>
<front>
<title>Energy Consumption of Always-On Applications in WCDMA Networks
</title>
<author><organization>Henry Haverinen, Jonne Siren, and Pasi Eronen</organization></author>
<date month='April' year='2007' />
</front>
</reference>
&RFC6059;
&RFC4787;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 05:46:56 |