RFC 2501

RFC 2501 🎀 Mobile Ad hoc Networking (MANET): Routing Protocol Performance Issues and Evaluation Considerations

okay bestie, title block tea 🫖 This one is a Network Working Group doc, filed as Informational 📚, so it's just sharing info and not setting a standard 🙅‍♀️. The authors are S. Corson (University of Maryland) and J. Macker (Naval Research Laboratory). It's dated January 1999 🗓️. The title block doesn't list anything it obsoletes or updates, so there's no drama there ✨.

---

Status of this Memo 💅

This memo gives info to the Internet community. It doesn't specify an Internet standard of any kind 🙅‍♀️. Distribution of this memo is unlimited 🌸.

Copyright Notice 🔒

Copyright (C) The Internet Society (1999). All Rights Reserved. 💜

Abstract 🦋

okay so the abstract is giving overview 🌈 It first describes what Mobile Ad hoc Networks (MANETs) are like, and how they're different from traditional, hardwired packet networks 🔌. Then it talks about how those differences change the way we design and evaluate network control protocols, with a big focus on how we evaluate routing performance 📊✨.

1. Introduction ✨

ngl this section is the setup 🧚 With recent performance upgrades in computers and wireless tech, advanced mobile wireless computing is about to get way more popular, and a lot of it will use the Internet Protocol (IP) suite 📱. The vision of mobile ad hoc networking is to keep things robust and efficient in mobile wireless networks by putting routing right into the mobile nodes 🛰️. These networks are expected to have dynamic, sometimes fast-changing, random, multihop topologies, probably built from wireless links with limited bandwidth 📉.

Inside the Internet community, routing support for mobile hosts is currently being developed as "mobile IP" technology 🌍. It supports nomadic host "roaming", where a roaming host might connect to the Internet in different ways instead of through its well-known fixed-address domain space 🧳. The host could be directly and physically plugged into the fixed network on a foreign subnet, or connected over a wireless link, dial-up line, and so on 🔗. Supporting this kind of host mobility (or nomadicity) takes address management, protocol interoperability upgrades, and more 🛠️. But core network functions like hop-by-hop routing still mostly rely on existing routing protocols running inside the fixed network 🏢. the goal of mobile ad hoc networking is different tho 💜 It's about pushing mobility into autonomous, mobile, wireless domains, where a group of nodes (which might be combined routers and hosts) form the network's routing infrastructure themselves, in an ad hoc way 👑.

2. Applications 🌸

this section is giving use cases 🍑 MANET tech is pretty much the same thing as Mobile Packet Radio Networking (a name that was coined during early military research in the 70s and 80s), Mobile Mesh Networking (a phrase from an Economist article about how future military networks might be structured), and Mobile, Multihop, Wireless Networking (probably the most accurate name, though kinda clunky) 📻.

There's a current and future need for dynamic ad hoc networking tech 🔥. The emerging field of mobile and nomadic computing, which is focused on mobile IP right now, should slowly expand and need highly adaptive mobile networking tech to manage multihop ad hoc network clusters. Those clusters can run on their own, or, more likely, be attached at one or more points to the fixed Internet 🌐.

MANET tech could be used for industrial and commercial stuff, like cooperative mobile data exchange 🏭. Mesh-based mobile networks can also run as sturdy, affordable alternatives to, or upgrades for, cell-based mobile network infrastructure 📶. There are also existing and future military networking needs for robust, IP-compliant data services inside mobile wireless communication networks [1], and many of these networks are made of highly dynamic, autonomous topology segments 🎖️. "Wearable" computing and communications might be another source of MANET applications 👓. When you combine MANET tech with satellite-based information delivery, it can be an super flexible way to set up communications for fire, safety, and rescue operations, or other situations that need quickly deployable, survivable, efficient dynamic networking 🚒. There are probably other MANET applications that the authors haven't imagined yet 🔮. Simply put, it's better IP-based networking for dynamic, autonomous wireless networks 💖.

3. Characteristics of MANETs 🦋

