idnits 2.17.1 draft-ietf-manet-issues-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-03-28) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard 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 document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 1998) is 9510 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) == Unused Reference: '1' is defined on line 426, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1677 (ref. '1') Summary: 10 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft S. Corson 2 Expiration: September 1998 University of Maryland 3 File: draft-ietf-manet-issues-01.txt J. Macker 4 Naval Research Laboratory 5 March 1998 7 Mobile Ad hoc Networking (MANET): 8 Routing Protocol Performance Issues and Evaluation Considerations 10 Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet- Drafts as reference 20 material or to cite them other than as "work in progress." 22 To view the entire list of current Internet-Drafts, please check 23 the "1id-abstracts.txt" listing contained in the Internet-Drafts 24 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 25 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 26 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 27 (US West Coast). 29 Distribution of this memo is unlimited. 31 Abstract 33 This memo first describes the characteristics of Mobile Ad hoc 34 Networks (MANETs), and their idiosyncrasies with respect to 35 traditional, hardwired packet networks. It then discusses the effect 36 these differences have on the design and evaluation of network 37 control protocols with an emphasis on routing performance evaluation 38 considerations. 40 1. Introduction 42 With recent performance advancements in computer and wireless 43 communications technologies, advanced mobile wireless computing is 44 expected to see increasingly widespread use and application, much of 45 which will involve the use of the Internet Protocol (IP) suite. The 46 vision of mobile ad hoc networking is to support robust and efficient 47 operation in mobile wireless networks by incorporating routing 48 functionality into mobile nodes. Such networks are envisioned to 49 have dynamic, sometimes rapidly-changing, random, multihop topologies 50 which are likely composed of relatively bandwidth-constrained 51 wireless links. 53 Within the Internet community, routing support for mobile hosts is 54 presently being formulated as "mobile IP" technology. This is a 55 technology to support nomadic host "roaming", where a roaming host 56 may be connected through various means to the Internet other than its 57 well known fixed-address domain space. The host may be directly 58 physically connected to the fixed network on a foreign subnet, or be 59 connected via a wireless link, dial-up line, etc. Supporting this 60 form of host mobility (or nomadicity) requires address management, 61 protocol interoperability enhancements and the like, but core network 62 functions such as hop-by-hop routing still presently rely upon pre- 63 existing routing protocols operating within the fixed network. In 64 contrast, the goal of mobile ad hoc networking is to extend mobility 65 into the realm of autonomous, mobile, wireless domains, where a set 66 of nodes--which may be combined routers and hosts--themselves form 67 the network routing infrastructure in an ad hoc fashion. 69 2. Applications 71 The technology of Mobile Ad hoc Networking is somewhat synonymous 72 with Mobile Packet Radio Networking (a term coined via during early 73 military research in the 70's and 80's), Mobile Mesh Networking (a 74 term that appeared in an article in The Economist regarding the 75 structure of future military networks) and Mobile, Multihop, Wireless 76 Networking (perhaps the most accurate term, although a bit 77 cumbersome). 79 There is current and future need for dynamic ad hoc networking 80 technology. The emerging field of mobile and nomadic computing, with 81 its current emphasis on mobile IP operation, should gradually broaden 82 and require highly-adaptive mobile networking technology to 83 effectively manage multihop, ad hoc network clusters which can 84 operate autonomously or, more than likely, be attached at some 85 point(s) to the fixed Internet. 87 Some applications of MANET technology could include industrial and 88 commercial applications involving cooperative mobile data exchange. 89 In addition, mesh-based mobile networks can be operated as robust, 90 inexpensive alternatives or enhancements to cell-based mobile network 91 infrastructures. There are also existing and future military 92 networking requirements for robust, IP-compliant data services within 93 mobile wireless communication networks [1]--many of these networks 94 consist of highly-dynamic autonomous topology segments. Also, the 95 developing technologies of "wearable" computing and communications 96 may provide applications for MANET technology. When properly combined 97 with satellite-based information delivery, MANET technology can 98 provide an extremely flexible method for establishing communications 99 for fire/safety/rescue operations or other scenarios requiring 100 rapidly-deployable communications with survivable, efficient dynamic 101 networking. There are likely other applications for MANET technology 102 which are not presently realized or envisioned by the authors. It 103 is, simply put, improved IP-based networking technology for dynamic, 104 autonomous wireless networks. 106 3. Characteristics of MANETs 108 A MANET consists of mobile platforms (e.g., a router with multiple 109 hosts and wireless communications devices)--herein simply referred to 110 as "nodes"--which are free to move about arbitrarily. The nodes may 111 be located in or on airplanes, ships, trucks, cars, perhaps even on 112 people or very small devices, and there may be multiple hosts per 113 router. A MANET is an autonomous system of mobile nodes. The system 114 may operate in isolation, or may have gateways to and interface with 115 a fixed network. In the latter operational mode, it is typically 116 envisioned to operate as a "stub" network connecting to a fixed 117 internetwork. Stub networks carry traffic originating at and/or 118 destined for internal nodes, but do not permit exogenous traffic to 119 "transit" through the stub network. 121 MANET nodes are equipped with wireless transmitters and receivers 122 using antennas which may be omnidirectional (broadcast), highly- 123 directional (point-to-point), possibly steerable, or some combination 124 thereof. At a given point in time, depending on the nodes' positions 125 and their transmitter and receiver coverage patterns, transmission 126 power levels and co-channel interference levels, a wireless 127 connectivity in the form of a random, multihop graph or "ad hoc" 128 network exists between the nodes. This ad hoc topology may change 129 with time as the nodes move or adjust their transmission and 130 reception parameters. 132 MANETs have several salient characteristics: 134 1) Dynamic topologies: Nodes are free to move arbitrarily; thus, 135 the network topology--which is typically multihop--may change 136 randomly and rapidly at unpredictable times, and may consist of 137 both bidirectional and unidirectional links. 139 2) Bandwidth-constrained, variable capacity links: Wireless links 140 will continue to have significantly lower capacity than their 141 hardwired counterparts. In addition, the realized throughput of 142 wireless communications--after accounting for the effects of 143 multiple access, fading, noise, and interference conditions, 144 etc.--is often much less than a radio's maximum transmission rate. 146 One effect of the relatively low to moderate link capacities is 147 that congestion is typically the norm rather than the exception, 148 i.e. aggregate application demand will likely approach or exceed 149 network capacity frequently. As the mobile network is often simply 150 an extension of the fixed network infrastructure, mobile ad hoc 151 users will demand similar services. These demands will continue to 152 increase as multimedia computing and collaborative networking 153 applications rise. 155 3) Energy-constrained operation: Some or all of the nodes in a 156 MANET may rely on batteries or other exhaustible means for their 157 energy. For these nodes, the most important system design criteria 158 for optimization may be energy conservation. 160 4) Limited physical security: Mobile wireless networks are 161 generally more prone to physical security threats than are fixed- 162 cable nets. The increased possibility of eavesdropping, spoofing, 163 and denial-of-service attacks should be carefully considered. 164 Existing link security techniques are often applied within 165 wireless networks to reduce security threats. As a benefit, the 166 decentralized nature of network control in MANETs provides 167 additional robustness against the single points of failure of more 168 centralized approaches. 170 In addition, some envisioned networks (e.g. mobile military networks 171 or highway networks) may be relatively large (e.g. tens or hundreds 172 of nodes per routing area). The need for scalability is not unique 173 to MANETS. However, in light of the preceding characteristics, the 174 mechanisms required to achieve scalability likely are. 176 These characteristics create a set of underlying assumptions and 177 performance concerns for protocol design which extend beyond those 178 guiding the design of routing within the higher-speed, semi-static 179 topology of the fixed Internet. 181 4. Goals of IETF Mobile Ad Hoc Network (manet) Working Group 183 The intent of the newly formed IETF manet working group is to develop 184 a peer-to-peer mobile routing capability in a purely mobile, wireless 185 domain. This capability will exist beyond the fixed network (as 186 supported by traditional IP networking) and beyond the one-hop fringe 187 of the fixed network. 189 The near-term goal of the manet working group is to standardize one 190 (or more) intra-domain unicast routing protocol(s) or mode(s), and 191 related network-layer support technology which: 193 * provides for effective operation over a wide range of mobile 194 networking "contexts" (a context is a set of characteristics 195 describing a mobile network and its environment); 197 * provides a standard "protocol or mode discovery" algorithm so 198 that newly-arriving nodes may learn the mode in which a given 199 MANET is operating; 201 * supports traditional, connectionless IP service; 203 * reacts efficiently to topological changes and traffic demands 204 while maintaining effective routing in a mobile networking 205 context. 207 The working group will also consider issues pertaining to addressing, 208 security, and interaction/interfacing with lower and upper layer 209 protocols. In the longer term, the group may look at the issues of 210 layering more advanced mobility services on top of the initial 211 unicast routing developed. These longer term issues will likely 212 include investigating multicast and QoS extensions for a dynamic, 213 mobile area. 215 5. IP-Layer Mobile Routing 217 An improved mobile routing capability at the IP layer can provide a 218 benefit similar to the intention of the original Internet, viz. "an 219 interoperable internetworking capability over a heterogeneous 220 networking infrastructure". In this case, the infrastructure is 221 wireless, rather than hardwired, consisting of multiple wireless 222 technologies, channel access protocols, etc. Improved IP routing and 223 related networking services provide the glue to preserve the 224 integrity of the mobile internetwork segment in this more dynamic 225 environment. 227 In other words, a real benefit to using IP-level routing in a MANET 228 is to provide network-level consistency for multihop networks 229 composed of nodes using a *mixture* of physical-layer media; i.e. a 230 mixture of what are commonly thought of as subnet technologies. A 231 MANET node principally consists of a router, which may be physically 232 attached to multiple IP hosts (or IP-addressable devices), which has 233 potentially *multiple* wireless interfaces--each interface using a 234 *different* wireless technology. Thus, a MANET node with interfaces 235 using technologies A and B can communicate with any other MANET node 236 possessing an interface with technology A or B. The multihop 237 connectivity of technology A forms a physical-layer multihop 238 topology, the multihop connectivity of technology B forms *another* 239 physical-layer topology (which may differ from that of A's topology), 240 and the *union* of these topologies forms another topology (in graph 241 theoretic terms--a multigraph), termed the "IP routing fabric", of 242 the MANET. MANET nodes making routing decisions using the IP fabric 243 can intercommunicate using either or both physical-layer topologies 244 simultaneously. As new physical-layer technologies are developed, 245 new device drivers can be written and another physical-layer multihop 246 topology can be seamlessly added to the IP fabric. Likewise, older 247 technologies can easily be dropped. Such is the functionality and 248 architectural flexibility that IP-layer routing can support, which 249 brings with it hardware economies of scale. 251 The concept of a "router ID" (separate and apart from IP addressing) 252 is crucial to supporting the multigraph topology of the routing 253 fabric. It is what *unifies* a set of wireless IP interfaces (each 254 with their own IP address) and identifies them as belonging to the 255 same mobile platform. This approach permits maximum flexibility in 256 address assignment, and does not require that all IP addresses 257 attached to a given router fall under a common CIDR prefix. Router 258 IDs are used at the IP layer for routing computations. To enable IP 259 routing to hosts associated with the router, the subnet mask(s) 260 (encompassing the hosts on the mobile platform) should be advertised 261 with the router ID to permit routing table construction. 263 6. MANET Routing Protocol Performance Issues 265 To judge the merit of a routing protocol, one needs metrics--both 266 qualitative and quantitative--with which to measure its suitability 267 and performance. These metrics should be *independent* of any given 268 routing protocol. 270 The following is a list of desirable qualitative properties of manet 271 routing protocols. 273 1) Distributed operation: This is an essential property, but it 274 should be stated nonetheless. 276 2) Loop-freedom: Not required per se in light of certain 277 quantitative measures (performance criteria), but generally 278 desirable to avoid problems such as worst-case phenomena, e.g. a 279 small fraction of packets spinning around in the network for 280 arbitrary time periods. Ad hoc solutions such as TTL values can 281 bound the problem, but a more structured and well-formed approach 282 is generally desirable as it usually leads to better overall 283 performance. 285 3) Demand-based operation: Instead of assuming an uniform traffic 286 distribution within the network (and maintaining routing between 287 all nodes at all times), let the routing algorithm adapt to the 288 traffic pattern on a demand or need basis. If this is done 289 intelligently, it will utilize network energy and bandwidth 290 resources more efficiently. 292 4) Security: Without some form of network-level or link-layer 293 security, a MANET routing protocol is vulnerable to many forms of 294 attack. It may be relatively simple to snoop network traffic, 295 replay transmissions, manipulate packet headers, and redirect 296 routing messages, within a wireless network without appropriate 297 security provisions. While these concerns exist within wired 298 infrastructures and routing protocols as well, maintaining the 299 "physical" security of of the transmission media is harder in 300 practice with MANETs. Sufficient security protection to prohibit 301 disruption of modification of protocol operation is desired. This 302 may be somewhat orthogonal to any particular routing protocol 303 approach, e.g. through the application of IP Security techniques. 305 5) "Sleep" period operation: As a result of energy conservation, 306 or some other need to be inactive, nodes of a MANET may stop 307 transmitting and/or receiving (even receiving requires power) for 308 arbitrary time periods. A routing protocol should be able to 309 accommodate such sleep periods without overly adverse 310 consequences. This property may require close coupling with the 311 link-layer protocol through a standardized interface. 313 6) Unidirectional link support: Bidirectional links are typically 314 assumed in the design of routing algorithms, and many algorithms 315 are incapable of functioning properly over unidirectional links. 316 Nevertheless, unidirectional links can and do occur in wireless 317 networks. Oftentimes, a sufficient number of duplex links exist so 318 that usage of unidirectional links is of limited added value. 319 However, in situations where a pair of unidirectional links (in 320 opposite directions) form the only bidirectional connection 321 between two ad hoc clusters, the ability to make use of them is 322 valuable. 324 The following is a list of quantitative metrics that can be used to 325 assess the performance of any routing protocol. 327 1) End-to-end data throughput and delay: Statistical measures of 328 data routing performance (e.g., means, variances, distributions) 329 are important. These are the measures of a routing policy's 330 effectiveness--how well it does its job--as measured from the 331 *external* perspective of other policies that make use of routing. 333 2) Route Acquisition Time: A particular form of *external* end- 334 to-end delay measurement--of particular concern with "on demand" 335 routing algorithms--is the time required to establish route(s) 336 when requested. 338 3) Efficiency: If data routing effectiveness is the external 339 measure of a policy's performance, efficiency is the *internal* 340 measure of its effectiveness. To achieve a given level of data 341 routing performance, two different policies can expend differing 342 amounts of overhead, depending on their internal efficiency. 343 Protocol efficiency may or may not directly affect data routing 344 performance. If control and data traffic must share the same 345 channel, and the channel's capacity is limited, then excessive 346 control traffic often impacts data routing performance. 348 It is useful to track two ratios that illuminate the *internal* 349 efficiency of a protocol in doing its job (there may be others 350 that the authors have not considered): 352 * Average number of data bits transmitted/data bit delivered-- 353 this can be thought of as a measure of the efficiency of 354 delivering data within the network. 356 * Average number of control bits transmitted/data bit 357 delivered--this measures the efficiency of the protocol in 358 expending control overhead to delivery data packets. Note that 359 this should include not only the bits in the routing control 360 packets, but also the bits in the header of the data packets. 361 In other words, anything that is not data is control overhead, 362 and should be counted in the control portion of the algorithm. 364 Also, we must consider the networking *context* in which a protocol's 365 performance is measured. Essential parameters that should be varied 366 include: 368 1) Network size--measured in the number of nodes 370 2) Network connectivity--the average degree of a node (i.e. the 371 average number of neighbors of a node) 373 3) Topological rate of change--the speed with which a network's 374 topology is changing 376 4) Link capacity--effective link speed measured in bits/second, 377 after accounting for losses due to multiple access, coding, 378 framing, etc. 380 5) Fraction of unidirectional links--how effectively does a 381 protocol perform as a function of the presence of unidirectional 382 links? 384 6) Traffic patterns--how effective is a protocol in adapting to 385 non-uniform or bursty traffic patterns? 386 7) Mobility--when, and under what circumstances, is temporal and 387 spatial topological correlation relevant to the performance of a 388 routing protocol? In these cases, what is the most appropriate 389 model for simulating node mobility in a MANET? 391 8) Fraction and frequency of sleeping nodes--how does a protocol 392 perform in the presence of sleeping and awakening nodes? 394 A MANET protocol should function effectively over a wide range of 395 networking contexts--from small, collaborative, ad hoc groups to 396 larger mobile, multihop networks. The preceding discussion of 397 characteristics and evaluation metrics somewhat differentiate MANETs 398 from traditional, hardwired, multihop networks. The wireless 399 networking environment is one of scarcity rather than abundance, 400 wherein bandwidth is relatively limited, and energy may be as well. 402 In summary, the networking opportunities for MANETs are intriguing 403 and the engineering tradeoffs are many and challenging. A diverse 404 set of performance issues requires new protocols for network control. 405 A question which arises is "how should the *goodness* of a policy be 406 measured?". To help answer that, we proposed here an outline of 407 protocol evaluation issues that highlight performance metrics that 408 can help promote meaningful comparisons and assessments of protocol 409 performance. It should be recognized that a routing protocol tends 410 to be well-suited for particular network contexts, and less well- 411 suited for others. In putting forth a description of a protocol, both 412 its *advantages* and *limitations* should be mentioned so that the 413 appropriate networking context(s) for its usage can be identified. 414 These attributes of a protocol can typically be expressed 415 *qualitatively*, e.g., whether the protocol can or cannot support 416 shortest-path routing. Qualitative descriptions of this nature 417 permit broad classification of protocols, and form a basis for more 418 detailed *quantitative* assessments of protocol performance. In 419 future documents, the group may put forth candidate recommendations 420 regarding protocol design for MANETs. The metrics and the philosophy 421 presented within this document are expected to continue to evolve as 422 MANET technology and related efforts mature. 424 6. References 426 [1] B. Adamson, "Tactical Radio Frequency Communication Requirements for 427 IPng," RFC 1677, Aug. 1994. 429 Authors' Addresses 431 M. Scott Corson 432 Institute for Systems Research 433 University of Maryland 434 College Park, MD 20742 435 (301) 405-6630 436 corson@isr.umd.edu 438 Joseph Macker 439 Information Technology Division 440 Naval Research Laboratory 441 Washington, DC 20375 442 (202) 767-2001 443 macker@itd.nrl.navy.mil