idnits 2.17.1 draft-garneij-6man-nd-m2m-issues-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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([RFC4861], [RFC4862]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 4, 2014) is 3583 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC4861' is mentioned on line 100, but not defined == Missing Reference: 'RFC4862' is mentioned on line 100, but not defined == Unused Reference: 'RFC2434' is defined on line 294, but no explicit reference was found in the text == Unused Reference: '6LOWPAN-ND' is defined on line 298, but no explicit reference was found in the text == Unused Reference: 'ND' is defined on line 309, but no explicit reference was found in the text == Unused Reference: 'IPV6' is defined on line 315, but no explicit reference was found in the text == Unused Reference: 'AUTOCONF' is defined on line 318, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 2460 (ref. 'IPV6') (Obsoleted by RFC 8200) Summary: 4 errors (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6man WG F. Garneij 3 Internet-Draft S. Chakrabarti 4 Intended status: Informational S. Krishnan 5 Expires: January 5, 2015 Ericsson 6 July 4, 2014 8 Impact of IPv6 Neighbor Discovery on Cellular M2M Networks 9 draft-garneij-6man-nd-m2m-issues-00 11 Abstract 13 The use of IPv6 in 3GPP cellular broadband networks for accessing the 14 Internet and other data services like voice-over-LTE(VoLTE) has 15 increased greatly as a result of EPS network deployments worldwide 16 and new IPv6 capable smartphones and tablets. The upcoming rise of 17 IoT/M2M is anticipated to bring billions of new devices into these 18 networks and the majority of these devices will be using only IPv6. 19 This document discusses the EPS network impact of IoT/M2M IPv6 20 connectivity specifically targeting the IPv6 Stateless Address Auto 21 Configuration (SLAAC), as specified in [RFC4861] and [RFC4862], which 22 currently is the only supported IPv6 address configuration mechanism 23 in 3GPP standards. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on January 5, 2015. 42 Copyright Notice 44 Copyright (c) 2014 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Definition Of Terms . . . . . . . . . . . . . . . . . . . . 4 61 2. The M2M Scenario and IPv6 Neighbor Discovery Impact . . . . . . 5 62 3. Analysis of Results . . . . . . . . . . . . . . . . . . . . . . 6 63 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 64 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 5.1. Normative References . . . . . . . . . . . . . . . . . . . 7 66 5.2. Informative References . . . . . . . . . . . . . . . . . . 8 67 Appendix A. . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 70 1. Introduction 72 Several of the IPv6 core protocols make widespread use of multicast 73 messages as they wished to avoid broadcast messages. Unfortunately, 74 in practice, the multicast operation at many link layers the 75 degenerates into broadcast messages. 3GPP links are cellular links 76 consuming expensive and limited radio spectrum. Thus such radio 77 networks like to limit unnecessary signals in the network. IPv6 78 neighbor discovery is one of the core protocols required for the 79 operation of IPv6, and this document shows how it can affect the 80 cellular networks for M2M. M2M networks are usually low bandwidth 81 radio networks. 83 In 3GPP networks, mobility and connectivity is generated by the 84 arrangement of allocated radio resources and EPC node resources into 85 a PDN connection. The following list gives the logical functions 86 performed within the Evolved Packet System (EPS): 87 o Network Access Control Functions. 88 o Packet Routing and Transfer Functions 89 o Mobility Management Functions. 90 o Security Functions 91 o Radio Resource management functions 92 o Network Management Functions 94 For a User Equipment (UE) attached to a 3GPP network there are 95 procedures defined related to device mobility, EPS Mobility 96 Management (EMM) states and connectivity session, EPS Connectivity 97 Management (ECM) states as described in [TS.23401] Section 4.6. The 98 purpose of this document is to analyze the EPS resources impacted by 99 the procedures of the IPv6 Stateless Address Auto Configuration 100 (SLAAC), as specified in [RFC4861] and [RFC4862], as it is utilized 101 in 3GPP standards. Special attention is put on EPS control signaling 102 load and the packets destined to UE generated by IPv6 periodic Router 103 Advertisements (unsolicited multicast Router Advertisements). 3GPP 104 also specifies its own values and behavior for Router Advertisement 105 as described in 3GPP TS 29.061 Section 11.2.1.3.4 IPv6 Router 106 Configuration Variables. This 3GPP adaptation defines how to send 107 initial and periodic Router Advertisements in order to preserve radio 108 resources and UE power consumption while still allowing for 109 appropriate robustness and fast user-plane set-up time even in bad 110 radio conditions to the radio. 112 Since in EPS, radio and network resources are not permanently 113 assigned to a specific UE there is a cost associated with the 114 allocation and release of resources and associated changes of states 115 in EPS nodes. Thus, it is desirable to reduce or avoid any 116 additional periodic packets that are not of any use to the 117 application using the 3GPP derived UE connectivity. 2G and 3G radio 118 resource allocation have their own mechanisms with similar 119 functionality but these are not described or considered in this 120 document. The following M2M usecase scenario will clarify why 121 periodic RA in 3GPP networks are harmful in especially for the M2M 122 scenario. 124 Note that there are IETF informational guidelines for IPv6 usage in 125 3GPP EPS networks [RFC6459], but this draft requests an update in 126 Standard IPv6 Neighbor Discovery specification to disallow periodic 127 RAs. 129 1.1. Definition Of Terms 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 133 document are to be interpreted as described in [RFC2119]. 135 3GPP Terminology 137 Second Generation Mobile Telecommunications, such as Global System 138 for Mobile Communications (GSM) and GPRS technologies 140 Third Generation Mobile Telecommunications, such as UMTS 141 technology 143 Fourth Generation Mobile Telecommunications, such as LTE 144 technology. 145 3GPP 146 Third Generation Partnership Project. Throughout the document, 147 the term "3GPP networks" refers to architectures standardized by 148 3GPP, in Second, Third, and Fourth Generation releases: 99, 4, and 149 5, as well as future releases. 150 eNodeB 151 The eNodeB is a base station entity that supports the Long-Term 152 Evolution (LTE) radio interface. 153 EPS 154 Evolved packet System in LTE 155 GTP-U 156 GPRS Tunneling protocol for user plane 157 LTE 158 Long Term Evolution 3GPP Specification. It is a 4G mobile 159 communication specification. The network speed in LTE is up to 10 160 times faster than the 3G network 162 Paging 163 A 3GPP defined mechanism for finding the radio base station at 164 which a specific UE currently can be reached. 165 PDN Connection 166 The association between a UE represented by one IP address and/or 167 one IPv6 prefix and a Packet Data network(PDN) assosiated to an 168 Access Point Name(APN). 169 PGW or PDN GW 170 Packet Data Network Gateway (the default router for 3GPP IPv6 171 cellular hosts in EPS). 172 SGW or Serving GW 173 Serving Gateway: The user plane equivalent of a Serving GPRS 174 Support Node (SGSN) in EPS and the default router for 3GPP IPv6 175 cellular hosts when using Proxy Mobile IPv6 (PMIPv6). 176 MME 177 Mobility Management Entity 178 UE 179 User Equipment or host terminal 180 M2M 181 Machine to Machine Communication networks and related standards. 182 M2M includes industrial networks and communication. M2M uses IPv6 183 as dataplane. 185 2. The M2M Scenario and IPv6 Neighbor Discovery Impact 187 The analysis considers an IoT/M2M UE deployment scenario with 188 infrequent packet communications occurrences than would normally be 189 seen in an interactive device such as a smartphone. Given such an 190 infrequent communication pattern, the UE is highly likely be in IDLE 191 ECM state when a downlink packet is sent from the PGW or the SGW. 192 Sending a packet to the UE while in ECM IDLE state triggers a paging 193 process followed by a UE Service Request and radio resource 194 allocation. These procedures are considered as among the heavier 195 procedures in EPS with regards to control signaling load and node 196 state changes. They cause increased utilization of the radio 197 interface as well as increased processing loads in the nodes involved 198 in the procedures. It is also likely that other devices with 199 different communications usage patterns like smartphones may compete 200 over network resources causing the procedure to be repeated in order 201 to complete. Thus, unnecessary control signals such as periodic RA 202 causes paging and waste of radio resources in cellular networks. 204 The M2M use case below considers the following network dimensioning 205 for a single PGW node based on information derived from real world 206 network deployment best practices: 208 o There are 10,000,000 simultaneous IPv6 connections to IoT/M2M 209 devices from PGW. There are no dedicated bearers available. 210 Communication direction for IoT/M2M service is from network to UE 211 infrequent (e.g. twice a day or less). GTP-U is used between PGW 212 and SGW as described in TS.23401 of 3GPP specification. The 213 following list shows the condition of the network, number of 214 resources and UE behavior in a typical 10M IPv6 connection-based 215 M2M network. 216 o If EPS Connectivity Management (ECM) state is ECM_IDLE, paging 217 will be triggered when a packet is received by the UE 218 o Each Tracking Area (TA) contains 100 base stations (eNodeB) 219 o MME UE Tracking Area Identifier (TAI) list containing 10 TA which 220 gives 10 * 100 eNodeB = 1000 eNodeB for a UE TAI list 221 o The MaxRtrAdvInterval configuration of RFC4861 has been set to its 222 maximum allowed value to minimize unsolicited multicast RAs 224 Based on the above data, the following analysis has been done. The 225 analysis focuses on the connectivity state changes and resource 226 allocation related to 1) Packet Routing and Transfer Functions 2) 227 Mobility Management Functions 3) Radio Resource Management Functions 229 3. Analysis of Results 231 The unsolicited mulicast RAs are sent at randomized intervals based 232 on a timer that is set to uniformly distributed random values between 233 the interface's configured MinRtrAdvInterval and MaxRtrAdvInterval as 234 described in Section 6.2.4. of RFC4861. We assume maximum possible 235 values for MinRtrAdvInterval and MaxRtrAdvInterval in order to 236 discover the *best-case* scenario. 238 MaxRtrAdvInterval = 1800 seconds 239 MinRtrAdvInterval = 0.75 * 1800 = 1350 seconds 240 Average RA interval = (1800 + 1350) / 2 = 1575 seconds 241 RAs/second = number of nodes/average RA interval 242 = 10e7/1575 = 6349 244 If the periodic router advertisements are allowed in the network, the 245 measurement result shows that approximately 6300 Router advertisement 246 packets can be sent to the eNodeB(base station) from the Edge Router/ 247 Gateway device(PGW). And there is ~100 to ~1000 state changes per 248 second for MME, eNodeB, UE in the network. 250 If we assume there are 1000 base stations (eNodeBs) in the network 251 there will be approximately 6.3 million paging messages per second as 252 each unsolicited RA will initiate paging on each eNodeB. Each of 253 these RAs will also trigger state changes in the MME, the SGW, the 254 eNodeB and the UE radio bearer. There will be approximately 50000 255 (12600*4) state changes per second in the network. This causes 256 significant increases in processing power as well as network traffic. 257 This will cause serious issues to network operators. This 258 illustrates the point is that even when unsolicited multicast RAs are 259 fairly infrequent, there is a huge effect on the M2M/IOT 3GPP 260 networks. 262 It has been shown that a single unsolicited downlink packet can 263 consume energy and bandwidth and ties up resources in the EPS network 264 and UE. It is desirable to free up the 3GPP networks from such 265 periodic signaling traffic (in this case IPv6 ND) so that energy and 266 bandwith can be saved and the saved energy and bandwidth can be used 267 for actual data traffic destined to users. Given the result above 268 the unsolicited RA traffic generated by the PGW is roughly equal to 269 the effort needed to poll all 53 million UK gas and electricity 270 meters once a day. If it amuses the reader, the number of 271 unsolicited RA sent by the PGWs connecting the IPv6-only UK smart 272 meters during a day can easliy be derived using the data in this 273 document. 275 Since all the UE are known to the PGW which acts as their default 276 router and packets to one UE to another go via PGW in many 277 deployments, the Address Registration Method(ARO) described in 278 [efficient-nd] is quite useful for reducing/avoiding periodic RA and 279 having the PGW or SGW keeping track of the UE registration status for 280 selectively exchanging the IPv6 Neighbor Discovery messages. In 281 addition the Address Registration Method(ARO) allows the PGW to learn 282 the IPv6 address that is used by the UE which is not possible using 283 currently defined 3GPP usage of SLAAC. 285 4. Acknowledgements 287 5. References 289 5.1. Normative References 291 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 292 Requirement Levels", BCP 14, RFC 2119, March 1997. 294 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 295 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 296 October 1998. 298 [6LOWPAN-ND] 299 Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann, 300 "ND Optimizations for 6LoWPAN", RFC 6775, November 2012. 302 [efficient-nd] 303 Chakrabarti, S., Nordmark, E., Thubert, P., and M. 304 Wasserman, "IPv6 Neighbor Discovery Optimizations for 305 Wired and Wireless Networks", 306 draft-chakrabarti-nordmark-6man-efficient-nd-05 (work in 307 progress), February 2014. 309 [ND] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 310 "Neighbor Discovery for IP version 6", RFC 4861, 311 September 2007. 313 5.2. Informative References 315 [IPV6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 316 (IPv6), Specification", RFC 2460, December 1998. 318 [AUTOCONF] 319 Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 320 Autoconfiguration", RFC 4862, September 2007. 322 [RFC6459] Korhonen, J., "IPv6 in 3rd Generation Partnership Project 323 (3GPP) Evolved Packet System (EPS)", RFC 6459, 324 January 2012. 326 Appendix A. 328 Authors' Addresses 330 Fredrik Garneij 331 Ericsson 332 Sweden 334 Email: fredrik.garneij@ericsson.com 336 Samita Chakrabarti 337 Ericsson 338 USA 340 Email: samita.chakrabarti@ericsson.com 341 Suresh Krishnan 342 Ericsson 343 8400 Decarie Blvd. 344 Town of Mount Royal, QC 345 Canada 347 Phone: +1 514 345 7900 x42871 348 Email: suresh.krishnan@ericsson.com