idnits 2.17.1 draft-ietf-intarea-adhoc-wireless-com-02.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 (July 20, 2016) is 2836 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- 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 Area E. Baccelli 3 Internet-Draft INRIA 4 Intended status: Informational C. Perkins 5 Expires: January 21, 2017 Futurewei 6 July 20, 2016 8 Multi-hop Ad Hoc Wireless Communication 9 draft-ietf-intarea-adhoc-wireless-com-02 11 Abstract 13 This document describes characteristics of communication between 14 interfaces in a multi-hop ad hoc wireless network, that protocol 15 engineers and system analysts should be aware of when designing 16 solutions for ad hoc networks at the IP layer. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on January 21, 2017. 35 Copyright Notice 37 Copyright (c) 2016 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Multi-hop Ad Hoc Wireless Networks . . . . . . . . . . . . . 2 54 3. Common Packet Transmission Characteristics in 55 Multi-hop Ad Hoc Wireless Networks . . . . . . . . . . . . . 3 56 3.1. Asymmetry, Time-Variation, and Non-Transitivity . . . . . 4 57 3.2. Radio Range and Wireless Irregularities . . . . . . . . . 5 58 4. Alternative Terminology . . . . . . . . . . . . . . . . . . . 7 59 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 60 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 61 7. Informative References . . . . . . . . . . . . . . . . . . . 9 62 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 12 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 65 1. Introduction 67 Experience gathered with ad hoc routing protocol development, 68 deployment and operation, shows that wireless communication presents 69 specific challenges [RFC2501] [DoD01], which Internet protocol 70 designers should be aware of, when designing solutions for ad hoc 71 networks at the IP layer. This document does not prescribe 72 solutions, but instead briefly describes these challenges in hopes of 73 increasing that awareness. 75 As background, RFC 3819 [RFC3819] provides an excellent reference for 76 higher-level considerations when designing protocols for shared 77 media. From MTU to subnet design, from security to considerations 78 about retransmissions, RFC 3819 provides guidance and design 79 rationale to help with many aspects of higher-level protocol design. 81 The present document focuses more specifically on challenges in 82 multi-hop ad hoc wireless networking. For example, in that context, 83 even though a wireless link may experience high variability as a 84 communications channel, such variation does not mean that the link is 85 "broken". Many layer-2 technologies serve to reduce error rates by 86 various means. Nevertheless, such errors as noted in this document 87 may still become visible above layer-2 and so become relevant to the 88 operation of higher layer protocols. 90 2. Multi-hop Ad Hoc Wireless Networks 92 For the purposes of this document, a multi-hop ad hoc wireless 93 network will be considered to be a collection of devices that each 94 have at least one radio transceiver (i.e., wireless network 95 interface), and that are moreover configured to self-organize and 96 provide store-and-forward functionality as needed to enable 97 communications. This document focuses on the characteristics of 98 communications through such a network interface. 100 Although the characteristics of packet transmission over multi-hop ad 101 hoc wireless networks, described below, are not the typical 102 characteristics expected by IP [RFC6250], it is desirable and 103 possible to run IP over such networks, as demonstrated in certain 104 deployments currently in operation, such as Freifunk [FREIFUNK], and 105 Funkfeuer [FUNKFEUER]. These deployments use routers running IP 106 protocols e.g., OLSR (Optimized Link State Routing [RFC3626]) on top 107 of IEEE 802.11 in ad hoc mode with the same ESSID (Extended Service 108 Set Identification) at the link layer. Multi-hop ad hoc wireless 109 networks may also run on link layers other than IEEE 802.11, and may 110 use routing protocols other than OLSR. The following documents 111 provide a number of examples: AODV [RFC3561], OLSRv2 [RFC7181], TBRPF 112 [RFC3684], OSPF ([RFC5449], [RFC5820] and [RFC7137]), or DSR 113 [RFC4728]. 115 Note that in contrast, devices communicating via an IEEE 802.11 116 access point in infrastructure mode do not form a multi-hop ad hoc 117 wireless network, since the central role of the access point is 118 predetermined, and devices other than the access point do not 119 generally provide store-and-forward functionality. 121 3. Common Packet Transmission Characteristics in Multi-hop Ad Hoc 122 Wireless Networks 124 In the following, we will consider several devices in a multi-hop ad 125 hoc wireless network N. Each device will be considered only through 126 its own wireless interface to network N. For conciseness and 127 readability, this document uses the expressions "device A" (or simply 128 "A") as a synonym for "the wireless interface of device A to network 129 N". 131 Let A and B be two devices in network N. Suppose that, when device A 132 transmits an IP packet through its interface on network N, that 133 packet is correctly and directly received by device B without 134 requiring storage and/or forwarding by any other device. We will 135 then say that B can "detect" A. Note that therefore, when B detects 136 A, an IP packet transmitted by A will be rigorously identical to the 137 corresponding IP packet received by B. 139 Let S be the set of devices that detect device A through its wireless 140 interface on network N. The following section gathers common 141 characteristics concerning packet transmission over such networks, 142 which were observed through experience with MANET routing protocol 143 development (for instance, OLSR[RFC3626], AODV[RFC3561], 144 TBRPF[RFC3684], DSR[RFC4728], and OSPF-MPR[RFC5449]), as well as 145 deployment and operation (e.g., Freifunk[FREIFUNK], 146 Funkfeuer[FUNKFEUER]). 148 3.1. Asymmetry, Time-Variation, and Non-Transitivity 150 First, even though a device C in set S can (by definition) detect 151 device A, there is no guarantee that C can, conversely, send IP 152 packets directly to A. In other words, even though C can detect A 153 (since it is a member of set S), there is no guarantee that A can 154 detect C. Thus, multi-hop ad hoc wireless communications may be 155 "asymmetric". Such cases are common. 157 Second, there is no guarantee that, as a set, S is at all stable, 158 i.e. the membership of set S may in fact change at any rate, at any 159 time. Thus, multi-hop ad hoc wireless communications may be "time- 160 variant". Time variation is often observed in multi-hop ad hoc 161 wireless networks due to variability of the wireless medium, and to 162 device mobility. 164 Now, conversely, let V be the set of devices which A detects. 165 Suppose that A is communicating at time t0 through its interface on 166 network N. As a consequence of time variation and asymmetry, we 167 observe that A: 169 1. cannot assume that S = V, and 171 2. cannot assume that S and/or V are unchanged at time t1 later than 172 t0. 174 Furthermore, transitivity is not guaranteed over multi-hop ad hoc 175 wireless networks. Suppose that, through their respective interfaces 176 within network N: 178 1. device B and device A can detect one another (i.e. B is a member 179 of sets S and V), and, 181 2. device A and device C can also detect one another (i.e. C is a 182 also a member of sets S and V). 184 These assumptions do not imply that B can detect C, nor that C can 185 detect B (through their interface on network N). Such "non- 186 transitivity" is common on multi-hop ad hoc wireless networks. 188 In summary: multi-hop ad hoc wireless communications can be 189 asymmetric, non-transitive, and time-varying. 191 3.2. Radio Range and Wireless Irregularities 193 Section 3.1 presents an abstract description of some common 194 characteristics concerning packet transmission over multi-hop ad hoc 195 wireless networks. This section describes practical examples, which 196 illustrate the characteristics listed in Section 3.1 as well as other 197 common effects. 199 Wireless communications are particularly subject to limitations on 200 the distance across which they may be established. The range- 201 limitation factor creates specific problems on multi-hop ad hoc 202 wireless networks. Due to the lack of isolation between the 203 transmitters, the radio ranges of several devices often partially 204 overlap, causing communication to be non-transitive and/or asymmetric 205 as described in Section 3.1. Moreover, the range of each device may 206 depend on location and environmental factors. This is in addition to 207 possible time variations of range and signal strength. 209 For example it may happen that a device B detects a device A which 210 transmits at high power, whereas B transmits at lower power. In such 211 cases, as depicted in Figure 1, B can detect A, but A cannot detect 212 B. This exemplifies asymmetry in wireless communications as defined 213 in Section 3.1. 215 Radio Range for Device A 216 <~~~~~~~~~~~~~+~~~~~~~~~~~~~> 217 | Range for Device B 218 | <~~~~~~+~~~~~~> 219 +--|--+ +--|--+ 220 | A |======>| B | 221 +-----+ +-----+ 223 Figure 1: Asymmetric Wireless Communication 225 Another example, depicted in Figure 2, is known as the "Hidden 226 Terminal" problem. Even though the devices all have equal power for 227 their radio transmissions, they cannot all detect one another. In 228 the figure, devices A and B can detect one another, and devices A and 229 C can also detect one another. Nevertheless, B and C cannot detect 230 one another. When B and C simultaneously try to communicate with A, 231 their radio signals collide. Device A may then receive incoherent 232 noise, and may even be unable to determine the source of the noise. 233 The hidden terminal problem is a consequence of the property of non- 234 transitivity in multi-hop ad hoc wireless communications as described 235 in Section 3.1. 237 Radio Range for Device B Radio Range for Device C 238 <~~~~~~~~~~~~~+~~~~~~~~~~~~~> <~~~~~~~~~~~~~+~~~~~~~~~~~~~> 239 | Radio Range for Device A | 240 |<~~~~~~~~~~~~~+~~~~~~~~~~~~~>| 241 +--+--+ +--+--+ +--+--+ 242 | B |=======>| A |<=======| C | 243 +-----+ +-----+ +-----+ 245 Figure 2: Hidden Terminal Problem 247 Another situation, shown in Figure 3, is known as the "Exposed 248 Terminal" problem. In the figure, device A and device B can detect 249 each other, and A is transmitting packets to B, thus A cannot detect 250 device C -- but C can detect A. As shown in Figure 3, during the on- 251 going transmission of A, device C cannot reliably communicate with 252 device D because of interference within C's radio range due to A's 253 transmissions. Device C is then said to be "exposed", because it is 254 exposed to co-channel interference from A and is thereby prevented 255 from reliably exchanging protocol messages with D -- even though 256 these transmissions would not interfere with the reception of data 257 sent from A destined to B. 259 Range for Device B Range for Device C 260 <~~~~~~~~~~~~+~~~~~~~~~~~~> <~~~~~~~~~~+~~~~~~~~~~~> 261 | Range for Device A | Range for Device D 262 |<~~~~~~~~~~~~+~~~~~~~~~~~~>|<~~~~~~~~~~~~+~~~~~~~~~> 263 +--|--+ +--|--+ +--|--+ +--|--+ 264 | B |<======| A | | C |======>| D | 265 +-----+ +-----+ +-----+ +-----+ 267 Figure 3: Exposed Terminal Problem 269 Hidden and exposed terminal situations are often observed in multi- 270 hop ad hoc wireless networks. Asymmetry issues with wireless 271 communication may also arise for reasons other than power inequality 272 (e.g., multipath interference). Such problems are often resolved by 273 specific mechanisms below the IP layer; CSMA/CA, for example, 274 requires that the physical medium be unoccupied from the point of 275 view of both devices before starting transmission. Nevertheless, 276 depending on the link layer technology in use and the position of the 277 devices, such problems may affect the IP layer due to range 278 limitation and partial overlap. 280 Besides radio range limitations, wireless communications are affected 281 by irregularities in the shape of the geographical area over which 282 devices may effectively communicate (see for instance [MC03], 284 [MI03]). For example, even omnidirectional wireless transmission is 285 typically non-isotropic (i.e. non-circular). Signal strength often 286 suffers frequent and significant variations, which do not have a 287 simple dependence on distance. Instead, the dependence is a complex 288 function of the environment including obstacles, weather conditions, 289 interference, and other factors that change over time. Because 290 wireless communications often encounter different terrain, path, 291 obstructions, atmospheric conditions and other phenomena, analytical 292 formulation of signal strength is considered intractable [VTC99]. 293 The radio engineering community has developed numerous radio 294 propagation approximations, relying on median values observed in 295 specific environments [SAR03]. 297 These irregularities cause communications on multi-hop ad hoc 298 wireless networks to be non-transitive, asymmetric, or time-varying, 299 as described in Section 3.1, and may impact protocols at the IP layer 300 and above. There may be no indication to the IP layer when a 301 previously established communication channel becomes unusable; "link 302 down" triggers are often absent in multi-hop ad hoc wireless 303 networks, since the absence of detectable radio energy (e.g., in 304 carrier waves) may simply indicate that neighboring devices are not 305 currently transmitting. 307 4. Alternative Terminology 309 Many terms have been used in the past to describe the relationship of 310 devices in a multi-hop ad hoc wireless network based on their ability 311 to send or receive packets to/from each other. The terms used in 312 previous sections of this document have been selected because the 313 authors believe they are unambiguous, with respect to the goal of 314 this document as formulated in Section 1. 316 In this section, we exhibit some other terms that describe the same 317 relationship between devices in multi-hop ad hoc wireless networks. 318 In the following, let network N be, again, a multi-hop ad hoc 319 wireless network. Let the set S be, as before, the set of devices 320 that can directly receive packets transmitted by device A through its 321 interface on network N. In other words, any device B belonging to S 322 can detect packets transmitted by A. Then, due to the asymmetric 323 nature of wireless communications: 325 - We may say that device A "reaches" device B. In this 326 terminology, there is no guarantee that B reaches A, even if A 327 reaches B. 329 - We may say that device B "hears" device A. In this terminology, 330 there is no guarantee that A hears B, even if B hears A. 332 - We may say that device A "has a link" to device B. In this 333 terminology, there is no guarantee that B has a link to A, even if 334 A has a link to B. 336 - We may say that device B "is adjacent to" device A. In this 337 terminology, there is no guarantee that A is adjacent to B, even 338 if B is adjacent to A. 340 - We may say that device B "is downstream from" device A. In this 341 terminology, there is no guarantee that A is downstream from B, 342 even if B is downstream from A. 344 - We may say that device B "is a neighbor of" device A. In this 345 terminology, there is no guarantee that A is a neighbor of B, even 346 if B a neighbor of A. Terminology based on "neighborhood" is 347 quite confusing for multi-hop wireless communications. For 348 example, when B can detect A, but A cannot detect B, it is not 349 clear whether or not B should be considered a neighbor of A; A 350 would not necessarily be aware that B was a neighbor, as it cannot 351 detect B. It is thus best to avoid the "neighbor" terminology, 352 except when bidirectionality has been established. 354 This list of alternative terminologies is given here for illustrative 355 purposes only, and is not suggested to be complete or even 356 representative of the breadth of terminologies that have been used in 357 various ways to explain the properties mentioned in Section 3. Note 358 that bidirectionality is not synonymous with symmetry. For example, 359 the error statistics in either direction are often different for a 360 link that is otherwise considered bidirectional. 362 5. Security Considerations 364 Section 18 of RFC 3819 [RFC3819] provides an excellent overview of 365 security considerations at the subnetwork layer. Beyond the material 366 there, multi-hop ad hoc wireless networking (i) is not limited to 367 subnetwork layer operation, and (ii) makes use of wireless 368 communications. 370 On one hand, a detailed description of security implications of 371 wireless communications in general is outside of the scope of this 372 document. It is true that eavesdropping on a wireless link is much 373 easier than for wired media (although significant progress has been 374 made in the field of wireless monitoring of wired transmissions). As 375 a result, traffic analysis attacks can be even more subtle and 376 difficult to defeat in this context. Furthermore, such 377 communications over a shared media are particularly prone to theft of 378 service and denial of service (DoS) attacks. 380 On the other hand, the potential multi-hop aspect of the networks we 381 consider in this document goes beyond traditional scope of subnetwork 382 design. In practice, unplanned relaying of network traffic (both 383 user traffic and control traffic) happens routinely. Due to the 384 physical nature of wireless media, Man in the Middle (MITM) attacks 385 are facilitated, which may significantly alter network performance. 386 This highlights the importance of the "end-to-end principle": L3 387 security, end-to-end, becomes a primary goal, independently of 388 securing layer-2 and layer-1 protocols (though L2 and L1 security 389 often help to reach this goal). 391 6. IANA Considerations 393 This document does not have any IANA actions. 395 7. Informative References 397 [RFC2501] Corson, S. and J. Macker, "Mobile Ad hoc Networking 398 (MANET): Routing Protocol Performance Issues and 399 Evaluation Considerations", RFC 2501, 400 DOI 10.17487/RFC2501, January 1999, 401 . 403 [RFC3561] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On- 404 Demand Distance Vector (AODV) Routing", RFC 3561, 405 DOI 10.17487/RFC3561, July 2003, 406 . 408 [RFC3626] Clausen, T., Ed. and P. Jacquet, Ed., "Optimized Link 409 State Routing Protocol (OLSR)", RFC 3626, 410 DOI 10.17487/RFC3626, October 2003, 411 . 413 [RFC3684] Ogier, R., Templin, F., and M. Lewis, "Topology 414 Dissemination Based on Reverse-Path Forwarding (TBRPF)", 415 RFC 3684, DOI 10.17487/RFC3684, February 2004, 416 . 418 [RFC3819] Karn, P., Ed., Bormann, C., Fairhurst, G., Grossman, D., 419 Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. 420 Wood, "Advice for Internet Subnetwork Designers", BCP 89, 421 RFC 3819, DOI 10.17487/RFC3819, July 2004, 422 . 424 [RFC4728] Johnson, D., Hu, Y., and D. Maltz, "The Dynamic Source 425 Routing Protocol (DSR) for Mobile Ad Hoc Networks for 426 IPv4", RFC 4728, DOI 10.17487/RFC4728, February 2007, 427 . 429 [RFC5449] Baccelli, E., Jacquet, P., Nguyen, D., and T. Clausen, 430 "OSPF Multipoint Relay (MPR) Extension for Ad Hoc 431 Networks", RFC 5449, DOI 10.17487/RFC5449, February 2009, 432 . 434 [RFC5820] Roy, A., Ed. and M. Chandra, Ed., "Extensions to OSPF to 435 Support Mobile Ad Hoc Networking", RFC 5820, 436 DOI 10.17487/RFC5820, March 2010, 437 . 439 [RFC6250] Thaler, D., "Evolution of the IP Model", RFC 6250, 440 DOI 10.17487/RFC6250, May 2011, 441 . 443 [RFC7137] Retana, A. and S. Ratliff, "Use of the OSPF-MANET 444 Interface in Single-Hop Broadcast Networks", RFC 7137, 445 DOI 10.17487/RFC7137, February 2014, 446 . 448 [RFC7181] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg, 449 "The Optimized Link State Routing Protocol Version 2", 450 RFC 7181, DOI 10.17487/RFC7181, April 2014, 451 . 453 [DoD01] Freebersyser, J. and B. Leiner, "A DoD perspective on 454 mobile ad hoc networks", Addison Wesley C. E. Perkins, 455 Ed., 2001, pp. 29--51, 2001. 457 [FUNKFEUER] 458 "Austria Wireless Community Network, 459 http://www.funkfeuer.at", 2013. 461 [MC03] Corson, S. and J. Macker, "Mobile Ad hoc Networking: 462 Routing Technology for Dynamic, Wireless Networks", IEEE 463 Press Mobile Ad hoc Networking, Chapter 9, 2003. 465 [SAR03] Sarkar, T., Ji, Z., Kim, K., Medour, A., and M. Salazar- 466 Palma, "A Survey of Various Propagation Models for Mobile 467 Communication", IEEE Press Antennas and Propagation 468 Magazine, Vol. 45, No. 3, 2003. 470 [VTC99] Kim, D., Chang, Y., and J. Lee, "Pilot power control and 471 service coverage support in CDMA mobile systems", IEEE 472 Press Proceedings of the IEEE Vehicular Technology 473 Conference (VTC), pp.1464-1468, 1999. 475 [MI03] Kotz, D., Newport, C., and C. Elliott, "The Mistaken 476 Axioms of Wireless-Network Research", Dartmouth College 477 Computer Science Technical Report TR2003-467, 2003. 479 [FREIFUNK] 480 "Freifunk Wireless Community Networks, 481 http://www.freifunk.net", 2013. 483 Appendix A. Acknowledgements 485 This document stems from discussions with the following people, in 486 alphabetical order: Jari Arkko, Teco Boot, Brian Carpenter, Carlos 487 Jesus Bernardos Cano, Zhen Cao, Ian Chakeres, Thomas Clausen, Robert 488 Cragie, Christopher Dearlove, Ralph Droms, Brian Haberman, Ulrich 489 Herberg, Paul Lambert, Kenichi Mase, Thomas Narten, Erik Nordmark, 490 Alexandru Petrescu, Stan Ratliff, Zach Shelby, Shubhranshu Singh, 491 Fred Templin, Dave Thaler, Mark Townsley, Ronald Velt in't, and Seung 492 Yi. 494 Authors' Addresses 496 Emmanuel Baccelli 497 INRIA 499 EMail: Emmanuel.Baccelli@inria.fr 500 URI: http://www.emmanuelbaccelli.org/ 502 Charles E. Perkins 503 Futurewei 505 Phone: +1-408-330-4586 506 EMail: charlie.perkins@huawei.com