idnits 2.17.1 draft-ietf-manet-issues-00.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-29) 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 == It seems as if not all pages are separated by form feeds - found 0 form feeds but 9 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** 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. ** There is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. 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 (September 1997) is 9692 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 391, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1677 (ref. '1') Summary: 12 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft S. Corson 2 Expiration: March 1998 University of Maryland 3 File: draft-ietf-manet-issues-00.txt J. Macker 4 Naval Research Laboratory 5 September 1997 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 the 23 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 24 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), 25 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 26 ftp.isi.edu (US West Coast). 28 Distribution of this memo is unlimited. 30 Summary 32 This memo describes the concept of mobile ad hoc networking--giving a 33 rationale for its existence and outlining the unique issues and 34 challenges found in this form of purely wireless, mobile networking. 36 1. Introduction 38 With recent performance advancements in computer and wireless 39 communications technologies, advanced mobile wireless computing is 40 expected to see increasingly widespread use and application, much of 41 which will involve the use of the Internet Protocol (IP) suite. The 42 vision of mobile ad hoc networking is to support robust and efficient 43 operation in mobile wireless networks by incorporating routing 44 functionality into mobile nodes. Such networks are envisioned to 45 have dynamic, sometimes rapidly-changing, random, multihop topologies 46 which are likely composed of relatively bandwidth-constrained 47 wireless links. 49 ^L 50 Within the Internet community, routing support for mobile hosts is 51 presently being formulated as "mobile IP" technology. This is a 52 technology to support nomadic host "roaming", where a roaming host 53 may be connected through various means to the Internet other than its 54 well known fixed-address domain space. The host may be directly 55 physically connected to the fixed network on a foreign subnet, or be 56 connected via a wireless link, dial-up line, etc. Supporting this 57 form of host mobility (or nomadicity) requires address management, 58 protocol interoperability enhancements and the like, but core network 59 functions such as hop-by-hop routing still presently rely upon pre- 60 existing routing protocols operating within the fixed network. In 61 contrast, the goal of mobile ad hoc networking is to extend mobility 62 into the realm of autonomous, mobile, wireless domains, where the 63 nodes themselves form the network routing infrastructure in an ad hoc 64 fashion. 66 This memo first describes the characteristics of Mobile Ad hoc 67 Networks (MANETs), and their idiosyncrasies with respect to 68 traditional, hardwired packet networks. It then discusses the effect 69 these differences have on the design and evaluation of network 70 control protocols with an emphasis on routing. 72 2. Applications 74 The technology of Mobile Ad hoc Networking is somewhat synonomous 75 with Mobile Packet Radio Networking (a term coined via during early 76 military research in the 70's and 80's), Mobile Mesh Networking (a 77 term that appeared in an article in The Economist regarding the 78 structure of future military networks) and Mobile, Multihop, Wireless 79 Networking (perhaps the most accurate term, although a bit 80 cumbersome). 82 There is current and future need for dynamic ad hoc networking 83 technology. The emerging field of mobile and nomadic computing, with 84 its current emphasis on mobile IP operation, should gradually broaden 85 and require highly adaptive mobile networking technology to 86 effectively manage multihop, ad hoc network clusters which can 87 operate autonomously or, more than likely, be attached at some 88 point(s) to the fixed Internet. 90 Some applications of MANET technology could include industrial and 91 commercial applications involving cooperative mobile data exchange. 92 In addition, mesh-based mobile networks can be operated as robust, 93 inexpensive alternatives or enhancements to cell-based mobile network 94 infrastructures. There are also existing and future military 95 networking requirements for robust, IP-compliant data services within 96 mobile wireless communication networks [1]--many of these networks 97 consist of highly-dynamic autonomous topology segments. Also, the 99 ^L 100 developing technologies of "wearable" computing and communications 101 may provide applications for MANET technology. When properly combined 102 with satellite-based information delivery, MANET technology can 103 provide an extremely flexible method for establishing communications 104 for fire/safety/rescue operations or other scenarios requiring 105 rapidly-deployable communications with survivable, efficient dynamic 106 networking. There are likely other applications for MANET technology 107 which are not presently realized or envisioned by the authors. It 108 is, simply put, efficient IP-based routing technology for highly 109 dynamic, autonomous wireless networks. 111 3. Characteristics of MANETs 113 A MANET consists of mobile platforms (combined router, host and 114 wireless communications platforms)--herein simply referred to as 115 "nodes"--which are free to move about arbitrarily. The nodes may be 116 located in or on airplanes, ships, trucks, cars, perhaps even on 117 people, and there may be multiple hosts per router. A MANET is an 118 autonomous system of mobile nodes. The system may operate in 119 isolation, or may have gateways to and interface with a fixed 120 network--typically envisioned to operate as a stub network connecting 121 to a fixed internetwork. 123 The nodes are equipped with wireless transmitters and receivers using 124 antennas which may be omnidirectional (broadcast), highly-directional 125 (point-to-point) or some combination thereof. At a given point in 126 time, depending on the nodes' positions and their transmitter and 127 receiver coverage patterns, transmission power levels and cochannel 128 interference levels, a wireless connectivity in the form of a random, 129 multihop graph or "ad hoc" network exists between the nodes. This ad 130 hoc topology may change with time as the nodes move or adjust their 131 transmission and reception parameters. 133 MANETs have several salient characteristics: 135 1) Dynamic topologies: Nodes are free to move arbitrarily; thus, 136 the network topology--which is typically multihop--may change 137 randomly and rapidly at unpredictable times, and may consist of 138 both bidirectional and unidirectional links. 140 2) Bandwidth-constrained, variable capacity links: Wireless links 141 will continue to have significantly lower capacity than their 142 hardwired counterparts. In addition, the realized throughput of 143 wireless communications--after accounting for the effects of 144 multiple access, fading, noise, and interference conditions, 145 etc.--is often very much less than a radio's maximum transmission 146 rate. 148 ^L 149 One effect of the relatively low to moderate link capacities is 150 that congestion is typically the norm rather than the exception, 151 i.e. aggregate application demand will likely approach or exceed 152 network capacity frequently. As the mobile network is often simply 153 an extension of the fixed network infrastructure, mobile ad hoc 154 users will demand similar services. These demands will continue to 155 increase as multimedia computing and collaborative networking 156 applications rise. 158 3) Power-constrained operation: Some or all of the nodes in a 159 MANET may rely on batteries for their energy. For these nodes, the 160 most important system design criteria for optimization may be 161 power conservation. 163 4) Limited physical security: Mobile wireless networks are 164 generally more prone to physical security threats than are fixed- 165 cable nets. The increased possibility of eavesdropping, spoofing, 166 and denial of service attacks should be carefully considered. 167 Existing link security techniques are often applied within 168 wireless network to reduce security threats. As a benefit, the 169 decentralized nature of network control in MANETs provides 170 additional robustness against single points of failure of more 171 centralized approaches. 173 In addition, some envisioned networks (e.g. mobile military networks 174 or highway networks) may be relatively large (e.g. tens or hundreds 175 of nodes per routing area). The need for scalability is not unique 176 to MANETS. However, in light of the preceding characteristics, the 177 mechanisms required to achieve scalability likely are. 179 These characteristics create a set of underlying assumptions and 180 performance concerns for protocol design which extend beyond those 181 guiding the design of routing within the higher-speed, semi-static 182 topology of the fixed Internet. 184 4. Goals of IETF Mobile Ad Hoc Network (manet) Working Group 186 The intent of the newly formed IETF manet working group is to develop 187 a peer-to-peer mobile routing capability in a purely mobile, wireless 188 domain. This capability will exist beyond the fixed network (as 189 supported by traditional IP networking) and beyond the one-hop fringe 190 of the fixed network. 192 The near-term goal of the manet working group is to standardize an 193 intra-domain unicast routing protocol which: 195 * provides a mode(s) of operation for effective operation in a 196 mobile networking "context". (a context is a set of defined 198 ^L 199 networking characteristics), 201 * provides a standard "mode discovery" protocol so that newly- 202 arriving nodes may learn the mode in which a given MANET is 203 operating, 205 * supports traditional, connectionless IP service, 207 * reacts efficiently to topological changes while maintaining 208 effective routing in a mobile networking context. 210 The working group will also address issues pertaining to security and 211 interaction/interface with link-layer protocols and internet security 212 protocols. In the longer term, the group may look at the issues of 213 layering more advanced mobility services on top of the initial 214 unicast routing developed. These longer term issues will likely 215 include investigating multicast and QoS extensions for a dynamic, 216 mobile area. 218 5. Why an IP-Layer Routing Solution? 220 A solution at the IP layer can provide a benefit similar to the 221 intention of the original Internet, viz. "an interoperable 222 internetworking capability over a heterogeneous networking 223 infrastructure". In this case, the infrastructure is wireless, rather 224 than hardwired, consisting of multiple wireless technologies, channel 225 access protocols, etc. Improved IP routing and related networking 226 services provide the glue to preserve the integrity of the mobile 227 internetwork segment in this more dynamic environment. 229 6. MANET Routing Protocol Performance Issues 231 To judge the merit of a routing protocol, one needs metrics--both 232 qualitative and quantitative--with which to measure its suitability 233 and performance. These metrics should be somewhat *independent* of 234 any given routing protocol. 236 The following is a list of desirable qualitative properties: 238 1) Distributed operation: This is an essential property, but it 239 should be stated nonetheless. 241 2) Loop-freedom: Not required per se in light of certain 242 quantitative measures (performance criteria), but generally 243 desirable to avoid problems such as worst-case phenomena, e.g. a 244 small fraction of packets spinning around in the network for 245 arbitrary time periods. Ad hoc solutions such as TTL values can 246 bound the problem, but a more structured and well-formed approach 248 ^L 249 is generally desirable as it oftentimes leads to better overall 250 performance. 252 3) Demand-based operation: Instead of assuming uniform traffic 253 distribution within the network (and maintaining routing between 254 all nodes at all times), let the routing algorithm adapt to the 255 traffic pattern on a demand or need basis. If this is done 256 intelligently, it will utilize network resources more efficiently. 258 4) Unidirectional link support: Bidirectional links are typically 259 assumed in the design of routing algorithms, and many algorithms 260 are incapable of functioning properly over unidirectional links. 261 Nevertheless, unidirectional links can and do occur in wireless 262 networks. Often times, a sufficient number of duplex links exist 263 so that usage of unidirectional links is of limited added value. 264 However, in situations where a pair of unidirectional links (in 265 opposite directions) form the *only* bidirectional connection 266 between two ad hoc clusters, the ability to make use of them is 267 invaluable. 269 5) Security: Without some form of network-level security or link 270 layer security, a MANET routing protocol is vulnerable to many 271 forms of attack. It may be relatively simple to snoop network 272 traffic, replay transmissions, manipulate packet headers, and 273 redirect routing messages, within a wireless network without 274 appropriate security provisions. While these concerns exist within 275 wired infrastructures and routing protocols as well, maintaining 276 the "physical" security of of the transmission media is harder in 277 practice with MANETs. Sufficient security protection to prohibit 278 distruption of modification of protocol operation is desired. 279 This may be somewhat orthogonal to any particular routing protocol 280 approach, e.g. through the application of IP Security techniques. 282 6) "Sleep" period operation: As a result of power conservation, 283 or some other need to be inactive, nodes of a MANET may stop 284 transmitting and/or receiving (even receiving requires power) for 285 arbitrary time periods. A routing protocol should be able to 286 accomodate such sleep periods without overly adverse consequences. 287 This property may require close coupling with the link layer 288 protocol through a standardized interface. 290 The following is a list of quantitative metrics that can be used to 291 assess the performance of any routing protocol. 293 1) End-to-end data throughput and delay: Statistical measures of 294 data routing performance (e.g., means, variances, distributions) 295 are important. These are the measures of a routing policy's 297 ^L 298 effectiveness--how well it does its job--as measured from the 299 *external* perspective of other policies that make use of routing. 301 2) Efficiency: If data routing effectiveness is the external 302 measure of a policy's performance, efficiency is the *internal* 303 measure of its effectiveness. To achieve a given level of data 304 routing performance, two different policies may expend differing 305 amounts of overhead, depending on their internal efficiency. 306 Protocol efficiency may or may not directly affect data routing 307 performance. If control and data traffic must share the same 308 channel, and the channel's capacity is limited, then excessive 309 control traffic may impact data routing performance. 311 It is useful to track two ratios that illuminate the *internal* 312 efficiency of a protocol in doing its job (there may be others 313 that the authors have not considered): 315 * Average number of data bits transmitted/data bit delivered-- 316 this can be thought of as a measure of the efficiency of 317 delivering data within the network. 319 * Average number of control bits transmitted/data bit 320 delivered--this measures the efficiency of the protocol in 321 expending control overhead to delivery data packets. Note that 322 this should include not only the bits in the routing control 323 packets, but also the bits in the header of the data packets. 324 In other words, anything that is not data is control overhead, 325 and should be counted in the control portion of the algorithm. 327 Also, we must consider the networking *context* in which a protocol's 328 performance is measured. Essential parameters that should be varied 329 include: 331 1) Network size--measured in the number of nodes 333 2) Network connectivity--the average degree of a node (i.e. the 334 average number of neighbors of a node) 336 3) Topological rate of change--the speed with which a network's 337 topology is changing 339 4) Link capacity--effective link speed measured in bits/second, 340 after accounting for losses due to multiple access, coding, 341 framing, etc. 343 5) Fraction of unidirectional links--how effectively does a 344 protocol perform as a function of the presence of unidirectional 345 links? 347 ^L 348 6) Traffic patterns--how effective is a protocol in adapting to 349 non-uniform or bursty traffic patterns? 351 7) Mobility--when, and under what circumstances, is temporal and 352 spatial topological correlation relevant to the performance of a 353 routing protocol? In these cases, what is the most appropriate 354 model for simulating node mobility in a MANET? 356 8) Fraction and frequency of sleeping nodes--how does a protocol 357 perform in the presence of sleeping and awakening nodes? 359 A MANET protocol should function effectively over a wide range of 360 networking contexts--from small, collaborative, ad hoc groups to 361 larger mobile, multihop networks. The preceding discussion of 362 characteristics and evaluation metrics somewhat differentiate MANETs 363 from traditional, hardwired, multihop networks. The wireless 364 networking environment is one of scarcity rather than abundance, 365 wherein bandwidth is relatively limited, and energy may be as well. 367 In summary, the networking opportunities for MANETs are intriguing 368 and the engineering tradeoffs are many and challenging. A diverse 369 set of performance issues requires new protocols for network control. 370 A question which arises is "how should the *goodness* of a policy be 371 measured?". To help answer that, we proposed here an outline of 372 protocol evaluation issues that highlight performance metrics that 373 can help promote meaningful comparisons and assessments of protocol 374 performance. It should be recognized that a routing protocol tends 375 to be well-suited for particular network contexts, and less well- 376 suited for others. In putting forth a description of a protocol, both 377 its *advantages* and *limitations* should be mentioned so that the 378 appropriate networking context(s) for its usage can be identified. 379 These attributes of a protocol can typically be expressed 380 *qualitatively*, e.g., whether the protocol can or cannot support 381 shortest-path routing. Qualitative descriptions of this nature 382 permit broad classification of protocols, and form a basis for more 383 detailed *quantitative* assessments of protocol performance. In 384 future documents, the group may put forth candidate recommendations 385 regarding protocol design for MANETs. The metrics and the philosophy 386 presented within this document are expected to continue to evolve as 387 MANET technology and efforts mature. 389 6. References 391 [1] B. Adamson, "Tactical Radio Frequency Communication Requirements for 392 IPng," RFC 1677, Aug. 1994. 394 Authors' Addresses 396 ^L 397 M. Scott Corson 398 Institute for Systems Research 399 University of Maryland 400 College Park, MD 20742 401 (301) 405-6630 402 corson@isr.umd.edu 404 Joseph Macker 405 Information Technology Division 406 Naval Research Laboratory 407 Washington, DC 20375 408 (202) 767-2001 409 macker@itd.nrl.navy.mil 411 ^L