idnits 2.17.1 draft-savolainen-6man-optimal-transmission-window-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 18, 2012) is 4329 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force T. Savolainen 3 Internet-Draft J. Nieminen 4 Intended status: Standards Track Nokia 5 Expires: December 20, 2012 June 18, 2012 7 Optimal Transmission Window Configuration Option for ICMPv6 Router 8 Advertisement 9 draft-savolainen-6man-optimal-transmission-window-00 11 Abstract 13 This specification describes an ICMPv6 Router Advertisement option 14 for a router to configure optimal transmission window for hosts 15 transmitting packets through the router. 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on December 20, 2012. 34 Copyright Notice 36 Copyright (c) 2012 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3 53 2. Optimal Transmission Window Option . . . . . . . . . . . . . . 4 54 3. Router Behavior . . . . . . . . . . . . . . . . . . . . . . . . 4 55 4. Host Behavior . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 5. Protocol Constants . . . . . . . . . . . . . . . . . . . . . . 6 57 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 58 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 59 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 60 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 61 8.2. Informative References . . . . . . . . . . . . . . . . . . 7 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 64 1. Introduction 66 This document describes an ICMPv6 Router Advertisement [RFC4861] 67 option, which the router can use in an attempt to schedule and 68 synchronize periodical communication activities of the hosts router 69 provides routing services for. The option describes an optimal 70 transmission window, during which hosts should perform periodic 71 transmissions. 73 In certain deployments routers are very power constrained. A class 74 of such routers are battery powered cellular phones that are sharing 75 the wireless cellular connection to wireless local area networks. 76 Hosts in the local area networks may be, for example, personal 77 computers or low-energy sensors. 79 In 3GPP cellular networks the radio, once activated, stays on for 80 some time based on network-specific timer values [Haverinen2007]. 81 This means that, for example, a single packet originated by a host in 82 a local area network and routed via a cellular handset can cause 83 handset's uplink radio to be activated into a significantly power 84 consuming state for tens of seconds. 86 The power consumption problem is made worse if a router provides 87 connectivity services for multitude of hosts and, in the case of 88 cellular handset, also provides connectivity for internal 89 applications as well. Potentially several different entities are 90 sending keep-alive and/or other periodic messages at random times and 91 by so doing causing router's uplink radio to be activated 92 unnecessarily often. 94 1.1. Requirements Language 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 98 document are to be interpreted as described in RFC 2119 [RFC2119]. 100 2. Optimal Transmission Window Option 102 0 1 2 3 103 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 104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 105 | Type | Length |R| SWF | Reserved | 106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 107 | Interval (ms) | 108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 109 | Next (ms) | 110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 111 | Duration (ms) | 112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 114 Type: TBD 115 Length: 2 116 R: If set, the optimal transmission window is open 117 when the Router Advertisement was sent. If not set, 118 the window may not be open. 119 SWF: Decimal value indicating secondary transmission 120 window timing as fractions of Interval. Value 121 of zero indicates lack of secondary transmission 122 windows. Other values are used as dividers for 123 Interval. Default value is decimal 8 (binary 124 '1000'). 125 Reserved: Reserved for the future, MUST be set to zero. 126 Interval: The time between optimal transmission windows, in 127 milliseconds. 128 Next: The time to the start of the next optimal 129 transmission window in milliseconds. 130 Duration: The time the optimal transmission window is open in 131 milliseconds, for example, how long the router 132 estimates the radio to be at least active. 134 3. Router Behavior 136 A router that attempts to synchronize periodic transmission of hosts 137 it serves MUST include Optimal Transmission Window option in all 138 ICMPv6 Router Advertisement messages it originates. 140 If the uplink radio is active at the time of sending the Router 141 Advertisement, a router SHOULD set the R-bit on to indicate 142 immediately suitable time for transmissions. Furthermore, in the 143 event of uplink radio activation, a router MAY send otherwise 144 unscheduled Router Advertisement message with R-bit set in order to 145 indicate unscheduled power efficient transmission opportunity for 146 hosts. 148 The router using this option MUST set the Interval-field to exactly 149 match the optimal sending window, as some hosts receiving the ICMPv6 150 Router Advertisement can choose to go to sleep until the optimal 151 transmission window opens. The value for the interval-field is 152 router's implementation decision and depends on the deployment 153 scenario. A default value of INTERVAL_DEFAULT (see Section 5) is 154 defined for the cases where router has no better information. 155 Interval field value of zero indicates transmission window to be 156 always open. The SWF-field indicates presence and time of secondary 157 transmission windows during one Interval. For example, default value 158 of 8 indicates secondary transmission window to occur at every 159 INTERVAL_DEFAULT/8. 161 With the default values for INTERVAL_DEFAULT and SWF-field hosts have 162 secondary transmission window every 100 seconds, which is enough in 163 case host needs to refresh UDP mappings of NAT utilizing two minute 164 expiration time (see section 4.3 of [RFC4787]). 166 The Next-field MUST be always set to point to the moment of the next 167 optimal transmission window. Even if the R-bit is set, the Next- 168 field MUST nevertheless point to the start of the next optimal 169 transmission window. 171 The Duration-field MUST indicate the length of the window during 172 which hosts should start their periodic transmissions. The length 173 has to be at least MIN_WINDOW_DURATION (see Section 5). 175 The secondary transmission window bitfield indicates possibly 176 alternative, but still synchronized, times for hosts to transmit if 177 the optimal sending window interval frequency is too low. 179 If the router implements synchronization services for router's 180 internal applications' periodical communications, the router MUST 181 synchronize the internal applications to communicate during the same 182 optimal transmission window. 184 4. Host Behavior 186 A host MUST utilize the timing information received via Optimal 187 Transmission Window option and time it's periodic transmissions 188 accordingly, when possible. Additionally, a host MAY use Router 189 Advertisement with this option and R-bit set as trigger for 190 communications. The host MUST refresh it's timing states after every 191 received Router Advertisement message. 193 The host MUST wait for a random period of time between the start of 194 the optimal transmission window, or reception of a Router 195 Advertisement with R-bit set, and COLLISION_AVOIDANCE_DURATION (see 196 Section 5) in order to avoid collisions caused by multitude of hosts 197 transmitting at the same time. 199 Sometimes a host needs to perform time consuming operations on the 200 link before transmitting to the Internet, such as performing 201 Detecting Network Attachment-procedures [RFC6059] if the host has 202 been asleep long enough. In such cases, the host SHOULD perform time 203 consuming operations before the communications are scheduled to take 204 place. 206 The host does not have to transmit during every window, but SHOULD 207 use the one right before the application's optimal periodic 208 communication event. If the host is running application that 209 requires more frequent periodic messaging that what the optimal 210 transmission window provides, the host SHOULD attempt to communicate 211 during secondary transmission windows as configured via SWF-field. 213 The host MUST only use timing values as learned from the Router 214 Advertisement message that has been used for the highest priority 215 default router configuration. If a host supports more-specific 216 routes [RFC4191], the host SHOULD also record optimal transmission 217 window schedules for each more-specific route. 219 The host SHOULD provide an implementation specific application 220 programming interface that applications can use to learn the optimal 221 transmission window schedules. If the host maintains destination- 222 specific optimal transmission window timing information, the 223 application programming interface SHOULD allow applications to ask 224 for the timing information specific to a destination. 226 The host does not have to transmit in every optimal sending window. 228 5. Protocol Constants 230 Following constants are defined for the operation of the Optimal 231 Transmission Window Configuration option. 233 INTERVAL_DEFAULT: 800 seconds 235 MIN_WINDOW_DURATION: 1000 milliseconds 237 COLLISION_AVOIDANCE_DURATION: 100 milliseconds 239 6. IANA Considerations 241 This memo requests IANA to allocate a type value from the "IPv6 242 Neighbor Discovery Option Formats" registry for the option defined at 243 the Section 2. 245 7. Security Considerations 247 This document specifies that a host uses timing information only from 248 the Router Advertisements the host accepts for configuring default 249 and more-specific routes. This helps to mitigate against attacks 250 that try to influence transmission schedules by sending malicious 251 Router Advertisements. 253 With this option it is not possible to hinder host's communications, 254 as the option is an optimization that help nodes to synchronize 255 transmissions with each other, while allowing transmissions at any 256 time when necessary. Therefore, if the timing values sent in Router 257 Advertisement do not make sense for a host, or it's applications, the 258 values will be ignored. 260 8. References 262 8.1. Normative References 264 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 265 Requirement Levels", BCP 14, RFC 2119, March 1997. 267 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 268 More-Specific Routes", RFC 4191, November 2005. 270 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 271 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 272 September 2007. 274 8.2. Informative References 276 [Haverinen2007] 277 Henry Haverinen, Jonne Siren, and Pasi Eronen, "Energy 278 Consumption of Always-On Applications in WCDMA Networks", 279 April 2007. 281 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 282 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 283 RFC 4787, January 2007. 285 [RFC6059] Krishnan, S. and G. Daley, "Simple Procedures for 286 Detecting Network Attachment in IPv6", RFC 6059, 287 November 2010. 289 Authors' Addresses 291 Teemu Savolainen 292 Nokia 293 Hermiankatu 12 D 294 Helsinki FI-33720 295 Finland 297 Email: teemu.savolainen@nokia.com 299 Johanna Nieminen 300 Nokia 301 Itaemerenkatu 11-13 302 Helsinki FI-00180 303 Finland 305 Email: johanna.1.nieminen@nokia.com