okay this part is the core vibes of what MANETs actually are 💅 A MANET is made of mobile platforms (for example, a router with multiple hosts and wireless comms devices). We'll just call these "nodes" 🧚. They can move around arbitrarily 🏃‍♀️. The nodes could be on airplanes, ships, trucks, cars, or maybe even on people or super tiny devices, and there can be multiple hosts per router 🚗. A MANET is an autonomous system of mobile nodes 🌈. It can run on its own, or it can have gateways and interface with a fixed network. When it's connected to a fixed network, it's usually expected to act like a "stub" network that hooks up to a fixed internetwork 🧩. Stub networks carry traffic that starts at or is headed to internal nodes, but they don't let outside traffic "transit" through them 🚫.

MANET nodes have wireless transmitters and receivers with antennas that can be omnidirectional (broadcast), highly directional (point-to-point), possibly steerable, or some mix of those 📡. At any moment, depending on where the nodes are, their coverage patterns, transmission power levels, and co-channel interference levels, there's a wireless connection in the form of a random, multihop graph (an "ad hoc" network) between the nodes 🕸️. This ad hoc topology can change over time as the nodes move or adjust their transmission and reception settings 🔄.

MANETs have a few salient characteristics 💎:

1. Dynamic topologies: Nodes can move arbitrarily, so the network topology (which is usually multihop) can change randomly and quickly at unpredictable times. It might have both bidirectional and unidirectional links 🌪️.
2. Bandwidth-constrained, variable capacity links: Wireless links will keep having way less capacity than their hardwired versions 🐢. Plus, the throughput you actually get from wireless comms, after counting things like multiple access, fading, noise, and interference, is often much less than a radio's maximum transmission rate 📉.

One result of these relatively low-to-moderate link capacities is that congestion is usually the norm, not the exception. That means total application demand will often approach or go over network capacity 🚦. Since the mobile network is often basically an extension of the fixed network infrastructure, mobile ad hoc users will want similar services 📲. These demands will keep rising as multimedia computing and collaborative networking apps get more popular 🎬.

3. Energy-constrained operation: Some or all of the nodes in a MANET may depend on batteries or other exhaustible sources of energy 🔋. For those nodes, energy conservation might be the most important system design criterion to optimize for 🌱.
4. Limited physical security: Mobile wireless networks are generally more open to physical security threats than fixed, cabled networks 😬. The higher chance of eavesdropping, spoofing, and denial-of-service attacks should be carefully considered 🚨. Existing link security techniques are often used in wireless networks to cut down on security threats 🔐. the good news 🌈 The decentralized nature of network control in MANETs gives extra robustness against the single points of failure you'd find in more centralized approaches 🫶.

In addition, some envisioned networks (like mobile military networks or highway networks) might be pretty large, with tens or hundreds of nodes per routing area 🛣️. Scalability isn't unique to MANETs 🤷‍♀️. But because of the characteristics above, the mechanisms needed to achieve scalability probably are 🙈.

These characteristics create a set of underlying assumptions and performance concerns for protocol design. Those go beyond what guides routing design in the faster, semi-static topology of the fixed Internet 🏎️.

4. Goals of IETF Mobile Ad Hoc Network (manet) Working Group 👑

this is the mission statement and it's giving main character energy 💖 The newly formed IETF manet working group wants to build a peer-to-peer mobile routing capability in a purely mobile, wireless domain 🎯. This capability is supposed to exist beyond the fixed network (as supported by traditional IP networking) and beyond the one-hop fringe of the fixed network 🌟.

The near-term goal of the manet working group is to standardize one (or more) intra-domain unicast routing protocol(s), along with related network-layer support tech, which:

• provides for effective operation over a wide range of mobile networking "contexts" (a context is a set of characteristics describing a mobile network and its environment) 🌍;
• supports traditional, connectionless IP service 📦;
• reacts efficiently to topological changes and traffic demands while keeping routing effective in a mobile networking context ⚡.

The working group will also look at issues about addressing, security, and interaction/interfacing with lower and upper layer protocols 🔍. In the longer term, the group may look at layering more advanced mobility services on top of the initial unicast routing that gets developed 🪜. These longer-term issues will likely include looking into multicast and QoS extensions for a dynamic, mobile area 🚀.

5. IP-Layer Mobile Routing ✨

okay so bestie, this is where the original Internet's whole vibe comes back: "an interoperable internetworking capability over a heterogeneous networking infrastructure" 🌈. The twist is that the infrastructure here is wireless instead of hardwired, and it's a mix of multiple wireless technologies, channel access protocols, etc. 💅 Better IP routing and related networking services are the glue that keeps the mobile internetwork segment intact in this more dynamic environment 🫶.

In other words, the real benefit of using IP-level routing in a MANET is network-level consistency for multihop networks made of nodes using a mixture of physical-layer media 🦋, i.e. a mixture of what people usually call subnet technologies. A MANET node is mainly a router 🎀. It may be physically attached to multiple IP hosts (or IP-addressable devices), and it has potentially multiple wireless interfaces, each one using a different wireless technology. So a MANET node with interfaces using technologies A and B can communicate with any other MANET node that has an interface with technology A or B 🔥. The multihop connectivity of technology A forms a physical-layer multihop topology, and the multihop connectivity of technology B forms another physical-layer topology (which may differ from A's topology) 👑. The union of these topologies forms yet another topology (graph-theory-wise, a multigraph) called the "IP routing fabric" of the MANET 🧚. MANET nodes making routing decisions using the IP fabric can intercommunicate over either or both physical-layer topologies simultaneously ✨. New physical-layer technologies can be developed, new device drivers can be written, and another physical-layer multihop topology can be seamlessly added to the IP fabric 🍓. Older technologies can easily be dropped too 💀. That's the functionality and architectural flexibility IP-layer routing can support, and it brings hardware economies of scale 🌸.

The concept of a "node identifier" (separate and apart from the concept of an "interface identifier") is crucial to supporting the multigraph topology of the routing fabric 💜. It's what unifies a set of wireless interfaces and identifies them as belonging to the same mobile platform 🫶. This approach permits maximum flexibility in address assignment 🌷. Node identifiers are used at the IP layer for routing computations 💖.

5.1. Interaction with Standard IP Routing

In the near term, MANETs are envisioned to function as stub networks, meaning that all traffic carried by MANET nodes will either be sourced or sinked within the MANET 🙈. Because of bandwidth and possibly power constraints, MANETs are not presently envisioned to function as transit networks carrying traffic which enters and then leaves the MANET (although this restriction may be removed by subsequent technology advances) 😭. This substantially reduces the amount of route advertisement required for interoperation with the existing fixed Internet ✨. For stub operation, routing interoperability in the near term may be achieved using some combination of mechanisms such as MANET-based anycast and mobile IP 🦋. Future interoperability may be achieved using mechanisms other than mobile IP 🌈.

Interaction with Standard IP Routing will be greatly facilitated by usage of a common MANET addressing approach by all MANET routing protocols 🎀. Development of such an approach is underway. It permits routing through a multi-technology fabric, permits multiple hosts per router, and ensures long-term interoperability through adherence to the IP addressing architecture 👑. Supporting these features appears only to require identifying host and router interfaces with IP addresses, identifying a router with a separate Router ID, and permitting routers to have multiple wired and wireless interfaces 💅.

6. MANET Routing Protocol Performance Issues ✨

okay bestie, so how do we even judge whether a MANET routing protocol is any good? 🧐 we need metrics, both qualitative (the vibes-and-properties kind) and quantitative (the numbers kind) 📊, and they should be independent of any single routing protocol so we can compare apples to apples 🍎 fr fr.

here's the list of desirable qualitative properties 💅:

1. Distributed operation: this one is essential 👑, and it still deserves to be said out loud because it's the foundation of everything else 🫶.
2. Loop-freedom: this isn't strictly required, not with certain quantitative measures in the picture 🤷‍♀️, but it's generally desirable 💖. the nightmare scenario is a small fraction of packets spinning around the network forever 😭. TTL values can put a cap on that mess, but a more structured, well-formed approach usually gives better overall performance ✨ (ngl that's the iconic move 💅).
3. Demand-based operation: instead of assuming traffic is uniform everywhere and keeping routes alive between every pair of nodes at all times 🙅‍♀️, let the routing algorithm adapt to the traffic pattern based on demand or need 🦋. done intelligently, this saves network energy and bandwidth 🔋, but the tradeoff is increased route discovery delay ⏳.
4. Proactive operation: the flip-side of demand-based 🪞. in some contexts that extra latency is a no-go 🙈, and if bandwidth and energy resources allow, proactive operation is the way to go in those spots 🌸.
5. Security: without some form of network-level or link-layer security, a MANET routing protocol is super vulnerable 💀. snooping traffic, replaying transmissions, manipulating packet headers, and redirecting routing messages are all easy on a wireless network without proper protections 😱. wired networks have these worries too, but keeping the "physical" security of the transmission media is way harder with MANETs 🥺. sufficient security is needed to stop anyone from disrupting or modifying how the protocol works 🛡️. this may be somewhat orthogonal to the specific routing approach, for example by applying IP Security techniques 🔐.
6. "Sleep" period operation: nodes can stop transmitting and/or receiving for arbitrary periods 😴, whether to save energy or for some other reason to be inactive 🔋 (and yes, even receiving costs power 🙃). a routing protocol should handle those sleep periods without getting badly messed up 🧚. this may need close coupling with the link-layer protocol through a standardized interface 🎀.
7. Unidirectional link support: most routing algorithms assume links are bidirectional 🙄, and lots of them just can't work over one-way links 💔. but unidirectional links do happen in wireless networks 📡. usually there are enough duplex links that one-way ones add only limited value 🤷‍♀️. however, if a pair of unidirectional links in opposite directions is the only bidirectional connection between two ad hoc regions, being able to use them is hugely valuable 🌈.

the following is a list of quantitative metrics that can assess the performance of any routing protocol 📊✨:

1. End-to-end data throughput and delay: statistical measures (means, variances, distributions) matter here 💅. these measure how well a routing policy does its job, from the external perspective of the other policies that use routing 🎯.
2. Route Acquisition Time: a special flavor of external end-to-end delay 🕰️, which is especially important for "on demand" routing algorithms ⏱️. it's the time needed to establish route(s) when they're requested 🙌.
3. Percentage Out-of-Order Delivery: an external measure of connectionless routing performance 📦. it's a big deal for transport layer protocols like TCP, which really prefer in-order delivery 🥹.
4. Efficiency: if data routing effectiveness is the external measure, efficiency is the internal one 🧠. two policies can spend different amounts of overhead to reach the same data routing performance, depending on how efficient they are internally 🔍. protocol efficiency may or may not directly affect data routing performance 🤔. if control and data traffic share one channel with limited capacity, though, excessive control traffic often hurts data routing performance 💀.

it's useful to track several ratios that show the internal efficiency of a protocol 📐 (there may be others the authors didn't think of 🤓):

• Average number of data bits transmitted/data bit delivered: this is the bit efficiency of delivering data within the network 📦. indirectly, it also tells you the average hop count taken by data packets 🦘.
• Average number of control bits transmitted/data bit delivered: this measures how efficiently the protocol spends control overhead to deliver data 🎁. note that this should count not only the bits in routing control packets, but also the bits in the header of the data packets 👀. literally anything that isn't data is control overhead, and it should be counted in the control portion 💅.
• Average number of control and data packets transmitted/data packet delivered: instead of pure algorithmic efficiency in bit counts, this one captures a protocol's channel access efficiency 📻, since channel access is expensive on contention-based link layers 💸.

also, we have to think about the networking context the protocol is measured in 🌍. these essential parameters should be varied 🎛️:

1. Network size, measured in the number of nodes 🐣
2. Network connectivity, the average degree of a node (the average number of neighbors) 🤝
3. Topological rate of change, how fast the network's topology is changing 🌪️
4. Link capacity, the effective link speed in bits/second after accounting for losses from multiple access, coding, framing, etc. 📶
5. Fraction of unidirectional links: how well does a protocol perform depending on how many one-way links there are? 🧐
6. Traffic patterns: how well does a protocol adapt to non-uniform or bursty traffic 💥?
7. Mobility: when and under what circumstances does temporal and spatial topological correlation matter for routing performance 🗺️? and in those cases, what's the most appropriate model for simulating node mobility in a MANET 🎬?
8. Fraction and frequency of sleeping nodes: how does a protocol cope with nodes that are sleeping and waking up 😴⏰?

a MANET protocol should work effectively across a wide range of networking contexts 🌐, from small collaborative ad hoc groups all the way up to bigger mobile multihop networks 🚀. the characteristics and metrics we've covered do set MANETs apart from traditional hardwired multihop networks 🔀. wireless is a world of scarcity, not abundance 🏜️: bandwidth is relatively limited, and energy may be too 🪫.

in summary, the networking opportunities for MANETs are intriguing 🤩, and the engineering tradeoffs are many and challenging 🧗‍♀️. a diverse set of performance issues calls for new protocols for network control 🎀.

a question that comes up is "how should the goodness of a policy be measured?" 🤔 to help answer that, this section outlined protocol evaluation issues and performance metrics that can support meaningful comparisons 📈. it's worth remembering that a routing protocol tends to suit particular network contexts better than others 🫵. when describing a protocol, both its advantages and limitations should be mentioned so people can tell which contexts it fits 🧩. these attributes can usually be expressed qualitatively, like whether the protocol can or cannot support shortest-path routing 🛣️. qualitative descriptions allow broad classification of protocols and form the basis for more detailed quantitative assessments 📋. in future documents, the group may put forward candidate recommendations for MANET protocol design 🔮. the metrics and philosophy in this document are expected to keep evolving as MANET technology and related efforts mature 🌱✨.

---

7. Security Considerations 🔐

okay this one is SERIOUS bestie 😤🚨. mobile wireless networks are generally more prone to physical security threats than fixed, hardwired networks 📡💀. existing link-level security techniques (like encryption) are often applied in wireless networks to reduce these threats 🔒. without link-level encryption, the most pressing network-layer issue is inter-router authentication before any network control information gets exchanged 🫣. the group will explore several levels of authentication, from no security (always an option 🙃) and simple shared-key approaches all the way up to full public key infrastructure-based authentication mechanisms 🗝️. as a side project to the working group's efforts, several optional authentication modes may be standardized for use in MANETs 🎀💅.

---

8. References 📚

[1] Adamson, B., "Tactical Radio Frequency Communication Requirements for IPng", RFC 1677, August 1994.

Authors' Addresses 🖋️

M. Scott Corson Institute for Systems Research University of Maryland College Park, MD 20742

Phone: (301) 405-6630 EMail: corson@isr.umd.edu

Joseph Macker Information Technology Division Naval Research Laboratory Washington, DC 20375

Phone: (202) 767-2001 EMail: macker@itd.nrl.navy.mil

Full Copyright Statement 💖

Copyright (C) The Internet Society (1999). All Rights Reserved. 🎀

okay bestie, so the Internet Society owns this doc, but they're basically letting us share it around 🫶 You can copy it and pass it to people, and you can make derivative works that comment on it, explain it, or help people implement it. You can publish and distribute those too, in whole or in part, with no restrictions of any kind. The one thing is that the copyright notice and this paragraph have to stay on every copy and every derivative work ✨

BUT the original document itself? Hands off 🙅‍♀️ You can't modify it in any way, like deleting the copyright notice or the references to the Internet Society or other Internet organizations. The exceptions are when you need it for developing Internet standards (then you have to follow the copyright procedures defined in the Internet Standards process 📜), or when you're translating it into a language other than English 🌍

These permissions are perpetual, which means they're forever 💜 The Internet Society or its successors or assigns can't revoke them, so you're good. 🦋

And now the boring-but-important disclaimer, which I'm keeping word for word because legal stuff hits different in caps 😭

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Basically, the doc comes as-is, and the Internet Society and the IETF are not promising anything beyond that, including that using the info won't infringe anyone's rights or that it'll be merchantable or fit for a particular purpose. Not giving any warranties is the most iconic plot twist 💀🌸